DevOps Security Watch: Three Trends To Track In 2018
Source – informationsecuritybuzz.com
In the face of incessant competition, countless organisations are turning to DevOps to improve efficiency and accelerate innovation. While this approach delivers proven benefits, DevOps is also creating new security risks and reviving old ones. That’s because these very organisations are failing to adequately train or develop staff to implement best practice in security, leaving them vulnerable to both internal and external threats. At a time when managing their security portfolio effectively is crucial, many are unwittingly introducing vulnerabilities in pursuit of rapid innovation.
Drawing on the teachings of 2017, here are three DevOps security trends that should be on the radar of every organisation in 2018:
One: The Uber breach was just the beginning
The Uber breach shook consumer confidence in 2017, but it shouldn’t have been so surprising. 57 million customers had their data exposed when Uber developers used a workaround to manage credentials in a software repository. This gave hackers access to their privileged accounts. Those developers aren’t alone, and this is a peek behind the curtain of a common practice amongst developers. There’s no obvious way to securely collaborate across tools.
Organisations at large fail to make security easy for DevOps practitioners, and that creates opportunity for failure. By their very nature, developers aren’t security practitioners. They are responsible for features and functionality, not figuring out how to manage credential collaboration and security for those key assets. Nonetheless, this is leaves a gap in organisation’s risk assessments. Our recent threat landscape report indicated that most organisations could not identify all the places and “workarounds” where credentials were stored, some of which are highly vulnerable. It also noted that 73 percent of organisations had no strategy to address privileged account security for DevOps at all, which is quite alarming.
There’s an obvious failure in the developer user experience, which means we’ll continue to see breaches similar to Uber’s in 2018 and beyond. Companies ask developers to manage security assets when it is beyond their core job function, and they have little experience in doing so. The future will be in automation for making security more seamless, and that means making security part of developers’ native experience.
When looking specifically at the way the Uber breach was handled, new research suggests that the company might not be alone in its response where it attempted to hide the breach from its customers. Our report also found finds that 50 percent of organisations did not fully inform customers when their personal data was compromised in a cyber attack. Alarming, yes; surprising, maybe not so much.
Two: DevOps security is a full-time job – creating a new DevSecOps talent gap
Organisations are turning to DevOps workflows to achieve transformative velocity and innovation, but they’re not prepared or staffed to manage the security of these environments. We’ll see a critical talent gap of DevSecOps practitioners as business leaders increasingly prioritise cyber security.
Many organisations simply task the same DevOps practitioners—often with no security experience—to protect these environments, in addition to the numerous other responsibilities they have to deliver. That’s no longer sufficient, especially considering the increasing threat surface in DevOps workflows and the associated risks in managing the scripts, platforms and systems used in automated workflows.
DevSecOps practitioners are in high demand. They’ll be even harder to find in 2018 as organisations realise that they have the right tools but not necessarily the right people to manage them. Security will become a full-time job focused on DevOps workflows, and there will be few practitioners to fill that role available in the market.
Three: Least privilege in DevOps will get a facelift
Organisations are starting to understand that “identity” hasn’t been fully addressed in the full enterprise stack. There’s no common standard for machine identity, access control and management, or audit across a multiplicity of platform components. Organisations are only as safe as their weakest link. The weak link could be a VM, container or any of the dozens of platform layers that now exist across the network. As these matrixes expand, they become substantially harder to control.
There needs to be a stronger definition of machine identity in highly automated systems that carry increasingly sensitive data. Soon, we’ll start to see a meaningful application of the concepts formerly used in human access management applied to machines. By forcing the DevOps team to consider and apply “Who are you, what are you, what are you asking for?” to machines—including the DevOps environment—organisations can follow security best practices and limit what machines are doing, without compromising operations. This will enable true accountability for the security posture of DevOps environments. The process of continuous delivery of least privilege in DevSecOps can finally become a reality.
Ultimately, it’s important to understand that DevOps practitioners don’t have a full picture view of security. They primarily think about software vulnerability and patch management as the “scope of their security function.” To test this, you can ask them which security tools they use. They will likely say, “Terraform, GitHub, Ansible, etc.” They are only looking at patches and vulnerabilities, not access control and privilege associated with their access to tier zero assets. Secrets management is simply not on their radar
DevOps failed to prevent the Uber breach because the “security tool” that was ultimately compromised was the source of the breach. The rest of the toolchain has the same problem. Think about it: I phish one DevOps tools, and I own your systems.