Baking Security In From the Ground Up on AWS
Starting from scratch in a new AWS account and building out a secure architecture
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.
🔒 Related Stories: Cloud Architecture | Cybersecurity
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

When I initially started writing this series on Security Metrics Automation, I was going to create a basic security architecture for secure automation of batch jobs. I actually want to use this framework in my own business for penetration tests and security assessments.
The problem was as I got down the line using an account where I had deployed AWS Control Tower and was using AWS SSO from AWS Identity Center I hit too many issues. I decided to start over at that point and build out a new AWS account and organization from scratch using AWS IAM, possibly with Okta as an IdP. (You could also user Azure AD in a similar manner). I have tried to use AWS Control Tower and AWS SSO but just finding too many issues.
Here’s the initial post where I started rebuilding with some explanation of why. It provides a lot of security recommendations you should consider when you create a new AWS account, so things ended up being a bit out of order.
If you want to follow along and build out an account from scratch you can start here and follow along.
From that point forward I will built out everything I’ve done so far in a new AWS account. Anyone following along can test and build out their own account and learn cloud security in the process. The concepts are also applicable to Azure and GCP, which I mention periodically, but the terminology and specific implementation will vary.
So does starting over in a new account mean I’m going to have to throw out all the code I’ve already written? Absolutely not. I’m already re-using the code I used to deploy CloudFormation stacks with a naming convention that helps you:
- Identify the resource type
- Identify who deployed it
- Only allow a role modify their own stacks.
Part of the above includes a common functions file used for deployment of all resources. This is still relevant as I start my AWS account over from scratch.
I’ve decided to try integrating with Okta to prevent privilege escalation as described in these posts.
My code for IAM roles is still relevant but needs to be modified to match the format from roles used with SAML federation.
All the other IAM policies and roles I created are still valid, but they will need to be modified to be SAML roles — and I’m going to keep both the IAM and the SAML roles in the directory so people can use whichever one works in their own environment. I’m not sure I will still use AWS Groups.
Once I get the IAM structure rebuilt, a lot of the rest of the code will remain the same. We’ll still use the single KMS key CloudFormation template I created to deploy keys throughout our organization, but we’ll probably start taking a look at cross-account access.
Note that key policy above got some modifications as I discovered some issues as the series progressed. Read all the KMS posts for more information and some issues you may want to be aware of related to AWS KMS.
Our network architecture is also reusable. That doesn’t change much. See the bottom of this list for the network related posts.
I’m finding a lot of rabbit holes as I implement all this code. I start out in one direction and end up down a windy path exploring some other security problem or requirement that popped up along the way. It’s all part of something I’ve wanted to do for a long time — create a code framework for secure cloud infrastructure from the ground up in a new account and organization. We can’t just skip over inconvenient details. In fact, I wrote about inconveniences as they relate to security here:
I like to think of this blog series like those people who watch people play video games online. You get to watch me write and troubleshoot code, though I’m not doing it on a live video stream (yet). I have a general outline but the posts will evolve as I go.
I’ve started putting a few of the posts behind a paywall because this is a very time-consuming endeavor and yes, I do need to make a living. We’ll see how that works out. Perhaps Medium will pay me more than $2 per month. It already increases my payments a bit but nowhere near what I would need to do to write full time and publish more than one post daily.
As I get into the details of building out an IdP — it starts getting complicated and even more time-consuming. Also, Okta is not cheap. For anyone following along who dislikes paywalls, I get it. I have a hard time paying for every news source that wants me to pay for a subscription. But consider this: You could pay for a $7,000 class such as those I used to teach for a certain organization.
Or you could help an author out and sign up for Medium using my referral link instead.
You’ll get a daily does of actionable cloud security tips to help you improve the security in your cloud account. You may also obtain enough knowledge to pass an AWS security certification if you’re into that. I’ll cover it all eventually, if I can.
But here’s what I don’t know. I get the most income when I refer a new subscriber, but I have no way know if I actually got paid for someone I referred. If you do sign up as a referral from me, please let me know so I can see if I get the corresponding referral fee. Because right know I get exactly one referral per month — always — which seems odd. Never zero or two or five— always one.
I get a few other cents when people read or like posts but I don’t even get how it all works. I’m too busy to figure it out.
An alternative to the paywall would be to spend a lot of time turning this into a book, pay an editor, and put the final chapters in the book like I did with my series on cybersecurity for executives. You would need to buy the book to get the final chapters which I think cover the most important aspects of organizational security. Also the book will have less typos. :)
It’s hard to know how to proceed as an author because there’s so much information out there and you want to make sure you’re providing value. At the same time, authors need to earn a living too. No, I do not want to write a book for Packt or teach classes through a third-party. People can reach out directly if they want to take a class from me on LinkedIn. I write classes as well. The most recent class I taught was a 6 week two hour class on Azure security. I do teach classes through IANS Research but you will have to work with them to arrange a contract with a 50% up front payment.
In any case, I will continue to publish some free and some paid posts in an effort to help as many people as possible as I work through this secure cloud architecture from scratch. I also appreciate if people post issues on GitHub and I’ll try to fix them. I don’t always see them right away but I will get to them eventually. The code is all out there for free — no paywall at this time. :)
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
