Speaking at AWS Community Day — Security Edition
Threat modeling the platform I’ve been building on this blog
I have no time and still working on my presentation! But I’m going to be speaking at the AWS Community Day THIS WEEK in Mountain View if you can make it. This is my brain dump thinking through what I’m going to talk about roughly.
Threat modeling all the things…
I’m going to be talking about the platform I’ve been building to run batch jobs on AWS, all the security, and how to deploy all the things. The point is — how and why did I do certain things a certain way? What are the attacks I’m trying to defend against? And what is the point of all this anyway?
Security Batch Jobs
What started out as an “I’m just going to show people how to run security batch jobs on AWS to analyze their own security like I do on penetration tests” became something much larger, as you can see from over a year, maybe two of blog posts.
Security is more than code in a container
The whole series involves checking out which services to use and then a deep dive into the core point of all of this — enforcing MFA on each batch job run. But what is the point of MFA if you can’t secure the code or the deployments or the systems and networks on which you’re running the jobs? And what about the systems you’re using to develop the code and kick off the job execution?
And that’s when it got complicated.
Different organizations have different needs
It got even more complicated when I wanted to show the job execution framework which I do use with my own tools without exposing the code for my own tools.
- What if I want to publicly share the code for the job execution framework but not the code for the jobs I am running with it?
- What if I wanted to use third-party repositories with jobs? I don’t want to duplicate those over and over.
- What if an individual is testing this? How can I keep it simple?
- What if an organization with multiple lines of business and different development and QA teams need to use it without allowing those teams to modify the actual job framework or each other’s code?
- What if you need two different branches from the same repository for different jobs you are testing and running?
- How can I segregate different resources in different environments (dev, QA, production, staging, R & D or whatever your environments may be)?
- What if you need to segregate jobs from different teams or lines of business from each other?
- How can you identify all the resources involved that get deployed in an AWS account, or an organization?
- How can I avoid giving one role or principal the keys to the kingdom — the ability to deploy, change, or delete anything in the account — when deploying what is required to use this job framework, which requires IAM roles, encryption keys, compute resources, and networks?
- How can the jobs run efficiently if they are very large?
- What if the jobs fail mid-run?
- How can the framework be as flexible as possible while still providing the necessary guardrails?
- How do you know who ran which job when and with what parameters, inputs, and outputs?
- How can you configure the framework to run and test jobs as a developer or QA engineer and run the same framework securely in a production environment?
- How can I make sure the jobs can be deployed without allowing the people who deploy and run them to change the code — a potential point for supply chain attacks?
- How can I allow someone to write jobs in an environment but not allow them to alter code in third-party repositories or the job framework itself?
- What if I want to allow separate people to deploy the job from the people who run the jobs?
- What if I want to run the same job but with different inputs and different output locations?
- What if I need to run the same job across multiple AWS accounts?
- What if I’m running jobs on different penetration tests and I want to make sure that any compromise of one job does not impact another customer’s data or environment? (Have you asked your penetration testing company how they do that?)
- What if I need to run actions in one AWS account but store the data in another AWS account using a different role?
- Most importantly, what is the best way to protect the credentials used to run the jobs, as stolen sessions and credentials are a key point of attack in cloud environments?
What are the attack vectors for a platform like this?
And the main point — how can the platform prevent the multitudes of types of data breaches occurring such as those I wrote about. The attack vectors for a platform like this are not so different from any other system that runs code and processes data.
> Supply chain attacks and code infiltration as was the case in the Solar Winds breach which I have yet to update and will talk about, I think.
> Phishing on MFA pages and and solutions like OAuth code flow — things like the Oktapus attack.
> Stolen credentials in GitHub actions (a solution I looked into and opted not to use, even with OIDC)
> Stolen credentials anywhere like the Sumo Logic breach — where they were running TruffleHog — a tool that can easily be run more securely (I think, I still need to try it) in my batch job platform. I run Prowler, for example, so why not anything?
> SSRF attacks such as Capital One due to excessive access to all the S3 buckets in the organization, with a slightly lower scope (yes, it could have been worse) due to application specific KMS keys.
> What about the laptops and phones and network I use to connect to AWS and the scenario that led to the Circle CI breach? An attacker leveraged a vulnerability to compromise a developer’s machine to carry out the attack. Similar attacks affected a popular password manager.
> Any web vulnerabilities in any web sites I have to log into in order to execute a job might be a point of attack and infiltration into the process — writing the code, deploying the job, executing the job, processing and viewing the data involved.
Those are just a few of the examples I’m thinking about as I develop my platform. I’m constantly researching and reviewing attacks to determine how systems and cloud environments are being compromised and using that to further develop my own tools, tactics, and techniques to use on penetration tests.
How to think about security
I haven’t finished all my ideas and thoughts yet but that’s what I’m going to be talking about with the main idea being — how to think about security. That was the premise for all my cloud classes I started writing back in 2018.
Security Architecture is Not a Checklist
Security is not a checklist of best practices from some organization, but how to think through the threats and the architecture and processes that would stop attacks.
I’ll talk about how those thoughts led to the current iteration of my job framework which is largely unpublished. That’s because I got super busy but also I could not justify the amount of time I spent publishing based on the ROI. I’m thinking about what to do about that.
This code is developed to quite a degree of depth and yet it is really just a prototype that would need to be taken to another level to make it production ready. For example, I wrote about container security and haven’t even take all the steps I wrote about yet. That’s just one example.
My own platform wouldn’t pass my own security assessment. 😳 So there’s that…but I can use it myself within my own secure confines which are a lot tighter than most organizations will be able to manage. The controls I have yet to add would help solve that problem. The complexities come to light when I think about adding someone to help me further develop the code. Maybe I’ll talk about that. It’s not so simple.
I’ll share my learnings and show you the thought process behind it and the types of things you should be thinking about when you build your own systems to defend against the most prevalent types of attacks that may lead to system compromise based on real world attacks of cloud systems, APIs, and applications.
Check out the website above for the date and time.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2025
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 callFollow 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
