Ensuring DevOps is secure
How can organisations keep DevOps secure from malicious activity and the creation of unauthorised backdoors into sensitive systems?
When it burst on to the scene around a decade ago, DevOps was seen as the best new way to streamline the process for creating and delivering apps and other services to clients. With greatly reduced time to market, organisations can beat their competitors to the punch in releasing apps that meet their clients’ needs and create valuable revenue streams. However, with greater efficiencies in deploying apps come greater potential security risks that a DevOps team must address. Specifically, with so many professionals needing to access a range of different assets quickly, serious consideration needs to be given to privilege access management.
The rise of DevOps
Before DevOps, creating a new app used to be an arduous task for any organisation. Traditionally engineers and developers would work on code for applications in silos and then pass the product on to operations to figure out how to deploy it. This was a time-consuming process as each team worked separately and often had to wait for sections to be completed or to receive feedback before they could carry on with their work.
Developers would write code in the development environment, but as this code might have to be manipulated to ensure it would fit into the production environment bugs could appear. The result would be a delay until the bugs were fixed. Having to wait for each team to finish their work would inevitably lead to bottlenecks that slowed the entire development process down sometimes causing delays that amount to years.
In bringing development and operations together, DevOps makes the deployment of solutions easier and faster, eliminating much of the delay without having to depend on any team passing their work onto another, also known as “throwing their work back over the wall” due to the obvious barriers.
Small teams now work on different components of an app, creating smaller micro services and applications that don’t have the baseline requirements they would have had in larger projects, making them much more versatile and mobile. During this process, these teams can test and verify each other’s code to make the coding more consistent with less bugs. This also allows people to play to their strengths – such database, or front-end.
A key part of making DevOps work is automation. Anything that can be automated should be, such as infrastructure, workflows and so on.
This ultimately means that it is much more of a continuous integration effort where updates are done in small steps. Whereas there used to be large product developments released once a year, smaller updates can be achieved and released in days or even hours.
- DevOps disruptors in 2019
The risks posed by DevOps
However, having so many different people creating and accessing so many different elements, means more credentials are required, increasing the attack surface for threat actors to target. There is also the issue that, as DevOps is seen to be more streamlined and efficient, users might try to take this too far by trying to shortcut or flout security measures to save time. Many have focused on ease of use and time to market by sacrificing security.
For example, developers could embed hardcoded credentials into a programme to save them from having to remember a different set of login details for each asset they need to use. Even worse, the credentials for each asset might then be the same. This is an obvious security flaw that would enable cybercriminals to more easily breach the defences of the DevOps pipeline.
We see this time after time, particularly with data buckets where coders need to have access to data. What can happen is that rather than using an integrated identity management solution, developers tend to use the same credentials in container after container for the sake of ease-of-use and simplicity. So, when a compromise happens, the next time the environment is spun up again, cybercriminals can regain access because the credentials are the same ones that have been used over time rather than having been rotated or changed.
The greater danger comes when this ‘shortcut’ combines with a fundamental element of DevOps – scaling. To improve efficiencies a DevOps team can use configuration management code in building infrastructure and scale servers, effectively creating clones of the original server. If a virtual machine is cloned 100 times, then the credentials will be cloned 100 times too. This results in credential sprawl, which is very difficult to bring back under control at a later date.
Mitigating the risks
- DevOps necessary for business success
The Open Web Application Security Project (OWASP) highlights defining security from the beginning by design as one of its top ten proactive security controls for developers. Other controls include leveraging different security frameworks, validating end points, implementing digital activity, enforcing access controls, protecting data, as well as the logging and monitoring of all activity.
To mitigate the risks associated with the DevOps pipeline, security needs to be considered from the beginning and by design to ensure safeguarding practices are part of the design and integral to the whole process.
Security must be a culture within everyone’s organisation, because it affects everybody, and it needs to be part of the deployment. The last thing you want to do is to figure out how to add security afterwards, as it is time consuming and costly sometimes even impossible without changing the product.
Using PAM to ensure and streamline security
With regards to leveraging different security frameworks, DevOps professionals should look to privileged access management (PAM), which is being used across organisations to secure their networks. Like DevOps, PAM uses automation to make processes more streamlined, but in relation to access security.
Through PAM, credentials and passwords for each element and user in the DevOps process are unique, rotated and augmented by tokens. The human user does not even necessarily need to know what these credentials are, so the risk of human mistakes is reduced too. No longer will DevOps professionals be able to inadvertently leave clues to their credentials exposed to cybercriminals. This makes the environment much more secure and also each time it gets spun up the credentials get rotated.
Streamlining processes to cut down on resources and time to market is an attractive prospect for any business. Yet this must not be done at the expense of security, otherwise DevOps could end up costing more time, money and reputation damage than a business was expecting. So, when bringing it all together, make sure security is top of the list.