DevSecOps and its principles

Speaking at the National DevOps Conference in June this year, I was amazed by two things from the audience’s answers regarding basic security practices.

When I spoke about security and DevOps in my session at the National DevOps Conference in June this year, hosted at the fabulous British Museum in London, I was amazed by two things. Firstly, the sheer interest in the subject and, secondly, my shock at the answers the audience gave when asking them about some basic security practices at their organisations.

Today, due to the lengths most companies are going to provide employees with information on protecting themselves and their organisation from cyber-threats, I expected engineers and managers in our field to know more. The biggest shock was the discovery that a third of the room admitted, via a show of hands, that they believe security to be less of a concern in a more highly-automated world.

This made the delivery of my session even more passionate. I’ll say this now, security is not optional, nothing replaces security, regardless of what form it comes in. In an automated world, we need intelligence to understand the process, find out when it has become compromised and have the tools available to look at that data and find out why, what has the attacker got, and how do we prevent it again?

The answer to this solution is DevSecOps.

What is this, I hear you say? I’ve only just got used to the DevOps methodologies. Add security to the mix, some monitoring and analytics, and you have DevSecOps: security wraps around the whole existing DevOps process, with tooling to provide monitoring and analytics sitting in the middle of both Dev and Ops, to provide insights to our security posture.

Principles of DevSecOps

In order to begin implementing DevSecOps at your organisation you need six key principles to follow. You could add a seventh, but this should be inherent in your organisation anyway – the culture to embrace this change:

• deliver small, frequent releases using agile methodologies
• wherever possible, make use of automated testing
• empower developers to influence security changes
• ensure you are in a continuous state of compliance
• be prepared for threats, always invest in advanced training for your engineers.

Let’s start to break these down in more detail. Some of these principles are no different to the day-to-day standard DevOps practices. I want to focus on three of these principles:

• wherever possible, make use of automated testing
• empower developers to influence security changes
• be prepared for threats, always.

Let’s discuss automated testing, DevOps is all about automation, and automation is proven to provide more consistent, error-free results. One field of IT where the use of highly consistent testing regimes produces consistent, error-free results, is security.

In my opinion, without automation you cannot say your solutions are tested from a security perspective consistently. A solid security testing plan, which is automated, provides you with confidence that the results of your security scan are performed in an idempotent way, which is removed from bias.

Automation drives DevSecOps

Run automated tests and dependency checks at every stage of the dev pipeline Think of this from an audit perspective for a minute, an auditor is more likely to have much more confidence in a security test which is automated, ran every time, without modification and produces standard results. Rather than tests which are sporadic, ran by different people, under different conditions and produces non-standard results.

Another keyphrase for anyone in any organisation: everyone is responsible for security. I really do mean everyone, regardless of the role they perform within an organisation. Empowering your teams with tools and expertise to respond to (and neutralise) threats before they become a major issue is a huge benefit to your organisation. The people who engineer your products know it better than anyone else, with appropriate training, industry skills and the tooling, they can be empowered to make their product safer from the point of development, without having to react to a compromised application or service.

Give people in your organisation these skills and capabilities, it will make your products safer, this in turns keeps your customers and their data safer. Together with this, grow a culture of no blame, this is vitally important, and like DevOps is not about technology or process, it is about encouraging people to speak up and arming them to do the right thing. The more you enable this, the quicker you can resolve security threats before they leave the development environment.

Finally, one of the principles of DevSecOps is to be prepared for threats, always. Countless times you hear the words, “it won’t happen to us”, “nobody wants to hack us”. Think again, especially if you hold personal data or financial data, you are a prime target.

According to Cybint Solutions (cybintsolutions.com/cyber-security-facts-stats) 43% of small businesses are targeted by cyber-attacks and the total cost for cybercrime committed globally has added up to over $1 trillion dollars in 2018. As long as you’re connected to the Internet, you can become a victim of cyber-attacks.

In order to know if your DevSecOps strategy is successful, you really need to measure your operations to ensure you can measure success.

Defect density

This is a simple measure, but also a powerful one. Simply take the number of reported security related defects and divide that by the size of the module. By having the security team and developers work together to set a target, it can serve to reduce the percentage of security defects and also decide if software should be released.

Risk profiling

The second metric is focusing on prioritisation, this is an important one. Instead of throwing lists of vulnerabilities to the DevOps team, security professionals can start working on the analysis of defects based on criticality, this adds value, a whole lot of value, as it makes it really simple for DevOps teams to know what order is best to work through those existing defects.

SLA’s

The trusty measure of success in any walk of life, especially in IT: how well am I performing? Simply answered by measuring your success against service level agreements. You should look at agreeing SLAs based on defect severity, committing to fix times for different levels of severity.

Vulnerability types & recurring bugs

Understanding which vulnerability types are coming back and which recurring bugs are coming back time again can help plan training, maybe your team need training in a specific area? Tracking this monthly highlights trends with the ever-changing landscape of applications.

Build a strong DevSecOps culture

One of the hardest things to do in an organisation is to transform the culture of an organisation, doing this successfully is the one single, most powerful thing you can do to change your organisation towards adopting a DevSecOps culture.

Remember, one size does not fit all, just like ITIL, DevOps and other frameworks, it doesn’t mean implementing everything, it doesn’t mean changing to fit around the framework. More than one model exists to implement DevSecOps; take parts of more than one model and adapt it to your organisation, this is the best path for success.

When DevOps came, you thought the friction between development and operational teams was bad – compared to traditional security teams isolated away, this is simple. Transparency must be at the centre of everything you do in this model. People believe making the security team a silo, helps. It doesn’t, all it does is make it harder for them to explain what they do and how they do it – this is all about people and process.

Silos destroy the DevOps culture, as we’ve already discussed, when it comes to security, everyone is responsible. How can you do this if your security team are hidden away somewhere in head office?

Security works best when it is hidden in plain sight. For that reason, consider DevSecOps just DevOps. Security, as I’ve mentioned, should be integral to what you do and thus should not get in the way. You can both empower teams and help make security silent in this model by letting teams use open source testing tools to improve the security of their stack. Security sets the ground rules, that’s it.

Final thoughts

As we end, I want to recap on the key things we have discussed. If you take anything from this article, I would like you to go off and research how you can improve your application or infrastructure by changing one thing in your day-to-day role. This is how you can directly improve and influence the security posture of your organisation.

In order to successfully implement DevSecOps you will need to think heavily about automated testing, this, as well as empowering your team, is fundamental to achieving your goal of implementing DevSecOps.

Take these points, the principles of DevSecOps, how you measure success, and the pillars of building a strong culture, to go off and implement your own model.

All of these things will give you the best possible chance along with all the online resources to make your organisation, your products and your customers, more secure.

The last thing I want to mention in this piece is sharing of intelligence data. One of the biggest debates in security, do you keep it to yourself or do you share vulnerabilities and threats? DevSecOps believes and teaches that sharing is better, it helps others learn, develop and improve the security of products we use day to day, keeping the good guys ahead of the bad guys.

As I mentioned toward the end of the article, transparency is key to building trust and building trust is the key to creating the right culture to develop.

Martyn Coupland
Director
Ensono