Amazon Web Services (AWS) Security 101

Cloud computing. Or as I like to call it, “computing.”

Who are we fooling, folks? It doesn’t matter if it’s sitting in our data center, in someone else’s data center, or under a desk in our basement: a computer is a computer is a computer. Whether or not the data on that computer is secure, however… that depends pretty heavily on whose job it is to secure it.

Amazon Web Services (AWS) has established themselves as a leader in the “computer in someone else’s data center” market. Despite a few high profile outages every now and then, the fact remains that companies aren’t shying away from moving business critical apps to Amazon’s cloud.

But who’s responsible for securing that infrastructure?

If you answered, “Amazon, of course. Isn’t that what we’re paying them for?” then you’d only be partially correct. Scratch that. You’d be wrong. Just plain wrong.

While cloud security is “job zero” at AWS (their words, not mine), the truth of the matter is that “AWS and its partners offer hundreds of tools and features to help you meet your security objectives around visibility, auditability, controllability and agility,” (again, their words, not mine).

Hundreds. Let that sink in for a sec.

It’s easy to get distracted all those bright, shiny tools, so easy that you might overlook that fact that someone has to spend time CONFIGURING those tools properly.

That someone, dear reader, is you.

To be fair, some (most?) of the tools come with some basic security features enabled out of the gate. Still, anyone with sec ops experience can tell you that properly configuring, tuning, and maintaining one security tool can take considerable effort.

So how much effort would it take to manage hundreds of security tools?

My best estimate to date is one metric $#!%-ton, but your mileage may vary.

If you have any… ANY business critical processes that rely on AWS, then it would be in your best interest (and your customers’… and your shareholders’…) if you were to familiarize yourself with some basic AWS security do’s and don’ts.

The good news is that Amazon has gone out of their way to make sure you have the info you need.

First and foremost, I strongly recommend that you register for and attend Amazon’s AWS Security Fundamentals online course. Three hours of training, straight from the source, split into five modules:

  • Introduction to Cloud Computing and AWS Security
  • Access Control and Management
  • AWS Security – Governance, Logging, and Encryption
  • Compliance and Risk Management
  • Auditing Your AWS Security Architecture


Did I mention that this particular training is free? Because it is. That’s a tough deal to beat.

If you want to go all in, there’s also the three day Security Operations on AWScourse. This one is not free (sorry), but holy criminy, it covers EVERYTHING. If you’ve got a significant investment in your AWS cloud infrastructure, then you should seriously consider setting aside some training dollars for this course.

If you’d rather do a little light reading, AWS has plenty of whitepapers on the topic. The three that I recommend you bump to the top of your list:


If conferences are more your thing, you could always hit up the Amazon Web Services YouTube channel. There, you can watch the 29 videos in their Security & Compliance | AWS re:Invent 2015 playlist. Pick your poison, plug in your headphones, and absorb some critical security knowledge at your leisure in one-hour snippets.

Amazon has a considerable amount of additional training materials available, including self-paced labs and professional certifications, but these options are pay-to-play. Make sure you’re being honest with yourself about the ROI.

Finally, I recommend that you spend a little time on the AWS Security Services page, reading up on those hundreds of tools that Amazon touts (both free and paid). Start with these seven tools:

  • Amazon Virtual Private Cloud (VPC) – Enables you to build and restrict access to your own private cloud (hence the incredibly appropriate name).
  • AWS Trusted Advisor – Includes 40 checks to make sure your AWS deployment is properly configured, focusing on cost optimization, security, fault tolerance, and performance improvement.
  • Amazon Inspector – A more in-depth AWS security controls assessment tool (still in preview, as of February 2016).
  • Scout2 – Okay, so I lied. This isn’t one of Amazon’s tools, but while their Inspector tool is still in preview, you might find this alternative pretty handy.
  • S2N – An AWS implementation of SSL/TLS. Encrypt all the things!
  • AWS Key Management Services (KMS) – Their encryption key management solution. Again, encrypt all the things!
  • Security Monkey – Another lie. You caught me. This one’s a Netflix tool, but given Netflix’s investment in AWS, it should come as no surprise that theyroll their own tools.


If your budget won’t allow for the hands-on labs, you could always sign up for theAWS Free Tier and create your own labs. The free tier will give you twelve months of access at no cost (hence the name), and it includes access to KMS and Trusted Advisor.

I know I’ve just scratched the surface here, but I’m gonna go ahead and wrap it up before your brain explodes.

AWS security can be big and scary and ridiculously complicated, but it doesn’t have to be. Break it down into bite-sized chunks, start eating that elephant one bite at a time, and… voila: you’re on your way to a secure AWS implementation.

Good luck!

What You Don’t Know About OSINT Can Hurt You

First things first: Open Source INTelligence

It’s okay if you didn’t already know the acronym. InfoSec folks love our TLA’s (Three Letter Acronyms), or in this case, FLA’s. We need to speak faster! No time for love, Dr. Jones!

Sorry. Back on topic…

Any penetration tester worth his/her salt absolutely loves OSINT. Why? Because OSINT activity doesn’t show up in the target’s logs. (Well, hardly ever, but I’ll get to that in a minute.)

When an authorized attacker (i.e., pen tester) or an unauthorized attacker (i.e., criminal) turns to OSINT, that attacker scours publicly available information for tasty little tidbits that can be used to stage an attack that’s likely to be both quick and effective.

How, exactly, do they do this? I’m glad you asked.

For starters, they profile the company by developing an understanding of how the company makes money. They turn to resources like Google Finance, Hoovers, and EDGAR to begin painting that picture.

After profiling the company’s financials, it’s time to start profiling the employees. LinkedIn is an absolute treasure trove of employee info, including names, titles, history with the company, and in the case of many IT employee profiles, a list of the technologies in play on the company’s internal network.

While LinkedIn provides insights into the employees’ lives at work, their lives at home are all over Facebook, Twitter, Pinterest, Tumblr, and Instagram. Info like birthdays, phone numbers, schools attended, family members… in other words, the answers to all their secret questions, are there for the taking.

How well has the company defended themselves against breaches in the past? If the breach has been publicly disclosed, chances are that a summary has been published to the Privacy Rights Clearinghouse. If the company doesn’t know that they’ve been breached yet, then maybe, just maybe, some of the stolen info (i.e., user credentials) has been posted to Pastebin.

Mobile apps? Search iTunes and Google Play. You’d be amazed at what an attacker can learn by pulling down a copy of your Android app and combing through the source code. (Just ask Lenovo…)

Want to know whether or not they do a decent job of protecting encrypted data in transit? Qualys SSL Labs will answer that question for you.

What about web app vulnerabilities? PunkSPIDER will hook you up with the details.

Is their DNS server leaking internal network information? UltraTools Zone File Dump will tell you.

And let’s not forget the mother of all online OSINT tools… SHODAN!!! Details on all the systems the company has connected to the Internet (including open ports), there for you to peruse at your pleasure.

Even if the only thing an attacker knows is your company’s primary Internet domain, that attacker can spend a little time with Netcraft, whois, ARIN, Robtex, and the Hurricane Electric BGP Toolkit, and develop a pretty comprehensive picture of your company’s Internet footprint.

The scariest part? Attackers can gather all of this information… ALL OF IT… without ever touching your network.


So how do we defend against this? The answer is rock simple, folks.


You don’t need to buy anything to gather the exact same OSINT on your own company. Keep in mind you have a key advantage over the attackers: your inside knowledge. Combining that knowledge with your OSINT findings will enable you to close these gaps before an attacker can take advantage of them.

Unauthorized ports open on Shodan? Close them.

Web app vulnerabilities on PunkSPIDER? Fix them.

Zone transfers were successful? Disable them.

Passwords on Pastebin? Change them.

Users oversharing on social media? Train them.

We’re not talking rocket science here, folks. We’re talking InfoSec 101.

And don’t tell me you don’t have enough time to do this. I’m not buying it, not when you can use Maltego and recon-ng to automate the process.

Side note: If you want to include some activity that will show up in the logs, toss in a little metadata analysis with FOCA and some Google Hacking, and you’re all set. (It’s still going to look like benign web traffic, but at least it’s a start.)

Another side note: What I’ve outlined here is a brief intro to OSINT, what I consider to be the fundamentals. If you’re hungry for more, head on over to Online Strategies and check out a list of OSINT resources long enough to make your eyes water.)

Take a few minutes, try a few links, and get a feel for what your company looks like from an OSINT perspective. You might be surprised at what you find.