What is this all about?

I had never heard of the AWS Security Jam. Our Delivery Director sent me a rather intriguing email about this “AWS Security Jam” that was being organised the day before the AWS Summit. I am always one to challenge myself, so I signed up immediately. The chance to start dealing with real world scenarios that are using AWS services that I had been reading about for the past month was an opportunity that would be foolish not to pursue.

I have only recently passed my AWS Certified Solutions Architect exam, so all the AWS services are still fresh in my mind. Granted, I have been using quite a few AWS services for some of the latest projects that I have had the pleasure to be working on.

So what is a Security Jam?

The AWS Security Jam is an event where a bunch of teams compete to solve the most challenges. These challenges vary in scope, and the challenge will tell you what resources you have access to, and also gives you a few pointers on where to start your investigation.

When you are split up into teams, you may not be with someone you know. As I went on my lonesome, I was grouped with 3 other guys. We were all strangers to each other (although we did have a nice conversation out in the hall before we filed in). We all had different levels of expertise, although one of our team members confessed to never having logged in to AWS before 😅!

What do you need to bring with you?

You need to bring the following things:

• A laptop
• Your charger (it’s a long day)
• A keen interest in cloud security (not really required…but it definitely helps)

What is the purpose of a Security Jam?

I think a lot of people take security for granted. Some may get a naive view that their infrastructure will never be attacked. I was reading the Hackers Playbook 3 on the train down to London, and it had a powerful phrase in there.

Assume that you’ve already been compromised

As I said, powerful! If you are always on the look out for something that could expose your infrastructure to attack, then you are one step ahead of someone who assumes that everything is A-OK 😎.

What happens at a Security Jam?

As I said earlier, at a security jam everyone is separated out into teams of four (or less). We had to follow some instructions that were given to us on a card. These instructions allowed us to access the dashboard for the Security Jam. Before we could access the full dashboard we had to set up an account on QuickLabs. QuickLabs was used to set up the environments for the challenges.

After confirming that our QuickLabs accounts were set up, we could then choose our team name. Because one of our team had joked about forgetting to bring a mascot (it mentioned something about mascots in the Security Jam registration confirmation), so we called our team No Mascot.

When we had that all set up we could view the challenge map!

How do you score points?

Points are awarded by putting a code inside a text field on the challenge page. This code can be found in a number of ways. For example, it could be inside a shell script or on a web page.

The number of points awarded depends on the difficulty of the challenge. Easy challenges usually only involve a single AWS services, whereas the hard challenges involve a few more that often interact with each other e.g. VPC, CloudWatch, EC2, Load Balancers etc.

If you are unsure about a challenge, there is a button that allows you to sacrifice a number of points from the challenge in order to get a clue. For example, we used a clue on a challenge that would have given us 150 points. The clue cost us 15 points, so we were only awarded 135 points for solving that challenge. That also cost us joint first position 😞.

What was your first challenge?

We were given a warmup challenge to get our feet wet!

Each challenge has an outline of what has happened, and what you should be looking for. This warmup challenge involved fixing a web page that had been accidentally replaced with a rather ugly page that referenced cats 😧.

The solution was to restore a previous version of the website from an S3 bucket. Once that was done, a link appeared at the bottom of the page which redirected to a site containing the answer. We then submitted this answer on the challenge page and got a good looking “The answer was correct” dialog 🙌!

What range of challenges were there?

There were 12 questions for this Security Jam, and they targeted a variety of AWS services.

We had challenges that required you to run queries against CloudTrail logs using Athena. We had challenges that required you to modify S3 Bucket and object policies to ensure that they weren’t accessible via the internet.

We had challenges that required you to build an environment that had certain levels of compliance.

We had challenges that involved searching for rouge shell scripts and isolating EC2 instances.

We had a challenge that involved using Splunk to see what was done with exposed API credentials.

We had a challenge that involved using Trend Micro for something to do with pen testing. I didn’t get a chance to look at this one. One of our team managed to solve it! 👍

What challenges were the easiest?

The easiest challenges were the ones that only involved one or two services. These challenges often involved looking through CloudWatch logs, or modifying a S3 buckets. I think it often helps to know where to look for potential solutions. I remember having to look for example S3 Bucket Policies because I forgot to add a CannedAcl policy.

What challenges were the trickiest?

These had to be the challenges that involved making sure an environment was compliant. In one of the challenges the compliance was communicated with you through a bucket object. It would tell you that 2 resources are not compliant. It wouldn’t tell you what those resources were, so you’d have to be very methodical about how you approached solving these kinds of problems, and not try and tackle multiple things in one go without checking that the first thing you did made that resource compliant.

What did you learn?

I learned that securing infrastructure can be just as exciting and satisfying as trying to break into it! There are a number of different problems you need to solve in order to make sure that you are not unintentionally exposing parts of your infrastructure. Because if there is a hole in there, someone will find it! And if you are one of the unlucky few… 🙈

I also learned about different products that hook into AWS services. I never knew what Splunk actually did, although I had heard about it before.

Conclusion

If you have AWS infrastructure, I would definitely recommend sending your engineers to the next Security Jam. If you can’t wait that long, they do offer a service that will host a Security Jam at your office! They’ve had events with 20–500 people, and I bet those people have felt a lot more confident about managing their infrastructure when they had finished.

I also have an urge to perhaps host a few exercises internally due to how useful this event has been for me personally. I know there are a few projects out there where you can set up environments specifically for Red Teaming, so I’ll try and get round to sorting something like that out :nerd:

The final results

See for yourself 🙌 🤓