Trust your devops team

You should not assume that just because your organisation follows a devops culture that your infrastructure and applications are more secure.  Security is just as important as it is adopted in the waterfall methodology This methodology works well for security but not so well for fast paced modern businesses. The waterfall methodology is widely adopted and thought of as the ‘right way’ of doing things. Typically each area of the business has a role, those roles engage with security at varying steps throughout the process until deployment in to production is achieved. Lots of documentation and slow processes, but worked.

In DevOps, security needs to be addressed by devops, security needs to shift left. Devops need to apply security principles into their day-to-day working, work with a security mindset and most important of all, adopt a security first approach culture.

A working relationship between devops and security can sometimes be strained. Devops have the impression that security hold up deployments and security feel devops is reckless, either way bottlenecks are created which ultimately impacts the business. A balance needs to be struck; everyone can achieve their goals.

Devops makes use of development and operations teams. They work to an Agile methodology to develop and deploy applications and infrastructure, capitalising on automation, continuous integration and feedback loops. The power of devops is clear, a devops team can quickly deploy new features, enhance existing features, fix bugs multiple times a day in very short time spans, sometimes multiple times a day.

One thing to note is that, development is a continuous process which never ends. There is a reliance on less documentation with devops, things change and need to change quickly and unfortunately security teams have complex forms that need to be completed, long drawn out approval processes and complex change systems. All this really goes against the devops grain.

When devising an Application Security Program which involves an agile devops function you have to think differently. Your strategy needs all the usual ingredients, you need to appease your stakeholders, auditors/regulators and customers that you can deliver services at pace without compromising on security. The shift here though is for devops to incorporate security into their daily activities.

A couple of issues I have seen is that, security teams and architects don’t really understand the devops way, the toolsets and technologies used, how they should be secured and more importantly how they can be abused by malicious threat actors or insiders, let alone how to bake in ‘geberic software development’ requirements, along with this the security teams don’t trust the devops teams to do the right thing.

So this leads me on to the first things we can do – Change the culture.

Education for devops teams is vital and most of the time you will find them extremely receptive, especially to learning new things, so this needs to be capitalised upon. They need to understand why security needs to be at the forefront of everything they do, so be prepared to demo some examples to really hammer home the consequences. Apart from a robust sdlc (which I’m avoiding in this article) you need to think about secure coding skills, how skilled is the engineering team, can they secure the systems they build? How can you help them achieve this, learn and apply what they have learnt? Mix up security training, self-pace, courses, learning from real incidents, keep it continuous and keep it interesting.

As a security team, especially if you are a specialist in your field, you really owe to yourself and the business to keep your skills relevant with modern deployment tools, frameworks and working practices.

Security champions have been used for some time now, and they are a great way to keep security in the picture, keep the culture going and ensure security is part of everything devops does, typically they have responsibility for building security into the development and automation process, remember though they are not there to replace the security team but act as a conduit between the two.

Good design principles

Having a good blueprint and following it is key. Within Devops things are structured, there are numerous resources to read but in essence you want something like the following; and people get bogged down trying to re-invent the wheel, don’t fall into this trap .

Above are some thoughts, more things can be added but for me, Threat Modelling is by far the most important as it drives what the security unit tests will be. Alongside this, Continuous Monitoring and Threat Intelligence. If we think about how attacks happen and what they relate to – vulnerabilities in frameworks, libraries, technologies used etc all pave the way for potential changes and updates.

Fix security from 1st line of codeProvide fast, valuable feedback to devsComprehensive check of application & infrastructureShould follow security traditionsContinuous Security & Lessons Learned 
Threat ModellingStatic code analysisInfrastructure code check – terraform etcSmoke testsContinuous monitoring 
IDE Security PluginsSecurity unit testsSecurity Scanning, OWASP, Containers etcConfiguration checks – No access to CI/CDThreat Intelligence 
Pre-commit hooksDependency ManagementCloud configuration auditsPenetration Testing if requiredRegular Vulnerability Assessments 
Secure coding standardsSecurity Acceptance testing 
Peer review     

One thing to mention is that all this, apart from penetration testing, bug bounties and peer reviews needs to be automated along the pipeline. Your Application Security Program should adopt strong design principles, security test automation, container security and strong feedback loops.

From a security point of view, please don’t forget to have your devops systems pen tested, you definitely don’t want these to get popped!

Read some related articles, and keep checking back for more.  

Leave a Reply

Your email address will not be published. Required fields are marked *