Securing DevOps’ application environments

In the latest in our series of guides to Modern App Development and Enterprise DevOps, we argue that it is a big mistake to skimp on application environment security.  As part of the application environment, test and development might serve a different purpose from production environments but they too can be open to the outside world and introduce risk if not secured.

As we point out in our Securing Enterprise DevOps Environments eBook, unsecured application environments present a dizzying array of opportunities for hackers, including configuration drift between updates, open ports, access escalation, and vulnerability unawareness. So, while companies often focus their privacy and data security on their production workloads, a focus on security in non-production environments is also needed to avoid the risk of leaving the company open to corporate espionage, sabotage, and theft of private consumer data.

In this chapter we explore how to secure your application environments to defend and anticipate next-generation threats by taking four key steps:

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.