See inline.
Hi List, Dom,
Automating as much detection through response is the name of the game
for both practical and theoretical reasons. Walking the RSA expo
floor, I can attest that there are less than a half dozen companies
that have any understanding of what it actually looks like and takes
to be effective at scale. All the ones that do are because the
founders had some exposure to these environments or people that worked
in them. If your durable data store is Elasticsearch or Mongodb, you
are doing it wrong. Sorry Logrhythm, your choice of datastore and
product packaging do not work at cloudscale. You won't find it in
Google, Amazon, Facebook, or even Yahoo. Look what AirBNB just open
sourced. That is an example of what a small, but cloud and scale
aware, team did to solve some of their monitoring and response
problems. What did AirBNB just open source?
https://github.com/airbnb/streamalert
There is a lot more that needs to be done to cover the broad range of
capabilities needed for detection and response, but StreamAlert achieves
something very important even for huge companies -- it radically lowers
the operational overhead of maintaining and scaling the infrastructure.
We really want our human capital investment concentrated on the analysis
and response phases of the process; the places where the human brain
still exceeds automated reasoning.
Thanks, I didn't know about StreamAlert. A cool feature would be to make
this cloud provider independent. I think both Google and Microsoft
provide (sort of) the same functions/features as Amazon.
If you don't get that the most secure place to build your systems are
on AWS or Google's clouds, then you don't have any idea about what
problems need to be solved to effectively monitor and respond to
threats. I will leave that as a thought exercise, though I am happy to
elaborate if anyone honestly cares to hear the answers. I honestly care to hear the answers.
Probably the best way to think about risk mitigation -- or defense -- is
in terms of assets, threats and controls. Assets are the hosts,
applications, systems, data stores, and specific data that compose our
computing environments and are at risk. Threats constitute all forms of
exploitation, loss, disclosure, manipulation, and unavailability that
affect our assets. Controls are all the available mechanisms we can
apply to our assets to eliminate, reduce the frequency of or reduce the
impact of threats. I also like to think of threats as static -- patch
state, access control, network accessibility, etc. -- or dynamic, as in
adversarial activity.
The huge advantages of operating your systems in mature cloud
environments predominantly center around complete visibility and
malleability your assets and controls and centralization of security
expertise and headcount on deeply technical and high-scale problems. To
really cover these topics would take a book or ten, but I will try to
hit the salient points.
In AWS [using AWS as example, because I am most familiar with the
primitives] you can enumerate all your assets and their current state
through API. You can also enumerate and manipulate much of your security
control state through API. The security control gaps are the controls
you apply at the OS and application level that the cloud provider does
not have visibility into. The logical progression is to move from
polling for asset inventory and control state to an event model. AWS
Config and Amazon Cloudwatch Events are great examples of services that
receive events for asset state changes and allow those events to trigger
code that evaluates them. Having programmatic access to all your asset
inventories, security controls and overall computing environment
composition is something that is extremely difficult and costly outside
cloud environments. In fact, the only way to achieve it is to run your
own cloud. Your compute, network and storage must all be virtualized
and/or distributed to achieve the necessary visibility and malleability.
It is this visibility and malleability that remove the asymmetry between
offense and defense. More on that in a minute.
What we see of the cloud is a service view. Underneath is obviously real
hardware, software layers, control-plane services etc. Somebody has to
worry about the security of this stuff too. If you deploy your own
private cloud to achieve the visibility and malleability of your
application and service assets, you are responsible for the security of
the underlying hardware, software and control plane. However, Amazon and
Google are amongst a very small set of organizations that have quietly
hired a majority of the best security people in the world and focused
them on securing the hardware, software and control-plane services that
make up their data centers and the cloud. Want to know who employs,
either directly or through contract, the best virtualization security
people? Yup. Security and hardware designers to build security
coprocessors? Indeed. Firmware integrity verification? Yes. Secure SDN
hardware and software? This is getting boring, and you get the point.
How many Xen vulnerabilities have their been? How many of those affected
EC2? It is a subset, largely because AWS knows Xen deeply and makes good
choices that restrict attack surface. Such expertise and resourcing
extends through the entire cloud substrate, and just as importantly, the
operational processes used to manage and secure. Chances are very good
that the expertise and resourcing applied to the security of everyone
else's data centers and infrastructure don't come anywhere close. This
is essentially the security corollary to the 0.01% wealthiest.
We all know there will be vulnerabilities in hardware, in ring -N to 3,
in control planes, in operating systems, and in applications. From the
offense side, the questions are whether the attack surface is reachable,
if exploitation is possible given the operating conditions, and if
post-exploitation actions can reach targets and are visible. From the
defense side, the questions are whether we have visibility into the
state and behavior of our assets and if we can manipulate a sufficient
set of controls to prevent or degrade the adversary's impact. Much of
the asymmetry attributed to offense actually stems from defense's lack
of asset visibility, understanding of attack trees, and ability to apply
and manipulate security controls. At a theoretic level, I dare say there
is nothing inherently asymmetric about offense. The asymmetry is only in
practice, and the cloud can change the defender's practices. If
defenders leverage the visibility provided by the cloud, they can go as
far as applying automated reasoning and automated changes to security
controls to defeat adversaries. I would yield that offense still has an
OODA loop speed advantage if defense is always reactionary. If you can
execute action on objectives in my log collection latency...but said
visibility, automated reasoning and automated control changes can be
used by defenders asynchronously. Defenders can enumerate attack paths
manually or automatically and reason about control changes that would
mitigate an attack path. Defenders can hypothesize the application of
known tactics and techniques to determine outcome and make changes
accordingly. Defenders can manipulate their environment to confuse or
deceive adversaries. All these things can be done when you have
programmatic visibility and malleability over your environment and
synchronously or asynchronously. Attackers have inverse and proportional
work items.
The cloud frees defenders from attacker asymmetry...in theory and in
practice for some. Make yourself one of the some.
.
Dom
Very interesting & thank you, there's a bunch of items there I didn't
even think of...