I am intensely lazy.

If you read anything by Tim Ferris (the “4 Hour X” guy), you have heard him talk about Minimum Effective Dose. What is the least you can do to achieve your objective? In some ways that’s how I define my life.

Not that I am above hard work. You don’t swim/bike/run for 3-4 hours, climb mountains, hike the back bowls, or participate in intense all-day rescues without a little hard work. Sometimes I even enjoy getting my hands dirty – especially since I started spending most of my time at a desk. In other words, if something interests me, I’m all on it.

But if it isn’t fun to me in some way, I will do everything in my power to minimize the time I need to spend on it. I’m on my third robot vacuum (A Neato, which is like a Cylon compared to the mousebot that is iRobot), pay a landscaper, have hired someone to clean my garage, and even confused a handyman I used to install some home automation switches (I like the programming – just not shocking the crap out myself because I’m too lazy to walk outside and hit the breaker). I relatively recently subscribed to FancyHands so I can email off requests to format papers, call various services that otherwise put you on hold for an hour, or research the nearest Mexican food to my current hotel.

So I am really digging all the new automation options with cloud computing and our new API-driven world. This week I have been working on using Chef for security and figuring out the interplay between Chef and Amazon Web Services or OpenStack to enhance security automation. Most of this is to have some advanced material on hand for our Black Hat cloud security class next month, but the fact that I am putting the work in probably means we will end up with one of those classes where nobody groks command lines.

The first add-on will be using Chef and OpsWorks to 1-click build out the secure demo application stack we put together for the labs, and push patches out to hundreds of systems with a second click (not that we will run hundreds – that might annoy Accounts Payable). If I have enough time I may have a Ruby app that simultaneously connects to AWS and Chef and monitors for any instances not managed by Chef, and instantly quarantines them and identifies the owner. (I have the pseudocode worked out but haven’t programmed Ruby much, so that will take some time.)

Those are just two simple examples of integrating security automation. It wouldn’t be hard to extend the tool to automatically run vulnerability scans (randomly or after patch pushes), then use Chef to auto-patch noncompliant systems, and then kick off a report. You could even spin up a pen-testing instance inside the same Security Group, run a scan, send off the results, and shut it down automatically on completion. Heck, even these ideas are just scratching the surface.

This kind of automation is powerful. If properly set up, it becomes extremely difficult for admins or developers to run anything that violates security policies. But it is a different way of thinking and requires different architectures so important things don’t go down when the Software Defined Security breaks them. Which it will – that’s what we actually want it to do.

Anyway, I now need to go learn the absolute minimum amount of Chef and Ruby to hack together my demonstrations, and I’m about two weeks behind schedule. I might need to go outsource some of this to save myself some time…

On to the Summary:

Webcasts, Podcasts, Outside Writing, and Conferences

Favorite Securosis Posts

Other Securosis Posts

Favorite Outside Posts

  • Adrian Lane: Edge Services in the Cloud. Open source tools for building out client services in a massively scalable way. Look at the request lifecycle and you will probably get an idea of how security would be implemented as a series of HTTP filters. You can even ‘canary’ test specific users onto different code, perhaps routing to an intrusion deception model… This is some very cool stuff!
  • Rich: Dealing with eventual consistency in the AWS EC2 API. As we move into Software Defined Security, these sorts of issues will really annoy the f### out of us.
  • Rich (2): Had to add this one: I ain’t in Kansas anymore… The real world is tough.
  • Dave Lewis: Sr. Information Security Analyst. Take Dave’s old job!

Research Reports and Presentations

Top News and Posts

Blog Comment of the Week

This week’s best comment goes to Patrick, in response to API Gateways: Access Provisioning.

Great to see this topic getting some love! I think it is really important.

I want to make one suggestion. As you drill into the subject, you may want to cover the difference between APIs for developers writing end-user applications and those that are being enabled by cloud and virtualization providers (e.g., AWS and VMware) for infrastructure management.

I know I am slicing the onion pretty thin. Hey, an “API is an API”, but there may be a good argument that they are not all created equal from a risk perspective. No disagreement on the fact that they all need appropriate protections/controls. APIs for virtual/cloud infrastructure APIs are the proverbial gateway to software defined networking and datacenter tasks. With the appropriate credentials/entitlements a script can add/change/delete and otherwise configure the entire infrastructure underlying the whole application candy shop. There are a bunch of new ops automation platforms (Chef, Puppet, et. al) that make this even more interesting.