SECURITY ARCHITECTURE & DESIGN REVIEW WITH THREAT MODELING

TL;DR

In this article, I'll walk you through the complete process of Security Architecture & Design Review (SAR) for an e-commerce web application. You'll discover how to use the Microsoft Threat Modeling Tool, create Data Flow Diagrams, identify threats using the STRIDE model, and produce a professional security report for your stakeholders.

Introduction: Why Security Architecture Review Matters

In a world where cyberattacks against e-commerce platforms have increased by 300% in recent years, Security Architecture Review is no longer optional — it's an absolute necessity.

Security Architecture Review (SAR) is the process of evaluating and improving a system's security by analyzing its design, implementation, and deployment. The goal? Ensuring your system is resilient against potential threats and meets your organization's security standards.

The security architecture review typically includes

A review of the design specificationsand architecture diagrams
Threat modeling to identify potential security threats and vulnerabilities
Review of design specifications and architecture diagram
Evaluation of security controls and countermeasures included in the design
Identification of potential desin weaknesses
Documentation of review findings and recommendations for improvement
Goal of enhancing overall security of the system

The security review is an important step in the software development life cycle (SDLC) and should be concluded regularly to ensure that the system remains secure over time and adapts to changes in the threat landscape. The review process should be integrated in the SDLC and be performed by a team of security experts who have the necessary knowledge and skills to evaluate the system from a security perspective.

The 6-Step SAR Process

A typical Security Architecture Review process includes the following steps:

1 - Planning & Preparation

This foundational phase includes:

Defining the scope and objectives of the review
Identifying the review team and establishing the timeline
Obtaining all relevant documentation (specifications, architecture diagrams, existing threat models)
Preparing the review checklist

2 - Threat Modeling

This is the heart of our process. Threat modeling involves:

Identifying potential threats and vulnerabilities
Documenting these threats in a structured model
Using the STRIDE framework to categorize threats

3 - Architecture Implementation Review

This step involves reviewing the implementation of security controls to ensure they are properly deployed and meet organizational standards.

4 - Deployment Review

Here we verify that the system deployment is secure and that controls are correctly configured.

5 - Reporting & Recommendations

Documentation of findings, including identified threats and improvement recommendations.

6 - Follow-up

Implementation of recommendations, regular follow-up reviews, and design updates to maintain system security over time.

Security Architecture & Design Review for an Ecommerce Web Application

In this picture a secure design checklist will contain a number of questions that will be answer by stakeholder who own the Application. If during the Application walktrough some of the questions have already been answered, then the secutity team will update those answers in the checklist and will ask the stakeholders to provide the information for the rest of the questions present in the checklist.

STEP 1 INSTALL MICROSOFT THREAT MODELING TOOL

Let's install Microsoft Threat Modeling Tool !

We have to look for Microsoft Threat Modeling Tool on Google and select the one I have highlighted in Yellow

After choosing the Microsoft Threat Modeling Tool 2016 we'll go on the following page

Then we'll click on Download and select "File Name" that will automatically select all

After successfully performed the Download now we have to install the tool

After the installation successfully completed we can now launch the application

STEP2: Gathering Requirements

Pro Tip: In 95% of cases, you'll need to ask technical questions to stakeholders during the walkthrough meeting to understand whether security processes are in place.

For our case study, let's imagine that STAN CONSORTIUM has engaged us to perform a Security Architecture Review of their e-commerce web application.

First of all we have received architecture diagram of the application from the stakeholders

A complete walkhrough of the application

In this architecture the user will access the web app via a firewall , then there is a proxy wall in front of the web server where the web application was hosted. Now we have the presentation layer of the web application, the web server is connected to the buisness layer and the data layer in the buisness layer. In the buisness layer we have the API layer where the web APIs are exposed, the Web APIs has the application buisness logic implemented as well. This application buisness logic interacts with the backend server where the legacy application resides. Now the application where the buisness logic is present also interacts with the database service and a third party service. Therefore database service and third party service resides in data layers. So it means that we have a database in a data layer, we have a Web APIs in the Buisness Layer precisely in the API Layer and we have the legacy application in the backend. A third party service is also present in the data layer. In front of the buisness layer at the presentaion layer is a web server. The web server requests are going to the internet via a proxy wall and then further via a firewall. And then finally the response goes back to the user.

To sum up :

STAN CONSORTIUM has engaged us to perform Security Architecture and Review of their Ecommerce Web Application
The Web Application is a simple 3 layer application (Presentation layer, Buisness Layer and Data layer)
The Architecture Diagram have been shared
Let's perform the security Architecture and Review activity

INPUTS GIVEN BY STAN CONSORTIUM

Currently, Developpers do not have a Secure Training Program
DDOS Protection is not enabled on the Firewall
SIEM Program is not in place
User input in only validated at client side
Server logs are backed up on same server
Encryption mechanism being used for data-in-transit is TLS 1.1
MD5 algorithms is used for generating password hashes
Data in database is not encrypted
Database backup schedule is not documented
Firewall alerts are not monitored in real time

In 95% of the cases, we will have to ask such questions during the walktrough meeting of the process, so it means that while we'll be provide walkthrough of the application by stakeholders, we'll have to ask such technical questions to the stakeholders that wether these processes are in place or not ?

This will help us to fill up or create our secured design review checklist. So right now this information has been provided to us using which we will perform the four step process of our workflow.

Now let's see the steps that we will follow to perform the security architecture and design review for STAN CONSORTIUM. Following are the steps in order that we should follow to perform Security Architecture and Review for this project:

First of all we have to ask STAN CONSORTIUM to provide a walktrough of the application in scope and share any architecture diagrams

After that we will create a Security Architecture and Review Checklist based on the information provided by STAN CONSORTIUM
Here is the Checklist on my github repo --> yvesstan/Security-Architecture-Review-with-Threat-Modeling: All the delivrable include in my article about Security Architecture & Review based on Threat Modeling
—>Now we'll perform a Threat Modeling Exercice using Microsft Threat Modeling Tool and create a DFD (Data Flow Diagram). DFD is a way of reprensenting a flow of data through a process or a system , this is really important because it will be a part of the final report that we'll be sharing with the stakeholders.

—> After doing the Threat Modeling exercise, we will generate a report from Threat Modeling Tool as per STRIDE Model and highlight all the assets and security controls applicable to each asset.
At the end we'll prepare a final Summary report for all the stakeholders

STEP 3: Security Architecture & Design Review Checklist

The security review checklist is our best ally. It contains questions that will be asked to stakeholders who own the application.

As you can see, this is the application security architecture review checklist as I have mentionned I've included the link to my Github repository where it's located. In this checklist you can see various categories based on authentication, authorization and similar other controls.

Now what we have to do ?

In each category we will have to define application security controls and hence our checklist should include questionnaire an all such security controls. I have filled up some of these questions based on the inputs received from STAN CONSORTIUM.

Generally in enterprise environment we will have to create such checklist for our project and will have to ask our stakeholders to provide inputs to each question brought up in the checklist.

Here's a simple workflow that I’ve made to use at this section:

How can we use this workflow ?????

In the checklist we will ask the questions on the column <<Application Security Control>> to the stakeholder or perform a check during a meeting section and based on the feedback that will be mentioned in the column --> "Controls Implemented (Y/N)" and our expertise we'll fullfill the following other columns --> "Comments" | "Impact if controls not implemented" | "Remediations"

To sum up all these controls will have to be discuss with the project stakeholders and we need to fill this information in order to identify which security controls are already implemented and which security controls have not been implemented and are missing in the application. This will help us to identifiy threat based on misssing security controls. We also have to know that this is a generic checklist and it should be modified as per the project under review.

In our case you can view the checklist that I've filled here --> yvesstan/Security-Architecture-Review-with-Threat-Modeling: All the delivrable include in my article about Security Architecture & Review based on Threat Modeling

STEP 4: Creating the Threat Model with Microsoft Threat Modeling Tool

This is where it gets interesting! We'll create a Data Flow Diagram (DFD) — a visual representation of data flow through the system.

In order to create a new threat model, let’s following the steps below:

First of all after launching the Microsoft Threat Modeling Tool we need to click on create a model

Here we bring the architecture for which we are going to create the threat model. In our case it is the Web Application Architecture Layers that we saw earlier --> https://github.com/yvesstan/Security-Architecture-Review-with-Threat-Modeling/blob/main/Web%20App%20Architecture%20Layer.PNG

We have a firewall , a proxy wall
Then we have a web server which is serving the web application
Then we have a buisness layer where the application is hosted
Then we have a dater layer where the database service is present and also a third party services present

Now let's build our data flow diagram based on that :

Now that we have created the data flow diagram, it's time to generate the threat modeling report, but before we do that we need to provide some information, so in order to add that information, we will have to click on File, and --> Threat Model Information and fill the informations that appear , at the end we will have something like this :

Now we'll close and save the work we have done!

And now let's generate the report by clicking on reports, create full report, and let's click on Generate Report

We'll have an HTML report like the following

You can check the report I’ve generated here --> yvesstan/Security-Architecture-Review-with-Threat-Modeling: All the delivrable include in my article about Security Architecture & Review based on Threat Modeling

Currently we can notice that all threats are mentioned as not started. It means that security team has not given any recommendation and the development team or the project stakeholders have not started mitigating those threats.

Now let's go back to our data flow diagram, let's click on view --> Threat List , after clicking on it we can see the ten threat that are present in our application or that are applicable to our system

Now let's suppose we have shared this report to the stakeholders and they say that, okay the have started in the Cross Site Scripting threat, so what we'll do is in the retesting stage we will go to status and we'll mention it as mitigated

Similarly, suppose they have also fixed the fourth threat, which is elevation using impersonation related to proxy wall, they have also mitigated it, we can select mitigate it and suppose for one of the threat like web server process memory tampered , they say that this threat is not applicable. So what we'll need to do is we'll need to select that appropriate status from this list

So now we need to save it again and generate another report , here's the following update report based on the modifications we’ve performed --> Security-Architecture-Review-with-Threat-Modeling/STAN SAR Threat Modeling Report 2.0.htm at main · yvesstan/Security-Architecture-Review-with-Threat-Modeling

Now we can publish this report again to the stakeholders, so this will be an ongoing process as soon as the development team will keep on fixing these threats, we will be generating new threat modeling reports. And also since there will be changes in the application which is under development, we will keep on doing threat modeling at a regular basis.

So that's how we perform threat modeling on a real life application. We create the data flow diagrams, we generate the threat modeling report, then we update the mitigation status based on the fixes implemented by the development team of the project, and we perform this activity on a regular basis.

In the following section we are now going to use all this information in order to generate the security architecture and design Review.

STEP 5: The SAR Summary Report

Now that we perform the threat modeling, we are going to create a security architecture and design review

Here --> yvesstan/Security-Architecture-Review-with-Threat-Modeling: All the delivrable include in my article about Security Architecture & Review based on Threat Modeling is the STAN CONSORTIUM Security Architecture Design Review summary report that we have created in our context.

If it is a draft report, we will add a version number mentioning that this is the version one of the report and once it is approved by the stakeholders, we will publish the final version of the report.

Now let's discuss about the contents of this report:

First of all we will learn the project scope and then we will understand about the project summary. Then we will see the application architecture that is currently under review and for which we are doing the security, architecture and design review. After that, we have listed the application component details. Then we have added the data flow diagram that we have recently created in Microsoft Threat Modeling Tool. And finally, we have given the identified threats and remediation suggestions. Then we can add any appendix, for example, we can add some data flow diagram, component details in the appendix or any other information that we would like to attach.

Generally in enterprise environment, these components will be present in the final security Architecture and Design Review Summary Report.

At the project summary section of te report you will notice that there are more threats present, you know why ???

It's because the requirements that we initially got from our client where they had mentioned data in database is not encrypted and encryption mechanisme that was being used is TLS 1.1, we will have to take into consideration all these requirements as well, which we can't define in a data flow diagram. And then we will have to identify threats as well.

To sum up while identifying the threats, we will have to take into consideration all the inputs given by the project stakeholders, then we'll have to take into consideration the application security review checklist that we have recently filled after going into discussion with the project stakeholders. And finally, we'll have to take into consideration the threats identified while doing threat modeling, using Microsoft threat modeling tools. Combining the outputs of all these three inputs would help us to identify the final summary of threats identified for the project under review.

So the count of the threats listed in the following screenshot should be based on our review of the inputs provided by project stakeholders based on the checklist answers that we fill after discussing with the stakeholders; and finally the threat modeling diagram that we have created using Microsoft Threat Modeling Tool.

At the end, the total number of threats identified from all the three inputs will help us to arrive at the total number of threats in the project summary.

Once the stakeholders approve our report, we will publish a final version of the report.

STEP 6: THE FINAL VERSION OF THE SAR SUMMARY REPORT

Now we are going to create our final version of the security architecture and Design Review summary report. Here you can notice that we have added the report status and the report version number in our slide title so that before sharing this final report with the project stakeholders, they are able to identify that this is the final version of the report . The other changes that we have made to the final summary report are the fact that we have added review comments in the appendix section which are received once the security team provides walkthrough to the project stakeholders, there might be some new inputs provided by the project stakeholders at that time. We will now have to incorporate those review comments in our final summary report and then only publish our final version of the report.

As we can see here for example, we had a finding in this report that there can be denial of service attack on the firewall because distributed denial of service protection is not enabled on Firewall. And during the walkthrough we got to know that they are already working on the firewall upgrade and that's why they have given the feedback that firewall upgrade is in progress then the finding that we have shared is no longer applicable because they are currently in the process of upgrading the firewall. In enterprise environment this kind of feedback has generally been given by a Senior Architect, then based on that the status of this feedback as you can see here is "To be Discussed" as approval is awaited from all the stakeholders before an update in the summary report can be made.

So in order to make any change in this report, we need to get approvals from all the project stakeholders so that everyone is on the same page and then only we can make such changes in the summary report. That's exactly why this feedback we see here in the "REVIEW COMMENTS" section is yet to be incorporated. Then once approval is received from all the project stakeholders, we can remove the finding from the project report.

So the finding that we presented was as you can see in the following screenshot the first finding about the Distributed Denial of Service not enabled on Firewall

Since the STAN CONSRTIUM is already in the process of upgrading the firewall so this finding will be removed from this report.

Next, feedback that has been received is database encryption Implementation is also in progress. This feedback comment is also given by the Senior Architect and this is also awaiting approval from all the project stakeholders. Once the project stakeholders provide their approval that this implementation is in progress and security team can go ahead to make these updates in the final summary report, then we will go in the report and we will remove this second finding which is related to missing encryption at the database level.

So that's how we publish the final version of the report. And as we keep on getting updates on a regular basis from the project stakeholders, we will be publishing new versions of the summary report. Once there is some change, we will need to update this major and minor version of the report. If there is a major change, we will change major version of the report.

For example, if there is a new component that has been added to the application, there will be a major version change of the report. But if there is any small change, then we will change smaller version of the report then we will publish the new report and share with all the project stakeholders and get approval on the final report . So that's how we will publish our final summary report of security, architecture and design review and the activity is complete.

Once this report is published, this entire activity is completed for this iteration and this entire process will be repeated on a regular basis based on the changes that will be made to the application.

By the way you can checkout the final version of our report here —> yvesstan/Security-Architecture-Review-with-Threat-Modeling: All the delivrable include in my article about Security Architecture & Review based on Threat Modeling

Conclusion: Mastering Security Architecture Review

Security Architecture Review is a critical step in the Software Development Life Cycle (SDLC). It should be:

Integrated into the development cycle
Performed by a team of security experts
Repeated regularly to adapt to evolving threats
Documented and shared with all stakeholders

Keys to Success:

Collaboration — Work closely with stakeholders
Documentation — Keep track of everything
Iteration — It's a continuous process, not a one-shot deal
Prioritization — Focus on critical threats first

Resources

Have you implemented a Security Architecture Review process in your organization? Share your experience in the comments!

Written with 💙&passion! for the cybersecurity community

Security Architecture & Design Review With Threat Modeling

TL;DR