Understanding DevSecOps

You come into work one day, only to learn that an evil hacker has gotten into a web server and absconded with all the access credentials left behind in a plain text configuration file. Pandemonium breaks out. The bosses go berserk. The next thing you know, cables are being pulled from boxes in the data center, non-essential IP addresses and ports are closed on the firewalls and everybody wants to see the systems logs — right now!. Then, of course, security gets called in to figure out what happened and make sure it never happens again. It’s a tale too often told.

There’s a saying that goes like this: Insanity is doing the same thing over and over again and expecting different results. This absurdity has not been lost on those whose pride and passion are security. Bringing security in after the fact might be a nice way to do post-mortem forensics and establish policies moving forward, but reacting to disaster will only get you so far. Hence the evolution of DevOps into DevSecOps.

DevSecOps is, as the names implies, the integration of Development, Security, and Operations into a unified, self-directed, self-correcting team completely accountable for all aspects of creating and maintaining the software and digital infrastructure in its portfolios.

Those in the know have figured out that the best way to improve an enterprise’s approach to security is not only to give security experts a first-class seat at the table of software development before projects begin, but to create a culture in which security is a principled way of life.

Some might think that the only requirement for implementing effective DevSecOps is to make sure a security expert is present at daily scrums. It’s more than that, way more! In fact, DevSecOps.org has defined these way-of-life principles as follows:

Leaning in over always saying “No”

DevSecOps requires security interests to move past the typical knee-jerk “no”, to offering educated, informed input based on the situation at hand. Leaning in means being involved in development initiatives as an active, invested team member, not as an authority whose role is to do nothing more than bless the activities of others. DevSecOps means taking an interest in the work of others and being able to learn from them. It also means learning the dynamics of the team and the details of the work being done. It’s not simply being the expert who gets to call the shots about matters concerning security.

Data & security science over fear, uncertainty, and doubt

DevSecOps is about thinking in terms of the facts at hand and using the science available to create computing environments that are safe and reliable. It’s not about being driven by imaginary organization demons that threaten catastrophic disaster and bankrupting litigation. For example, acting on verifiable reports about a demonstrable hazard rather than reacting to a recent attention-getting telecast on a cable news network. A security practice that is based on facts and science is manageable. One based on fear, uncertainty, and doubt is beyond control.

Open contribution & collaboration over security-only requirements

Making software is an undertaking requiring the concerted efforts of many parties. It’s an orchestrated collaboration. And, just as a well functioning orchestra operates beyond the concerns of any one section in the ensemble — violin, oboe or trombone, for example — so too does the software development team. Hence, effective DevSecOps means that the security members of the development team need to have an operational awareness of all aspects of the development process– from design, programming, and testing to product release. DevSecOps means knowing the overall intention of the enterprise and how all the pieces, security included, fit together to make the entire operation work.

Consumable security services with APIs over mandated security controls & paperwork

DevSecOps understands the world of modern technology is fast changing, that no one product will ever satisfy a need forever. Today’s great security tool might be tomorrow’s ineffective hazard. Thus, DevSecOps promotes a services approach to security in which required functionality is represented as an abstract service backed by an ever-changing set of tools and security policies. Abstracting security into a set of services represented by way of APIs provides the flexibility needed to make sure that security practices stay current and effective.

Business-driven security scores over rubber stamp security

DevSecOps understands that appropriate security measures are a reflection of business needs that are continuously changing. A security policy that is written in stone will become outdated as the business changes over time. Instead of a binary, Yes/No approach to determining security compliance, DevSecOps promotes establishing compliance by using a passing grade method based on scoring. A score-based approach is one in which points are awarded according to metrics gathered from concrete security testing and subsequent analysis of the enterprise’s infrastructure. It’s the difference between “rubber stamping” that a penetration test has been conducted and awarding a score to the penetration testing based on breadth and depth of the penetration attempt. Attempting to penetrate all the access points of an enterprise will yield a higher score than attacking a single server.

How compliance is scored over time will change as the business evolves and the digital environment changes. Rubber stamping runs the risk of becoming obsolete. Business-driven security scoring provides the flexibility needed to create a secure computing environment that meets the current demands, both in terms of the business and the digital infrastructure.

Red & blue team exploit testing over relying on scans & theoretical vulnerabilities

A Red Team is an outside attacker. A Blue Team in an inside defender. DevSecOps promotes using the Red/Blue teams on an ongoing basis to emulate real word attacks against the enterprise and to defend against such attacks. While scanning for vulnerabilities and perpetrating attacks against theoretical vulnerabilities can be useful, such practices run the risk of becoming misguided and obsolete. DevSecOps asserts that Red Team/Blue Team attack and defense activity is a more real-world approach to security monitoring than prescribed scanning. Of course, this assumes that Red & Blue Team exploit is done continuously. The key here is the word, continuously.

24×7 proactive security monitoring over reacting after being informed of an incident

Football teams don’t plan defensive strategy after the touchdown has been made. Rather, they establish an overall approach to defense. The team gets drilled every day to hone defensive capabilities. A team will study the habits of other teams before game time to determine strategy. Then, they make adjustments as the game is being played. Yes, the team might alter defensive tactics on the field in response to another team’s touchdown, but momentary reaction is not the only approach to overall defense.

The same is true when it comes to DevSecOps. DevSecOps understands that security is a way of life and goes beyond one incident or response. Hence, DevSecOps advocates continuous 24/7 proactive security monitoring as a way of putting security into the very fabric of an enterprise’s daily operation.

Shared threat intelligence over keeping info to ourselves

DevSecOps understands that security is a team support. Therefore, sharing all information, all the time is critical to making each member of the software development team a contributing resource for a more secure computing environment. As security becomes a more pervasive practice among all members of the digital enterprise, the role of the DevSecOps engineer becomes one of the expert guide on the sidelines of activity rather than being a gatekeeper authority for work in progress. Therefore, the open, continuous sharing of information, particularly threat information, is critical for raising the level of security acumen of all contributors throughout the digital enterprise.

Compliance operations over clipboards & checklists

Compliance operations is the discipline by which an enterprise verifies that it adheres to the rules and best practices as defined for a given field of operation. Compliance operations is more than having a checklist on a clipboard and checking conditions as True or False as one would do during a car inspection — headlights work? Check!; brake lights work? Check!; horn works? Check!

Compliance operations requires not only knowing the rules in play, but also having an in-depth understanding of the reasoning behind the rules.

DevSecOps promotes compliance operations over clipboards and checklists. Putting compliance operations as a forefront of activity means having an ongoing awareness of the rules, regulations and best practices around corporate IT security. DevSecOps personnel apply what they know and understand to establish policies and procedures to ensure compliance with the most current rules and standards in force. Inherent in understanding is the ability to learn and adapt. Adaptability is essential to the practice of DevSecOps. Simply checking off items in a checklist on a clipboard does not scale nor does it provide the level of proactivity needed to operate securely on the modern digital landscape.

Putting it all together

It takes years of experience to develop the knowledge and intuitions required to be a first-class security professional. However, any security expert, whether from a traditional security discipline or from the modern DevSecOps school, cannot go it alone. In today’s digital infrastructure, security is everybody’s concern — from the maintenance worker noticing strangers dropping thumb drives with the label, “Use Me” in the IT breakroom, to the senior CISSP certified professional battling the newest menace threatening to bring the enterprise to its knees. DevSecOps is an important movement that will go a long way to foster the sensibilities needed to promote security best practices in the modern enterprise.