Establishing a DevSecOps Program within your organization? It can be easily achieved for businesses small and large. Here are the 5 foundational DevSecOps principles to help you get started:
1) Customer Focused Mindset
With customer focus comes the benefit of aligning business and security strategies to ensure just right, just enough security that everyone in an organization can support and implement. Yet sometimes mixing security and business outcomes can feel like trying to mix vinegar and oil. Security professionals that spend a majority of their time learning nuanced ways to break software often have a hard time relating this information back to the customer and ultimately to business outcomes. In fact, the complexity of security and the vast difference in how security and business professionals spend their time can cause a major divide in decision making. Security professionals tend to think about how to keep business assets safe and business professionals focus on how to take risk to meet customer demands to increase revenues. And these differences can lead to a great deal of friction between these disciplines.
Differences aside, a customer-back focus can help security professionals drive better security adoption and ease complexity that often stands in the way of reducing risk. With a customer focused mindset, security programs and outcomes can be tailored to customer needs and business outcomes where complexity can be mapped in via automation and reporting. And making it easier to understand the controls necessary to support business outcomes ultimately makes implementing security something anyone can do.
2) Scale, Scale, Scale
Adding onto a customer focus, it is imperative for security to scale. It's not helpful for security professionals to think of their function as the gate keeper when the business needs to innovate quickly to solve customer problems. Instead, security in support of DevOps and Continuous Innovation must evolve to keep pace with business outcomes by introducing the same working style and conditions for security teams. And the case for security evolution becomes even more compelling as continuous deployment, lean start-up, agile, DevOps, and other innovation driven methods become the norm. That's right - security professionals must become lean, code and begin to demand software defined platforms that help gather, interpret and report on the security profile of our business resources and environments.
Achieving security scale is all about solving problems by reducing the amount of manual processes and time it takes to achieve a risk reduced outcome. But it's not always easy for security professionals to change and address the challenge of making security transparent and easier for everyone to implement. However, with dedication it is possible for security professionals to adapt and develop automation that allows for risk decisions to be made via self-service that allows for security to be scaled. And Security as Code has the added benefit of being portable, shared, and made better over time because its not a document that gets read once, shelved and forgotten. Instead, Security as Code has the advantage of being a living part of the system that supports business outcomes.
3) Objective Criteria
Ever try to make a fast decision from a report with hundreds, if not thousands, of findings that still require interpretation? It's not fun for those that receive security reports and instead can be quite confusing. Providing security Information for fast decisions is actually becoming an art form that is wildly better by the introduction of objective criteria and a maturity based approach. Objective criteria can help business professionals know how, when, and in what order to improve the security profile of its business resources. In fact, one can argue that the sole goal for a security professional is to produce actionable remediation advice that can be consumed by business partners. Establishing objective criteria and a means of measuring the security of business assets is ideal for producing actionable requirements that business partners can use to make quick decisions. And, objective criteria can become more powerful than policies because it can be tuned to the current maturity of controls within a business that also allows risk decisions to be better understood.
Creating a security scorecard is an essential element in developing a DevSecOps program because it provides direction for business partners and the security team that performs continuous testing and monitoring for business assets. And depending on who the audience is, a scorecard can leverage instrumentation and results to create context for decision making. As an example, if the audience is Development, the measures used and reporting provided may be more development based, ie. number of security defects per line of code. Whereas with Operations as the audience, the measures used may address configuration defects and infrastructure vulnerabilities. But for the most part, simply setting up a scorecard can help teams that are running fast and operating lean to make decisions without interruption or friction.
4) Proactive Hunting
Imagine if your organization could get ahead of attackers and remediate the right defects before they are used. Proactive hunting and testing of business resources aids in surfacing weaknesses which could be easily exploited by an adversary. Establishing a proactive approach to keeping business resources secured also contributes to better measurement and scale because it requires automation and lots of data to discover important attack surface before it impacts business. And its not enough to simply think that a good Incident Response process will cover this need because by the time weaknesses are discovered from external attempts, its often too late.
Implementing a Red Team function forced to build automation, leverage its own information, and identify defects before they become attack targets goes a long way towards establishing proactive hunting. And this type of capability can take advantage of passive inputs that attackers are now fond of using to increase its defense strategy. Essentially, establishing the Red Team function increases reconnaissance about the organization's technology environment and allows for inline testing and exploitation in order to prioritize remediation efforts as part of the overall system required to support business outcomes. In other words, by increasing internal security testing and making it proactive, an organization benefits because remediation guidance becomes immediately actionable and integrated with business processes.
5) Continuous Detection & Response
And finally, with all of these other principles in mind, it is necessary to ensure that continuous detection and response is put in place in order to complete information discovery and real-time attack detection. DevSecOps requires continuous detection, comparison, correlation and response to mitigate the lack of attack analysis derived from gating processes and paper based controls. Simply stated, continuous detection and response is essential because it provides monitoring and analysis of external attempts to attack company targets which allows for incidents to be defeated quickly.
It may sound like the same tale for detection and response that's been told for the last decade. Not so. While most companies have established detection and response practices, DevSecOps requires a more continuous approach that feeds back into automation and Red Team processes to increase the speed by which internal teams learn about external discovery and attack attempts. And more importantly, the implementation of Security Science allows for real-time information used to identify events of interest and incidents that require response to be harnessed for decision making and forecasting of defensive controls required to support business outcomes.