Credit: ID 130101397 © M-sur | Dreamstime.com
Conventional views of credential compromise may focus on external activities such as mass credential-stuffing attacks and password-stealing malware, but new breach-compromise statistics suggest that the fast-paced adoption of cloud and associated DevOps techniques has created other vulnerabilities that CISOs still don’t fully appreciate.
Those vulnerabilities emerge during the frenetic process of designing, writing, building, testing, releasing, deploying, operating, monitoring, and revising applications, a recent CyberArk report warned.
Each of these stages involves access to cloud-based platforms and services, with developers often given powerful access credentials to bypass barriers that might slow down the DevOps process.
“The culture of DevOps emphasizes high velocity, intensive sharing of code, ad-hoc tooling, and full-on automation,” the report’s authors noted. “In this culture, low-security shortcuts often flourish and traditional security processes are not easy to integrate.”
Yet that approach can easily backfire if those super-user accounts are somehow compromised. In one scenario, for example, an attacker using stolen credentials can log into the master server, then change configuration files to give themselves a privileged account on every host machine in the target company’s network.
This approach gives attackers access to all of the company’s cloud-based data, applications, and other resources – the risks of which were painfully learned in 2014 when project-management provider Code Spaces was forced to shut down after attackers stole its Amazon Web Services (AWS) keys, ransomed the company’s data, and deleted its data and backups when the company tried to recover its data.
Privileged access is not a commodity
The increasing use of highly-privileged tools for container management, container orchestration, and configuration management has exacerbated the problem, leaving transformation and growth-minded companies struggling to protect their credentials the way they need to.
Compromised DevOps practitioners’ credentials, for example, allow attackers to operate DevOps tools, access code repositories, access databases and production systems, and manage cloud resources.
Credentials for DevOps tools and scripts would give attackers the ability to operate other DevOps tools, access code repositories, access databases and production systems, and manage cloud resources. And stolen credentials for DevOps-built applications would allow a malicious outsider to access databases and production systems, and to manage a target company’s cloud resources.
The potential exposure from compromised credentials means these areas need to be well and truly locked down if DevOps is to work effectively as a mechanism not only for getting businesses into the cloud, but getting them there safely.
Yet poor practices abound, with one recent GitHub scan identifying more than 200,000 hosts that had had credentials hard-coded into production code to speed testing and deployment.
Tesla was hit when attackers identified an unprotected Kubernetes console, which was accessed to extract AWS access keys and install cryptocurrency mining software. And Uber was attacked after a developer stored administrator-level AWS access keys in the company’s code repository.
Such incidents remain quite common, if a new analysis of Australian data breaches is any indication. New statistics gauging the performance of the notifiable data breaches (NDB) scheme found that 75 percent of the 262 incidents reported during the quarter involved the use of compromised or stolen credentials.
Where DevOps and security collide
With more users, devices, and applications requiring high-level credentials, new automation tools have become an intrinsic part of the DevOps security defence – particularly as attackers use increasingly sophisticated algorithm-driven bots to shape, iterate, and execute their attacks.
Fortinet global security strategist Derek Manky recently told CSO Australia that companies need to be prepared with the tools to respond to attempted and successful attacks within “seconds if not microseconds”.
“Having automation in your security stack is really important,” he explained. “All too often, there is too much security gear out there and they are not integrated. But things like adding Access Control Lists need to be done in an automated fashion, and not by relying on human administrators to do that.”
“DevOps teams sometimes need a little help to connect those dots – and it’s a good investment to have those resources stacked up a bit on the defence side. The more the facilitator of the crime is not a human, it gets tougher and tougher.”
To bolster security throughout the DevOps process, the Cyberark report recommends that businesses pursue strategies such as transforming the security team into DevOps partners – for example, by training security professionals in development and development professionals in security – and developing a systematic approach to getting developers to think like hackers.
Businesses should prioritise securing DevOps tools and infrastructure; set enterprise standards for securing credentials and secrets in DevOps and cloud environments; adapt security processes to accommodate continuous application-testing processes; and continually evaluate the results of the change program to ensure that it is, even incrementally, improving the overall security of the process.