Hyperautomation in Data Center/Cloud
Venetian Maritime Supremacy and Lessons for Cyber Security
For about 200 years, starting around the year 1250, the small city-state of Venice didn’t just control international trade—it completely dominated it. First built in 1104, Venice consolidated ship construction in the Arsenale di Venezia, Venetian Arsenal:
The Arsenal could, at its height, produce a fully loaded and sail-ready ship in a single day. By contrast, other manufacturers in Europe or Asia needed months to complete a single working craft. At Venice’s zenith, with just 36,000 sailors, the city-state deployed 3,300 ships. Mass production on this scale would not be seen again for another 500 years until Henry Ford’s Detroit production lines.
Venice’s estimated population in 1400 was shockingly low—between 150,000-180,000 people. In context, Venice made up just a tiny fraction of Europe’s total population and 0.0004% (!!) of the world’s 350 million. With 7.8 billion people, that’s the equivalent of a town of 35,000 people—say Manhattan Beach, CA3—controlling today’s global maritime commerce.
How could this tiny city of merchants become so dominant?
Why Automation Hasn’t Succeeded in Security
Venice’s success exemplifies automation at a level never seen before its time. By centralizing ship building in a single location and automating basic workflows—wood, nails, carpentry—Venice achieved what many manufacturers do today with machines.
In cyber security and IT, while we’ve seen automation, it has mostly touched already deployed controls. Many tasks in security remain incredibly manual. Even SOAR—Security Orchestration, Automation and Response, requires a lot of manual work. Gartner notes in its 2019 SOAR market guide:
SOAR solutions are not “plug-and-play.” Even though solutions have a library of out-of-the-box use cases and integrations, buyers are reporting multiweek professional services engagements to implement their initial use cases, as every organization’s processes and technologies deployed are different.
SOAR, although helpful, missed the lesson of Venice: interlock operational workflows with those for security. Otherwise, by the time you get to detecting an incident, so many attacker activities have taken place that it is hard to estimate the losses. It’s a bit like telling the Venetians to deploy cannons at sea, sometimes months after they have met an adversary.
For the same reason automation failed in security—the focus was wrong. For workflows to include security, you need hyperautomation where the challenge becomes avoiding any manual steps during deploying infrastructure. Most tasks need to be performed through automation assisted by machine learning with little human touch so they can happen exactly when they are required to be executed.
To illustrate, let’s sample some basic, IT workflows:
Adding a new public cloud subscription
- Bringing up new applications
- Creating new networks
- Scaling an application to meet increased demands and scaling it back after demand goes away
- Extending the datacenter by bringing in new servers
- Upgrading / repairing existing servers
Those changes typically dovetail into workflows for security teams. If they get security controls in place and the correct policies pushed down, it becomes a whole lot easier downstream. Screw it up and you end up experiencing the Bullwhip Effect, a supply chain concept that refers to the distorting impact customer demand has on disruption in inventory.
For security teams, the inability to automate basic tasks has distorted cyber defense like the arc of a cracking bullwhip. Security teams feel the impact downstream, manifested by post-compromise events that shouldn’t have to be there in the first place. As result, security teams have been forced to buy and implement more and more point solutions. And with the onset of cloud computing, complexity has increased exponentially. And the breaches continue.
Hyperautomation: Security as Code
Some IT organizations have highly automated processes and are targeting to achieve the ambitious goal of infrastructure as code. As orchestration of virtual infrastructure management in public and private clouds are supporting those tasks via APIs this goal is becoming more achievable and business processes can be accelerated. One of the major hurdles remains the dependency on traditional security which requires manual actions to an otherwise automated process. When customers experience about 90% of outages caused by firewall misconfigurations, the ambition to hyperautomate security becomes a necessity to avoid costly downtime and support business agility.
Let us run through a few of those workflows assuming they are as automated as they can be and identify typical hurdles and benefits when using hyperautomation for security.
- Adding public cloud subscription
- Typical workflow: deploying a standard set of security controls into new subscriptions, configuring and tuning them for the applications expected and sizing them for expected performance requirements.
- Hyperautomation: providing credentials to a new subscription and allowing the system to automate the implementation and configuration, results in operational efficiency.
- Bring up new applications
- Typical workflow: classify application components, evaluate and adapt segmentation strategy, place components into appropriate segments, determine security policy for L3-4 and L7 for blocking attacks, evaluate if new security controls need to be deployed and roll them out if required, push down new security policy to all relevant security controls.
- Hyperautomation: if it is an instance of an already known application, no manual changes are necessary. If it is a new application, let the system classify it and automatically generate proposed security rules and allow the system to realize them.
- Create New Networks
- Typical workflow: reevaluate segmentation strategy and if required, route traffic through security controls, evaluate additional controls required (scale, HA), determine, create and push down security policy.
- Hyperautomation: if it is of a known network type, no manual action is required. If it is a new network type, the system should automate passive traffic insertion for learning policies and recommend the controls required to secure the workloads and applications.
- Scale application up / down
- Typical workflow: monitor security controls for meeting / exceeding load thresholds and purchase, provision, configure new devices typically planning for the peak throughput. Make sure new devices are hooked up to load-balancers and are receiving a consistent policy.
- Hyperautomation: the system detects scale changes and automatically provisions additional security controls. When the load reduces, it automatically deprovisions resources resulting in efficiencies and cost savings.
- Add servers to datacenter
- Typical workflow: evaluate additional security controls due to increased throughput / performance demands and if required, purchase, provision, configure new security devices. Make sure new devices are hooked up to load-balancers and are receiving a consistent policy.
- Hyperautomation: the system detects new servers and automatically provisions policy, avoids costly mistakes of misconfiguration and downtime to deploy.
- Datacenter maintenance
- Typical workflow: make sure IP address changes are propagated to all firewall policies as and when servers are going down and when they come back up. Once systems are out of maintenance, place them into the right segments and apply the correct L4-L7 security policy.
- Hyperautomation: the system detects servers going into maintenance and reacts automatically to those changes (e.g. updates security policies and provisions security controls where and when needed at scale).
|Infrastructure Workflows||Time for executing the workflows||Time for manual security adaptations||Time for manual work with Hyperautomation|
|Adding public cloud subscription||10 minutes||1-4 weeks||10 minutes|
|Bring up new applications||10 minutes – hours||Up to 2 weeks||0-1 hour|
|Create New Networks||10 minutes – 1 hour||Up to 2 weeks||0-1 hour|
|Scale application up / down||0 – minutes||Up to 2 weeks||0|
|Add servers to datacenter||Weeks (procurement)||Up to 2 weeks||0|
|Datacenter maintenance||Hours||1-6 hours||0|
The above table represents rough estimates and the “Time for manual security adaptations” will vary depending on the security teams’ effectiveness. However, what becomes blatantly visible is that each of those infrastructure workflows takes a toll on the security teams. This often leads to either bypassing security or security becoming the long pole of heavily automated workflows happening frequently in virtualized datacenters and clouds. Without a solution that is in lockstep with those changes, security will not be in place where and when needed and not have the appropriate security policies.