Work with threat modeling. Understand how to create a ranked threat model to prioritize risk modeling for security planning.
- [Instructor] So yet another tool that's commonly used in the security industry is a threat model. So a threat model is a written document that shows the parts and pieces of your application. It lists and ranks potential threats, and it lists countermeasures and mitigation. And this is an important design document for discussions with the business around how you are going to spend basically to prevent these threats from occurring. What you'll generally do is use some sort of ranking system.
So you can create a hierarchy around risks, so what's an example of this? So a risk could be that your database is unavailable, and then looking at database unavailability, you then would determine the impact to the business, the damage potential, and the number of affected components. So if your website for example required your database to be available then that would impact your website. You next would assign a numerical value to the possibility of this occurring.
Yes it is somewhat of a guess, but depending on the level to which you need to apply these security mitigation techniques you might want to bring in external consultants who do this as a business. And then they can help with the ranking. So, the possibility is going to be the degree of mitigation, and then the ease of exploitation. Again, external security professionals can really help because this is what they do full-time. They can talk about this protocol has been attacked, or this type of application has been attacked, and here are the attacks, and so on and so forth.
Now not always do you need to bring in third-party people. Sometimes you can engage with somebody on your team who spends some time researching the industry, maybe going to conferences, being aware of, what are the threats that are out there? Because unfortunately every time there's a new service there is a new threat or a new attack that comes up against it. It's just physically impossible to program and implement services that are unhackable. So you have to be aware of the landscape. So understanding the ease of exploitation means the discoverability, the exploitability, and the reproducibility.
So if you assign numeric ranking to each risk in terms of the impact, possibility and ease of exploitation, that can help you to prioritize the mitigation strategies. Now once again, in threat modeling it's common in addition to the written information to have a diagram. So this is an example of a very simple solution, and it pulls together the idea of data flow that we had in an earlier movie, and it provides a basis on which you could write positive and negative use cases.
This is simply a website, and in this case it's running on some Amazon services. So you can see that we've got users accessing information provided by Amazon CloudFront and that information is being pulled out of Amazon S3. This could be videos being served up on an Edge location. Then, the next piece of information is going to the Elastic Load Balancer, and this is in a public subnet. And that's serving up the webpages which are in a private subnet, being hosted by a web app probably running on EC2, but it could be running on Docker or even Lambda.
Amazon EC2 uses Elastic Block Store as a file basis for storing information to be served up in a website. You can see that the information also can be accessed by admins through a gateway over HTTPS. And to complete the data flow, in a private subnet, private subnet B, we have Amazon Relational Database Service which is being accessed over HTTPS. So this pulls together the concepts that we've learned in this section and starts to layout your application so that you can determine, where are the points that you need to protect? And in the next sections we're going to be learning what kind of services and how you would protect these various aspects of your application.
As we wrap up our discussion of threat modeling, there are two resources I want to point you to. The first is a open discussion of threat modeling, and this covers many of the topics we've talked about in this section and gives examples and links. So if you're interested in the theoretical underpinnings of application security and in particular if you're going to engage with an external security firm, I recommend that whoever on your team is responsible for engaging with them reviews these core types of diagrams and concepts in this section.
In addition to that, Amazon has written a great whitepaper around what's called CIS Web Service Foundations, and this is the Center for Internet Security. It's a pretty long whitepaper, 150 pages almost, but if you scroll down here, you can see this document provides prescriptive guidance for configuring security options for a subset of Amazon Web Services with an emphasis on foundational, testable, and architecture-agnostic settings. And in scope for the document are IAM, Identity and Access Management, Amazon Config, CloudTrail, CloudWatch, Simple Notification Service or SNS, Simple Storage Service or S3, and VPC.
I've used this with many customers and it's provided us with a lot of great actionable information, so I wanted to include it here.
- Core AWS security design concepts
- Designing using a data flow diagram
- Using negative use cases
- Working with IAM user and role objects
- Design concepts for encryption
- Design encryption with AWS Key Management Service
- Third-party data security tools
- Designing for disaster recovery services