Avoiding the most common DevOps security vulnerabilities in the cloud
When applying DevOps principles, like continuous automation and continuous delivery, many organizations are creating DevOps security vulnerabilities in their public cloud.
One of the key DevOps principles is the idea that all tasks should be automated and new code should be able to move seamlessly into production without any manual interactions slowing down the process. And when the DevOps principles of continuous delivery and continuous deployment move into the realm of the public cloud, the opportunity to automate what would otherwise be manual tasks explodes.
In the public cloud, the configuration of just about every conceivable setting is done through an API, meaning everything from the provisioning of servers to the allocation of processors can be written into a script. It's a powerful concept, but bringing DevOps principles into the public cloud is also one that is fraught with danger, meaning organizations should place a greater priority on DevOps security and DevSecOps. "When moving systems into the public cloud, every element that can be configured can also be misconfigured," said Roy Feintuch, CTO and co-founder of Dome9 Security. "In the cloud, those misconfigurations put you one strike away from having your data exposed or your machines compromised."
Common DevOps security mistakes
So, what are the most common misconfigurations DevSecOps tools are identifying in software deployed to public clouds, like Google, Amazon and Azure? How can organizations improve their DevOps security?
"There are multiple fronts in which we find users are challenged. One of them is managing security groups," Feintuch said. "When environments become large, tens or hundreds of security groups connect to hundreds or even thousands of server instances. With almost every customer, we see some type of security group misconfiguration that can lead to a security issue."
When moving systems into the public cloud, every element that can be configured can also be misconfigured.
Roy FeintuchCTO and co-founder of Dome9 Security
Another common DevOps security mistake is the unwitting exposure of public data being stored in a publicly accessible Simple Storage Service (S3) bucket. According to Feintuch, it's not uncommon to see far too permissible access to Amazon cloud resources that should be private and restricted data.
The third most common problem is the combined issue of misconfigured identity management systems and poorly thought-out access management policies. "Cloud providers provide a powerful identity management system, but its power and granularity also mean that it's complicated."
So, why are these recurring DevOps security issues happening? There are a myriad of possible reasons. Sometimes, DevSecOps problems are rooted in a lack of training. Sometimes, it's a misunderstanding in terms of how DevOps principles are applied to nonfunctional requirements, like security. Sometimes, DevOps security issues stem from an oversight in a deployment or configuration script. And sometimes, things just don't work when security is turned on for a given microservice or storage bucket, and in a haste to get code working, security gets reduced until a program starts to work, while policy and security requirements get dismissed.
Addressing DevOps security issues
So, what can be done to mitigate the public cloud security risk? A simple first step is to get a report on your S3 buckets or similar resources and see who has full access rights to a given resource and then find out why. That simple first step can quickly identify areas in your public cloud deployments that require more scrutiny.
Another approach is to iterate over the security permissions provided to any newly deployed microserivces or APIs and determine what the most restrictive permissions are that can be applied to the system, while ensuring access to required users. It's an iterative and possibly time-consuming process, but it's much more preferable than walking into the office one morning to discover that the newly deployed system has been hacked.
In terms of offering DevSecOps tools, Dome9 provides an interesting tool called IAM Safety that makes it practically impossible for an unauthorized user to perform destructive actions. "IAM allows public cloud users to define a policy that determines which actions they'd never want a hacker to perform. Actions such as deleting database servers, deleting encryption keys, accessing database backups or changing DNS [domain name system] values can be defined one time, in advance," Feintuch said. "It's an identity and access management firewall, and it gets applied across the board." When an admin does need to perform a dangerous action, there are ways to temporarily elevate her status in order to perform the dangerous work, but it's not an option that would be available to an intruder.
Solving the security problem is never an easy task. But when moving to the public cloud, stakeholders need to be far more diligent than they were when the entire system was on premises. A public cloud can indeed be more secure than having a local data center, but that means making DevOps security and DevSecOps a priority and using all the tools in your power to ensure that your systems don't get compromised.
