A couple of weeks ago marked AWS re:Inforce 2022 held in Boston. re:Inforce is AWS’s global security conference aimed at enabling customers and this was the second time it was held in Boston. I love attending re:Inforce and think it’s the best opportunity for AWS customers who focus on security to learn more about security on AWS. The conversations that I had with customers were the deepest I’ve had on the topic and there was an opportunity to meet cloud security specialists from all over the world. During the event there were 266 sessions were split over 5 tracks in 2 days and in this post I’ll summarize the key highlights and takeaways.
Stephen Schmidt has moved to a new role this year as the Chief Security Officer for Amazon as a whole. During the keynote he noted that despite the wider scope of his role he still wanted to be involved in AWS re:Inforce. Throughout the keynote there was a lot of focus on security culture which mirrors a lot of the conversations I have with people using AWS. To have a successful cloud security program, organizations need to subtly change their approach in how they think about security. The key opening message from Stephen Schmidt was to start with your short term security needs, the deep edge cases can be done later. In a lot of cases, AWS is seeing these threats for you and dealing with them.
“At our scale, every outlier scenario that can happen, does” - Stephen Schmidt
Every day AWS tracks quadrillions of events which means that learnings are added back to the services. If you think of services like Amazon GuardDuty, the events that AWS sees at scale are able to be notified on as new findings. Rather than focussing on trying to create your own specific set of findings, use GuardDuty and use the saved time and resources to get the basics right. Stephen Schmidt reiterated that the most successful security teams (and the way it’s done at Amazon) is to weave security into your development cycle, not just operations. At AWS there are a group called Security Guardians who don’t report to the security team but are engineers in the teams that are building services, features and produce. These folks know their products the best and are therefore best placed to make it secure.
Schmidt also some shared key lessons from his time as the AWS Chief Security Officer. Firstly, you need to ask who has access to what and why. An overly permissive environment cases headaches. For me, this is even more true in the cloud where who has access to what cloud APIs is controlled by your identity strategy.
“Any time you store data it should be intentionally controlled, intentionally encrypted, and intentionally protected” - Stephen Schmidt
A key design principle in the security pillar of the AWS Well-Architected framework is to “keep people away from data”. If people don’t need access to data, don’t give it to them. He also spoke about building a multilayered protection strategy. If you rely on a single control it will fail. Instead build an environment where multiple failures need to occur for an incident to occur.
“Security tools are always stronger when used as a holistic strategy” - Stephen Schmidt
The last theme on a culture stand point is “we’re stronger together”. Again, reiterating that security should be baked into operations. Don’t silo security as the “other” group, they need to partner with the development groups. As an AWS customer, also ensure you’re using all the resources at your disposal - AWS, AWS partners and tools available on the AWS Marketplace. Don’t rely on individuals because that doesn’t scale.
At this point, Schmidt handed over to CJ Moses who has succeeded him as the AWS Chief Security Officer. Moses also spoke to the theme of aligning your development and operations teams. He further iterated on what this means at Amazon. Single threaded leaders for a business own all aspects of their business - that includes security. As security professionals, that means we need to have regular touch points with business leadership to make sure we’re meeting their security needs.
“We have a weekly security meeting with our CEO. That meeting is more than just a meeting. It’s a mechanism that reinforces our security culture” - CJ Moses
One example of this that Moses spoke to was at the weekly security meeting after an acquisition made a few years ago. Rather than the acquisition’s business leader being present, only the security team was there to represent them. The meeting was paused until the business leader was present and it was reiterated that the single-threaded owner for the business is the owner for security. Those needs are then reflected throughout the company. Prioritizing security by baking security into the build pipeline and throughout the development process means that security reviews are quicker and uneventful. Providing the right tools means that doing the right thing becomes easier. In order to support this, security teams needs to change from the office of “no” to the office of “yes but” or “yes and”. Follow up by measuring your impact with satisfaction surveys.
Moses spoke about some specific learnings for AWS customers in recent times. Least privilege is a conversation that remains high on the radar and is an essential defense in depth mechanism. Least privilege isn’t just what access you give folks all the time - it’s also thinking about time based access. Admin access should be temporary, unused software should be removed, and if someone is on vacation their access should be removed too. Vulnerability reporting remains a high priority. Ensure that your customers know how to contact you, track events through tickets, and build an environment where everyone can give input - bias towards escalation. Customers continue to be concerned about ransomware. Prepare to detect vulnerabilities and anomalous behavior ahead of time, know how to respond, and lock down your data. Lastly, make sure you take the opportunity to learn from the Log4J vulnerabilities that were discovered last year. This was a large security event that all organizations would have had to investigate. Defense in depth was a key to being able to defend against this and the ability to hot patch shortened the time to mitigation. Having an inventory of software and its usage as well as keeping third party software up to date was critical. Not all versions of Log4J were affected so you need a list of what software exists to know were to start.
One aspect I love about AWS events is the highlighting of customer stories so other customers can learn from each other. This event was no different. Lena Smart, the CISO at MongoDB, spoke about their security program. The way that security is built at MongoDB mirrored a lot of the other content from the keynote. MongoDB’s goal is to “make data simple and easy to work with” which means they also need to keep it secure. Smart spoke about her teams approach and focussed on the foundational aspects, reiterating that they work with AWS as a partner to stay secure. They also run a security champions program to help their teams build securely.
The last speaker in the keynote was Kurt Kufeld, the VP of Platform at AWS. A lot of his talk was focussed on areas that AWS has built security into the AWS platform moving forward, looking ahead to where customers need AWS to be.
“I skate to where the puck is going to be, not where it has been” - Wayne Gretzky
All AWS services that store data allow you to encrypt that data at rest, most of those with keys that you can control in AWS KMS. The algorithms used are the best you can get today and Kufeld also spoke to the work that Amazon has been doing to contribute to quantum-resistent cryptography. Although we are not quite living in a post-quantum world, work is already being done to secure AWS today. The call to action from Kufeld was to please encrypt everything, a core component of a good data protection strategy. Another area which he spoke to which I think is fascinating, is the work AWS has been doing in automated reasoning. Automated reasoning is building an ability to formally prove security. This allows statements to be made that are universally true about resources. Some areas you can already see this in use is in block public access for S3, IAM access analyzer and VPC reachability analyzer.
This was followed by some final key calls to action. Firstly, use the block public access setting for S3. Access analyzer will let you know when a bucket has been made public but block public access will prevent it from being made public in the first place. Secondly, use MFA. In addition to something you know (your password), enabling MFA checks against something you have - like a physical token. For US based AWS customers you can even order a free MFA token from AWS.
If you want to watch the keynote yourself, a video of it is up on YouTube.
In addition the the keynote and many breakout sessions there were seven leadership sessions from key thought leaders at AWS. If you want to dive deeper into any of the content from the keynote this would be my recommendation of where to start.
- What “security is our top priority” means to AWS - If you only watch one of these sessions I would recommend this one! Eric Brandwine , Mark Ryland and Colm MacCárthaigh are all long term Amazonians and very engaging speakers. This session focussed on how AWS approaches security. If you’re looking to dive deeper into those subtle, cultural differences of security in the cloud start here
- Proactive security: Considerations and approaches - This session focusses on how security in built into the builder experience at Amazon. Dive into this session on a real world example of how the secure way can become the easiest way
- Security mindfulness - This session was very different! Rather than focussing on the technical aspects of running a security organization this session focussed on how to build a psychologically safe security team and how to ensure that you’re developing your team
- Streamlining identity and access management for innovation - As I mentioned in my keynote summary, identity is very important in the cloud. This leadership session focussed on how identity is foundational in the cloud journey and highlighted the latest features that can help you get there
- Reframing the way we think to achieve compliance at scale - AWS customers who work in regulated industries will be interested in this session that focussed on how AWS is thinking about compliance at scale
- Cryptography from the future: Research & innovation to protect customer data - this session dives deeper in to the areas Kufeld covered in the keynote about quantum-resistent cryptography - a very technical session!
- Security operations at scale - Another session with the legendary Eric Brandwine where he dives deeper into his experiences at AWS and how AWS has approached security
During the key note AWS made five key announcements made starting with a new feature from a few weeks ago, IAM roles anywhere. An important best practice in the security pillar of the AWS Well-Achitected framework is to “use temporary credentials”. Until recently that’s been hard for customers who have a requirement for connectivity to systems running on premises. With the release of IAM roles anywhere there’s now a viable option for temporary IAM credentials to be used for systems running outside of AWS.
Next, Amazon Detective now supports Kubernetes workloads running in EKS. Amazon Detective is a service that allows customers to analyze and respond to events. Previously this was around calls logged in CloudTrail and network traffic logged in VPC. The addition of EKS audit logs allows customers to get visibility into events within their Kubernetes infrastructure.
For me, the biggest announcement was the additional of Malware Protection in Amazon GuardDuty. GuardDuty is a detection service that surfaces intelligent findings from a number of different sources. With the additional of malware protection customers can now configure GuardDuty to perform a scan on a snapshot of an EBS volume attached to a machine displaying anomalous behavior. For customers dealing with incidents this should shorten the time between getting an EC2 related finding and a clearer answer about what’s causing it.
Of course many customers are using AWS Security Hub to centralize their findings across services, accounts and region. Luckily the next announcement was that the AWS GuardDuty Malware Protection findings are imported to Security Hub too. For customers working in large organizations this provides an additional layer of visibility into their environment.
Lastly, AWS also announced the preview of AWS Wickr. Wickr is an Amazon acquisition which is delivering end-to-end encrypted messaging for enterprises. It will be interesting to see where this goes during the preview.
My call to action is to use the resources available at your disposal to build your skills. AWS events like re:Inforce are a great enablement opportunity to build your understanding of AWS. You can sign up for updates on the release of on-demand content via the AWS re:Inforce website but there are two particular pieces of training highlighted in the keynote I want to point out.
The [Cloud Audit Academy] is designed to educate risk and compliance specialists in auditing AWS workloads. In particular, a new workshop has been announced to educate these professionals in the audit of PCI DSS compliant workloads. A new workshop focussing on US federal and DOD workloads is in development for later this year.
A brand new workshop has also been released on AWS Skill Builder called Threat Modeling the Right Way for Builders. With developers now standing up infrastructure as part of the development of their workloads it’s more and more important that they are familiar with how to secure it. This workshop is based on how AWS does threat modelling aimed at builders who are getting started in this space.
Overall it was great to be overseas again and speaking with security professionals face to face. Were you also there? Or did you catch up on the content online? Either way I would love to hear your highlights and key takeaways so please reach out!
Cover photo from @woomantsing on Unsplash