Security Automation – RSA 2011
February 14, 2011 RSA Conference, Cloud Security Alliance Summit, San Francisco–Christofer Hoff, director of cloud and virtualization solutions at Cisco Systems talked about management through security automation. The existing legacy IT tools and practices are the greatest impediment to change in network operations and security practices.
Security practices policies and procedures require continuous monitoring, and users need better tools to improve their capabilities. It’s important to stop manual procedures or single vendor security tools. In fact, after a few millennia of development there is probably more automation in the latest high-tech toilets than in cloud security.
Most data centers have separate tools and functions for the system administrator, developers, network administrators, and even the applications themselves. All of these must change as functions moved to the cloud, because the cloud also enables migration to other platforms, many of which are mobile. When the cloud is envisioned as a set of virtual machines, these virtual machines become a packaging problem for a bundle of resources.
In the past, private networks were centralized and defended on the perimeters. Now, almost every machine must be considered a separate perimeter. Systems used to require between one and 100 firewalls for fairly reasonable access security. Now, a system can easily have more than 1000 firewalls as the systems themselves change from single function servers to scalable virtual machine fabrics. The virtual machine is now the perimeter.
The value of the cloud is the ability to distribute workloads, but this comes with a very heavy expectation for automation functions for security. Unfortunately, there are many inhibitors to increased automation. As the infrastructure becomes a meta-structure, the applications become more closely tied to the data. This causes security to be fractured by level.
These security levels change with functionality. IaaS, PaaS, and SaaS (Infrastructure, Processing, and Software) changes requirements for consumers and providers of these services. As a result, security managers need to map the data use models with the hardware to understand various compliance, security, and cloud models. In many cases, there’s actually too much security because of high duplication across levels and no exposure across these levels.
To increase the level of automation requires security functions to start at an API and not through some other interface. For example, a security attack could be communicated to the application to identify a required function. These communications could scale and redeploy servers in a DDoS attack. Traffic monitors could monitor traffic skew and initiate additional server insertions to balance content physical versus virtual workloads.
All these functions would require standards on telemetry and policy, and a higher vision of the platform API. Other areas of change are as follows: first, the service provider and the security provider cannot remain separate. Second the DMZ is dead. The model for software has evolved so code becomes part of the infrastructure but the tools are not keeping up. Three for existing applications, brokers automate the function and the security appliance is in the virtual machine.
Four, demand must be programmable and not through a user interface like a GUI. Five, the security functions must be nimble, agile, and flexible using a language like Python and other tools to ease maintenance and revisions. Six, automatic audit and compliance data collection is necessary to reduce duplication and improve coverage. And finally, users must partner with developers. Because standards for highly automated security do not exist, you need to ask vendors to change security policy enforcement to become independent of technology. If all of these steps are implemented, security will be automated at the same level as the applications.
