Andrea Danti - Fotolia
Automation has sounded like a dirty word to security teams for far too long. We still think of all the things that could go wrong with security automation, reminiscent of the days when network problems were routinely blamed on "the firewall."
Moving to the cloud is all about gaining service capabilities -- rapid delivery, flexibility and scalability -- that would take most businesses too long to develop in-house. As enterprises embrace hybrid environments, security functionality will need to become more automated, and embedded into deployment processes, in order to be successfully implemented into cloud operations.
Sadly, even as development and operations align, security teams continue to be left out of the DevOps conversation. We are too often seen as roadblocks to rapid development or operations implementations; the group who "slows down" production systems. Application and service deployment into cloud environments is pushing all facets of IT to move much faster.
Ready for DevOpsSec?
A number of changes within security teams need to take place before most organizations can fully support and facilitate cloud operations. Gartner's Neil MacDonald anticipated some of these technical and organizational changes early on, in his 2012 blog "DevOps Needs to Become DevOpsSec":
… information security must change in multiple ways including security infrastructure becoming more adaptive and programmable and making information security representation an integral part of DevOpsSec teams from the genesis of new applications and services.
Whether security teams truly embrace DevOps or not, security needs to be more wholly integrated into cloud-focused development cycles and workload deployments. There are many reasons for this.
Security won't be able to scale with business operations in the cloud unless it's tightly coupled to workloads. Imagine a business needs to rapidly increase the number of virtual machine instances running in a cloud environment. Ideally, the VM templates already exist, and the operations teams involved create new instances from those templates. If some form of host-based security isn't embedded into the templates ahead of time, however, each new VM will start in a less secure state.
Even if a security agent were in place within the templates, any changes to security policy would need to be rolled out to all new instances, which would slow down operations. A flexible agent would fetch its policy when a new instance started, thus ensuring continuous and up-to-date security.
Quarantine of a cloud system in which malicious behavior is detected is another use case for security automation. In a cloud environment, security teams likely have fewer tools and less operational control than they would within the traditional data center. To facilitate network isolation, an automated detection-and-response cycle is initiated. This process is based on indicators of compromise or unusual behavior that isolates the system at the host or virtual/cloud orchestration level, moving it to a virtual switch or network segment dedicated to quarantined systems only. Disk and memory forensic acquisition could also be automated, with the images copied to a forensic node in the cloud environment, where encryption is then applied to protect them.
Network and vulnerability scans could be automated, too, continually sweeping cloud environments to determine the inventory of systems and services as well as their overall risk posture. To scale security functions effectively without becoming a roadblock, security teams in the future will need to think like this more and more.
Help with the script
Cloud security automation has its challenges. Security teams need to familiarize themselves with orchestration tools and even APIs available to help implement prevention, detection and response tactics in the cloud. Common frameworks like Chef, Puppet and SaltStack can all help security teams to configure and monitor systems and application services with scripted approaches. Many cloud providers are adding extensible security features and controls, such as Amazon Web Services' Config and Microsoft's Azure Security Center, which support policy implementation and assessment. Programmable security products from Dome9, CloudPassage, HyTrust, and startups like Palerra are changing the information security market, along with API-driven policy implementation from cloud access security brokers and other security-as-a-service offerings.
None of this comes without risk. Things can go wrong, and they likely will, in some cases. Scripts will fail, legitimate traffic will get blocked, cloud instances might be quarantined without cause, and security automation and orchestration tools may come under attack or be misused. These risks we have to take, because the alternative is nothing short of obsolescence. Security teams need to work with development and operations side by side, every step of the way, and that means moving at their pace. That speed is faster than most security professionals are comfortable with, but we'll need to get out of our comfort zone sooner rather than later to keep pace with the next wave of agile cloud computing. Security automation is the way to get there, and we need to embrace it rather than fear it.
Read more about cloud security and automation
Why you need an API-driven strategy for cloud security
Five ways to fend off cloud security threats