Best Practices for DevSecOps in Azure

The DevSecOps approach to releasing and maintaining software has largely replaced the old way of having separate teams for development and administration. Combining them makes it possible to keep up with the rapid cycle of iterations which online applications demand.

Security needs to keep up with the cycle too. Each new release has to be checked for risks, and the discovery of previously unknown dangers calls for a quick response. DevOps is evolving into DevSecOps.

The people responsible for security can adapt their methods to resolve issues quickly. DevSecOps calls for a new way of thinking, based on the recognition that prevention won’t be 100% successful. Indeed, it’s necessary to anticipate the attacker’s thinking and to test and monitor constantly.

Microsoft recommends eight practices for DevSecOps in Azure environments. Following them will mean fewer successful attacks, faster discovery and mitigation, and less damage and downtime.

1. DevSecOps Training

Everyone on the team, not just the security people, needs training in security. This doesn’t mean they all have to be experts, but they should have a basic understanding. Knowing what kind of things attackers look for and what approaches they take will help in creating software which is free of vulnerabilities. Security has to be built into the software. Coders should know about common patterns of vulnerability and avoid them. Admins should learn to recognize the signs of trouble and know what actions they can take. When everyone on the team knows their part, there are fewer mistakes and fewer breaches.

2. Defining the Security Requirements

Every software product needs to have explicit security requirements. They need to be based on the assets being protected, the way they are used, and the obligations which the law and business standards impose. Requirements should always take into account standard lists of issues, such as the OWASP Top 10.

The requirements ought to be defined as part of the design process. Each unit of functionality, such as logins, data requests, and updates, should come with a risk evaluation. The iteration process for new releases has to be set up in a way that satisfies the defined obligations.

What is necessary will change as new threats emerge. In fact, the definition process isn’t frozen with the initial requirements document.

3. Defining Metrics

Security has to be measured to improve. Each factor should have a quantitative value that contributes to an overall security score. The metrics have to be realistic, rather than being tweaked to make the situation look good.

Security issues should be entered as part of the bug tracking process and assigned a severity level. Consistent standards are necessary, and all severity levels should get some attention. If some testers call every bug a “show-stopper” just to make sure it gets noticed, the process is broken. Prioritization ensures that the problems which carry the most risk get fixed the quickest.

4. Using Software Composition Analysis

Third-party components can have a positive or negative impact on security. Proven, well-tested components are safer than rolling your own code. Badly written ones introduce serious risks. Software composition analysis (SCA) is a set of techniques for managing and evaluating the open-source libraries used in a project. It provides an inventory of the components in use and reports any vulnerabilities associated with them. SCA tells DevOps teams when they need to update or replace open-source components because of the risks they carry.

5. Modeling Threats

Threat modeling is an advanced technique, but it’s valuable for organizations that have strong security requirements. It describes and prioritizes potential threats, making it easier to judge how vulnerable a software component is to them. Threat modeling takes the attacker’s perspective, asking what an intruder is likely to go after rather than what weaknesses the software has.

Some threats will be irrelevant to a given target, while others will be prime ways to look for and exploit weaknesses. Knowing the effective attack types tells developers and administrators what they need to guard most carefully against.

6. Using Tools

Tools for automating the DevOps process make it consistent and efficient. They should include security checks so that each new build passes a set of tests before release. The wrong tools, though, can hinder more than they help.

Good tools for a DevSecOps pipeline are easy enough to use that a security expert isn’t necessary on a regular basis. Qualified developers and administrators can understand what they’re saying. They should be configurable so that they don’t give a lot of false positives. Otherwise, teams will spend too much time on problems that aren’t real, or they’ll learn to ignore all warnings. Tools that are well-chosen and configured will prevent real weaknesses from getting through the pipeline.

7. Securing Credentials

Passwords, keys, and other sensitive information need to be kept out of code. Once they get into a shared repository, especially a distributed one like Git, it’s difficult or impossible to eradicate them from all copies. Developers should know better, but sometimes they’ll put a password into the code as a quick hack, forgetting it could get into the repository.

There should be a pre-commit process for making sure such keys don’t get into the code. Thus, if one does, it should be changed if considered compromised. Consistently using a hardware security module or other specialized services to manage keys will help to avoid that mistake.

8. Monitoring on a Regular Basis

Some attacks will get through, and monitoring is a necessity to make sure they’re addressed quickly. It should be integrated with the development and deployment pipeline. If there’s a change in performance following a release, the monitoring tools will report it, possibly forcing a rollback until the cause is discovered. Integration with the release cycle helps to pinpoint the cause of a problem which the tools discover.

In many cases, monitoring will identify newly introduced risks before they become actual problems. It will catch risks early so they can be fixed faster. Indeed, often before they become actual problems.

Conclusion

The DevSecOps techniques described here are applicable to any online software application. With Azure, there are multiple tools that aid in the process, such as:

• Microsoft Threat Modeling Tool
• Microsoft Security Risk Detection
• Security Code Scan
• Security Code Analysis extension

Making security an integral part of DevOps keeps software tighter and lets issues be addressed faster. As a Microsoft DevOPs Gold Partner, we can help you to get your Azure-based application running securely and reliably.