Application Threat Modeling

I have dedicated a whole chapter to this topic because people underestimate the importance of Application Threat Modeling (ATM). If you're an employee or a consultant in application security, you will always encounter projects that will deliver new releases of their product, and you will need to make sure to test these projects before they are deployed into the production servers. ATM happens at the beginning when the project is still in the Architecture phase. In fact, ATM is a security architecture document that allows you to identify future threats and to pinpoint the different pentest activities that need to be executed in the future deployment of the web application project.

Here's the plan for this amazing chapter:

• Introducing the software development life cycle
• Application Threat Modeling at a glance
• Application Threat Modeling in...

Software development life cycle

Every application proceeds into a development life cycle before it is deployed into production. First, the project team comes up with an idea for a new product (a website) that allows the business to earn more money and clients. This is the Analysis/Architecture phase, where everyone sits around the table to discuss all the challenges of this new project. At the end of this phase, an Architecture document will be produced and presented to the Architecture Board who will approve it if the project meets the company's policies. After the approval, the project will start in the Development phase, where a team of developers and quality assurance engineers will join together to deliver the product. After a few sprints, a stable release will be ready for deployment into the production; the team will test this application and make sure that it&apos...

Application Threat Modeling at a glance

ATM is a methodology for analyzing the security posture of an application and it aims to help you lay out the foundations before starting the penetration testing activities. The document should address the security risks during the Architecture phase by identifying and quantifying them before project reaches the Development phase. You will see so many approaches out there for how to handle the threat modeling document (the best one that I recommend is the OWASP Application Threat Modeling document; check it out yourself and you will understand what I mean), but from my personal experience, I suggest you make it as simple as possible and don't waste your time over-describing the security risks of the application, because in this case, you're stepping on the feet of the information security risk assessment document. Use this document...

Application Threat Modeling in real life

At the end of this chapter, I will provide a practical sample of an ATM document. If you feel that any of the items that I'm trying to discuss here are not clear (very theoretical), then I invite you to look at the example at the end of this chapter. If you want your team to be successful during the pentest phase, then you must do an ATM document prior to your penetration test activities. Let's take an example that I witness on a daily basis when I use this approach. A new project comes in, and the Project Manager (PM) contacts management, asking for an expert in application security, because they're going to build a new website. The management team then assigns you to that new project, which is still in the Architecture phase. You attend a couple of meetings to understand the contents of the project. Most probably, another...

Application Threat Modeling document parts

An ATM document has multiple sections. In fact, this document can be between 40-70 pages long. Understanding each section is crucial for a successful project. I know I told you previously to keep this document simple, but not too much; you should not miss the important details of an ATM document.

So, here's the list of the most important sections that an ATM document should contain:

• Data Flow Diagram
• External dependencies
• Trust levels
• Entry points
• Assets
• Test strategies
• Security risks

Data Flow Diagram

I placed this title, Data Flow Diagram (DFD), at the beginning for a reason; because it's my favorite section and I use it as a reference in the ATM document. The DFD will...

Practical example

Our practical example is based on the Company Name XYZ Inc. The marketing team in XYZ wants to add a blog page to attract more clients and they want to call the project xBlog. You attended a few kick-off meetings and now, finally, they have sent you the architecture document, and inside it, you have the following diagram:

According to this diagram, the clients (customers) will be able to access the blog from anywhere and they can add comments (the authentication process for customers is out of scope because clients will be authenticated through the main page of the company's website). On the other hand, the employees of XYZ can add a blog or approve a client comment through the WordPress CMS. Simple, right? Your job as an application security expert is to submit an ATM document to the project team before going to the architecture review board; let&apos...

Summary

As you've seen in this chapter, ATM is not so hard after all. People underestimate the importance of this document, but once you start using it, you won't be able to stop because it has so many benefits. Be creative and don't stick to the same template discussed in this chapter; instead, use it as a guideline for your next application threat modeling document.

Any professional website project starts with an architecture phase, and that's when you need to show your skills and consider the ATM document as a security architecture document as well. Your job is not only to be a pentester, and that's a very important concept to understand in the security field. Feel free to add your desired sections, for example monitoring, logging, secure coding, security controls, or any recommendations that you feel will help the project at the beginning before they...