Securing DevOps’ application environments

Step 1: Leverage a Well Architected Framework (WAF) for landing zone provisioning

A great place to start with securing application environments is by building a secure landing zone. However, both privilege escalation hacks and data breaches target the landing zone due to the high volume of secrets, subscriptions, and company data located there. So, leverage the Well Architected Frameworks (WAFs) built by public cloud providers, such as the Microsoft Azure WAF, for a set of guiding principles to run your cloud workloads efficiently and securely. And put in place automation for all your landing zone deployments to help ensure conformity to security protocols.

Step 2: Lock down environments with segmentation

Segmentation reduces the attack surface when a system is hacked by creating boundaries that hackers cannot pass. This limits the impact or blast radius when an application gets compromised. To accomplish segmentation, you must carefully configure networks and identities, where networks are physical boundaries with controlled access between them. This section looks at the different levels of segmentation and offers guidance on ways to achieve it, such as with a management group on an Azure subscription.

Step 3: Provide security teams with visibility into delivery pipelines

Security teams normally live in the production environment, securing the production data from being compromised with their specific tools like Microsoft Sentinel and Microsoft Security Center. When DevOps teams share security scans results, pipeline incidents, and deployments with security teams, not only does the barrier between security and DevOps teams decrease, but security issues are also found earlier. Security teams can then use the functionality of their security tools to help find security issues before a system is deployed to production.

Step 4: Remediate vulnerabilities quickly with a SBOM

A software bill of materials (SBOM) helps companies remain cognizant of all software and software dependencies running across environments. This is important for several reasons, not least that while teams with fully automated release pipelines can redeploy a system almost instantly after the necessary fixes are made following the discovery of a vulnerability, not all systems have an automated deployment, let alone a list of systems running in production. Without that production system knowledge, it is nearly impossible for teams to keep track of downstream vulnerabilities as well. That’s where a SBOM can help.