Threat Modeling 102: Applying STRIDE to Payments Architecture

Threat Modelling 102: Applying STRIDE to Payments Architecture

Credit : This is my solution to the Threat Modelling exercise provided in the repository Security Engineering Training, created by Jeevan Singh.

In this blog post, let’s continue threat modelling series by focusing on applying STRIDE methodology to a payments architecture. After exploring how to map OWASP Top 10 vulnerabilities to STRIDE in the previous post, let’s now dive into identifying and addressing the top security risks in a typical payment processing system.

In this blog post, let’s discuss about the STRIDE threat model methodology to the payments architecture. Understanding identification and mitigation the threat in a typical payment processing system with cloud components along following previous blog which talked about mapping OWASP Top 10 vulnerabilities to STRIDE.

Problem Statement

For the complete problem statement, please refer to the detailed exercise at the GitHub repository for Threat Modelling.

The payments architecture that is used in this Threat Modelling blog enables the participants to identify possible threats in a payment processing system. The purpose of the exercise is to expose risks to the security of a multi-tenant microservice architecture.

In this system:

• Once admin user submits credit card details, which is validated through the Payment Processing API (VISA, Master Card) and stored in a Billing Database.
• The system has several components, including a Gateway API, Billing Service, and Billing Logs, stored in an AWS S3 bucket.
• Critical assets such as credit card information and tenant data need to be protected from a variety of attacks, including spoofing, tampering, and denial of service (DoS).
• It also covers below mentioned best practices.

Best Practices Already Implemented

• TLS encryption is implemented for all communications between system components thus defending against MiTM.
• Access to Billing Database is already restricted only to authorised users, (e.g., Prod Admin), which needs additional approval.
• Billing Database including sensitive data like credit card information is encrypted at rest.
• The Gateway API has a rate limit of 100 calls per minute per Tenant Admin to prevent abuse of the API.
• JWT tokens are used for authentication.
• Billing Logs specifically exclude sensitive information like credit card details by ensuring logs do not leak sensitive data.
• System-generated tokens to connect with VISA, which are also stored in a secure secrets store.
• Billing Service performs strong input validation for sensitive fields like credit card numbers, tenant names, etc.

Through STRIDE, let’s break down the this typical architecture consist of cloud and microservice components. This exercise is next part of this series is aimed to understand threat modelling principles to real-world systems and identify risks before they can be exploited.

Assumptions:

Before moving to the threat analysis, it’s important to set some context. Here are the assumptions:

• Payment processor is not just VISA, and can be any payment processing API.
• Infra is hosted on AWS.
• Gateway API as well as Billing Service is a microservice.
• Billing Logs are stored in an AWS S3 bucket.
• All sensitive data is encrypted at rest and in transit.

Understanding the Assets

The payment architecture relies on several key assets:

1. Credit Card Information: Sensitive information which must be encrypted at all times.
2. Tenant Information: Information about the users/tenants who are making the transactions.
3. Audit Logs: Online transaction records for various HTTP actions.
4. Billing Logs: Transactional logs which are stored securely in an S3.
5. Gateway API: Entry endpoint for processing payment-related actions.
6. Billing Service: Backend service handling payment data.
7. Billing Database: Storage of sensitive payment information.
8. Payment Processor API: Third-party associated with payments.

STRIDE Threat Analysis

So, let’s use STRIDE for the payment architecture to identify the threats. Each component might be vulnerable to multiple types of threats.

Spoofing: An attacker could impersonate a tenant to update or manipulate payment information.

Tampering: Attacker could modify credit card information in transit or at rest in the Billing Database or can tamper logs if exposed via cloud misconfiguration.

Repudiation: Attacker might replay the payment request or deny initiating transactions, & system can’t prove otherwise due to tampered logs if not stored securely.

Repudiation: A user/tenant may replay payment requests or deny initiating transactions, and tamper with logs if they are not securely stored and monitored.

Information Disclosure: Sensitive information exposed due to any security misconfiguration or vulnerability.

Denial of Service (DoS): Attacker could send excessive calls to the Gateway API causing DoS or disrupt the payment validation.

Elevation of Privilege: An attacker could escalate privileges within the system, gaining access to sensitive data or services

Security Controls and Mitigation Strategies

The following table highlights the STRIDE threats and the mitigation (gist) strategies for each of the assets:

Top 3 Risks:

Now that we’ve identified the threats, here are the top three risks that should be prioritized:

Risk #1: Information Disclosure (Credit Card Information Leak)

• Threat: Unauthorised access to the Billing Db could expose sensitive credit card information.
• Impact: Loss of customer trust, financial penalties, and potential legal action.

Risk #2: Exposed Public Bucket

• Threat: An attacker find the bucket if exposed to public
• Impact: Based on privileges, attacker can read or even tamper the logs as well

Risk #3: Elevation of Privilege (Compromised Billing Service)

• Threat: Compromised Billing service due to broken access control could lead to unauthorised modification of billing data or access to cross-tenant data.
• Impact: Data integrity issues, unauthorised transactions & unauthorised data read.

Conclusion

By applying STRIDE methodology to the payments architecture, it is possible to proactively identify and mitigate risks.

Disclaimer

This implementation will change based on addition of new components, this should be considered as example exercise and might need more enhancement based on additional real world test-cases.

This analysis presented is completely based on personal assumptions and architectural understanding specific to this exercise.

Thanks

• Thanks to Jeevan singh for this security-engineering repo, also for session on threat modelling.
• https://owasp.org/www-community/Threat_Modeling_Process
• https://github.com/rhurlbut/CodeMash2019/tree/master
• Previous blog: Mapping OWASP Top 10 vulnerabilities to STRIDE.
• Editing & Paraphrasing via https://chatgpt.com

---

Threat Modeling 102: Applying STRIDE to Payments Architecture was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.