<div dir="ltr">inline...<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 23, 2017 at 7:42 AM, Laurens Vets <span dir="ltr"><<a href="mailto:laurens@daemon.be" target="_blank">laurens@daemon.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi List, Dom,<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Automating as much detection through response is the name of the game<br>
for both practical and theoretical reasons. Walking the RSA expo<br>
floor, I can attest that there are less than a half dozen companies<br>
that have any understanding of what it actually looks like and takes<br>
to be effective at scale. All the ones that do are because the<br>
founders had some exposure to these environments or people that worked<br>
in them. If your durable data store is Elasticsearch or Mongodb, you<br>
are doing it wrong. Sorry Logrhythm, your choice of datastore and<br>
product packaging do not work at cloudscale. You won't find it in<br>
Google, Amazon, Facebook, or even Yahoo. Look what AirBNB just open<br>
sourced. That is an example of what a small, but cloud and scale<br>
aware, team did to solve some of their monitoring and response<br>
problems.<br>
</blockquote>
<br></span>
What did AirBNB just open source?</blockquote><div><br></div><div style="font-size:12.800000190734863px"><a href="https://github.com/airbnb/streamalert" target="_blank">https://github.com/airbnb/<wbr>streamalert</a></div><div style="font-size:12.800000190734863px"><br></div><div><span style="font-size:12.800000190734863px">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. </span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If you don't get that the most secure place to build your systems are<br>
on AWS or Google's clouds, then you don't have any idea about what<br>
problems need to be solved to effectively monitor and respond to<br>
threats. I will leave that as a thought exercise, though I am happy to<br>
elaborate if anyone honestly cares to hear the answers.<br>
</blockquote>
<br></span>
I honestly care to hear the answers.<br></blockquote><div><br></div><div style="font-size:12.800000190734863px">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.</div><div style="font-size:12.800000190734863px"><br></div><div style="font-size:12.800000190734863px">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. </div><div style="font-size:12.800000190734863px"><br></div><div><span style="font-size:12.800000190734863px">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.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">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 </span>corollary to the 0.01% wealthiest.<span style="font-size:12.800000190734863px"> </span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">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.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">The cloud frees defenders from attacker asymmetry...in theory and in practice for some. Make yourself one of the some.</span></div><div><span style="font-size:12.800000190734863px">.</span></div><div><span style="font-size:12.800000190734863px">Dom</span></div></div><br></div></div>