Secure DevOps
From the beginning, the Microsoft SDL identified that security needed to be everyone’s job and included practices in the SDL for program managers, developers, and testers, all aimed at improving security. Further, recognizing that one size doesn’t fit all development approaches, it described flexible practices and activities proven to improve security of software applications at every stage of development using either the classic waterfall or newer agile methodology. However, other than considering the production environment, the SDL didn’t include activities for operations engineers.
The DevOps approach changes that. Now, development and operations are tightly integrated to enable fast and continuous delivery of value to end users. DevOps has replaced siloed development and operations to create multidisciplinary teams that work together with shared and efficient practices, tools, and KPIs. To deliver highly secure software and services in this fast-moving environment, it is critical for security to move at the same speed. One way to achieve this is to build security in development (SDL) and operational processes.
Practical experience
The practices used in DevOps provide a great opportunity to improve security. Practices such as automation, monitoring, collaboration, and fast and early feedback provide a great foundation to build security into DevOps processes.
Useful links:
Mindset shift to a DevSecOps culture
Provide Training
Define Requirements
Define Metrics and Compliance Reporting
Use Software Composition Analysis (SCA) and Governance
Perform Threat Modeling
Use Tools and Automation
Keep Credentials Safe
Use Continuous Learning and Monitoring
Practice #1—Provide Training
Training is critical to success. Ensuring that everyone understands the attacker’s perspective, their goals, and how they exploit coding and configuration mistakes or architectural weaknesses will help capture the attention of everyone and raise the collective knowledge bar.
Practice #2—Define Requirements
Establish a minimum-security baseline that takes account of both security and compliance controls. Ensure these are baked into the DevOps process and pipeline. At the very minimum, ensure the baseline takes into account real-world threats such as the OWASP Top 10 or SANS Top 25, and industry or regulatory requirements and issues known to exist or that could be introduced by human error in the technology stack you select.
Practice #3—Define Metrics and Compliance Reporting
Drive the behavior you want with the engineers by defining specific metrics which drive action and support compliance objectives.
Practice #4—Use Software Composition Analysis (SCA) and Governance
When selecting third-party components (both commercial and open source), it’s important to understand the impact that a vulnerability in the component could have on the overall security of the system. SCA tools can assist with licensing exposure, provide an accurate inventory of components, and report any vulnerabilities with referenced components. You should also be more selective when using high-risk third-party components and consider performing a more thorough evaluation before using them.
Learn more about using secure third-party components
Useful links:
Practice #5—Perform Threat Modeling
Although threat modeling can be challenging in DevOps because of its perceived slowness, it is a critical component of any secure development process. In most situations, applying a structured approach to threat scenarios helps a team more effectively and less expensively identify security vulnerabilities, determine risks from those threats, and then make security feature selections and establish appropriate mitigations. At the very least, threat modeling should be used in environments where there is meaningful security risk.
Practice #6—Use Tools and Automation
Use carefully selected tools and intelligent automation that’s integrated into the engineer’s world (such as an integrated development environment). In the modern engineering world, it’s easy to assume that automation is the solution and it’s correct that automation is critical, but it’s important to be selective when choosing tools and be careful when deploying them. The goal is to fix issues and not to overload engineers with too many tools or alien processes outside of their everyday engineering experience. The tools used as part of a secure DevOps workflow should adhere to the following principles:
- Tools must be integrated into the CI/CD pipeline.
- Tools must not require security expertise.
- Tools must avoid a high false-positive rate of reporting issues.
Integrating Static Application Security Testing (SAST) into your IDE (integrated development environment) can provide deep analytical insight into the syntax, semantics, and provide just-in-time learning, preventing the introduction of security vulnerabilities before the application code is committed to your code repository. Similarly, integrating Dynamic Analysis Security Testing (DAST) tools into the continuous integration / continuous delivery pipeline will help quickly uncover issues only apparent when all components are integrated and running.
Useful links:
Roslyn Diagnostics Security Analyzers
Automated Penetration Testing with White-Box Fuzzing
Microsoft Security Code Analysis
If you are using Azure, the Secure DevOps Kit can be downloaded from the Visual Studio Marketplace.
Practice #7—Keep Credentials Safe
Scanning for credentials and other sensitive content in source files is necessary during pre-commit as they reduce the risk of propagating the sensitive information into your team’s CI/CD process. Instead of storing sensitive keys in code, consider using a bring-your-own-key (BYOK) solution that generates keys using a hardware security module (HSM).
Useful links:
Practice #8—Use Continuous Learning and Monitoring
Monitoring of your applications, infrastructure, and network with advanced analytics can help uncover security and performance issues. When utilizing continuous integration/continuous deployment (CI/CD) practices paired with monitoring tools, you will be able to gain better visibility into your application health and proactively identify and mitigate risks to reduce exposure to attacks. Monitoring is also an essential part of supporting a defense-in-depth strategy and can reduce your organization’s mean time to identify (MTTI) and mean time to contain (MTTC) metrics.
Useful links: