Now that most enterprise organizations have moved to the cloud, it seems security issues have doggedly followed them there like an orphaned puppy infested with fleas.
Among the findings from a Fugue poll, released Oct. 4, of 300 IT and security pros in North America:
- 82 per cent reported security and compliance incidents due to cloud infrastructure misconfiguration, including critical data breaches, system downtime and unauthorized user logins
- 51 per cent reported 50 or more such misconfiguration incidents per day
- despite the prevalence of such incidents, “few enterprises have automated remediation processes that can prevent them,” the authors say
- the study says “half of the teams surveyed only review alerts and remediate issues on a daily – or even longer – timeframe, leading to dangerously long infrastructure vulnerability periods”
Why have cloud-based security oopsies become so commonplace?
Infosec veteran Mike Rothman presented a few theories at this year’s recent SecTor security conference in Toronto.
While Rothman noted that tapping into cloud services like Azure and Salesforce offers some built-in encryption, he added that, “we also have no security consistency there, because every one of your SaaS providers does something different.”
Furthermore, enterprises lose security visibility because “you don’t get to see the traffic, so you’re somewhat restricted to the application and to the logs that your SaaS provider gives you,” said Rothman, president of cloud management startup DisruptOPS and president and analyst at cloud research and consulting firm Securosis.
What can you do about these and other security gaps in enterprise cloud environments? Rothman recommended a few key steps.
Cloud native architecture
Remember the Fugue stats mentioned earlier, with all those incidents stemming from cloud misconfiguration? According to Rothman, cloud security requires cloud native architecture.
“Build the infrastructure to fit the application. Leverage architecture for security,” he advised the SecTor audience.
If you’re trying to shift your existing system to the cloud and patch it like a quilt, he’d like to stop you right there.
“It’s not a matter of ‘Hey, let’s just take the crap we built before and move it up there.’ Cloud native does not equal legacy, and that means I either build it from scratch or redesign [legacy assets] without compromise.”
After you get on board with cloud native infrastructure, Rothman suggests taking a DevOps approach to bake security right into everything coming out of your pipeline.
“[DevOps] allows us to move a lot faster, to build security testing into applications as they’re being built,” he said.
Rothman’s prescribed DevOps approach includes APIs, automation and isolation.
“Isolate the traffic to certain application stacks [coming] only from people who are supposed to be there by definition,” he said. “If you do segregation correctly, there’s very little to worry about … in terms of attackers getting at your data.”
Once you define (and design) parameters for who has access to what, automation can send up immediate red flag alerts — and in many cases, even fix or contain the situation automatically.
What Rothman described, of course, is called DevSecOps. Network security becomes a living, breathing organism; as the conditions and demands of your network change, the security woven throughout it constantly evolves too. Security stops being a series of tools you install and patch; it becomes a continuous cycle of adaptation and production.
“We actually build a new recipe with immutable infrastructure and autoscaling. We basically just change the infrastructure, then rotate everything out. And we use our continuous DevOps pipeline to manage all this stuff,” said Rothman.
This sounds great, but how does it all shake out IRL, as the kids say?
A DigiCert poll of 300 enterprise orgs last year found that nearly half (49 per cent) had already completed their transition to DevSecOps. Yet only 22 per cent felt the process had improved security.
Why the relatively low satisfaction level? As DigiCert’s chief security officer Jason Sabin told DevOps.com, although many of the surveyed enterprises expected the move to DevSecOps to take just seven to 11 months, it actually took 12 to 14 months in most cases.
In Toronto, Rothman alluded to another potential hurdle on the path to DevSecOps: it requires coding skills not possessed by every infosec manager. This means people at the top of the infosec pyramid literally don’t speak the same language (like Python, for example) as the developers they hire to put DevSecOps in motion.
Rothman closed his SecTor talk with a reminder that even if you do overcome these challenges and move to DevSecOps, there’s one thing that automation and APIs will never change.
“What you don’t push out into the cloud is accountability. For security, that still rests with us,” he said, gesturing toward all the IT pros sitting in the audience.