To increase the speed of delivering new software features and value to even the most “traditional” enterprise businesses, such as banking, utilities and staid government organizations, developers are shifting to a DevOps mode. Meanwhile, security teams scramble to secure and manage the plethora of new tools and technologies used to deliver on that promise. The biggest gap security teams face today is the massive proliferation of secrets and privileged users throughout the DevOps pipeline. Both teams have to deliver without compromising on security.
Now more than ever, it’s important to find a way to meet speed and agility with faster security and compliance delivery. But as a CISO, where do you start?
First, while the list of tools and technologies can seem to be overwhelming and disparate, it’s important to remember that you do not need to know every single tool in order to help control the security of DevOps environments. A strong foundation requires a system-based approach that is API driven. APIs are the lingua franca of today’s software development systems, and it’s how next generation users and their technologies of choice will want to interact with security tools. The more abstraction of security “as a service” the better, because it shifts the burden of managing security policy, tooling and reporting from the development teams and puts the control back into the hands of the security team.
With this is mind, the security team needs a set of best practices based upon the desired security posture for the environment, AND THE PATH OF LEAST RESISTANCE for end users. You don’t want teams to come up with solutions or implementation details on the fly in order to meet their deadlines and deliverables.
Easy wins with the development teams include the following basic principles, because they already know these are good practices but just may not be doing them visibly or consistently:
- First, no secrets in source control.
- Second, follow least privileged access control across your entire infrastructure. The over-privileging of system accounts can be tremendous and very risky.
- Third, micro-segmentation of access to secrets, passwords, SSH keys, etc. is essential in minimizing the impact of any potential breach or event. In fact, the events you should work to minimize are not just security-related (where some malicious actor has gained access to infrastructure) but are also what we call “misadventure,” or human mistakes that are bound to happen. Things are moving so fast in DevOps environments that one could quite literally screw up at the speed of light. You need to have a bit of a throttle, so that when this happens (and it inevitably will), you can easily roll back to a previous environment or rotate a key.
Key Considerations for Privilege and Machine Identities
One of the key differences in controlling privileged access in a DevOps environment is honing in on the path on which no human user is involved. These privileges are exercised on a daily—even minute-to-minute—basis. Imagine a scenario whereby I’ve written a script, and I can launch instances in AWS from that script and those are all privileged in order to access a key database from my organization. In this instance, there is no human involvement. It could’ve just been a big red button called “deploy here,” and thus, there’s really no traceability back to a human user to identify how this infrastructure got there, where it came from, how it got its permissions, etc. Tools that can specifically recognize and identify machine and system account users and can ultimately authorize them based on policy—and then audit that entire transaction—are crucial for forensic analysis, for governance of least privilege, and for the ability to ensure that you have a security posture consistent with whatever your program or policy might be.
Extending Your Privileged Account Security Programs
Privileged account security is a proactive step you can take to mitigate risk. A crucial first step is to devise a program early on that enables you to curate, and distribute via automation, consistent security policies for access to cloud keys and credentials—in a compliant way. Far too often, organizations scramble to remediate issues, as opposed to implementing solid best practices from the start.
For companies with existing privileged account security programs in place, the goal is to extend those solutions into the next generation infrastructure. We call this trust forward. Trust forward is the concept that you can leverage existing tools, protocols and existing certified solutions and map them to these next generation workflows. This is possible because best practices around controlling privileged account credentials have built up over decades, some of which cannot be jettisoned as we move into the new world. What we do need to do is acknowledge when they do and don’t work with the new workflows, and that’s key. Some break-glass, two-key human user escalation workflows should remain in the hands of humans, and not bots, to make the key and critical decisions, with full session recording.
What Your DevOps Colleagues Need to Realize About Security Tools
Some DevOps personnel have had negative experiences with timeliness and delivery of security in the past. So it’s critical that they understand it doesn’t have to be that way—speed, velocity and resiliency do not need to be sacrificed in order to be secure. But it also can’t be bespoke to any one development group’s tools and preferences. The business needs a consistent security and risk posture across all groups, tools and technologies.
From a cultural standpoint, it’s important for DevOps engineers to embrace that their security team has something important to offer in terms of best practices and knowhow. They have experience and focus to deliver, and they are now being empowered with tools that have been designed with the developer and operations team user experience in mind. Tools, like CyberArk Conjur, that can effectively bridge the two methodologies and help people to work together collaboratively—and at velocity—to secure their infrastructure. From a technological standpoint, it’s important to think ahead and select best-of-breed solutions that are going to evolve with their infrastructure. Partner with companies that can drive an agenda forward—which may include one set of tools today and an entirely different set of tools tomorrow.
Security teams can work with built-for-purpose security tools that provide a strong foundation on which to build. That’s why CyberArk is boosting its education efforts within the DevOps and Security communities about best practices in the evolving technology landscape of cloud, containers and micro-services/serverless—to empower teams to craft programs and policies that can be used to deploy and secure cloud assets in a consistent, scalable way.
Editor’s Note: CyberArk Conjur, part of the CyberArk Privileged Account Security Solution, helps organizations keep up with the rapidly shifting DevOps landscape. To learn more, visit here.
