Simplifying Security in AWS
ACM.184 Abstraction and how it helps you reduce management and complexity in AWS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.
🔒 Related Stories: Application Security | Secure Code | AWS Security
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In my last post I was creating an SCP to help prevent unauthorized removal of an account in your organization, while allowing removal when you need to do so without modifying your SCPs.
Today’s topic was inspired by someone who contacted me about a prior post. It made me realize a recap might be in order. I also apologize to that person because I currently cannot log into my buymeacoffee account for some reason to respond.
There is a spreadsheet in that post but that’s not the point of the post so I didn’t take it further than what you see in that post, nor do I want to do so because I have so many other things to complete. That was just to illustrate that the way AWS names things across the platform are not consistent. I was just trying to find a naming convention that works everywhere.
In fact, I don’t think I followed the naming convention I defined within my CloudFormation templates because things don’t always align and the names within the template are not used anywhere else — plus I keep my templates small and typically for a single purpose. That way it’s easier to figure out which template created which stacks and resources. In addition, I add the path to the template in GitHub at the top of each file so it shows up in the template in the CloudFormation dashboard.
The point of that naming convention post was to come up with a common naming convention for CloudFormation stacks and resources. I want to be able to easily see who create a stack and what’s in it. In addition, the use of a consistent naming convention helps me easily apply policies that limit access to CloudFormation stacks to the role that created them or is supposed to manage them.
However, without reading all the posts leading up to and after that post it might not be clear why and how I did that. So, that person inspired me to do a recap of my naming convention — what’s the point of the naming convention?
Simpler, but not simple
Everyone wants things to be SIMPLE but they are NOT in cybersecurity, ever. So whenever I see the world simple or simplify in relation to cybersecurity I cringe a little bit. Because nothing is simple. But we can make it simpler. I was thinking about this as I was asked to consider the topic of simplifying multi-cloud security and it makes my head explode a little bit.
I’m going to stick with AWS for the moment and what I’ve created so far in my GitHub account and written about in these blog posts.
The cool thing with the code I’ve written is that uses the principal of abstraction to reduce the lines of code we need to write and maintain:
To help us prevent repetitive code:
Every single CloudFormation stack I create is deployed by a single function which is in this shared functions file:
Now, I’m not going to claim this code is perfect nor is it my final iteration undoubtedly, but it deploys every stack in a consistent manner in one place. (Apologies for the weird formatting likely due to mixing up spaces and tabs or something. Maybe I’ll fix that later but working fast at the moment as this code is more of a prototype of something I hope to build long term.)
If you don’t like my naming convention, you can change it right there in that small block of code (for your own personal use — Please see the license for terms of use.)
You could also implement any security checks you want in conjunction with that single point of deployment. Of course it will be more complicated than that in a large organization as explained here:
That’s a topic I cover with customers in IANS Research calls:
If you wanted to change the format of the convention, such as adding a region for global resources in a multi-region deployment (something I might do if I need to in the future) you can easily add it to that block of code.
If you don’t like the names I’ve given my roles or resources, you can easily change those and pass in some other names, or add additional resources and roles if you need them and use the above block of code to deploy them.
Use of the naming convention in conjunction with IAM Policies
One thing you’ll want to keep in mind is that the prefix for each stack is used in the related IAM Policies that define which roles can modify which stacks.
If the stacks start with:
IAM-
Then the IAM administrator role policy allows the administrator to modify those related stacks:
If you decide to change your naming convention later — it will break the permissions for those roles and they might not be able to access and modify their stacks.
If you give someone else too much CloudFormation access, they might be able to modify stacks they shouldn’t.
Of course we can also look at creating Service Control Policies at a higher level to enforce these restrictions and prevent such policy misconfigurations.
That’s why I have a separate IAM and Governance teams in my scenario:
Although it’s simpler, it’s not simple. You need to keep your architecture in sync in that case. People maintaining security across the IAM and governance and other security teams need to understand how your naming convention, your stacks, and your SCPs work together to enforce your security policies. You may need a higher-level security architect to help with this who understands all the moving parts, as well as clear documentation on the rules your organization follows for creation of cloud resources.
Simplifying management with a thoughtful security architecture
The method I’m showing you simplifies security by reducing the amount of code you need to manage to enforce security policies. At the same time, you need people in your organization to understand how it works and not introduce changes that create a security gap or prevent people from doing their jobs.
So no matter how you implement security, it’s never easy. But you might be able to make it easier if people understand the basic principles and objectives of governance and a solid security architecture.
Which is not a checklist:
Or a tool.
A CSPM tool isn’t going to help you design your policies as shown above. You need to understand the rules and structure of your organization to define a naming convention that works for you and the associated policies.
Tools are useful! But you need to understand their purpose and limitations.
What the CSPM will do for you is help you monitor your cloud accounts for misconfigurations and security gaps you may have missed in your policies. Then you can fix those problems and adjust your policies, processes, and training to help prevent those same mistakes moving forward. Some CSPM tools may also help you implement policies or auto-remediate, but it seems to me that is best prevented in the first place by the policies in the cloud itself and and a well-designed IAM and Governance architecture.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2023
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab