By Morey Haber, CTO & CISO, BeyondTrust
By merging software development and IT operations ― two traditionally mutually exclusive functions ― DevOps has fundamentally transformed how today’s organizations develop, operate and maintain applications across their environment. It is easy to see the allure of DevOps ― through rapid iteration and automating processes at scale, DevOps teams can bring high-value applications to the organization, giving them the agility that is a critical success factor in today’s fast-paced world.
But in their haste to adopt DevOps, several organizations gloss over the security challenges that this methodology of application delivery introduces. As a consequence, DevOps practices often widen the attack surface and increase the enterprise’s risk of data exposure. So why is it so challenging than, for IT teams to secure DevOps environments? What makes DevOps security different from more traditional IT security?
Prioritizing speed over security
Speed and agility lie at the core of DevOps ― DevOps teams work incredibly fast to deliver applications in line with compressed, and often unrealistic, timelines. These teams thrive in an environment of ad-hoc tooling with an emphasis on intense code sharing and automation at every step. While these practices do allow teams to deliver business-critical applications quickly, they do also create a plethora of security shortcuts. It is a real challenge for security teams to integrate traditional security into the DevOps pipeline as traditional tools force developers to change the way they work and slow down their pipeline, resulting in low tool adoption.
Excessive use of privileges
To expedite the process of delivering code, DevOps teams often circumvent or even override critical security safeguards. For example, humans and machines within DevOps environments are afforded much higher levels of privilege compared to traditional development and operations environments. It’s not unusual — and one might argue, it is even standard practice — for developers to share private keys and credentials with colleagues for quick access. This negligence vastly expands the attack surface ― primarily in the form of insider threats, whether malicious or accidental ― while also complicating the process of creating clear audit trails.
Within applications, developers may hardcode passwords so they can easily be found locally or on repositories such as Github, Bitbucket, and others. Some of the other widely used practices for storing credentials include config files and excel spreadsheets, both of which are highly insecure. These risky practices have significantly increased secrets sprawl in the enterprise, creating dangerous backdoors for savvy hackers, and once again, expanding the attack surface.
Cultural challenges
Don’t get me wrong. My intent is not do dissuade organizations from adoption DevOps ― there’s hardly anything wrong with this highly collaborative, iterative, and open approach to coding. In fact, given its high yield of valuable applications and features, I would argue that its certainly a culture that organizations should foster.
But as the “shift left” practice, at the core of the DevOps philosophy, moves security to be considered earlier in the process, its painfully evident that traditional security tools are not capable of securing these DevOps environment. Developers need solutions that adapt to their workflows and highly collaborative environments. Lightweight applications that leverage code to deliver robust security, using developer-preferred UIs such as CLI and APIs, will see more successful adoption as compared to traditional security-minded GUIs.
So, given that most organizations are ramping up investment in DevOps, how can they mitigate these challenges?
Establish strict controls
As organizations accelerate the adoption of DevOps, enterprise security requirements must evolve to ensure they cover all environments, including DevOps. The new requirements should mandate the creation of a centralized repository for management of credentials and secrets (more on that later) and control user ability to share credentials. They should also completely eliminate hardcoded credentials and passwords from scripts and prevent the storage of secrets or passwords in config files, excel spreadsheets or other repositories not explicitly built for security.
Centralize secret management
As I touched on earlier, it is imperative for security teams to implement a centralized system for secrets management that will serve as an intermediary between the user ― be it a human or machine ― and the application, process, or tool they want to access. Use the centralized system to store all secrets used by DevOps practitioners, tools, and applications in a password safe and provide enforcement for access, credential complexity, and other basic tenets of privileged access management.
Support adoption and agility
Automation is key to DevOps teams’ ability to accelerate application delivery and minimize pipeline delays. Their agile workflows may be impeded by traditional security tools that work counter to their practices. So to ensure robust security, without compromising developers’ efficiency, organizations must adopt security solutions that leverage automation. Providing out-of-the-box integrations with common DevOps tools — Puppet, Jenkins, Ansible, Chef, Docker, Git, etc. — that can be managed through the developers’ preferred interfaces, will guarantee higher adoption rates and enable greater agility in the DevOps process.
DevOps is no longer a buzzword — faced with the pressure of staying one step ahead of the competition and delivering unmatched experiences, organizations across the globe are making DevOps a central part of their IT strategies. However, unmanaged credentials and secrets sprawled across DevOps environments increases the number of attack vectors, creating easy targets for bad actors. Against this backdrop, what organizations need is a centralized administration solution — one that can address the requirements of complex enterprise environments but is also easy to adopt by DevOps teams.
About the Author
With more than 20 years of IT industry experience and author of Privileged Attack Vectors and Asset Attack Vectors, Mr. Haber joined BeyondTrust in 2012 as a part of the eEye Digital Security acquisition. He currently oversees the vision for BeyondTrust technology encompassing privileged access management, remote access, and vulnerability management solutions, and BeyondTrust’s own internal information security strategies. In 2004, Mr. Haber joined eEye as the Director of Security Engineering and was responsible for strategic business discussions and vulnerability management architectures in Fortune 500 clients. Prior to eEye, he was a Development Manager for Computer Associates, Inc. (CA), responsible for new product beta cycles and named customer accounts. Mr. Haber began his career as a Reliability and Maintainability Engineer for a government contractor building flight and training simulators. He earned a Bachelors of Science in Electrical Engineering from the State University of New York at Stony Brook.
