automation and orchestration - harnessing threat intelligence for better incident response

Automation and Orchestration

2

CONTENTS

Background ............................................................................................................................. 3

Early Moves ............................................................................................................................ 5

SDKs and APIs ....................................................................................................................... 6

The Way Forward in Automation and Orchestration ............................................................... 7

Conclusion—Having Your Cake and Eating It Too ................................................................. 7 © 2015 Wisegate. All Rights Reserved. All information in this document is the property of Wisegate. This publication may not be reproduced or distributed in any form without Wisegate's prior written permission. There’s a good chance we’ll let you use it, but still: it’s nice to ask first.

Harnessing Threat Intelligence for Better Incident Response

3

In June of 2014, Wisegate conducted a member-driven research initiative designed to assess the current state of security risks and controls in business today. Assessing IT Security Risks addresses many of the top takeaways from that survey. This current document is the fourth in a new series of reports designed to look more closely at four specific issues highlighted by that survey.

» Metrics and reporting

» Malware and data breaches

» Data-centric security

» Automation and orchestration

Background The nature of information security is evolving. With the emergence of Web 1.0 it took a basic perimeter defensive stance, with a barrier defending the trusted corporate network from the untrusted internet. But with the arrival of Web 2.0, the cloud and mobile computing coupled with the increasing maturity of threat actors, has come the growing realization that a barrier is no longer good enough to keep bad actors off the company networks.


4

The consensus today is that defenders should assume that it is impossible to keep a determined and resourceful adversary out—indeed, defenders should assume that they have already been breached; or if not yet, they very soon will be. This requires a new way of thinking: if you have already been breached, how you respond is now the priority. This has led to a new type of security: incident response. It comprises recognizing the incident and responding to it quickly and effectively. It therefore encompasses products like DLP, SIEM, threat detection and anomaly detection with the specific intent to both find and respond to a breach in as close to real-time as possible. A key element in almost all incident response systems is the collection and presentation of potential incident information, more usually described as ‘threat intelligence.’ This comes with two problems: firstly the sheer volume of data presented by incident response systems; and secondly the disparate and isolated manner in which the intelligence is reported. A common response from CISOs is that “I don’t need more intelligence, I just need better intelligence.” That ‘better’ intelligence also needs to be ‘usable’ intelligence by different security controls. It is of little surprise that the Assessing IT Security Risks report shows that today’s CISOs have a strong interest in acquiring the ability to automate and orchestrate the intelligence they receive from different controls (see Figure 1 taken from the underlying survey).

Figure 1. Survey Question: Which Incident Response security controls will be most relevant to you during the next 3 - 5 years in your organization?

Source: Wisegate, June 2014


5

As the Assessing IT Security Risks report notes, “Over half (59%) of respondents marked either proactive threat/misuse detection or automated orchestration as a top choice to streamline their incident response plans and limit their exposure windows.” The question, however, is how do you achieve that automation and orchestration in incident response?

Early Moves The early attempts at orchestrating infosecurity really focused around vendor mergers and acquisitions in an attempt to build a single supplier covering all of the angles. The commercial argument is that buyers would be attracted by the ‘all-under-one roof’ argument. In reality this never materialized—the argument for buying best-of-breed point products is generally more attractive than buying a single product that is perceived to provide lesser security. But the result of buying separate point products is the basis of today’s problem: how do you automate and orchestrate the threat intelligence provided by multiple disparate security controls? One possible solution is to develop a separate product to do it for you—and SIEMs are a good example. In theory, SIEMs can receive and interpret alerts taken from one control and automatically instruct a different control to perform a required response. For example, theoretically, a SIEM should be able to receive an infection alert from an AV control, shut down the infected system, and write firewall rules to prevent further infection by the malware detected. That would indeed provide both orchestration and automation. The problem is that early SIEMs never quite delivered on what they promised. But the SIEMs’ promise, says Bill Burns, author of the Assessing IT Security Risks report and developer of its underlying survey, is good. “The goal was right,” he comments: “how can we get a standard protocol and a standard process in place so that all of our different security products can deliver their intelligence to a single system that will then, with some hand-waving and magic, come out with better answers than each of the products working by themselves?” If those answers could be used to automatically trigger the correct response from other systems, then that would indeed be the problem of orchestration and automation solved. But, continues Burns, “the standard protocols were very rudimentary. The initial complaint with SIEMs was that there was a high promise—but it required a very large investment in human capital and a very large investment in professional services to get delivery on that promise.”


6

He gave an example of the difficulties. He once used a single AV product across all of his company’s computers. “That AV,” he said, “generates a report each week that I could not read on my iPad. When I went to the vendor and asked for the report in PDF format, the reply was, ‘Well, we’re thinking about it, but it’s not a priority for us.’” In other words, the vendor could not or would not provide a standard output, never mind a format that could be understood by other machines. “That is a dinosaur of a product,” he added; and dinosaurs became extinct. It leaves the customer with the choice of accepting the problem, or going to the trouble of developing his own format conversion routine. At an earlier company, commented Burns, he had replaced the very same AV product “with a different vendor that had an open API allowing us to write our own reports using a RESTful API. It allowed me to tie my analytics system to my anti-virus system.”

SDKs and APIs While one line of development explored acquisitions and specific orchestration products, a second line led to standards in APIs. APIs first existed as part of and within products’ SDKs. The existence of an SDK was an essential selling point for all new products—it allowed developers to produce new products that would work with, and therefore improve the overall value of, their own products. But the API began to take on a life of its own as buyers chose to use the API within separate products and tie them together rather than to buy one and develop one. The first serious API standard to emerge was SOAP (Simple Object Access Protocol). Although this is still in use, it is largely being replaced by REST (Representational State Transfer). The driving force behind these APIs is the evolution of the web and the increasing use of web services. Burns explains, “Traditionally, IT products were proprietary and complicated. If you wanted to wire two things together you would call in a consulting company to do a custom integration.” But the web and web services changed things. “There was an early realization that the way IT departments were provisioning their computers and services through hardware dependent manual processes was just too slow. As the web began to make communications easier it exposed friction in the IT organizations because they couldn’t move fast enough—they couldn’t change their systems and their interconnections in a timely fashion.” This led to a pent up demand for more efficient provisioning, which in turn led to APIs emerging from within their SDKs to stand on their own—first with SOAP and then with REST. While both are described as ‘web services,’ this is probably only accurate for REST. SOAP is focused on accessing named operations, while REST is focused on accessing named


7

resources through a single consistent interface. SOAP concentrates on pieces of application logic, while REST is superior at handling CRUD operations over the internet. “Consider,” continues Burns, “that I want to do security controls in the cloud—something like Amazon, for example—and I want to apply an AV software to all of my servers in that cloud. If I don’t have an API that I can program to push out all of the configurations I will never be able to keep up with the velocity of change in the cloud. So products that don’t participate in orchestration simply won’t get chosen going forward.” APIs make it possible to automate provisioning—but they also make it easier for different systems to talk to each other. In other words, what might start as provisioning can expand into orchestrated automation between different products.

The Way Forward in Automation and Orchestration While companies still acquire other companies in order to strengthen their product line or increase their customer reach, there are others separating so that each new part can focus on its own core product area. It seems to be a natural process in business—companies combine, lose their edge over time, and separate again. Whatever the reason for this, it appears that the era of widespread company acquisitions to provide the all-in-one killer security product seems to be over. The options for automation and orchestration are now focused on the use of RESTful APIs; either with IT departments doing the work themselves, or waiting for SIEM 2 or even SIEM 3 (not specifically, but as a metaphor for new orchestration products) to do it for them. Burns believes that the evolution of SIEM-like products into a universal connector—something he calls the ‘notion of centralized security management’—is unlikely. “I think the trend will be decentralized,” he explains, “so that products talk to and integrate with other products directly rather than going through a centralized broker (although there may also be a centralized aggregator of information).” The value of a single central orchestration system is less important now as people have seen SIEMs fail—the reality was just too unwieldy. “The future,” he concludes, “is more decentralized.”

Conclusion—Having Your Cake and Eating It Too “For orchestration and automation,” says Burns, “I don’t necessarily need different companies and different products to work together in lockstep, but I need them to work together in some way. So I guess the question is, is it easier for me as a customer to glue these products together via their APIs, or wait for a vendor to do it for me? It’s the tension


8

between speed and capability on the customer side.” In infosec, the need for speed will always prevail, provided only that the company also has the capability. So self-made orchestration and automation via best-of-breed products and APIs is not merely the best solution, it is by definition tailored to individual requirements. It’s like having your cake and eating it—but to achieve this requires a staff of people who are both security-minded and also able to write and develop their own code. “It’s not just a case of deploying products,” says Burns, “but being able to orchestrate the response from those products. So, if an AV product says, ‘Hey, I think I’ve found an infected machine’, that response needs to generate a firewall rule to kick the infector off the network.” It requires, he continues, “a network person and an AV person, but also someone with a security mindset and the ability to glue these systems together in a fashion that neither product can do by itself.” This in turn becomes a forcing function on security staff, who now require an additional skill to what’s been accepted in the past: orchestration and automation requires APIs and an in-house security developer.


9

PHONE 512.763.0555

EMAIL [email protected]

www.wisegate i t .com

Would you like to join us? Go to wisegateit.com/request-invite/ to learn more and to submit your request for membership.

automation and orchestration - harnessing threat intelligence for better incident response

Technology