How to secure DevOps from the start
More streamlined, efficient and offering an accelerated time to market, DevOps has been a revelation to any business developing and releasing apps and digital services.
Yet by creating such a slick digital production line, many organisations could be unwittingly sacrificing security in the process. This is due to various factors including an increased attack surface.
Plus, in their quest for speed, DevOps professionals potentially taking shortcuts that are leaving their systems open to exploitation. Fortunately, many of these can be mitigated through the use of privilege access management (PAM).
Everyone gets stuck in
The primary reason that most organisations decide to take a DevOps approach is the simple fact that it is quicker than what went before, much quicker. Deployments that used to take months or even years can be achieved in days.
One piece of research from DevOps Research and Assessment (DORA) and Google Cloud suggests that elite DevOps teams have a lead time from commit to deploy that is as much as 2,555 times faster than traditional methods.
Such eye-watering speed can be achieved because the DevOps approach uses automation to streamline processes and allows more or less everyone to work on their element of the project at the same time.
That is a huge change from how things used to be, when the app production line was made of many isolated teams, each waiting for the developing app to be passed along before they could make their contribution.
For example, development engineers would write code in the development environment, which would then be sent to operations who had been eagerly waiting to insert it into the production environment.
Unfortunately, as these environments were different, the code would have to be changed to fit, which could often result in errors that would need to be fixed.
With DevOps, different elements of an app are worked on by small teams of coders who can test each other’s work to eliminate bugs and ensure consistency.
A potentially very serious downside to this is that with so many people accessing so many different elements, i.e. database or front end, it creates a greatly increased attack surface for cyber criminals to target.
The need for speed
As discussed, a significant motivator for implementing DevOps is the dramatically reduced time to market for apps and services.
The speed at which products can be released has become business critical in attracting and retaining customers, mostly in an attempt to have a unique proposition on to the market before competitors catch up.
With so much relying on how quickly the DevOps process can happen, there is likely to be the feeling among DevOps professionals that anything they can do to help improve its speed is acceptable.
Unfortunately, if organisations don’t have the right security procedures and processes in place from the start, this could result in DevOps professionals taking unnecessary risks.
One such risk concerns trying to remember the login details for every single asset they need to access – for instance they might require a username and password for GitHub, CircleCI and Amazon AWS for starters.
A shortcut that developers might use to get around this could be to have the same security credentials for every asset. In the event that the credentials are different, again developers are unlikely to want to keep tabs on each one.
So, some might be tempted to embed them into a programme to save looking them up. Both of these practices might be seen to be saving time.
However, they also introduce serious security risks that could end up jeopardising not only the integrity of the product, but also the organisation as a whole and are best avoided.
We keep seeing these types of “shortcut” happening time and again, especially in relation to data buckets. Buckets are used to organise and control access to data necessary for a specific DevOps process.
However, as there are often many of them and they all need to be accessed on a regular basis, developers might use the same login credentials for every single one.
The implication is that if a threat actor gets the credentials to one container, they get them to all.
The risks can be exacerbated when scaling is brought into the equation. Scaling is a key element of the DevOps process, allowing the rapid and automated creation of infrastructure to support the development of an app.
It does this by making a clone of the original server over and over again, which means that if the right procedures are not in place, credentials will be duplicated across all instances of the server.
This results in credential sprawl, a clear security risk which is very difficult to redress once it has happened.
Secure from the start
Because DevOps is all about speed, once the process gets going nobody wants to have to halt it halfway through to change a whole lot of elements to make it more secure.
It would be like stopping a Formula 1 car during a Grand Prix to change the braking system for a better one – the result would be a lost race, reputation and revenue.
Instead, organisations need to think about security from the very beginning, making it part of the work culture. In this way everyone should be thinking about how secure their actions are at every stage of the process.
This is highlighted by the Open Web Application Security Project (OWASP), which has security by design as one of its top proactive security controls for developers.
Don’t just automate the process, automate security
To ensure the DevOps process is both secure and not slowed down by those working on it having to remember their security credentials, PAM should be deployed.
This approach uses automation to ensure that every user’s credentials for each asset they need to access are unique, rotated and augmented by tokens.
This eliminates the issue of users worrying about forgetting their login details as they don’t ever need to know what they are in the first place.
As they don’t have access to their credentials, there is also the added advantage that users can’t write them down somewhere, creating the risk that a threat actor could steal them.
The old adage more haste less speed has never been more true when it comes to DevOps. Rush in without thinking about security from the get-go and all that time and money saved could be wiped out by a security breach.
As such, security needs to be the first consideration in the DevOps pipeline.