Security is everyone’s job. There, I said it. Now that I got that under my belt, I’ll tell you how the first (Amazon Web Services) AWS re:Inforce conference went.
The Senior Information Security Architect at my job wasn’t able to attend the conference and asked me to go in his place. With the focus being on security, this wasn’t something I would have picked for myself. Alas, my manager said I could go if I came back and shared what I’d learned. I’m so glad I did.
Day 1
Dejavu all over again. I was just here at the Boston Convention Center a few weeks ago for Red Hat Summit which means I’d have a greater chance finding my sessions. They had shuttles to and from hotels which was great, but upon entering the convention center, there were metal detectors and bag checks. I’ve never been to a conference where they had metal detectors and went through your stuff. It felt like I was at the airport, except I didn’t have to take my shoes off. You had to empty your pockets and if you had keys or any metal, you had to walk through with it in your hands and your hands over your head (like don’t shoot). Of course, the metal detector goes off as I walk through. The guard wands me and stops on my pocket. He’s starts getting louder and louder asking me what’s in my pocket over and over again. I said, “nothing” and he asks again, so I just lifted shirt up and patted my pocket and said, “nothing!!!”. He lets out this little laugh and says, “oh, it’s your jeans.” How many people do you think walked through there with grommets on their jeans? DO BETTER re:Inforce organizers.
Off to breakfast. There is nothing good to report here. On to my review of the keynote.
Keynote
Tuesday started with the keynote, lead by AWS VP and CISO, Steve Schmidt. His talk started off separating AWS from the other cloud vendors by way of the revenue generated and the number of ‘regions’ competitors have verses the number of regions AWS has. With 21 regions and 66 availability zones, the way AWS constructs regions, seems to far surpass that of the next closest competitor.
There was a lot of emphasis on security of the cloud and security in the cloud, which is called, the shared responsibility model. Looking at the culture of security, (this is a security conference, right) it must be “built into what we do everyday”. Touting AWS products that will provide the type of granular security, monitoring and compliance businesses need now and in the future, he hoped we all walked away with 3-5 things to make you more secure.
Separated in to chapters, the talk covered the following topics:
- Chapter 1: The Current State of Security
- Chapter 2: Culture of Security
- Chapter 3: Governance, Risk and Compliance
- Chapter 4: Security Deep Dive
- Chapter 5: The Future of Cloud Security
As he reviewed the current state of security, he hailed that fact that currently, 94% of all websites are using SSL, but on the other end of the spectrum, 94% of all IOT devices are sending information in plain text. AWS has service called IOT Defender, a fully managed service which gives you a way to patch and update devices and even more importantly, encrypting device data.
There is a service called AWS Ground Station, which is a fully managed service that lets you control satellite systems as well as ingest and process of of that data.
The most talked about suite of security services in this keynote was Security Hub (which just went GA), GuardDuty, Inspector and Macie. Together, they provide automated compliance checks of application and resources, uses machine learning to analyze and monitor account activity and networks, and classify and protect sensitive data. Although separate products, they seem to always be mentioned together.
He mentioned that “encryption is no silver bullet”, but it surely beats a blank, There is a new feature that customers have been waiting for is Elastic Block Storage (EBS) encryption by default. You can opt-in to have all newly created volumes encrypted at creation, with the ability to use customer managed keys or AWS default keys. Since keys are regional, you have to opt-in region by region. This, on top of layering defenses, AWS is putting security at every level.
There were many more services mentioned and reintroduced; Control Tower, Config Rules, IAM Access Advisor + Organizations, AppMesh, Nitro w/ Firecracker, Radar Framework, Root CA Hierarcy for ACM and so many more, I thought they were just making stuff up at this point.
How to Secure Your Active Directory Deployment on AWS
This is the session that I looked forward to the most. Since we are working towards deploying Active Directory (AD) to AWS, this was pretty timely. The presenter, an AWS employee, discussed the use cases for deploying AD to AWS, then gave an overview that covered 2 deployment types, self-manged AD and managed AD. Starting with an overview of the basics of AD, he used the shared responsibility model as the starting point to draw the distinction between the two solutions.
The managed AD solution is of course easier and less work to deploy. Creating a separate forest or domain and either a 1-way or 2-way trust in the beginning was biggest part of implementing that solution. The only thing the customer has to worry about after that are the users, group and group policy. We looked at that solution in the beginning, but for what the level of access we require in our domain, we opted for the self-manged AD, where we deploy a server and promote it to a domain controller (DC). This allows us to extend our on-prem out to AWS and work with our single sign on.
He discussed the of separation of responsibility by creating an account structure that separated the management of AD into separate accounts using AWS Landing Zone. Also, creating a separate organizational account that logged all accounts using CloudTrail and AWS Config logs as well as a security account that had the GuardDuty master in it.
This talk covered quite a bit of very relevant information for me. I’ll definitely be reviewing the slides and rewatching the session.
Securing Serverless and Container Services
This talk was on 2 technologies I’m not very familiar with; serverless and containers. He talked about common sense approaches to securing both technologies, using slides that covered multiple security domains and services as well as ‘cloud adoption framework’ from a security perspective. Slides & recording.
Security Best Practices and the Well-Architected Way
As a student of the Well-Architected Framework, this session gave me a great primer into how AWS provides services that upholds this pillar. With the Well-Architected tool, which is free to use, you can review your workloads and discover areas where you can improve technical decisions on how to secure your workload in AWS. I also found out about the labs on security as well as other pillars of the framwork. This look like a very good resource to play around with tools (outside of your production account, of course) and discover what’s available. Slides & recording.
Learn to Love The AWS Command Line Interface
This was a talk held in the expo center at the Developer’s Lounge by one of my favorites who teaches online AWS certification classes on Udemy and A Cloud Guru, Ryan Kroonenberg. I was so excited to see his tweet that he was doing a talk on the AWS CLI. Although the title was different, it was the same exact talk he did at AWS Public Sector Summit, but with a different name.
I wasn’t the slightest bit upset by it. At his talk at Summit, he mentioned he used Amazon Polly to help him study for exams. I took his advice and learned about Polly and did the exact same thing for my exam,which was a little over a week away. I typed my notes up and used the SSML markup and was able to download them all to MP3s. It was so rad to be able to study on the go.
Before the talk started, I’d asked could I get a selfie with him because he was swamped at the end of his talk at summit. Of course he obliged and his right hand, Faye Ellis volunteered to take the photo. There was NO WAY I was going to have her take the photo, I wanted her in it.
He went over 20 CLI commands and stipulated that this talk wasn’t aimed at gurus, just regular folks who want to learn about what’s possible in the CLI. He covered installing it on Mac and Windows as well as setting it up with your access keys (the very insecure way, but hey, that’s how we all learned). There were quite a few that I didn’t know about or forgotten about. I didn’t use Polly via the CLI, but this time I took a photo of the URL in the slides and I will definitely check it out.
Of course, I had a better grasp on some command the second time around. It was a great 30 minutes well spent and I got to thank them for the great content. There was no need to take notes, he put all the commands up in S3 for our CLI enjoyment.
Threat Detection on AWS: An Introduction to Amazon GuardDuty
Finally, a primer on GuardDuty. By this time, I’d heard so much about this product, it was high time a found out what it actually was. My colleague said we were already using it so now I was even more interested in seeing it for myself.
GuardDuty is a regional managed service that can aggregate logs across AWS accounts and analyze them for unexpected and/or malicious behavior happening into a record called a Finding. With no agent needed, it takes information from VPC Flow Logs, CloudTrail events and DNS logs and produces the findings. Rated high, medium and low, findings contain information about the resource in question and the behavior detected. You click on it for even more details about the issue. Details may include account id, the type of resource, the port, the number of times it’s been logged, as well as a link to learn more about the behavior.
GuardDuty gets their threat intel from CrowdStrike, ProofPoint and threat information gathered by AWS. With this much information, you can imagine the number of events being processed. This data is never logged, just streamed and processed in memory, unless the log entry contains a finding.
Once you get a feel for the type of behaviors that are occurring in your environment, you can set up automated remediation using Lambda, and CloudWatch events to take action on a finding. If someone adds or changes a rule to something insecure like port 22 on 0.0.0.0/0, you can create a Lambda function that will lock the port down to whatever you like.
I’m sure it will be a great tool in our AWS security arsenal. Slides & recording.
Day 2
How to act on your security and compliance alerts with Security Hub
This talk was aimed at getting customers to look at Security Hub (SH) as a way to address compliance. With two AWS employees and two SH customers, they started off with 4 problem statements that outlined issues that can be addressed by this product.
- Backlog of Compliance requirements
- Too many security alert formats
- Too many security alerts
- Lack of integrated view
SH offers a single view into your security and compliance tools. Using best practices suggested by the Center for Internet Security AWS security benchmarks, you’ll get a compliance score against their standards. It’s a bit like GuardDuty in that it will offer a single view for you to review, triage and take action on issues. It even works with GuardDuty as well as Macie and Inspector as they can send their findings into SH for review. You can also centralize accounts and it will give you insight into what types of issue it discovers across your organization.
Plenty of third-party integrations like CrowdStrike Falcon, Palo Alto: VM-Series and Splunk Enterprise to enable and gain the ability to consume their data. With provided CloudFormation templates, you can set up integration between them and SH. You can also send findings to partners like PagerDuty, Slack and Splunk for even quicker notifications.
Aligning to the NIST Cybersecurity Framework in the AWS Cloud
This talk was way over my pay grade, but I was able to glean some gems to bring back to my colleagues
I learned what NIST Cybersecurity Framework was what industries, organizations and even states that use it. They mentioned a whitepaper on it as well as a workbook that outlines the responsibilities.
I had to run in the middle the talk to grab a special swag item by request, but here are the slides and recording.
Securing your Block Storage on AWS
This talk was an overview of block storage in general as well as availability to opt-in for default encryption on new EBS volumes. It’s just a check box and from then on, all new volumes will be encrypted using a key you create or a default key. Although you’ll need to enable this on a region by region bases, you can forever be sure that volumes will be encrypted.
There was so much talk of KMS, I decided to make sure I dropped into the hands-on labs to see if I could get some time with it.
Containers and mission-critical applications
I hope the slides and recording can shed light on this. This session was PACKED. The walk-ups couldn’t even get in. *** Inside Hack*** Next time, walk in on an empty line, grab some headphones and sit in an empty seat in another section.
Hands On Labs
I passed on the last 2 sessions of the day to get some time in with hands on labs. When you entered the room, you were given a ticket with a code that gave you 1 free lab on qwiklabs. Once you were done with a lab, you could get another code and learn something else. I was able to knock out quite a few before they closed down. Here are the labs I completed.
- Caching Static Files with Amazon Cloud Front
- Introduction to Amazon EC2
- Working with Amazon Elastic Block Store (EBS)
- Working with Elastic Load Balancing (ELB)
- Introduction to AWS Key Management
- Introduction to AWS Identity and Access Management
The EC2 and IAM lab were elementary, but I’d never created an application load balancer before, so that was a pleasant surprise how straight forward it was to set up.
End of the conference
After an exhausting day and an AWS online study group to get to, I didn’t go to the closing reception. However, I was able to make my way to the expo floor and snag a few more t-shirts and a beer.
Overall, this was a really good conference. I learned a lot about services I’d never heard of and more about services that I use frequently. With all this information about what AWS has and how some services work together, I feel like I’m in a better position to investigate and dig around the console more and gain some nuggets for the Solution Architect exam.