Defender for Servers Plan 2 now integrates with Defender for Endpoint unified solution
Today, we're excited to announce the release of Microsoft Defender for Endpoint’s unified agent integration with Microsoft Defender for Servers Plan 2. With this release, we align the integration experience between Microsoft Defender for Endpoint and both Microsoft Defender for Servers Plans.How to Effectively Perform a Microsoft Defender for Cloud PoC
[Post updated on 06/27/2024] Introduction Organizations are starting to realize that they need to closely monitor their cloud security posture and protect cloud workloads against threats. At the same time, they need to do this without creating silos across different solutions. Cloud Native Application Protection Platform (CNAPP) bring the capabilities from Cloud Security Posture Management (CSPM), Cloud Workload Protection (CWP), in addition to many other platforms in a single place. To learn more about Defender for Cloud as your CNAPP solution, we recommend you use the resources below: Improving Your Multi-Cloud Security with a CNAPP - a vendor agnostic approach Microsoft CNAPP Solution Planning and Operationalizing Microsoft CNAPP Understanding Cloud Native Application Protection Platforms (CNAPP) Cloud Native Applications Protection Platform (CNAPP) Microsoft CNAPP eBook Understanding CNAPP To effectively determine the benefits of adopting Microsoft Defender for Cloud, you should perform a Proof of Concept (PoC). Even before enabling enable Microsoft Defender for Cloud in your subscription and start validating your scenarios, you should go through a planning process to determine a series of tasks that must be accomplished in this PoC. Planning Each Phase Use following schedule to perform their Microsoft Defender for Cloud PoC. Keep in mind that this is an example, and each organization may adequate this according to their needs. The sections that follow will explain each phase in more details. Planning During the planning phase you will organize a meeting with key stakeholders of this PoC. At minimum, you should have representatives from IT (mainly the ones that are responsible for your Cloud workloads), Security Operations, and Security Governance. The intent of this phase is to determine the answers for the following items: Scope of the PoC: what are you going to validate on this PoC? What scenarios do you want to test? Requirements: based on the scope, you can start determining the requirements for this PoC. This includes at least the following items: Determine if the type of deployment: single cloud (Azure) or multi-cloud. For AWS considerations, read this article. For GCP considerations, read this article. Determine which users should have administrative and read access to the subscriptions that Microsoft Defender for Cloud will be enabled. Use this article as a reference to review the roles (RBAC) available for Microsoft Defender for Cloud. Determine if you need policy centralized management for Microsoft Defender for Cloud, and use the best practices from this article. If you are going to use multiple subscriptions, define the workspace model (centralized or distributed). In Microsoft Defender for Cloud, this is defined using the Data Collection tier, visit this article for more information about the options available. In the same Data Collection option, define if you are going to use Auto Provision or not. By using auto provision, the MMA agent will be automatically installed in the VMs that are under the selected subscription (preferred option). If you are going to use multiple subscriptions, consider using Management Group to manage Security Policy across all subscriptions. For more information about this, read this article. If you are going to use multiple subscriptions and want to automate the onboarding process, use the PowerShell examples described in this article. If you need to prioritize security recommendations based on risk factors, and disrupt potential attack before it happens, consider enabling Defender CSPM. If you need to create governance rules to assign to workload owners and establish SLA to remediate recommendations, consider enabling Defender CSPM and use the governance feature. Define which resources will be monitored during the PoC to define which Microsoft Defender for Cloud plans you need to enable: Note: you can enable any of the Microsoft Defender for Cloud plans for 30 days free trial. Determine which PaaS workloads will be tested. Use this article to determine which PaaS workloads are supported by Microsoft Defender for Cloud. Define which VMs will be available through the Internet (via RDP or SSH) to test functionalities such as JIT VM Access, Network Map and Network Hardening. Determine the Operating System for the VMs that will be deployed for this PoC. Use this article to obtain the list of supported operating systems. These VMs can be in Azure, or on-premises. Take in considerations different scenarios for recommendations, such as: Validate scenarios where you need to exempt resources from recommendations. Use this article to learn how to create exemptions. Validate scenarios where you need to disable a recommendation that is not applicable to your scenario. Read this article for more information on how to perform this task. Validate scenarios where you need to automate a response for a recommendation. You can use the Workflow Automation feature to accomplish that. Measure success: this is something very important to establish before starting your PoC, because this will help you to set the right expectation and based on that expectation, measure if your PoC was a success or not. At the end of this phase you have the first checkpoint (A). On this checkpoint you should document the following items: Scope of the PoC, the requirements, timeline and the decision of how you will measure success. Next steps of the PoC If there are requirements that needs to be in place before the implementation, these requirements must be listed and planned for implementation The timeline for implementation of those requirements needs to be established Preparation This phase will focus on the implementation of the requirements. When going through those requirements, make sure to document everything that needs to be changed in the environment. One classic example is when the members of the Team that are implementing Microsoft Defender for Cloud don’t have the right level of permission in all subscriptions. This can cause delays if the team that is implementing Microsoft Defender for Cloud is not the same team that manages Azure Identity. For this reason, it becomes critical to involve the right stakeholders since the planning phase. At the end of this phase, you have the second checkpoint (B). On this checkpoint you should document the following items: Changes that were performed in the environment to adequate with the PoC requirements. Define when the implementation phase will start This is critical because once you enable Microsoft Defender for Cloud, you have 30 days free trial, and you should ensure that you utilize those days to validate all scenarios. You can also use the cost estimation workbook to estimate how much each plan will cost based on the resources you have in the subscription. Define who the workload owners are. Many times, the team that manage Microsoft Defender for Cloud do not have privileges to remediate recommendations in different workloads. For example, recommendations to remediate vulnerabilities in SQL Database might be something that the team that manages Microsoft Defender for Cloud can't do it, therefore it is imperative to involve the workload owners. Implementation and validation Now you can enable the Defender for Cloud enhanced security features, and once you do that the next step is the implementation of the scenarios that you established during the planning phase. Here are the most common scenarios that are covered during a PoC: Scenario 1: Security Posture Management If you decide to try the Foundational CSPM (free tier) you can immediately start testing the following scenarios: Ensure that you are driving your secure score up by addressing the recommendations raised by Microsoft Defender for Cloud. Use this article for more information about Secure Score. To drive your secure score up, you need to review security recommendations for the different workloads and follow the remediation steps to address them. Use the Workflow Automation feature to create automations for recommendations. You can test to send recommendation to workload owners using instructions from this article. If you want to validate advanced cloud security posture management feature, you will need to enable Defender CSPM. If that's the case, use this DCSPM POC article. Scenario 2: Reducing the Attack Surface Enable JIT VM access for Internet facing VMs and test the functionality. Use this article as a reference to perform the configuration/validation and watch this video to understand how JIT helps to reduce the attack surface. Use Adaptive Application Control to review the list of apps that should be allowed. Use this article as a reference to understand and implement this feature. Scenario 3: Threat Detection & Response Enable File Integrity Monitoring in your workspace to track changes to files and registry keys. Use this article as a reference to configure this feature. You can use the following guides to simulate attacks against the VMs and see how Microsoft Defender for Server will trigger Security Alerts: For Windows For Linux If you are validating threat detection for PaaS workloads such as Containers, Azure Key Vault, Storage and SQL, visit this page and select the scenario that you want to validate. Try to suppress alerts that are considered false positive for your environment using the Alert Suppression feature. Validate the integration of Microsoft Defender for Cloud with Microsoft Defender for Endpoint (MDE) using the instructions from this article. Configure SIEM integration (optional): if you need to validate SIEM integration, visit this site for more information about supported SIEM platforms. Create workflow automation using Playbooks to run once you receive an alert. You can use the examples below as a reference: Automate Microsoft Defender for Cloud actions with Playbooks and ServiceNow Microsoft Defender for Cloud & automatic creation of an incident in ServiceNow At the end of this phase, you have the third checkpoint (C). On this checkpoint you should document the following items: Each scenario that was tested and its results The learnings from each scenario. These learning can be used to determine if you foresee any roadblock that can delay the Microsoft Defender for Cloud adoption in the production environment and how to overcome those If you need a deeper plan to perform a PoC for each Microsoft Defender for Cloud Plan, please access them from here: Microsoft Defender for Kubernetes Microsoft Defender for Resource Manager Microsoft Defender for Storage Microsoft Defender for Key Vault Microsoft Defender for DNS Microsoft Defender for App Service Microsoft Defender for Container Registries Microsoft Defender for SQL Microsoft Defender for Servers Microsoft Defender CSPM Conclusion This is the final phase of the PoC, and it is strategically done 5 days before you reach the 30 days trial, and the reason for that is because you want to have a spare time to make your final decision if you want to keep using Microsoft Defender for Cloud or not, and if not you can disable Microsoft Defender for Cloud. This is the time to re-engage the stakeholders, present the results, and the benefits of adopting Microsoft Defender for Cloud in production. At the end of this phase, you have the last checkpoint (D). On this checkpoint you should document the following items: Final PoC report Final decision regarding Microsoft Defender for Cloud adoption Summary of the next steps, which needs to include the final considerations of Microsoft Defender for Cloud adoption in production and across all subscriptions Additional Resources Microsoft Defender for Cloud Documentation http://aka.ms/ascdocs Videos https://aka.ms/MDFCInTheField Training Roadmap https://aka.ms/MDFCNinja Microsoft Defender for Cloud Lab http://aka.ms/MDFCLabsAgentless scanning for virtual machines in the cloud – technical deep dive
Over the past three years, a notable shift has unfolded in the realm of cloud security. Increasingly, security vendors are introducing agentless scanning solutions to enhance the protection of their customers. These solutions empower users with visibility into their security posture and the ability to detect threats — all achieved without the need to install any additional software, commonly referred to as an agent, onto their workloads.Uncover the latest cloud data security capabilities from Microsoft Defender for Cloud
Learn about the latest multicloud data security capabilities from Microsoft Defender for Cloud to strengthen your data security posture and protect your cloud data estate against data breaches and malware distribution.Microsoft Defender for Endpoint for Linux and Microsoft Defender for Servers
When it comes to protecting servers in hybrid and multicloud environments, Microsoft Defender for Servers as part of Microsoft Defender for Cloud is the solution you might be looking for. However, with all the features, dependencies, and complexity, it might become challenging to always make the right decision when planning, integrating, and deploying Defender for Servers across your environment. With this blog, we are focusing on deployment and integration of Microsoft Defender for Endpoint with Microsoft Defender for Servers on Linux machines.Announcing new CNAPP capabilities in Defender for Cloud
At Ignite 2023, we are excited to announce new innovations in Microsoft Defender for Cloud that will help security admins strengthen their CNAPP deployment, improve the cloud security posture through additional code to cloud insights, and protect cloud-native applications across multicloud environments in a unified solution.What you need to know when deleting and re-creating the security connector(s) in Defender for Cloud
Introduction: Have you ever found yourself in a situation where you needed to move a security connector in Defender for Cloud between subscriptions or tenant? This article provides guidance on important considerations for removing and re-creating security connectors for AWS/GCP in Microsoft Defender for Cloud. These security connectors store the configuration preferences that Defender for Cloud uses to access your AWS/GCP environment and provide security recommendations and alerts. There may be instances where you need to re-create the connector, such as following best practice guidance, connecting to a different Azure tenant, or storing connectors in different resource groups. I cover the process of re-creating the connector in more detail, including the creation of the connector, the deletion of the connector, and the re-creation of the connector. Creating the security connector: To onboard your AWS/GCP environment to Defender for Cloud, you need to create a security connector. As part of this process, you run a Cloud Formation template in AWS or a cloud shell script in GCP. These templates/scripts create the roles and resources that Defender for Cloud requires to provide security recommendations and alerts for your workloads. The resources and roles created in AWS/GCP depend on the Defender for Cloud plans you select on the security connector. In AWS, the minimum set of roles and resources created by the template includes: Identity provider IAM roles In GCP, the minimum set of roles and resources created by the script includes: Workload identity provider Workload identity pool Policy (role bindings) The outcome of the security connector creation process is the creation of the connector as an Azure resource inside the selected subscription and resource group, as well as the roles and resources created in AWS/GCP. If you enable CWP capabilities and auto-provisioning, the Azure Arc agent and extensions also get installed on AWS/GCP compute resources such as servers, managed Kubernetes, and databases (figure 1). Deleting the security connector: If you need to delete the security connector, you can do so through the Environment settings blade or via the Security Connectors REST API. This will delete the connector as an Azure resource inside the resource group and subscription selected during the creation process. However, it is important to note that deleting the connector in Defender for Cloud does not remove the roles and resources created by the template/script in AWS/GCP. After deleting the connector, it is your responsibility to properly delete these resources in AWS/GCP (like the AWS roles created by the security connector that are displayed in figure 2, note that some information is intentionally obfuscated). There is an additional consideration, if you enable CWP capabilities, on AWS/GCP compute resources such as servers, managed Kubernetes, and databases. Defender for Cloud will now automatically delete Azure Arc machines when those machines are deleted in connected AWS or GCP account. This applies to machine connected to an AWS and GCP account and covered by Defender for Servers or Defender for SQL on machines. After deleting the connector, it is your responsibility to properly remove the Azure Arc agent and extensions installed on any other resources in AWS/GCP. If you wish to offboard completely, additionally you need to delete the Azure Arc representations of these resources, in the resource group in which the security connector was stored. If you're planning on re-creating the security connector, there are some exceptions to the above guidance: if you’re connecting the same AWS/GCP environment, to the same Azure tenant and are using the same Azure subscription, but different resource group to store the connector in, then you don’t need to delete the roles and resources that the security connector created in AWS/GCP. if you’re connecting the same AWS/GCP environment, to the same Azure tenant and are using different Azure subscription, and different resource group to store the connector in, then you don’t need to delete the roles and resources that the security connector created in AWS/GCP. if you’re connecting the same AWS environment, to a different Azure tenant and are using different Azure subscription, and different resource group to store the connector in, then it's highly recommended due to security reasons to delete the Stack/StackSet in AWS you used during the onboarding process. if you’re connecting the same GCP environment, to a different Azure tenant and are using different Azure subscription, and different resource group to store the connector in, then it's highly recommended due to security reasons to delete the old Workload identity pool and providers in GCP. Then you can create a new workload identity pool and providers in the management project and link the providers to pre-existing policy (role bindings). Re-creating the security connector: There are certain scenarios that warrant re-creating the security connector, for example you might want to store security connectors in different subscriptions or resource groups. If you need to re-create the security connector, you will need to follow the same process as outlined in the "Creating a security connector" section. Please note, you need to wait at least one minute after deleting the security connector in Azure, prior to re-creating it. When re-creating the security connector in the same Azure tenant, you don’t need to delete the roles and resources on the AWS/GCP side. However, if choose to do so you might need to wait longer until you're able to re-create the security connector, because in GCP there is a 'soft' delete for 30 days. The deletion in AWS is instantaneous. Conclusion: In summary, it is important to carefully consider the process of removing and re-creating security connectors in Microsoft Defender for Cloud. Properly deleting and re-creating these connectors requires following the correct process and properly deleting the resources and roles created in AWS/GCP. Following these steps will help ensure the security and effectiveness of your cloud environments. Reviewers: Or Serok Jeppa, Senior PM Manager Ameer Abu Zhaia, Software Engineer II Giulio Astori, Principal Product Manager Contributors: Ameer Abu Zhaia, Software Engineer II Chemi Shumacher, Senior Software Engineer
