The DevSecOps Process

There are various practices that need to be integrated into the DevSecOps environment and strategic points along the pipeline. The processes defined for these practices have to ensure that security is built-in to the development in a way that enables developers and does not create obstacles to high-paced deployment.

Reducing delivery friction

One concept that has emerged from the success at Netflix and is being adopted as a strategy for DevSecOps culture is the idea of the “Paved Road”. The paved road concept refers to focusing on creating a low friction path for software to move from concept to production. Decisions made that could in some way impact or influence those delivery processes should therefore take into account whether they enable developers or create impediments to delivery. The latter should be minimized or ideally, avoided all together.

An important facet to establishing a DevSecOps culture is removing the friction between teams by cultivating empathy.

To achieve this approach requires buy-in from many areas of the organization, but it all starts at executive levels. If business leaders are not the ones driving the change in culture, it simply will not change. Top-down leadership must stress adoption of the paved road principles through all levels of the company. Corporate values should make it clear that everyone is responsible for delivering secure products swiftly to customers. From there it becomes easier to prioritize practices that ease the burden on software delivery.

Threat modeling

The 2020 DevSecOps Insights Report found that threat modeling has a significantly positive impact on a team’s overall confidence in the security of their code. Unfortunately, threat modeling has long been looked at as a very labor intensive activity. As a result, with organizations moving to a DevOps/DevSecOps approach, threat modeling is often excluded from the security practices employed. However, the impact that thread modeling has on development must not be overlooked. 

At its roots, threat modeling is meant to examine planned software to identify what could go wrong if an attacker were to target that software. The goal of this analysis is to inform the development team about what security controls they should be considering as part of their implementation. Traditionally, threat modeling has been done with a wide scope across the entire context of the application. Data-flow diagrams, detailed threat analysis frameworks, and prescriptive threat prioritization methodologies have often been leveraged as part of this process.

Within a DevSecOps model, however, time and resource intensive threat modeling methodology is inhibitive. However, a streamlined approach can be utilized within the pipeline. DevSecOps typically leverages practices from agile development, such as product backlog management. Rather than designing a whole system, new features and enhancements are added to the backlog via user stories. These manageable, independent elements are at the core of enabling high-paced development. Organizations can approach threat modeling in the same way.

Instead of looking at threat modeling as a process that has to be conducted against a monolithic application, simple threat modeling practices can be implemented at the backlog. When writing a new user story, that story should also include a brief description of the threats that are introduced or affected by the user story. Sensitive functionality or data that are a part of the story should be identified. With this information available to developers in the backlog, the role of threat modeling is achieved in a way that can actually speed up development of each story.

Version control, metadata, and orchestration

Within an automated world, the only constant is change, and change needs to be both consistent and traceable. To track all changes, DevSecOps must ensure that adequate and immutable versioning is in place. Every action needs a version, in the same way that code is managed, to allow quick recovery. Once turned into metadata, operational teams can efficiently track a change and measure it.

Orchestration software doesn’t only provide a repeatable way to deploy infrastructure, it also provides a huge amount of metadata regarding any task. The metadata can in turn be used not only by the orchestration software itself, but as an authoritative source for integrated tooling. Once coupled with versioning, orchestration software becomes a powerful source of information for all operational teams.

Compliance

Implementing compliance initiatives doesn’t have to be a paper-based exercise. Instead, organizations can create metadata representing the compliance requirement and integrate it in their assets directly. This can also be used by security policy automation by tagging assets that can in turn implement the desired security architecture, for example, zoning.

This approach enables compliance at scale. For instance, it can bring into reality the ability to respond to a breach under the new GDPR rules in 72 hours. By coding to compliance requirements in DevSecOps, the development process now becomes an enabler of the compliance program.

Security architecture

Security architecture is supported by a set of principles that are specific to each company. These principles depend on the type of data being processed, although a high-level set of principles can be used to guide software delivery towards more secure practices. Organizations adopting a DevSecOps model need to ensure processes are in place to establish and continuously update these architectures. This enables faster and more secure development.

Coding these principles as part of the DevSecOps culture and having them available and included in the backlog allows product managers to seamlessly integrate security as part of their plan and supporting architecture. If there is any deviation due to business process and/or lack of resources, the deviation is captured and the risk associated with it taken into account. These deviations ultimately can be addressed in the same way as any other bug and tracked to resolution.

Incident management

Responding to security incidents should not be an improvised or unplanned activity. It is key that workflows, action-plans, playbooks and runbooks are created in advance. This is to ensure that the response to an incident is consistent, repeatable, and measurable. Incident management should make use of the metadata to help simplify this process, thus changing the metrics to highlight the time taken to redeploy a compromised asset. As the playbooks are developed, the processes introduced should be inclusive of all forms of incidents. As DevSecOps unites the various functions, so should the processes that implement it. Therefore, incident management processes should have a level of abstraction where operational and security incidents are treated following the same framework. This is another effective step in reinforcing the share responsibility culture that is crucial for DevSecOps.

In turn, once the playbooks have been codified, they can be integrated in the CI/CD pipeline to automate them. In a DevSecOps world, proactive and preemptive threat hunting, and continuous detection and response to threats and vulnerabilities mean that there are fewer major incidents and more mitigations. The use of penetration testing, red-teaming, and bug bounties provide an additional layer of mitigation against the risk of breaches. While continuous detection is a great thing, organizations must be vigilant against alerting fatigue. This means establishing feedback loops that drive continuous improvement of monitoring and greater automation in assessing and responding to alerts.

Proactive security assessments

No matter how advanced an organization’s DevSecOps methodology becomes, the need for active vulnerability identification is needed.  Penetration testing is a term often used to refer to efforts around comprehensive identification of vulnerabilities within a given scope. Red teaming differs in that it usually is more focused on mimicking the actual motivations and tactics of an attacker. For instance, while a penetration test may seek to identify all pages of an application that are vulnerable to a SQL injection attack, a red team assessment would identify perhaps only one or two vulnerable pages and use those vulnerabilities to further exploit the application.

Penetration testing

Penetration testing is often the first stage of maturity when it comes to vulnerability management within applications. The goal of these tests is to identify areas within an application that may be vulnerable to some form of attack. The ideal goal of these assessments is to provide comprehensive visibility into the overall security posture and attempt to remediate risky vulnerabilities. However, to achieve this comprehensive view of the vulnerabilities in the application can be time consuming. Therefore, within DevSecOps, while this testing is a basic requirement of security hygiene, it is typically implemented as a post-production activity.

Red teaming

Red team assessments are typically seen in organizations with a high level of maturity. Red team assessments are an additional step on top of penetration testing. In a Red team approach, the goal isn’t to identify as many vulnerabilities as possible. Instead, the approach is more objectives-based, more similar to the approach an attacker would take. The scope typically isn’t limited to a single application and instead spans the full breadth of systems in the environment. This enables the organization to understand how vulnerabilities within multiple systems can be combined to achieve an attack. It gives greater context into the expected impact of a successful attack. As such, these assessments require a higher degree of skill and more diverse skill sets than traditional penetration testing. As a company’s DevSecOps approach matures, they may want to explore red team engagements as part of their regular security hygiene.

Bug bounties

Bug bounties have also received a lot of attention in recent years, due, in part, to crowd-source bug bounty programs that have become available. Bug bounties setup scopes, reporting requirements, and reporting methods for external hackers to attempt to identify vulnerabilities within an organization’s environment. In exchange for following these rules, hackers are provided a “bounty” for vulnerabilities they report to the organization.

While bug bounties are a great way to encourage outside parties to disclose vulnerabilities in a responsible fashion, and while they offer an additional layer of vulnerability identification, they should not be relied on in place of penetration testing practices. Security researchers who participate in bug bounty programs generally don’t have the best interests of the organization in mind. They are not seeking to comprehensively identify vulnerabilities and most are searching only for the highest severity findings that net them the largest bounty.

Threat intelligence

As more and more components of the environment are defined and documented in code, visibility for threat intelligence grows as well. Many organizations struggle to identify their IT assets in a way that they can effectively link threat intelligence received to the assets in their environment. By ensuring building processes to feed metadata from the DevSecOps pipeline to threat intelligence capabilities, the organization can ensure that the right intelligence is being gathered and that it is being applied and responded to in an appropriate risk-prioritized fashion.