A couple years ago we made a purely business decision to move to Amazon Web Services (AWS). We were spending many thousands of dollars on servers, on hosting, on things to load balance our servers, on repairs to the servers, etc. It was a vicious cycle that I hated, so we started looking at cloudiness.
We decided on AWS, because we endeavor to be smart and not daft. So we followed the herd, so to speak. Overall, it was a good decision – costs are down and availability is up, along with the fact that we don’t have to think too much about things like hard drives failing or hosting center air conditioning bills. We also don’t have to pay exorbitantly for an electrical socket because we “ran out of space” in the wall.
Now, fast forward a little bit (you know what’s coming). That’s right, I’m a control freak.
When everything was hosted locally I had some comfort in my firewall rules and seeing my physical firewalls. I’m old, just allow me this one comfort… but nope, that got ripped away from me (oh the horror). One of my main concerns was visibility in the cloud, because that’s something you hear all the “experts” screaming about. So let’s walk through the journey, shall we? Good. If you’ve read this far I’m assuming you would like to know more.
Amazon’s visibility tools in review
Amazon has a number of visibility tools to use. There’s CloudWatch, which is definitely the big kahuna. CloudWatch lets you see basically anything going on in your AWS Virtual Private Cloud (VPC). Well not anything, but lots of things. You can even get network flow traffic in there so you can see what traffic is hitting where, if you’re into that sort of thing. It’s pretty high on the list of must haves for any AWS implementation. If you don’t have it… enable it today, right now. It’s fine, I’ll wait.
Amazon also has a service called Trusted Advisor, which does some basic security checking for your account and also shows you billing adjustments you can make to save money. I really like this one. It will report on underused EC2 instances, or other underused/over-configured services too (RDS and the like). Both work so you can downsize them to save more money. It has a lot of things it can report on. So, while I won’t say it’s a must have, it is definitely a must look at.
The non-vendor point of view on things
Now, I am never one to trust a vendor to tell me when their stuff is broken, or even misconfigured. So, I decided to look outside the AWS ecosystem for other things that will give me a different, non-vendor view on things.
I settled on a selection of tools across the spectrum in order to have a complete picture of our AWS setup.
Qualys’ Cloud Agent
First up is Qualys’ Cloud Agent. This tool allows you to install an agent on each EC2 instance and get a pretty good picture of how that host is configured and any vulnerabilities therein. For example, we found that while our upgrade procedures were pretty good (OS was patched religiously and pristinely), some of the application libraries needed to be updated separately and that wasn’t happening. We were able to fix this pretty quickly, so it was a good, quick win. Cloud Agent runs pretty much continuously, and lets us know if things get off from what we want. For example, if I decide to install PHP 3 on a server, that would be a good thing to know about.
That takes care of EC2 instances and some general visibilities, but I wanted, nay, needed more.
Enter: CloudSploit. I’m going to say something here that I almost never say, but this service kinda rocks. It was painless to set-up and their engine has really helped us reduce our risks in AWS. It will tell you if you’re not encrypting things properly, using the wrong keys, and other things you might not consider when you move to the cloud. I actually enjoyed setting up and using their product with one caveat (that will come later), but this is a great addition to your AWS arsenal though so do check it out.
Now, let’s talk about application “monitoring” for a minute
That took care of most of my infrastructure needs, which is great. I have visibility and I have configuration monitoring and enforcement (Puppet, but we’ve used that since before the cloud move). So now I needed to do some monitoring of my applications. And, of course, when I say “monitoring” I mean vulnerability scanning, since we are talking about security here. (I might cover actual application monitoring in another post). I needed to do some continuous monitoring of our external web apps, but because AWS is very demanding about you telling them when you’re scanning from one of their networks (hint: “all the time” isn’t a valid answer), I needed something else. I also wanted a truly “external” look at our stuff.
Much like CloudSploit, setting up Detectify was super simple with few, if any, real complications. The one technical downside is that they’re like your annoying, know-it-all, little brother telling you things wrong about your web application that you didn’t even know existed. It’s not enough to beat them up about, but it is loud up front.
The nice thing they do though is give you a great interface to report false positives with. It opens a ticket right with their support team and, get this, they actually respond to you! It is an involved tuning process, as is with any sufficiently complex web application, but well worth it in the end.
And on to my final buzzwordy point about our old friend Splunk…
All of these things lead me to my final point… which is that these tools do not talk to each other, like at all, which is the curse of point product bingo. The least I could do though is give my admins and analysts a… wait for it… buzzword time… “single pane of glass” to view all this stuff.
Enter our old friend Splunk and its SIEM product Enterprise Security. Qualys already has a Splunk app for pulling in their data, so we were good there. However, Detectify did not (although it does now because we built one). We are also currently building a CloudSploit Splunk app, but it’s in a very rough state so it’s a to-be-released soon thing. This allowed us to put together a few dashboards around the actual vulnerabilities for easy use, but more importantly allowed us to use the data inside of Enterprise Security. This was so all of these tools, more or less, integrated within our workflow effortlessly. This is a good thing.
Yes, there are going to be some challenges. No, you shouldn’t be afraid of them.
Now everything in this brave new world is not all peaches and cream, there are some challenges. All of these products charge for API access to get what is, essentially, your data. I have a lot of philosophical problems with that but I need the data so I have to pay for it. This does increase the costs of every tool here (well, not technically Splunk since you pay for the amount of data you ingest, but we’re not talking huge amounts of data here), so you have to factor that in. All in all though every one of these tools works as advertised and in the security world that is truly rare.