What is DevSecOps?

This may seem obvious, that DevSecOps includes the security team with the development team and the operations team all working together, but a deeper understanding of why is of definite benefit to your planning and operating processes.

Where Security Fits In: A Reason for DevSecOps

In 1983, the International Standards Organization (ISO) introduced a useful seven-layered model for networked computing called the Open Systems Interconnection (OSI) model.

Moving outward from the user, data is entered into the network through software running on the Application layer. This application is running on a device-based operating system at the Presentation layer which is signed in through the Session layer. Data is moved from that user to another destination by the Transport layer which uses the Network layer to connect to that destination. This connects to the actual network via a network interface card at the Data-Link layer which, finally, connects to the actual cabling and wireless infrastructure at the Physical layer.

Arriving at the other end, the data travels back up the seven layers to arrive at its intended destination. Each layer has its own protocols and other communication standards that govern its efficient operation.

So, you may be asking, where is the Security layer? Where does security fit in?

The answer is “Yes.”

Security is a Chain

Data and network security consists of a chain of measures implemented at every level of the ISO/OSI seven layered model. A chain is a good metaphor because, as we all know, a chain is only as good as its weakest link. A security deficiency on the Transport layer can result in catastrophe even though the other six layers are well protected. Or a problem with the Network layer, or a mis-appropriated Session. It doesn’t take more than one to take down the whole.

This is analogous to the deployment of security measures across a company or other organization. So many of today’s most popular threats employ “human engineering” meaning they attack by fooling a human into doing something that compromises network security. Beyond doubt, that means that effective data and network security is the responsibility of everyone in any organization.

That includes the software developers and the network operators, especially so. Developers are constantly introducing new code which could potentially contain new opportunities for compromise. As such, they must be particularly diligent in protecting the network. Network operators must be on high alert to detect anomalies that may indicate a breach. LoB managers and their teams, facilities people, communications people, literally everyone must remain vigilant. One weak link breaks the chain.

The DevSecOps Mindset

An extension of DevOps, DevSecOps also extends the mindset and philosophy behind it to include the role and responsibilities of those who enforce security standards. Consistent with its source, DevSecOps is a mindset grounded in cooperation and consistency of tools and processes. Imagine a hacker attempting to compromise your network and coming face-to-face with your entire DevSecOps team. That overwhelming force and effectiveness are the driving forces behind this joining together of three such fundamental groups.

Embedded in the Code

A DevSecOps team doesn’t wait until the code is finished to start thinking about security. The thinking starts with the developers themselves who incorporate sound security strategy even as they construct code. Their thinking is shared with the Security team who “sanity-check” everything to make sure all decision making on the part of development is nicely aligned with security best practices. Operations is informed by this confirmed strategy and acts accordingly to provide constant protection during utilization.

This end-to-end strategy from the start reduces the likelihood of errors later on. Where most systems introduce security measures once the application goes into production, DevSecOps teams work to build security measures right into the application as well as every step after that. By doing so, the developers become aware of and are able to remediate any weaknesses or errors in the code before it is tested, staged, deployed, and put into production.

What Would a Methodology be Without a Manifesto

In earlier segments we introduced the DevOps Manifesto and the Agile Manifesto. Naturally, you would expect there to be a DevSecOps Manifesto. And here it is:

DevSecOps Manifesto

Through Security as Code, we have and will learn that there is simply a better way for security practitioners, like us, to operate and contribute value with less friction. We know we must adapt our ways quickly and foster innovation to ensure data security and privacy issues are not left behind because we were too slow to change.

By developing security as code, we will strive to create awesome products and services, provide insights directly to developers, and generally favor iteration over trying to always come up with the best answer before a deployment. We will operate like developers to make security and compliance available to be consumed as services. We will unlock and unblock new paths to help others see their ideas become a reality.

We won’t simply rely on scanners and reports to make code better. We will attack products and services like an outsider to help you defend what you’ve created. We will learn the loopholes, look for weaknesses, and we will work with you to provide remediation actions instead of long lists of problems for you to solve on your own.

We will not wait for our organizations to fall victim to mistakes and attackers. We will not settle for finding what is already known; instead, we will look for anomalies yet to be detected. We will strive to be a better partner by valuing what you value:

  • Leaning in over Always Saying “No”
  • Data and Security Science over Fear, Uncertainty and Doubt
  • Open Contribution and Collaboration over Security-Only Requirements
  • Consumable Security Services with API’s over Mandated Security Controls and Paperwork
  • Business Driven Security Scores over Rubber Stamp Security
  • Red and Blue Team Exploit Testing over Relying on Scans and Theoretical Vulnerabilities
  • 24×7 Proactive Security Monitoring over Reacting after being Informed of an Incident
  • Shared Threat Intelligence over Keeping Info to Ourselves
  • Compliance Operations over Clipboards and Checklists

Enjoyed This Article? Check Out Our Other DevOps Content