Importance of Automated Reasoning In AWS
Building a Secure System?
It is our goal for security practitioners to build and operate secure systems that seems straightforward but if we’re going to do that we need to define “SECURE” and there are plenty of Bad ways to define “SECURE”
You want to stop bad stuff , bad guys but that definition is insufficient because it leads to you purchasing cable cutters and ready-mix cement we need the counterbalancing goal but good things do happen that you deliver to your customers and this is more or less where I was up until a couple of years ago and then something happened and my definition of “Secure” shifted and so I came up with this and it’s not really me it’s kind following along in the footsteps of the people that done deep thinking here this much more formal structured way of thinking about the definition of SECURITY for a system it’s thinking about the states and the state transitions for that system and
I do security I do all of the things like we check all of the boxes out my job is really hard I’m really good at my job and it just consistent like successive iteration refinement getting better and better at your job like this is it right this is the careers and we had these nutjobs show show up and I say show up like I interviewed these people I helped bring them into the company little did I know what I was in for when we brought them on to Amazon and so we brought them on we took a little leap of faith and they made all of these outrageous claims this is almost a literal direct quote from Byron he didn’t inhale at any point while saying this either and i can tell you that they weren’t completely right they were far from wrong so let’s dig into how our thinking is evolved here
you got a computer and these things are amazingly complex if you think the amount of code that’s just running in say your web browser or the operating system kernel it’s huge but if you’re an optimist you can convince yourself that you can reason about this system and if nothing else at least this image is pretty simple
then you need to have users you need to have people doing something with a system or it’s not useful and so as soon as you add humans to the mix only the most optimist of us possibly think that we can still reason to understand this system you the image here is pretty simple we should be able to dig in at least on an idealized version of the systems but none of us actually builds that system that’s not a system that we wind up with that the business want features customers want bug Fixed the CEO just read an article in wired or whatever CEOs read these days the press release is already out so you gotta start CODING
the nice simple diagram that you had quickly accretes complexity it changes and your ability to look at the diagram and fool yourself and thinking that you can understand that diagram dwindles
Here’s a simple architecture for a system this is class 1 boxology and you’ve already seen this before we’ve got the internet web servers a bastion host, back-end servers all of the SSH traffic is shown in orange and we have security invariant a property that we always want to be true and that is that all inbound ssh from the internet goes through a bastion motherhood and apple pie right it’s pretty easy to check like look at all the orange line they all go through bastion right like this is straightforward but no real system is static your system is going to grow and change over time
and you’re going to make alterations to the network and most of them are going to be in accordance with your desires
but they are not always and wherever you work like you have JOE
and he is probably different but you have seen this server and whatever JOE did it might have been the right thing at the time the application might have been on fire this might have been the only way to fix things it might have been the right thing but now your mental model of the network that you have the system you’re operating and the system that you’re actually operating no longer line up
and JOE’s server is easy to spot in that little diagram
This is the result of an application discovery tool we have this diagram from the amazon.com retail shopping site amazon people call it the death star diagram because it’s opaque gray sphere and there’s www.amazon.com in the middle in this huge so a ball of service calls it’s completely incomprehensible to any human being we generated every so often just to reassure ourselves that we can but you can’t think about it like look at this above diagram tell which is those links in there is the server under JOE’s desk which of them is the unwanted traffic and as i want to say that networks aren’t special.
All system changes with time and missions policies suffer from the same issues.
The code which we write 100% of the bugs are written by humans but it applies to things outside the world of computers if you are homeowner if and if you are not the 1st owner of your home i guarantee that the previous homeowner did something creative and you are just waiting to peel back the drywall to find out what they did like a guy have a bunch of old trucks the previous owners of old trucks are likewise creative in all sorts of terrible ways any system is going to change over time and so what are we to do how do we handle this complexity and one of the core realisations that i’ve had as a security engineer is that every security problem is caused by an assumption that was broken someone didn’t think that something was going to happen some other creative person did that thing and then excitement and so if we’re gonna make the world a better place if we’re gonna make our systems more secure we can try and violate some assumptions or we can try and find our assumptions and to adjust the system to remediate.