Chris Farris

We’re a week away from AWS re:Invent and the level of cloud activity is reaching a fervor pace. Two things I’d like to share this morning. 1) How to Do re:Invent and 2) what all this re:Invent craziness means to a security professional.

If you’re lucky enough to go to re:Invent (and as far as I’ve heard it’s not sold out) a few things to bear in mind:

1. This is Vegas. It’s dry, there is alcohol and sleep deprivation. Chapstick is the most useful vendor giveaway. So are the “survival kits” which usually contain some form of vitamins and Pedialyte. Stay hydrated my friends.
2. All of the Breakout sessions will be on YouTube. What is not on YouTube are the workshops, chalktalks and vendor exhibition. Prioritize those over the breakouts. Blatant Plug: I’m giving two ChalkTalks on how I manage resources across my 250 or so AWS accounts. The first one is Tuesday 3:15 in the Aria and the second is Wednesday at 4pm in the Bellagio.
3. Transportation last year was a total clusterf—. The first few days the lines were an hour long to get on the bus. Plus the Vegas strip has horrible traffic. Try and plan your day to avoid moving between venues.
4. Attend the re:Play party. Even if you’re old and busted and have no idea what DupStep is, attend to see the sheer spectacle of the thing. Also you can forevermore call BS on Amazon’s Frugality leadership principle.
5. You’ll be in lots of line. Strike up a conversation with the folks around you. Most of us are introverts, but everyone there has something in common.
6. Fill out the post-session surveys. AWS gives you free swag for doing so. Also swag disappeared quickly last year.
7. Watch the keynotes but don’t feel you must attend the keynotes (unless you just love the smell of diesel). There are usually overflow spots and other places you can watch the keynotes. Some of those spots serve mimosas.

On the topic of keynotes, AWS is going to release a bunch of neat stuff. My biggest problem with the top three cloud providers is they release new products and features faster than I can understand the security implications of those products and features. This means security is playing a catchup game with developers who want to rush and put new services into their applications.

If your company is blessed (and cursed) with a culture where the risk management groups (InfoSec, Legal, Privacy, Enterprise Architecture) get to explicitly approve cloud services before they can be used, then December and January are when your work queue fills up and you have a chance to review things in an orderly fashion. You can schedule meetings with your AWS account team and AWS service teams to understand how the product works.

If your risk teams do not have the power to block the usage of new services until they are reviewed and approved, you as the security professional need to triage.

For all the new products announced in about a week, this is the ordered list of concern:

1. Anything that supports resource policies. Like S3 buckets and ElasticSearch clusters, these are the services a developer can expose to the world as they try and get the service to work. Last year, AWS announced SageMaker. I bet you didn’t know SageMaker notebooks can be publicly readable.
2. New security tools (GuardDuty, Macie, etc.) for InfoSec teams. I typically give these a quick look to see if I want to turn them on for specific high risk accounts/applications or plan a more orderly enterprise-wide roll-out. GuardDuty didn’t support an enterprise the size of mine when it was first released, so we held off a full roll-out and turned it on in our most high-risk locations. Towards early spring the GuardDuty team got their scaling under control and we could push it out via automation to all our accounts.
3. New security tools for development teams. These are things like Secrets Manager, Secure Parameter Store, S3 Default Encryption, etc. You want to understand them enough you can advise teams on the proper usage, and if they are mature enough mandate their usage.
4. New VPC Features. These fall into the Network-layer lateral movement category. Last year it was cross-regional VPC peering. That was actually a great thing for DR/BCP purposes. But if you rely on segmentation as part of your defense-in-depth you want to be careful how that peering happens.
5. New IAM Features. These fall into the Cloud-layer lateral movement category. AWS just this past week announced resource tags on IAM Users and Roles. That’s great for documenting things, but if people start using tag-conditionals as part of IAM or Resource Policies you now have another way someone can conduct IAM Privilege Escalation.
6. EC2 Management tools. These fall into the downward vertical movement category. How can someone who has limited access to an AWS Account get elevated access to an EC2 Instance (and possibly assume the instance’s IAM Profile).
7. Anything we can use to lower our AWS bill.

Here is a great example of a new AWS feature which could have significant security implications: ECS now support PID namespace sharing and IPC. Is this safe? Should I ban this? Do we already have something in our InfoSec policies and standards that prohibits this? What are the valid reasons I should grant an exception if the policy states this is not allowed?