AWS Workshops Threat modeling the right way for builders

Day 1 of workshops #

For my first workshop i’ll be working through Threat modeling the right way for builders

Initial thoughts #

The workshop introduction is a nice view that lets me know i’m going to be building a threat model. I’ve worked in security since 2007, and I’ve yet to build a threat model graph on my own. I’ve used tools and performed audits, but creating a threat model is new to me. Additionally AWS defines ’two-pizza teams" which is a large part of AWS and Amazon’s success in growing teams, developing individuals and creating solutions to meet customer needs.

Security is “The top priority at AWS”, so I find it fitting that I’ll be performing a security workshop to kick things off here.

Estimated time to complete for this workshop : 3 hours

Let’s begin #

There is an evident focus Shostacks question frame during this workshop. This is new for me:

Shostack’s 4 Question Frame for Threat Modeling

1. What are we working on?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good job?

These questions are designed to help people build better systems. They work less well for end-users of technology.

Workshop Overview #

The AWS Connected Vehicle solution diagram appears on the page and I audibly say “Holy Sh!!!”. I read the first line “Don’t panic”. To myself i breathe a sigh and say “Ok.” Reference: The pic:

I’m also given a link to a ‘participant workbook" which looks to be just the web page in a PDF form, with some nice tables to fill in at the end of the doc.

Overall Response: There isnt much to “do” here. This section is only to give the workshop doer a background on what they are going to do.

• My view of this Section: Positive
• My rated level: 100

What are we working on #

This section is another overview section. It gives a good overview of what trust boundaries are and zones of trust. This is another overview section and there isnt much to it. It takes a few minutes to read and then onto the next piece.

• My view of this section: Positive
• My rating level: 100

Data Flow Diagram #

My elementary school lessons come back to me “Read the instructions before you begin.” I read the instructions before I begun, and they say “read through the steps before you begin.” Taking that note, I’ll read all the steps and then begin at step 1.

This sections is confusing me at the moment. It gives me icons of humans and external processes, but then says draw based on the system description. There’s no clear label on the system description, so I think I am drawing a AWS architecture for something that handles the “Vehicle Registration Feature.” Re-re-re-reading the feature, I’m supposed to create just the backend workflow.

Step 1 #

Step 2 & 3 #

Here’s my quick take at it

Step 4 & 5 #

Here is my take at creating a trust boundary diagram on the flow

I think my assumptions stand, and I do not need to modify any of them at this time.

• My view of this section: Middle of the road
• My rating level: 200

you had to know a bit about services to draw a diagram. If there was an example solution and assumptions at the end of this, then my rating level would have been a 100

What can go wrong? #

Oh my goodness here lies the reference architecture. If I were to instruct this workshop in a live environment, I would use this or update my attempt above to better match the guide shown here.

Excercise 2 #

Lets begin with dumping my assumptions on the page.

The Step 2 page took me a few reads to understand. After reading the examples and the instructions a few times, I came up with the information below:

Step 3 we begin to dive further into the code and the infrastructure. Here we begin to understand an attacker might come into the system, and make changes and disrupt your service or infrastructure. Identifying all the pieces and digging into each level of this step takes a large amount of time. If I were to do this on a production infrastructure, this would be a multi day exercise.

Step 4: We begin understanding how data can be altered by attackers and what it means to our infrastructure and services. This excercise gives a good understanding on expanding on threats to each individual element in my diagram.

Step 5: Attackers breaching across trust boundaries is a great point that this step brings up. Attackers exploit boundaries to get information from different trust zones. This step is a bit harder than the previous steps because you have to understand how attacks can occur and how data can be modified. Without an instructor with experience on these topics I’d say these items on this step are a bit harder than the previous ones.

Step 6: Prioritization of threats on your infrastructure can take hours at a time. The good news is every time you do it for a service or tool that you own it gets a bit faster. I’m gonna cut corners on this workshop, and not prioritize, which is bad… but I’ve taken about 30 minutes for this section already.

• My view of this section: Exhausting and repetitive (but threat modeling is)
• My rating level: 200 (knowledge of prioritization and threats is necessary to complete)

What are we going to do about it #

This section gives a great overview of risk response strategies. When I have the mitigation conversation with customers these are the points I bring up. It’s good to see them written out in a short page here.

1. Avoid - skip this feature or remove feature
2. Mitigate - apply standards to remove risk
3. Transfer - Choose a solution that gives risk to another party
4. Accept - Choose to accept the risk for a period of time

Exercise 3 #

Step 1 #

This step requires me to go through my notebook and make notes. It feels like I’m basically doing a WAFR (Well Architected Framework Review) and writing out the steps to mitigate or remove risk. This entire page is a great overview of how to get started on securing a system if you have inherited an AWS account and you want to secure it and need somewhere to begin.

• My view of this section: Excellent
• My rating level: 100

Exercise 4 #

This is a full recap section on how I did. It’s critical to rate yourself and find ways to improve. I was unsure about some of the exercises when I started, but now feel like I have a decent understanding of how to go through a threat modeling workshop with someone on their architecture.

Did I find this process useful? #

It mentally hurt at moments, and challenged me to think beyond my normal infrastructure review steps. Short answer is “Yes I did find it useful.” I think this workshop could be done by security teams whenever they are tasked with an infrastructure review.

Fin #

I finished it. All in all this workshop took me around 2 hours. I did it between my meetings and was able to complete it over the course of two days. I’m pleased with this material and plan to use some of the pages in future conversations with customer.

• Overall view of workshop: 4 out of 5 stars
• My rating of skill needed to complete: Between 100-200 level.

If you dont have a security background, I’d suggest performing this workshop with someone with at least 2 years of security experience.

Thats all. Onto the next one.

For an overview of all the workshops I’m doing, #

Please view 100 Days of AWS Workshops →