As demands increase on speed to deliver new software, services and value are increasing for all enterprises, including government departments, banks, and critical infrastructure, the agile new development mode ‘DevOps’ is taking hold.
While new tools and technologies are being spun up at a rapid rate in a bid to fulfil consumer expectations, security teams have been left with the unenviable task of racing to secure and manage them, often retrospectively.
A huge new attack surface is established by the creation of privileged credentials and secrets throughout the DevOps pipeline, leaving a substantial remediation task for security teams. And as the world of business continues on its forward trajectory, both DevOps and security teams have to deliver without compromising on either innovation or security.
As a CISO, it’s more important than ever to manage your teams as they deliver on all fronts: speed, agility, security, and compliance. But where do you start?
Firstly, it’s important to realise that you don’t need to be across every single disparate tool and technology on the network in order to manage and secure DevOps environments. In most organisations that would be near-impossible. A strong security strategy requires an API driven, system-based foundation. APIs have become the universal language of software development systems, and the way next generation users and their technologies will interact with security tools moving forward.
Secondly, the security team needs a set of best practices in order to unify the security posture across the business environment. The more the burden of managing security policy, tooling and reporting can be shifted away from the development teams and put back into the control of the security team, the better. You want to avoid scenarios where development teams are creating security solutions in the rush to meet delivery deadlines.
Thirdly, there are some basic ground rules that should be set for development teams (they already know these, but may be sacrificing consistent best practice in favour of speed):
- Do not embed secrets in source control – source code repositories are not secure.
- Minimise privileged access control across your organisation’s entire network and infrastructure. The over-privileging of system accounts can be very risky.
- Micro-segment access to secrets, passwords, SSH keys, etc. is essential in curtailing the impact of a breach or security event. This will also help to minimise “misadventure,” or human errors, which are bound to happen in the fast-paced DevOps environment. In the inevitable event of a breach or misadventure, you will easily be able to revert to a previous environment or rotate a key.
The following considerations should also be on the radar of any CISO grappling with DevOps security:
Securing machine identities
A major challenge in managing privileged access in a DevOps environment is securing paths that have no user involvement. For example, a script that can launch instances in AWS that are all privileged in order to access a key database from the organisation. In this scenario, there is no human contribution, which means there’s no way of tracing it back to a user.
The challenge is: if there’s no user, how do you identify where the infrastructure came from or how it got its permissions? Such privileges are frequently used – sometimes on a minute-to-minute basis. So, it’s important to utilise security tools that can identify machine and system account users, authorise them, and audit their activity, based on your security policy. Such technology is crucial for forensic analysis, minimising privileged access, and ensuring that security posture is consistent and optimised across the network.
Stepping up your privileged account security strategy
Adopting privileged account security is a best practice in mitigating risks associated with DevOps. Crucially, your solution should enable you to curate and automate consistent security policies for access to cloud keys and credentials at the beginning of the development process. Far too often, enterprises rush to secure credentials retrospectively, in order to remain compliant, when its far less of a headache to implement security from the start.
Organisations that have an existing privileged account security strategy in place should look to broaden those solutions across next generation infrastructure. This is called “trust forward”: leveraging existing tools, protocols and certified solutions and extending them to next generation workflows.
Privileged account security best practice incorporates wisdom and experience accumulated over decades, and some practices can’t be abandoned as the technological landscape evolves. Established privileged account security practices must be assessed for their efficacy with new workflows. Sometimes it’s necessary for critical decisions to remain under the authority and accountability of humans, not machines.
Removing the stigma from security
Read more: Intel dangles $250k award for bugs worse than Meltdown-Spectre
Many DevOps teams have had damaging experiences with the timeliness and delivery of security, so it’s paramount that they know speed, agility and resiliency need not be undermined by security. However, ‘islands of security’ – where different teams develop custom solutions to suit their preference – are not acceptable. In order to minimise entry points in the network, an organisation needs a unified security and risk policy across all teams, tools and technologies.
Culturally, it’s also important that DevOps teams acknowledge the essential expertise their security counterparts offer. Security personnel are increasingly equipped technology that has been designed with DevOps in mind. Such tools can effectively unite DevOps and Security teams and practices in a collaborative, agile environment.
When selecting this technology, opt for nimble, scalable solutions and partner with best-of-breed companies that are as forward-thinking as your DevOps environment.
Read more: App-vancing Through Australia's Next Growth Frontier