[FEATURE] Maturity Level 2 - WAF Security #3726
Description
Your suggestion
Just like the existing baseline for level 1 Azure.Pillar.Security.L1, we need to identify rules that should be included in the Level 2 baseline that are not already assigned a level. Some rules have already been labeled for Azure.WAF/maturity = L2, however others have not.
We need to initially identify the rules that should be included in level 2 based on the following guidance.
In Level 2 of the Security pillar, you build on your baseline security configuration to further reduce potential threats during workload deployment. This stage emphasizes strengthening deployment practices, establishing a maintenance plan for code assets and workload components, developing a data classification framework, securing network ingress points, and hardening workload components—all essential steps to enhance your overall security posture.
Level 1 of the Security pillar focuses on securing the development phase of your SDLC. Level 2 assumes that you established baseline security measures for the development phase and that you're ready to deploy the first iterations of your workload or components of your workload.
In this phase, focus on building your deployment automation to optimize efficiency and security. Use deployment pipelines like Azure Pipelines or GitHub Actions and standardize using these pipelines exclusively for all changes to your workload. Routinely perform good code hygiene practices to ensure that your code base is free of defects and code that might introduce risks. Finally, familiarize your team with the Microsoft Security Development Lifecycle. As your workload evolves, regularly revisit the recommendations in this guidance to ensure that your SDLC remains optimized for security.
Develop a maintenance plan:
In the context of security, a maintenance plan refers to standard practices that you adopt to maintain the security of your code and workload components throughout their life cycles. Build mechanisms and processes to handle emergency fixes in your deployment pipeline. For example, you might accelerate deployments through quality gates by using direct communication between teams and developing expedited roll-back and roll-forward plans.
Include software, libraries, and infrastructure patching in your standard processes to ensure that all components of your workload are always up to date. Keep a catalog of versioned assets to help during incident response, problem resolution, and system recovery. You can also use automation to compare these versions with known vulnerabilities in the Common Vulnerabilities and Exposures program.
Classify data based on sensitivity needs
Adopt a data classification system and its supporting processes to help ensure that you maintain confidentiality and integrity. Start with broad categories like Public, General, Confidential, and Highly Confidential, and apply appropriate levels of security to protect those categories throughout your data stores. Consider investing in tooling like Microsoft Purview to govern your data. For detailed best practices, see the data classification guidance in the Microsoft compliance documentation.
Apply authorization and authentication controls
As part of your IdP solution implementation, you can start applying controls related to authorization and authentication. Use role-based access controls to help limit access to workload components by applying granular permissions to resources based on user roles. Apply these permissions based on the principle of least access.
Further enhance your controls by using conditional access policies. These policies grant or deny access to resources based on specific conditions like a user's geographic location or whether a user's device complies with security policies. You can also take advantage of features like just-in-time access to lock down access to sensitive components.
Secure your network ingress
Secure your network ingress as much as practical to improve your overall security posture. A secure network ingress is your first line of defense against outside attackers. Your cloud provider might have various tools that you can use in your specific environment, but be sure to understand all possible ingress points in your workload. You might add a firewall to a virtual network or its subnets, like network security groups in Azure virtual networks. If you use platform resources like Azure SQL Database, you might have options to limit or disable public and private access within the configuration of the resource itself. Likewise, limit or disable any direct access to virtual machines to a practical extent.
In general, choose a native or partner firewall to control all ingress to your workload. You might also use a web application firewall that's built into a load balancing solution, like Azure Front Door, or an API gateway, like Azure API Management.
Harden the attack surface
Hardening the workload is an iterative process that requires continuous improvement. Be vigilant and analyze the workload for vulnerabilities. As your workload matures, use a vulnerability scanning tool to help you easily identify vulnerable components. Early in your development, a better strategy might be to perform the hardening exercise manually. Look at the configurations of your components to find potential weaknesses, such as misconfigured or unconfigured firewall rules or inappropriate permissions. Look for any unused or unnecessary components that you can shut down or remove entirely and for unused accounts that you can deactivate.
Alternatives
na
Additional context
No response