Automated risks – secrets of DevOps security exposed
Source – diginomica.com
The enterprise cyber- and data security landscape is constantly shifting, with new threats bubbling to the surface. One emerging security vulnerability is the booming DevOps environment.
Digital transformation within the organization and the ‘consumerization’ of IT are encouraging many enterprises to bring traditional IT and new product development together under the same management umbrella. DevOps specialists are at the core of this new function. The theory is that they allow the central IT team to support business strategy right across the enterprise, while speeding new products to market.
But as many organizations shift away from the back-room maintenance model of IT and into a continuous development cycle of customer-facing applications, automated tasks proliferate, which means that any security weaknesses risk being replicated and spread by machines.
Many organizations are unaware and underprepared for the explosion of potential vulnerabilities that arises from expanding the DevOps function, suggests a new report from specialist security provider CyberArk, The Threat Landscape Report 2018. It warns that organizations risk having their new apps blocked unless they look at security at code level from the get-go.
According to CyberArk, one of the biggest vulnerabilities is that DevOps ‘secrets’ – such as privileged account credentials, secure shell (SSH) keys, API keys and more – are being disseminated throughout the IT infrastructure, creating new kinds of security risks:
As organizations adopt cloud-based environments and DevOps pipelines, more and more privileged account credentials and secrets are shared across interconnected business ecosystems. Automation tools enable machine-to-machine interactions without human intervention, and consequently rely on machine identities rather than human identities.
While this further helps accelerate the pace and agility of compute environments, it also increases and dynamically creates credentials, secrets and access points – expanding the attack surface, with increased numbers of privileges and credentials, while also enabling vulnerabilities to potentially be more rapidly exploited.
CyberArk spoke to over 1,000 IT security leaders, line of business owners, and DevOps and application specialists in seven countries to compile its report, so the document has more rigour than the many vendor-produced industry surveys that only speak to a handful of their own customers.
The report continues:
Nearly every component of the highly interconnected DevOps ecosystem utilises secrets. But when asked to identify where secrets exist within the organisation’s environment, 38 per cent of respondents did not cite cloud environments, containers, CI/CD tools, microservices, and source code repositories.
Bolstering DevOps security is a challenge for IT leaders because the systems for managing privileged accounts and secrets are not always integrated with DevOps processes, explains the report. Additional challenges include the fact that:
- More critical and regulated workloads are moving to the cloud, creating an additional layer of risk.
- Deployment of virtualised services, containers, and microservices has become so fast that humans cannot monitor and manage them without code-based tools.
- As automated solutions execute tasks traditionally performed by employees, new security gaps are opened at the systems’ interconnections.
In short, traditional security programmes have not kept pace with the new vulnerabilities that are opened up by increased automation.
As more and more tasks are automated in DevOps, the risk of flaws and exploits being shared automatically rises, even as human’s ability to deal with them falls. Together, these problems present a formidable challenge to the security of secrets, says CyberArk:
As a comparatively nascent discipline, DevOps security has not reached the maturity levels of traditional enterprise IT, with a very high number (75 per cent) of security respondents reporting their organisation has not implemented a privileged account security solution for DevOps.
This is potentially problematic, especially in light of 60 per cent of DevOps respondents saying that they store privileged account or administrative passwords in a document on a company PC or laptop. These represent unmanaged, unsecured, high-value accounts.
What to do?
So how did we get to the point of digital business potentially becoming a highly automated attack vehicle for malicious agents, and why should organisations give the problem much greater consideration? Elizabeth Lawler is VP of DevOps security at CyberArk, and founder of open source security service, Conjur. She says:
There has been a tremendous amount of value delivered by the ability to scale infrastructure to meet business needs, and building in application resilience is part and parcel of being able to navigate through digital transformation and deliver awesome software, like Netflix, at scale. And business leaders have seen how well some of these companies have done!
Meanwhile, in many organisations, particularly those that are highly regulated and potentially more traditional, such as financial services, healthcare, and government, there is this huge mass of requirements around security and being able to demonstrate a secure posture.
And what DevOps fundamentally did was potentially switch everything to code, but code isn’t necessarily that human readable or intuitive. It sometimes exists in a black box. And this also makes it difficult for people who are non-techies to interface with the technology people.
So in the new corporate technology model, in which traditional back-end maintenance and a new DevOps-driven front end have been brought together, what new risks should IT leaders be most concerned about? Lawler says:
The fundamental shift that we recognised early on was that we saw the role of the privileged or super user change. That is the super-powerful system administrator of yore is now a set of coded scripts, and you have very little insight or ability to control it.
This often leads to things like embedded passwords in these scripts, or privileges and access tokens, and you have these systems and these tools, such as configuration management, which automate the functions that people used to do. If they become compromised, then you have a very large attack surface for a malicious hacker. That is fundamentally the risk that people are taking on now when they’re doing DevOps.
So what can IT leaders do to remain in control of the attack surface within their increasingly automated environments? Lawler says that the solution isn’t just to lump everything together in security terms with embedded functionality, but to create a purpose-built bridge:
There needs to be a bridge between this desire for velocity – for high-velocity software development and scaling – and security compliance, knowledge, and transparency. And those two don’t have to be a mismatch if you can get the foundational technologies right.
But what we’ve seen as a market trend has been that a lot of security tools for high-velocity environments have embedded functions within them. But for this type of security problem, there needs to be a single, purpose-built function, because with the administrator, which could be code, and the security that watches the administrator, which can also be code, there need to be checks and balances against each other, and therefore they need to be separated via privileged account and secrets management.
However, it also takes an integrated approach and team, says the CyberArk report:
DevOps is a new discipline, so it’s not entirely surprising that respondents report a lack of integration between DevOps and security teams. In fact, fewer than half (46%) of DevOps respondents say the two teams and processes are well integrated throughout the development process.
And 43% say that the security team is always brought in at the end of each development cycle. […] The most effective strategy will demand that security and DevOps work closely together from the very beginning and throughout development, testing and deployment.
It’s worth noting that collaboration varies by industry, adds the report, with some of the most security-sensitive organisations being among the least well integrated:
Closer partnerships between DevOps and security are most often found in consumer services and technology and telecommunications segments. On the other hand, it was surprising that financial services organisations report slightly below-average collaboration. And it was downright troubling to learn that only 16% of healthcare respondents believe that their security and DevOps teams are well integrated.