The document discusses automation and orchestration in incident response. It notes that early attempts focused on vendor mergers but that never fully delivered. Standards like APIs and REST have enabled products to integrate more easily. The future of automation and orchestration likely involves products communicating directly through APIs rather than going through a centralized system. This allows for customized solutions and speed while still using best-of-breed products. It requires security teams to develop these integrations themselves.

1. 22

2. 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.

3. 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. Automation and Orchestration 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. Harnessing Threat Intelligence for Better Incident Response 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. Automation and Orchestration 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. Harnessing Threat Intelligence for Better Incident Response 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. Automation and Orchestration 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. Harnessing Threat Intelligence for Better Incident Response 9
PHONE 512.763.0555
EMAIL info@wisegateit.com
www.wisegateit.com
Would you like to join us? Go to wisegateit.com/request-invite/ to learn more and to
submit your request for membership.