DevSecOps: an approach

Methodologies for security operations

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

That’s the manifesto for the DevSecOps movement, in the classic style of Agile and DevOps ones.
DevSecOps is, clearly, the addition of security in development operations.
What I wanted to research is what these security operations are, in a wider way than a simple “develop more secure software” approach.

Keeping the manifesto as a reference, let’s see the different kinds of security operations: the development ones, the IT monitoring ones and the more strictly security-related ones.
Since different organizations require different approaches to information security operations, I’ll consider as a subject a company (SMB) which makes online-only business, like online counseling, with an internal infrastructure that involves just a LAN, a local server for development purposes (version control, testing) and a dedicated server for production deployment.
I’ll also assume that the development team is Agile-minded and that there’s an IT manager who’s responsible for sysadmin duties, without any other security related roles.

Rugged Software

The first aspect is the most evident one: secure coding.
Respecting the principle of “leaning in”, security operations should be easily integrable in the daily development routines.
A team that normally unit tests its codebase is prone to accept what we are calling here unit security testing.

Probably many teams already do that: unit testing the codebase against specific bugs or vulnerabilities in code. And that’s good.
Many teams already integrate also an issue tracking system (like github/lab, launchpad, trac) that manages the bug’s status and gives IDs to the bugs reported. And that’s good too. But we want more.
So we integrate this two practices by policing that every bug tracked and confirmed on the bug tracking system should correspond to a unit test that asserts if the bug or vulnerability (let’s use the term issue) is present or not.
And also the other way round. If the usual process of unit testing (or development itself) reveals issues, they should be tracked on the issue tracking system to be checked and fixed.

But to make this sytem become a truly security operational methodology, we’ll play the the threat modeling card.
As explained in the great Threat Modeling: designing for security book, threat modeling requires a framework acting like an issue tracking system in which integrate vulnerability tracking informations like CVE/CWE IDs, the STRIDE category and other useful descriptions.

In this context some time ago I developed a dummy threat model tracker to use as a framework in the process of threat modeling, referring to the methodology of OWASP and of the aforementioned book.

Sticking with this method we can integrate this threat modeling features into existing issue tracking systems to have a valuable tool for security operations.

Icing on the cake: threat intelligence. One of the daily tasks for an eventual SecOps guy could be matching the constant flow of threats from threat intelligence sources with the codebase or IT organization. Potential threats which apply to the organization will be inserted in the issue tracking system, unit tested against and ultimately (hopefully) fixed. This way much more vulnerabilities are addressed and a more secure codebase is built.

Monitoring

Let’s give a look now to the monitoring aspect of DevSecOps.
A lot of emphasis is put on this aspect, and for no overestimated reason.
Constant monitoring, done properly, is a kind of risk mitigation practice. Choosing this approach over Incident Response, as the principles advice, is a smart choice but it’s better not to forget the old saying: “the problem it’s not if you’ll get breached. It’s when”.
By the way, let’s find a good approach to this aspect too.
We all know Elasticsearch. It became so famous that we now talk not only about ELK stack (Elasticsearch, Logstash, Kibana) but about ELK-as-a-service.
With this kind of technology available, we have open source software to easily integrate data anlysis tools for security purposes.
We can do this by integrating network security monitoring tools like Bro with the ELK stack, perhaps with an ad-hoc linux distro like Security Onion.

The main task of the eventual SecOps guy I mentioned above in a company would be monitoring the network, the servers and the endpoints for suspect activity, educating the IDS (Bro is analysis-driven) to block malicious or out-of-boundary activities. This can be done by protocol (SSH, VPN etc) and threat intelligence external sources can automatically build rules to block malware activity by recognising its indicators of compromise.

Vulnerability Assessment

So far we identified at least three security operations: Unit Security Testing, Threat Modeling and Network Security Monitoring.
But there’s more. Penetration testing and vulnerability scanning are security operations in its most traditional sense. DevSecOps principles advice to prefer Red & Blue pentesting over vulnerability scanning. While that’s true (we’ll see why in a moment), I see vulnerability scanning as a valuable practice too, especially for systems with a low changing rate.
Vulnerability scans can be mostly automated, and that’s crucial. Automation is great for Agile, and makes possibile to add additional, undemanding controls to close security holes that would be otherwise unsupervised.

Coming to penetration testing, there’s a reason because the Red & Blue team method is better than other methods.
When there’s a division between a red team (attacker, usually external professionals) and a blue team (defender, usually internal), the simple fact that there’s this kind of scenario in place creates a sort of “arms race”, that is educational by itself.
Going further, the attacking and defensive activities permit to the IT management to build and improve the security posture, while other formulas of vulnerability assessment doesn’t have this didactic function.

Other common security operations are Compliace Ops, as in the last principle of DevSecOps.
With Compliance Ops we mean an un-bureaucratic and more free way of getting compliant with the chosen standard (ISO 27001, PCI-DSS, OWASP).
With DevSecOps adoption in a firm like the one we’re considering as a reference, this operations can become physiological by putting strategic compliace testing points in the security development lifecycle flow.
This point is critical to adhere also with other principles of the movement, like open contribution and the business driven security.

For example a firm can build a score system that’s more respectful of its own business model using as a reference the various open source security testing and code review manuals like OSSTMM and OWASP ones.
By sharing their experience companies can also create a pool of open and freely accessible security manuals that would increase the overall level of availability of business-specific security frameworks.
With the same spirit, the vulnerabilities discovered can be shared via existing threat intelligence exchange projects, adhering with another manifesto’s principle as well.

Conclusion

We can see that the DevSecOps practices are fit to get security inside an organization in the most physiological way by simply adopt a framework of security operations that is compatible with Agile and DevOps and requires little employees injection and commitment thanks to a good amount of automation.

This movement is probably the best security culture to adhere to right now without being caught in the net of consultants and expensive commercial solutions while staying at the same time in the mindset of open source.