DevSecOps – Can We Be Fast and Safe?

~ Written by Vic Laurel

The Currency of Trust

In many businesses, it’s become the norm for employees to bring their own devices to work and fire up their own environments without implementing a company-wide, standard security policy. These days applications are never really complete, they evolve continuously, so tagging security on at the end simply isn’t an option – and let’s be honest it wasn’t really an effective choice even pre-DevOps! Developers’ biggest concern is that, now they’ve finally achieved innovation at speed, properly securing their applications will slow down development, testing and production. According to Capgemini’s “The Currency of Trust” report, this is even prevalent in more risk-averse sectors, as “one in two banks and insurers have inadequate data security frameworks or privacy policies”.

So what are the security challenges brought about by Agile and DevOps and how can you overcome them?

DevOps Security Challenges

TLS Keys & Certificates

We often see that conventional internal security processes such as requesting transport layer security (TLS) keys and certificates take too much time to be viable in a DevOps environment. For example the containerisation and orchestration associated with DevOps requires these security measures to be available immediately and, if they aren’t, people tend to use unreliable shortcuts such as duplicate keys and weak encryption. 

Mindset

Before DevOps, security was traditionally seen as “someone else’s responsibility”. Now, the risks associated with multi-tenant cloud environments and the costly, high profile cyberattacks of recent years demonstrate that everyone needs to be accountable. Gartner refers to this as a “trust and verify” mindset.

User Accounts

This is a prolific weak spot because once a hacker has your account details they can hijack your whole environment. If your developers have access to development, test and production environments from their user accounts, then all of these will become compromised.

Cloud Providers’ Responsibilities

Cloud providers like Amazon Web Services deploy high level security for their own data centers and hardware. They also provide security tools to customers but, ultimately, the customer remains responsible for the security of their own infrastructure and applications.

To avoid expensive, reputation-damaging security breaches and attacks, businesses need to adopt a new DevSecOps mindset. In practical terms, they need to take a shift left approach to creating a highly automated and integrated security strategy with secure infrastructure; network rules; secure design patterns; security testing; security reviews; and an accessible security policy and handbook.

DevOps Security Solutions

Here is an outline of some of the security measures you can take to secure your DevOps way of working:

1. Shift left and take a security-driven approach with comprehensive security testing, as opposed to a purely developer-driven approach.
2. Allow the security team access to implement a comprehensive Security Review of networks and pathways during the development process to lay the groundwork for secure testing and deployment.
3. As Gartner says in their report on DevSecOps “Information security architects must integrate security at multiple points into DevOps workflows in a collaborative way that is largely transparent to developers, and preserves the teamwork, agility and speed of DevOps and agile development environments, delivering ‘DevSecOps’”
4. Start by using firewalls and virtual local area networks (VLANs) to create secure development, test, and production environments that have the same configurations across the board.
5. Apply inbuilt security to cloud images when creating them and ensure security tools are pre-configured allowing developers to deploy off these secure images so that self-service is also a secure service.
6. Avoid user accounts whenever possible. Where you would usually use new accounts for provisioning and scaling, good cloud providers like Amazon provide APIs that will do the job so you don’t need to open the accounts and risk your security.  Where you must use accounts start all at the most basic privilege level and only provision them up when the standard security protocol is followed.
7. Selecting a provider like Amazon Web Services that enables you to create multifactor authentication on all accounts, is a must. Create separate accounts for developers, operations teams and testers, so that no one is sharing passwords, and use separate AWS accounts to isolate different environments.
8. Where totally separate accounts are not possible, ensure each environment requires a different key to prevent cross connections and make it a prerequisite for developers to apply to the Security Team for a key.
9. Ensure developers are comfortable with the security strategy and realise we can be fast and safe
10. When you need to make changes try to implement them simultaneously on the development, test, and production environments so they are standardised across the lifecycle and any weaknesses that materialise can be addressed in all 3 areas at once.
11. Automate the processes required to request security access so it is faster and standardised throughout the business
12. Shift testing left and carry out comprehensive security testing on all cloud environments, instantly escalating any issues for immediate tightening up.
13. Cloud providers like Amazon Web Services provide solid security tools, so make sure you implement them and back them up with their non-security tools, while remembering that it is still necessary for you to architect your own environment.
14. Ensure everything is backed up, not just to another cloud environment but also in an offline archive, if you have space, or if you are in an industry that is heavily regulated and requires it.
15. When creating and implementing your DevSecOps strategy make sure that the measures you take (and the end results) are GDPR compliant – check out our GDPR assessment and our GDPR blog for setting out an effective strategy.