🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.
Overview
📖 AWS re:Invent 2025 - Building Secure-by-Design Environments with AWS Capabilities (SEC208)
In this video, Gal from Native and Sowjanya from AWS identity team discuss shifting from detective to preventative security approaches using AWS native controls. They explain how Service Control Policies (SCPs), Resource Control Policies (RCPs), and declarative policies enable security by design, using encryption enforcement as an example. The speakers highlight the complexity of implementing data perimeters across multiple policy types and cloud providers, then introduce Native's solution that simplifies the entire process from discovery through planning, simulation, implementation, and operationalization of security controls across AWS, Azure, and GCP.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
From Detective to Preventative: Understanding Security by Design with AWS Native Controls
Thank you very much. Hi everyone. My name is Gal. I'm one of the founders of a company called Native. I'm speaking together today with Sowjanya, my former colleague from AWS. As mentioned, I used to work for AWS up until a year and a half ago. Prior to that, I was actually leading a product called Security Hub.
During my time at AWS, I learned that cloud providers, AWS and the other ones, offer really robust security capabilities that customers can use in order to make sure that their environment is secure by design. I've also learned that while these capabilities are strong and powerful, it's also incredibly hard for customers to make the most advantage out of those. So in today's talk, we will talk about why security by design is important, about those AWS capabilities that you can use to achieve security by design, about the steps to achieve that and define the guards that you would like around your environment, and finally towards the end about how what we do at Native makes this simple, not just at AWS but actually rather across cloud providers. With that note, I'm going to pass it to my friend and colleague Sowjanya from the AWS identity team to kick us off.
Perfect. Good morning. Hope you're all having a wonderful Thursday here at re:Invent. All right, so let's start with talking about a scenario that you are all probably and painfully aware of, right? Your security team came in and said, hey, we want to enforce encryption on all of my EBS volumes, right? Your security team did a scan and identified about 1,000 unencrypted volumes, right? And here begins what I call a remediation treadmill, right?
So what happens? You reach out to all of the resource owners, try to find out who created them, why were they unencrypted, and then go through the painstaking process of encrypting each of these volumes and then also creating an exception list if you have a legacy application that forces you to keep the volume unencrypted. And then spend months together to encrypt all of these 1,000 volumes, and then you celebrate your success. Hey, you know, you're done with meeting your security control, and then run another scan and discover now you have 500 more after six months.
So it's a never-ending cycle, right? And that's the nature of detective controls or a detective approach. It's always reactive. You wait for things to happen and spend expensive resources and time identifying, detecting these gaps, and remediating them. And what's furthermore concerning is your organization is at risk while you're trying to detect and remediate this. So how about we flip this and move from a detective approach to a preventative approach?
You put in a policy saying that going forward, no new EBS volumes would remain unencrypted in your organization, right? So this is the premise of secure by design where you are shifting from a reactive approach to a preventative approach, right? So this magically doesn't remediate all the existing unencrypted volumes. You still have to clean them up once, but instead of all your security team spending months of time performing the same repetitive cleanup job, they spend a few hours enforcing a preventative control, and then your security control remains intact, right?
So a combination, this is the whole foundation of secure by design as I mentioned, right? And then you repeat this process, not just for EBS. You move it to EFS, to S3, to KMS, and all the other AWS resources where you want to enforce encryption by default, right? So this secure by design approach is not just applicable for configuration of your AWS resources, right? This is furthermore, or much beyond configuration.
It could be applied to cloud footprint management. Where do you want your AWS resources? What regions do you want your users accessing your AWS resources in, right? So this prevents shadow IT creation. It could help you enforce your data residency requirements, right? And then we also can apply the same philosophy to external access management. Do you have partners? Do you have secure third-party integrations? And you want to enforce your security controls and requirements for each of these external access patterns.
Similarly, moving beyond the configuration, we at AWS have a framework called data perimeters, which we will be discussing in a couple of slides. When you're enforcing your security controls beyond configuration, data perimeter comes into the picture. Then you have privileged actions. You may have privileged actions like deletion of databases or making sure that your security services are not tampered with, and you want to enforce and put preventative controls for each of these domains.
By implementing secure-by-design in each of these domains, you're not just preventing and meeting one single security control. You're creating a secure architecture across your domains. Within AWS, we have certain native controls that can help you build on your secure design. The first one is Service Control Policies, or SCPs. I'm sure many of you are familiar with this. What you do with SCPs is you put in controls saying that for all my principals, whether it be AWS services acting on my behalf or my own users, federated users, or the roles that my users assume, I put in a boundary or the maximum permissions that these principals can access.
Then Resource Control Policies, or RCPs, work backwards. They come in from a resources perspective, so irrespective of who's accessing my resources, whether they are my users, whether they are external partner roles, or any other service acting outside of my organization, I want to control how they get access to my resources and what resources can be accessed. That's where you're putting controls on your resources, which are called Resource Control Policies. Finally, declarative policies. We talked about configuration management. Declarative policies are powerful because you can define and then enforce the configuration of your AWS resources and services. We have additional policies like VPC endpoint policies that control what gets in and outside of your network, resource-based policies and identity policies.
Using these constructs, for example, in the scenario that we talked about where we want to enforce encryption, we have a couple of policies. You can always refer to these policies from our GitHub, but the gist of these policies is you're denying the creation of EC2 volumes. Here, the volume create volume call, if the encrypted EC2 encrypted condition is false, so you're preventing creation of any new volumes without encryption. At the same time, you're also preventing anybody from tampering with the account-level encryption setting, the default setting.
Similarly, you can take the same context to EFS, where you are denying creation of file systems or updating file systems if the encrypted condition is false. Then you can extend this to other AWS resources as well. The philosophy is the same. You're trying to enforce the similar pattern but for multiple resources. Here's where the complexity increases, as you see the conditions and the actions that you want to take care of and control are different. You have to carefully craft each of these policy types for each of the AWS resources and service types and need to know them. You have to design them in such a way that these do not block or interrupt your existing business workflows, while at the same time implementing your security controls. Yes, this can be done, but you need to understand and learn about each of these services and the actions that you need to control.
We talked about data perimeters, and we have a whole GitHub repository where you can refer to the data perimeters, so you do not have to start from scratch. In essence, what you're doing here is you are defining perimeters. You're building a perimeter around your identity, saying that only trusted identities can access my resources and only trusted identities are allowed from my networks. Similarly, for resources, you're saying my identities can only access my resources or the trusted resources that I know of, and only from the trusted networks. From a network perspective, you're saying, I don't want anyone else bringing in their private credentials or personal credentials and accessing from my network or through my network.
All of these are enforced through the policy types that we talked about: the RCPs, SCPs, VPC endpoint policies, and a plethora of the conditions that we have. The gist of this is this can be done, but the complexity is that you have to perfectly balance and create a harmony between the types of policies that are shown here.
And that's where the complexity of implementing secure by design comes into place. And this is only, we are talking about in AWS, but the complexity increases when it gets beyond AWS. And Gal, do you want to talk about that?
Simplifying Multi-Cloud Security Governance: How Native Operationalizes Security by Design
Yeah, absolutely. So thank you again for presenting this. I couldn't have done it any better, but really to the point that we had. Security by design is about enforcement. It's about building an environment that's always secure, and the way to do that both in AWS but also in other cloud providers is relying on the native built-in controls and security policies. That's why our company is called Native. As I mentioned, I used to work for AWS, so I saw firsthand how this is built and baked. We saw that the built-in native capabilities can help customers enforce things at the source, no matter whether they go through a pipeline or the console or for some other mechanism. It can help. It does the enforcement with zero latency. It's built for scale as you add more and more and more accounts into your organization. The policy would still be enforced and would be enforced all over the place and so on.
It gets to a level where Amy Herzog, the CISO of AWS, has said herself that the fastest path to better security, to security by design, is using the protections that are built into the environment. And while this quote comes from the CISO of AWS, there are similar quotes on the internet from the CISOs of all of the other cloud providers. But I also know that making the most out of these built-in mechanisms is complex. So Sowjanya herself showed you all of the different condition keys and policy types and so on, and it's a puzzle that you need to go and build around. These are basically Lego bricks, and then this was just AWS, and now those things work differently in Azure and GCP and so on. And this is really where Native comes in.
So we've worked with countless security architects, cloud security teams, platform teams, and we've identified that the process to go and define those controls goes all the way from discovery to planning the rollout to simulating it all the way to implementing them and operationalizing those controls. So you start with discovery, the effective policy, what's currently at stake, talking about security outcomes and translating that. You move to planning. What do I actually want to enforce? How do I want to enforce that? What's the rollout? You then go on to the simulation. How is this going to impact my resources? It goes on to implementation.
Just perimeter policies, network perimeter policies on AWS can be 30 plus policy statements. We go and do the translation for you, not just into those two SCPs that Sowjanya showed earlier, but rather to many more and different types of policies and go all the way into giving you the implementation instructions and the rollout and so on and so forth. And finally operationalizing what's the effect of the policy, exception requests and so on and so forth.
The point is that this entire cycle that's made simple for the platform really allows you to go in and ensure security by design. It allows you, to my point from earlier on, to be secure at the source itself, build and operate environments that are secure by design. It allows you to unify your governance policies and your governance processes and manage policies across different cloud providers from a single location. So if you're AWS experts, but you also have Azure and GCP, you don't need to become experts in those clouds. You can just take your existing policies, hit a button, and they would be enforced or vice versa.
It gives you the end to end operationalization capabilities, what has been blocked by the policy, exceptions management, drift, many more, and it gives you adaptive coverage. Cloud providers, I know this, I worked for AWS, they launch consistent updates to the platform, new APIs, new capabilities. We go in and provide those updates as things are being updated, as your cloud changes, as your business needs evolve. We allow you to quickly adapt.
With that, I hope that was a clear introduction into why security by design is important, why it is hard, but also how we can be of help. If you want to learn more, feel free to just stop by our booth. I'll be there. Ask any questions. We will have other fantastic members of the team there. Feel free to also log in online to our site at native.security. Feel free to reach out to me on LinkedIn, Gal Ordo, to my colleague Sowjanya, or to any other colleague that I have that you'll meet at our booth. Thank you so much for the time.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)