Programmatic Governance in AWS
Multicloud.7 Using CloudFormation, Accounts, OUs, and Service Control Policies for governance on AWS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.
🔒 Related Stories: Multi-Cloud Security | AWS Security
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the last post I wrote about programmatic governance in GCP.
In this post, I’m going to summarize programmatic governance in AWS. I’ve covered most of this in my other series on automating cloud security so I’ll mostly be referencing that series.
In AWS you can use something called CloudFormation to define resources in files called templates and deploy them programmatically. I already explained in my posts on Azure and GCP programmatic governance that these files should be static and something you can always check into your own source control system, so you can monitor for unauthorized changes and drift.
If you are just getting started with CloudFormation check out this post.
My approach to CloudFormation may differ from some examples you see. I like to create what I call Micro-Templates for all the same reasons we use Microservices, containers, and classes in object-oriented programming.
You can and should use a tool like AWS Control Tower if you aren’t doing anything for governance or automated organizational deployment. It will handle some of the work for you and help you deploy policies. It uses AWS Config which can be a bit pricey compared to a DIY solution, but if you don’t have the resources to maintain governance any other way you should use it.
I don’t use Control Tower (yet) because it deploys roles and templates for you as opposed to code you control and check into your own source control system. I had some issues with that partway through the series. That’s why at some point in the midst of my deployment of a full governance architecture on AWS I started over and built everything in code starting with this post.
On AWS you can create an Organization, Organizational Units and Accounts as I wrote about in a prior post in this series. In this post I proposed a potential AWS Organizations Architecture. I’m still working through and testing out this architecture in my other series if you want to follow along.
On AWS, you can set up an Organization to link accounts together. This post explains how you can programmatically set up an organization.
At the time I first wrote about this, AWS CloudFormation could not be used to deploy an organization and there are some properties you need to control programmatically. As with Azure Tenants, and GCP Organizations the creation of an Organization is a rare occurrence. However, it’s not as easy to monitor for drift with the programmatic settings compared to a CloudFormation option and its the one inconsistency at this point in maintaining fully automated governance on AWS.
As I wrote: Maybe it’s in the works. And it was:
YAY!
You can programmatically add new accounts to your AWS organization. These posts show you how to do that programmatically.
Via a Lambda function:
I prefer CloudFormation over the programmatic method for the reasons already explained in other posts.
Here’s the syntax for an account in CloudFormation:
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*TtFR4AN1cXCiiw1oDMoQZA.png)
In my post, I am using an organization prefix stored in AWS SSM Parameter store (described in prior posts) to ensure anyone who uses my code gets unique names in their organizational structure. For example, your prefix name may be acme and every account would be named acme-dev, acme-iam, acme-test, etc.
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/0*PLmmFz9BdGny7GPo.png)
You can also create an Organizational Unit (OU) to group accounts that require the same policies with CloudFormation. You can also create the organizational Service Control Policies (SCPs) with CloudFormation. This post explains how.
Here’s what an OU looks like in CloudFormation:
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/0*BSx395y8-pN8Tek-.png)
Here’s what an SCP looks like in CloudFormation:
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/0*OBJW5Trw7ZQTfBnf.png)
AWS SCPs are policies that are block-only at this time. There’s no alert-only mode (#awswishlist item) so you can use this strategy to roll out AWS SCPs and avoid problems like preventing people from doing their jobs and production system outages.
AWS doesn’t have a service to map policies to compliance frameworks just yet. I hope that is under consideration. In the meantime, you can use AWS Audit Manager as a tool for reporting on compliance.
Here is a list of frameworks AWS Audit manager supports:
Now the obvious stepping stone here is that eventually, AWS audit manager allows you to deploy service control policies to support governance of various frameworks. I just hope they do so in a manner that allows the customers to own the source code used to implement the policies. For example, a customer might choose to generate a policy and either push it to their accounts, or, if they wish to control the policy in their own source control system, they can download the code for the scps and framework. #awswishlist.
One of the issues with that is that AWS should not create a monolithic template as has been done in AWS Control Tower, and in order to create separate SCPs for each control so customers can pick and choose which controls they want to deploy, the limit for SCPs will need to be increased most likely. Customers may want to also deploy different SCPs at various layers in their organization hierarchy, as opposed to an organization as a whole. Allowing customers to download the code and use it is much more flexible than a system that creates and deploys code on a customer’s behalf.
For now, you can create your own service control policies as needed to align with any framework you choose using service control policies. AWS offers a number of sample SCPs here:
and here:
I’m sure some vendors will also create and manage SCPs aligned with various frameworks for you, but you need to be aware of the risk of allowing third-party services to take actions in your accounts. I’ll cover that in a separate post.
If you are using AWS Control Tower it makes use of AWS Config to help you comply with frameworks such as NIST and PCI DSS. AWS Config can automatically rollback unwanted changes. It’s another tool to help with governance but note the cost of each individual config rule and understand that at the time of this writing, I don’t think you can fully control all the source code and roles used for these deployments. You may or may not want or need that so this solution might work well for you in that case. You can find a list of the frameworks AWS Control Tower supports here:
After this review of the three cloud provider options for automated governance, it seems obvious to me that AWS has the most fully developed mechanisms for implementing completely automated governance. I’m doing just that and providing the code for you in the source code repository associated with the other related series.
Note that the related code is an on-going proof of concept (POC) at the moment so no guarantees, but the sample code will help you get started and I explain how to use it effectively in my related blog series. The final result will be a bit different if I can complete it the way I want in the future so it will change over time. Check out the readme in the GitHub repository for the most up to date information.
I was initially thinking of writing governance code for all three cloud providers for the presentation in October, but given the licensing requirements for Azure which would somewhat pricing for one presentation and the different languages and constructs you have to use in GCP I’m going to skip that. You have enough information in my recent blog posts to attempt to write governance code for each platform if that’s something you need to do.
Let’s take a look at some other options for simplifying the complexity of maintaining governance on all three cloud providers. Again, if you want to join in on this conversation, come to Atlanta in October to provide suggestions and ask questions about multi-cloud security. If you’re a vendor, reach out to IANS to find out how you can have your own session to showcase your products and services.
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 Lab
Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation
Follow 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
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/0*H9Ew1KCl-29nZiPR.jpeg)