DevOps to DevsecOps

DevOps is a culture of collaboration between teams, Developers and Operations who have traditionally operated in silos working together towards a common goal, in essence, this allows teams to release software faster and more reliably.

The word DevOps has been going around for a few years now and most organisations have embraced this and are now implementing this into their organisations.

But what about security?

Most regulated environments such as banks also have a security team so this is where DevSecOps comes in, Developers, Security and Operations teams working together building on a mindset of “everyone is responsible for security” allowing teams to release secure software faster and more reliably.

Mixing old with New

Banks are finally embracing new practices such as DevOps, Agile and looking to embrace Public Cloud Services and Containers.

However traditional security process are still being used and are a major roadblock, e.g. securing containers is vastly different from securing virtual machines and monitoring a public cloud is different from monitoring servers in a data centre.

The aim of the game is to release faster, traditional security at best will slow you down or at worst will prevent you from going into production at all.

In order to avoid this, we have to start thinking differently about security.

Shift Left & Secure Software Development Life Cycle (SSDLC)

Most have heard of the Software Development Lifecycle (SDLC) but what about the Secure Software Development Lifecycle (SSDLC).

Shifting left and trying to put the emphasis on security from the earliest stages and ensuring that security is baked into the SDLC from the start will ensure that you can move into production as quickly as possible.

When embracing the DevSecOps we end up with a DevOps figure of 8 similar to that below, remember that security should be part of every stage:

devops to devsecops process

So what do we add to each stage:

Plan with Security at the start

Traditionally security came into the picture once the application was ready to go into production, the problem with this is that usually by then it’s too late.

Remember the idea behind DevOps is to get into PRODUCTION as quickly as possible & the idea behind DevSecOps is to ensure that whatever you are deploying is also secure.

Shifting left and ensuring security is alway been thought about is key and thinking about at the planning stage will ensure you build to succeed.

Code – We are all human & Open Source

Developers are human, humans make mistakes and can end up writing insecure code. It’s never intentional but it does happen. Open source is fast becoming a standard however have you ever asked about its composition? Does this library follow the same strict security guidelines in place in your organisation?

Static Code Analysis and Software Composition Analysis tools which are baked into the IDE allow developers to identify security holes in the code whilst they are writing the code allowing them to change things quickly rather than further down the line.

Build – Containers, they are everywhere

“Tailor the organisation’s operational culture and technical processes to support the new way of developing, running and supporting applications made possible by containers”

NIST Special Publication 2017

Containers are everywhere and for the near future at least are here to stay, however, it is key to ensure organisations are operationally ready for containers. Organisations should encourage the use of purpose built container image which has been approved by the security team. Containers should be scanned to ensure that no vulnerabilities are found as early as possible.

Test – Shift Left

Penetration testing is something that most regulated organisations, these are quite expensive and if vulnerabilities are found then chances are another one will have to be scheduled to ensure the vulnerabilities have been fixed.

There are tools on the market which allows for an internal penetration test to be done. Again we are shifting left as much as we can by identifying issues before the external test is conducted.

Dynamic Application Security Testing also plays an important part, this is when a tester examines an application when it is running and tries to hack it as an attacker would. Once again there are tools available for this so it can be automated allowing issues to be discovered as soon as possible.

DEPLOY & OPERATE

When WAF is just not enough

Most people have heard of Web Application Firewall (WAF) however this provides perimeter based protection essentially detecting and blocking attacks by using network information rather than contextual awareness.

Runtime Application Self Protection (RASP) technology allows for contextual awareness, an application is installed with a RASP wrapper and its this RASP wrapper that is monitoring the application from a threat perspective.

When a threat is detected RASP can prevent exploitation and take other actions, including terminating a user’s session, shutting the application down, alerting security personnel and sending a warning to the user. RASP aims to close the gap left by application security testing and network perimeter controls, neither of which have enough insight into real-time data to either prevent vulnerabilities slipping through the review process or block new threats that were unforeseen during development.

Secrets Management

How many times have we heard a story where a secret such as a database credential has been uploaded to a public repository? Or that system was hacked due to a hacker getting hold of a key?

Secrets Management ensures that all secrets such as a database credential are accessed via a secure API, secrets can also be revoked, rotated or even dynamically created for every request.

Implementing secrets management is key in today’s world where new regulations coming into force and with more organisations moving to public cloud.

Monitor – But not the way you use to

In the days of the data centre intrusion detection devices (IDS) were installed to monitor network traffic for suspicious activity and issue alerts when activity was detected.

In public cloud intrusion detection has to be thought about differently, for a start you don’t have access to the underlying infrastructure & as mentioned earlier we are living in a container world with hundreds if not thousands of services to manage.

AppSec security is the best way to monitor your application, the application is deployed with a “micro agent” which not only monitors for secure-coding mistakes in order to flag to the users but also monitors the application for malicious behaviour. With AppSec monitoring you can block attacks such as Cross Site Scripting in real time, used together with RASP you can make intelligent decisions about what to do next, including disabling the application completely.

Report Immediately 

If at any point security has been violated whether it’s with unsecure code being picked up at the build stage, at testing or malicious behaviour is detected once in production – Ensure this is flagged straight away and the right people notified, this should be an automated process. In today’s world, everything should be automated so escalations are part of this.

Conclusion

DevOps bought developers and operations together and many teams who have embraced it have seen and reaped the benefits. DevSecOps is the next step in the evolution of DevOps, organisations that want to unite operations, security and developers need to integrate security into their pipelines with the objective being to make security a core component of software development from the start rather than retrofitting it later.

However, it’s a mindset change and it starts with realising that “normal” security practices won’t be effective in the new world. However DevSecOps is maturing and the tools that will help organisations get there are available with many of them open source, the key is ensuring that organisation start as they mean to go along – Thinking about security as early as possible and not when it’s too late.