[Dailydave] Improvements

[Dominique Brezinski]

inline...

On Thu, Feb 23, 2017 at 7:42 AM, Laurens Vets <laurens at daemon.be> wrote:

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


>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.immunityinc.com/pipermail/dailydave/attachments/20170223/7b8578cf/attachment-0001.html>