rad-tm.md

RaD-TM — Rapid Developer-driven Threat Modeling

Contributor	E-Mail
Alan Pestrin	alan.pestrin@thomsonreuters.com
Andrea Scaduto	andrea@secureflag.com
Andrea Cardaci	acardaci@secureflag.com
Andrew Hainault	andrew.hainault@aon.co.uk
Grant Ongers	grant.ongers@owasp.org
Stefano Ciccone	stefano.ciccone@secureflag.com

The RaD-TM Methodology

While threat modeling is widely recognized as a critical step in building secure software, traditional approaches often attempt to model an entire application all at once. This requires a comprehensive understanding of the system from various teams, including engineering, operations, and security, which can produce overly broad findings that are difficult to refine and maintain at scale.

In modern software development, the shift-left movement emphasizes addressing potential issues early in the development lifecycle. Our Rapid Developer-driven Threat Modeling (RaD-TM) empowers software developers to incorporate threat modeling seamlessly into the development workflow. It enables them to generate threat models of individual pieces of functionality after the earliest design phase to identify and address security threats before development begins. This approach allows for quick turnarounds for security reviews and minimizes costly security rework later in the process.

Our vision is rooted in a systematic approach to building secure software containing four key stages: Requirements, Design, Threat Modeling, and Development. By integrating threat modeling during the design phase, teams are better equipped to anticipate potential risks and address them when changes are easiest and least costly to implement.

This methodology is versatile and designed to fit different contexts:

• Individual Use: Developers can model the threats for features they are working on individually.

• Group Sessions: Teams can collaboratively model potential threats for larger functionalities or an entire application.

A further limitation of traditional threat modeling is its reliance on the specialized expertise of security professionals. Most developers are not trained to systematically identify or prioritize threats, which makes traditional threat modeling methods challenging to implement without expert guidance. As these experts are scarce, it limits both the scalability of threat modeling and its adoption across large or fast-moving development organizations. The goal of this methodology is to empower developers to perform effective, lightweight threat modeling on individual features during the development workflow without requiring deep security expertise. The methodology is based on simplicity, speed, and repeatability.

Threat Templates introduce a novel approach to security standardization by eliminating the need for specialized security expertise. Rather than generating a massive threat model containing hundreds of items, our method focuses developers on identifying threats from a concise set of lists of up to 20 high-priority threats. These Threat Templates are pre-defined collections of threats and corresponding controls, each tailored to specific compliance standards, application environments, or organizational priorities. This streamlined structure guides developers—whether working individually or as part of a team to systematically identify and mitigate threats, making security a more accessible and efficient process.

The methodology makes threat modeling accessible to all developers, not just security experts. Its lightweight nature ensures it does not add significant overhead to the development workflow. Moreover, it supports continuous refinement, allowing threat models to evolve alongside the application's functionality, and ensures that security remains integrated throughout the development lifecycle.

By equipping developers with a structured, accessible approach to threat modeling, we enable organizations to deliver more secure software while reducing the time and effort spent on addressing security issues later in the development process. Below is a description of the six phases of our RaD-TM methodology, designed to be quick, easy, and seamlessly integrated into the development workflow. By breaking threat modeling into smaller, well-defined steps, any developer can identify and address security threats without undue overhead.

Below is a description of the six phases of our Rapid Developer-driven Threat Modeling (RaD-TM) methodology, designed to be quick, easy, and seamlessly integrated into the development workflow. By breaking threat modeling into smaller, well-defined steps, any developer can identify and address security threats without undue overhead.

Produce a Graphical Representation

Start by creating a clear graphical representation of the functionality. This step should take no more than ten minutes per individual feature and follows the requirements phase—where stakeholders identify, analyze, and document the necessary functionalities and constraints yet often overlook security considerations. Visualizing the application's structure at this stage helps bridge the gap left by requirements, specifically capturing potential security-relevant data flows, interactions, and dependencies that might otherwise go unaddressed.

Steps

1. Identify the Feature: Clearly define the feature or functionality being analyzed (e.g., "Transfer Funds Between Accounts").

2. Map All Elements:

   • Identify all components involved (e.g., user interface, APIs, databases, external services).

3. Illustrate Interactions:

   • Show how these elements interact, such as the flow of data between components:

     1. Inputs: What data does the feature consume? How does it enter the system?
     2. Outputs: What data does the feature produce? Where does it go?
     3. Specify the type of data exchanged at each interaction (e.g., user credentials, tokens, requests, responses).

Deliverable

A visual representation of the feature, showing its components, interactions, and data flows. This diagram sets the foundation for identifying security threats.

Identify Trust Boundaries

Once the functionality is mapped out, focus on identifying trust boundaries: points where the level of trust changes within the system. Trust boundaries are critical for pinpointing potential attack surfaces.

Steps

1. Locate Trust Boundaries:

   • Identify points where data crosses between:

     • Different trust levels (e.g., user-to-server, internal-to-external systems).

     • Privilege levels (e.g., regular user-to-admin system interactions).

     • Ownership domains (e.g., your application and third-party APIs).

2. Highlight Security-Relevant Transitions:

   • Mark transitions where sensitive operations occur, such as authentication, encryption, or data storage.

Deliverable

A list of trust boundaries identified within the system. Each of them includes one or more nodes created in the previous step.

Example

• User-to-System: Input from the user into the application (e.g., login form submission).

• System-to-Database: Data exchanged between the application and its database.

• Internal-to-External: Interactions with third-party services or APIs.

• Privilege Changes: Where roles or permissions escalate (e.g., user-to-admin).

Identify Threats Using Threat Templates

Threat Templates empower developers to conduct threat modeling independently, reducing reliance on security experts. These concise, pre-defined collections of (max) 20 threats and corresponding controls are tailored to specific contexts, such as:

• Compliance Standards (e.g., FedRAMP, PCI DSS, HIPAA, GDPR).

• Deployment Environments (e.g., AWS, Azure, on-premises, etc).

• Coding Guidelines (e.g., secure code best practices, NIST CSF, OWASP recommendations).

• Organizational Priorities (e.g., vulnerability patterns or high-risk areas for the business).

Threat Templates streamline threat identification by focusing on relevant threats for a feature or system, ensuring no critical threats are missed. Their structured approach simplifies the process, enabling developers to work efficiently without requiring deep security knowledge.

For best results, Threat Templates must be created and reviewed by a security expert. Refer to the dedicated section on Building Threat Templates in this paper for detailed guidance on how to develop and maintain these templates effectively.

Steps

1. Select a Threat Template Aligned to a Context (reference the Appendix, for example, Threat Templates):

   • Compliance Context: (e.g., FedRAMP, PCI DSS, HIPAA, GDPR).

   • Deployment Context: (e.g., AWS, Azure, on-premises).

   • Implementation Context: (e.g., threats due to common code vulnerabilities).

   • Organizational Priorities: (e.g., threats identified from internal vulnerability management programs).

   Multiple threat templates can be selected depending on the audience working on the Threat Model. For example, in the context of a financial application within the scope for PCI DSS and deployed on AWS, developers can use the PCI DSS and Secure Code Implementation Templates while DevOps engineers can use the AWS Threat Template. Reference the full example for more information.

2. Match Threats to the Feature: Identify threats from the template that apply to the feature's components or workflows.

Deliverable

A list of threats relevant to the feature based on the selected Threat Template.

Example

Example of Selected Threats from the PCI DSS Threat Template for a Banking Application.

Threat	Description	Default Severity	Applicable Components
Unauthorized Access to Sensitive Systems	Unauthorized individuals gain access to critical payment systems or administrative functions by bypassing authentication controls, potentially leading to data breaches or system compromises.	High	Back-end APIs
Unencrypted Network Connection	Sensitive payment data is transmitted without adequate encryption, increasing the risk of interception or theft by malicious actors.	Moderate	Data Store Backoffice Portal Back-end APIs
Unauthorized Devices or Users	Unauthorized back-office support users gain access to payment networks, exposing data and potentially enabling fraudulent activities.	High	Backoffice Portal
Lack of Detection for Anomalies	Systems do not effectively identify unusual login patterns, fraudulent transactions, or suspicious network activities in a timely manner, allowing prolonged unauthorized access or financial losses.	Moderate	Backoffice Portal Back-end APIs

Identify Controls Using Threat Templates

For each threat identified, developers select corresponding pre-approved controls from the same Threat Template while having the flexibility to incorporate additional security measures as needed. These controls should align with:

• Compliance Standards (e.g., PCI DSS requirements, NIST 800-53).

• Deployment-Specific Guidance (e.g., AWS Well-Architected Framework).

• Secure Coding Best Practices (e.g., OWASP recommendations).

• Internal Security Policies (e.g., mandated libraries, APIs, or business processes).

Steps

1. Identify Controls: For each threat, list the controls provided in the Threat Template.

2. Evaluate Implementation:

   • Implemented: Control is operational and effective.

   • Partially or not implemented: Control exists but has gaps or is missing.

3. Document Implementation Rationale: Provide reasons for the control's implementation status.

Deliverable

A list of controls from the selected Threat Template, specifically designed to mitigate the risks posed by the identified threats.

Example

Threat-to-Control Mapping Example.

Threat	Suggested Controls	Applicable Components	Control Implemented?	Rationale
Unauthorized Access to Sensitive Systems	PCI DSS Requirement 8: Identify and Authenticate Access to System Components. Implement strong authentication methods, including unique IDs and multi-factor authentication.	Back-end APIs	Yes	Centralized access management and MFA are fully implemented.
Unencrypted Network Connection	PCI DSS Requirement 4: Encrypt Transmission of Payment Data Across Open, Public Networks. Use strong cryptography (e.g., TLS 1.2 or higher) to protect payment data during transmission.	Data Store	Yes	TLS 1.2 is enforced.
		Backoffice Portal	No	TLS 1.2 not enforced.
		Back-end API	Yes	TLS 1.2 is enforced.
Unauthorized Devices or Users	PCI DSS Requirement 8: Identify and Authenticate Access to System Components Enforce authentication for all users and devices accessing the system.	Backoffice Portal	Partially	Stringent authentication has been enforced for end-users, but not for back-office support agents.
Lack of Detection for Anomalies	PCI DSS Requirement 10: Track and Monitor All Access to Network Resources and Payment Data Implement comprehensive logging and monitoring to detect unusual activities.	Backoffice Portal	No	Logging is operational, but real-time monitoring is not implemented.
		Back-end API	No	Logging is operational, but real-time monitoring is not implemented.

Rate and Prioritize Threats

For each identified threat, perform the following steps.

Steps

1. Assess Severity: Update the default severity rating of High, Moderate, or Low based on the likelihood of the threat occurring, its potential impact, and on the controls which have been already fully or partially implemented as documented in Identify Controls Using Threat Templates.

   Note: Each threat in a Threat Template typically comes with a default severity rating to streamline evaluation and prioritization.

2. Determine Threat Status:

   • Mitigated: The threat has been fully addressed through implemented controls.

   • Accepted: The threat is acknowledged and accepted because of low likelihood, minor impact, or a business decision.

   • Open: The threat remains unaddressed due to incomplete or missing controls.

3. Provide Rationale: Briefly explain why the threat is categorized as mitigated, accepted, or open. Propose actions or mitigations to address the remaining threats.

Note: Risk assessment considerations, including residual risk evaluation, are inherently tied to an organization's specific risk appetite and security posture. These aspects involve subjective judgments on impact and likelihood, which can vary significantly between organizations based on their controls and priorities. As such, they extend beyond the scope of this methodology, which focuses on a streamlined, developer-friendly approach to identifying and addressing threats. Instead of using risk ratings, we focus solely on severity ratings, simplifying the process while maintaining a practical approach to security. By avoiding complex risk assessments, we improve the chances of developer adoption, ensuring security is integrated efficiently without unnecessary overhead.

Deliverable

A report including all threats, severity ratings, and proposed mitigations.

Focus on high-severity unmitigated threats first and prioritise low-severity threats for later review.

Example

Threat Assessment Table Example.

Threat	Applicable Components	Rationale & Next Steps	Threat Status	Severity
Unauthorized Access to Sensitive Systems	Back-end APIs	Centralized access management and MFA are fully implemented.	Mitigated	-
Unencrypted Network Connection	Data Store	TLS 1.2 is enforced. No further actions required.	Mitigated	-
	Backoffice Portal	TLS 1.2 is enforced. No further actions required.	Mitigated	-
	Back-end APIs	TLS 1.2 is enforced. No further actions required.	Mitigated	-
Unauthorized Devices or Users	Backoffice Portal	Stringent authentication has been enforced for end-users, but not for back-office support agents. Enforce authentication for back-office support agents.	Open	High
Lack of Detection for Anomalies	Backoffice Portal	Logging is operational, but real-time monitoring is not implemented. Introduce real-time monitoring capabilities.	Open	Moderate
	Back-end APIs	Logging is operational, but real-time monitoring is not implemented.	Open	Moderate

Document Results, Automate, and Iterate

Summarize the threat modeling outcomes in a concise, shareable report that includes:

• Feature description

• List of identified threats and linked controls

• Control implementation status and accepted threats

• Mitigation plans for any unaddressed issues

Store the threat model in the same ticket or feature record (e.g., Jira, Azure DevOps), ensuring easy access for the entire team and a clear audit trail proving security was addressed during development.

Integrate threat modeling into routine workflows (e.g., feature refinement or sprint planning). Leverage checklists, templates, or automated tools to generate or update models automatically, reducing manual overhead and fostering continuous security awareness.

Building Threat Templates

Creating effective Threat Templates is best done by security experts, who curate a focused set of threats and corresponding controls tailored to specific compliance standards, application environments, or organizational needs.

Threat Templates serve as the core enabler of the RaD-TM methodology by allowing organizations to have their developers focus on a concise list—no more than 20 items—tailored to each new critical functionality. This developer-focused approach removes the need for extensive brainstorming and reduces complexity while ensuring that threats and controls remain aligned with compliance and context-specific priorities. By reusing pre-approved templates, organizations simplify and accelerate their threat modeling process, maintaining a balance between thoroughness and usability through a manageable list of (ideally) a maximum of 20 entries. As a result, threat modeling becomes both accessible to developers and robust in upholding high security and compliance standards.

This chapter provides a step-by-step guide for creating Threat Templates, using threats and controls relevant to PCI DSS as an example. Alternatively, threats can be derived from CIS Benchmarks or the NIST Cybersecurity Framework (CSF), with controls mapped from NIST SP 800-53.

Reference the Appendix for examples of Threat Templates.

Define the Scope of the Threat Template

Clearly establish the scope and context for the Threat Template to determine which threats and controls are most relevant.

• Compliance Context: Is the template aimed at PCI DSS, HIPAA, GDPR, or another standard?

• Deployment Context: Will the application run on AWS, Azure, on-premises, or embedded systems?

• Industry Context: Does the organization operate in banking, healthcare, automotive, or another vertical?

• Implementation Context: Which technologies and programming languages are being utilized?

• Organizational Priorities: What threats and vulnerabilities occur most often based on historical data?

For example:

• Scope: Banking application under PCI DSS compliance.

• Focus: Protecting sensitive payment data, preventing fraud, and ensuring secure authentication.

Select Relevant Threats

Extract the most pertinent threats that align with the identified scope. For example, for a financial application subject to PCI DSS compliance, focus on threats outlined in the PCI DSS framework. Limit the total to a maximum of 20 entries, ensuring each threat aligns with the defined focus.

Map threats to specific, actionable controls. Organize the selected threats and mapped controls into a concise, developer-friendly format. Each threat should have one or more controls clearly listed for quick reference.

Update and Maintain the Threat Template

Threat Templates should evolve over time:

• Leverage Vulnerability Data: Update templates based on recurring vulnerabilities identified in penetration tests or incident reports.

• Monitor Emerging Threats: Add new threats from industry reports or internal threat intelligence.

• Incorporate Feedback: Refine templates based on developer input and lessons learned during threat modeling.

Example Threat Templates

PCI DSS

Threat	Description	Severity Rating	Suggested Controls
Unauthorized Access to Cardholder Data	Unauthorized individuals gain access to stored cardholder data through inadequate access controls or compromised credentials.	High	PCI DSS Requirement 7: Implement strong access control measures, ensuring that only authorized personnel have access to cardholder data. Requirement 8: Enforce unique user IDs and strong authentication methods. Requirement 10: Maintain comprehensive audit trails of all access to network resources and cardholder data.
Inadequate Data Encryption	Sensitive cardholder data is not properly encrypted both at rest and in transit, making it vulnerable to interception or theft.	High	PCI DSS Requirement 3: Encrypt stored cardholder data using strong cryptography (e.g., AES-256). Requirement 4: Encrypt transmission of cardholder data across open, public networks using TLS 1.2 or higher. Requirement 3: Implement robust key management practices, including key rotation and secure storage.
Insufficient Physical Security	Physical access to systems storing cardholder data is not adequately controlled, allowing unauthorized physical access.	High	PCI DSS Requirement 9: Restrict physical access to cardholder data to authorized personnel only. Requirement 9: Use surveillance cameras and secure access mechanisms (e.g., biometric scanners, badges) for sensitive areas. Requirement 9: Implement visitor logs and access monitoring for facilities storing cardholder data.
Inadequate Network Security	Network defenses are insufficient, enabling attackers to penetrate and access cardholder data.	High	PCI DSS Requirement 1: Install and maintain a firewall configuration to protect cardholder data. Requirement 1: Implement network segmentation to isolate cardholder data environments (CDE) from other networks. Requirement 1: Regularly review and update firewall and router configurations.
Weak Authentication Mechanisms	Authentication processes are weak or improperly implemented, allowing unauthorized users to bypass security controls.	High	PCI DSS Requirement 8: Enforce multi-factor authentication (MFA) for all access to the CDE. Requirement 8: Implement strong password policies, including complexity and rotation. Requirement 8: Ensure that default passwords are changed and not used in production environments.
Lack of Segregation of Duties	Lack of proper role-based access control and segregation of duties increases the risk of insider threats and unauthorized actions.	High	PCI DSS Requirement 7: Define and enforce role-based access controls (RBAC) to ensure separation of duties. Requirement 7: Regularly review user roles and permissions to prevent excessive access. Requirement 7: Implement least privilege principles across all systems handling cardholder data.
Poor Vendor Management	Third-party vendors with access to cardholder data do not adhere to PCI DSS standards, introducing additional vulnerabilities.	High	PCI DSS Requirement 12.8: Maintain and enforce policies and procedures to manage service providers. Requirement 12.8: Ensure third-party vendors comply with PCI DSS standards through contracts and regular assessments. Requirement 12.8: Monitor and review third-party service provider activities related to cardholder data.
Inadequate Logging and Monitoring	Systems do not have sufficient logging and monitoring in place to detect and respond to security incidents involving cardholder data.	High	PCI DSS Requirement 10: Implement logging mechanisms to capture all access to network resources and cardholder data. Requirement 10: Use a Security Information and Event Management (SIEM) system to aggregate and analyze logs. Requirement 10: Regularly review and analyze logs for suspicious activities and anomalies.
Insufficient Incident Response	Lack of a robust incident response plan hinders timely and effective response to breaches or security incidents involving cardholder data.	High	PCI DSS Requirement 12.10: Develop and maintain an incident response plan. Requirement 12.10: Conduct regular incident response drills and tabletop exercises. Requirement 12.10: Ensure proper communication channels and roles are defined for incident management.
Incomplete or Outdated Security Policies	Security policies and procedures are incomplete, outdated, or not enforced, leading to gaps in security measures protecting cardholder data.	High	PCI DSS Requirement 12.2: Establish and maintain a policy that addresses information security for all personnel. Requirement 12.2: Regularly review and update security policies to reflect current threats and compliance requirements. Requirement 12.2: Ensure policies are communicated and enforced across the organization.
Data Retention Beyond Requirements	Cardholder data is retained longer than necessary, increasing the risk of exposure if compromised.	Moderate to High	PCI DSS Requirement 3.1: Limit data retention to what is necessary for business, legal, and regulatory requirements. Requirement 3.1: Implement data retention and disposal policies that comply with PCI DSS. Requirement 3.1: Regularly audit stored data to ensure compliance with retention limits.
Lack of Regular Security Assessments	Organizations do not perform regular security assessments and vulnerability scans to identify and remediate security weaknesses.	High	PCI DSS Requirement 11.2: Perform quarterly vulnerability scans and annual penetration tests. Requirement 11.2: Use automated tools to identify and remediate vulnerabilities. Requirement 11.2: Track and resolve security weaknesses in a timely manner based on risk prioritization.
Inadequate Change Management	Changes to systems and processes are not properly managed, potentially introducing new vulnerabilities or misconfigurations that affect cardholder data security.	High	PCI DSS Requirement 6.4: Implement a change control process for all system components. Requirement 6.4: Ensure that all changes are tested and approved before deployment. Requirement 6.4: Maintain documentation for all changes, including approvals and testing results.
Unauthorized Software Installation	Unauthorized or unapproved software is installed on systems handling cardholder data, potentially introducing vulnerabilities.	High	PCI DSS Requirement 6.3: Develop software applications securely, following secure coding standards. Requirement 6.3: Implement application whitelisting to prevent unauthorized software installations. Requirement 6.3: Regularly audit installed software and remove unauthorized or unnecessary applications.
Insecure Backup Practices	Backups containing cardholder data are not securely stored or encrypted, risking unauthorized access and data breaches.	High	PCI DSS Requirement 9.9: Protect all backup media and ensure that it is stored securely. Requirement 9.9: Encrypt backup data to protect it from unauthorized access. Requirement 9.9: Regularly test backup restoration processes to ensure data integrity and availability.
Inadequate Employee Training	Employees are not adequately trained on security policies, procedures, and best practices for handling cardholder data, increasing the risk of human error.	Moderate to High	PCI DSS Requirement 12.6: Train personnel on security policies and procedures. Requirement 12.6: Conduct regular security awareness training to educate employees about data protection and compliance. Requirement 12.6: Evaluate the effectiveness of training programs through assessments and simulations.
Improper Data Masking or Tokenization	Sensitive cardholder data is not masked or tokenized in environments where it is not needed, increasing the risk of exposure.	High	PCI DSS Requirement 3.4: Mask PAN when displayed (e.g., truncation, encryption). Requirement 3.4: Implement tokenization to replace PAN with tokens in non-secure environments. Requirement 3.4: Ensure that masking and tokenization techniques are consistently applied across all systems handling cardholder data.
Inadequate Access Revocation	When employees or contractors leave the organization, their access to cardholder data is not promptly and effectively revoked, increasing the risk of misuse.	High	PCI DSS Requirement 7.1: Limit access to cardholder data to only those individuals whose job requires it. Requirement 7.1: Implement processes to revoke access promptly when an employee leaves or changes roles. Requirement 7.1: Regularly review and update access rights to ensure they remain appropriate.
Insecure Data Handling	Sensitive data is not handled securely throughout its lifecycle, from collection to processing to storage, increasing the risk of unauthorized access or modification.	High	PCI DSS Requirement 3.5: Protect stored cardholder data by implementing strong access controls. Requirement 3.5: Ensure that sensitive data is handled securely throughout its lifecycle, including collection, processing, and storage. Requirement 3.5: Implement data handling procedures that comply with PCI DSS standards.

Secure Code Implementation

Threat	Description	Severity Rating	Suggested Controls
Logic Bugs	Errors in application logic can lead to subversion of security requirements, potentially allowing unauthorized actions with an impact specific to the application in scope.	High	Conduct thorough code reviews and testing to identify and fix logic errors. Use automated tools to detect logical flaws and ensure secure application logic.
Broken Access Control	Involves flaws where application logic does not properly enforce user roles or permissions, letting unauthorized users access restricted resources or perform privileged actions.	High	Implement server-side authorization checks. Follow the principle of least privilege. Use robust role-based or attribute-based access controls.
Insecure Direct Object References (IDOR)	Occurs when an application exposes references to internal implementation objects (like database records, file names, URIs) without proper checks, allowing attackers to manipulate these references to access unauthorized data.	High	Implement access control checks at every layer (object-level authorization). Use randomized or hashed references (not easily guessable). Validate user permissions before returning data.
Cryptographic Failures	Results from using weak or outdated algorithms, improper key management, or failing to encrypt sensitive data at rest or in transit.	High	Use modern, reputable encryption libraries (e.g., AES-256, RSA-2048). Enforce TLS/HTTPS for data in transit. Securely store and rotate keys.
Hard-coded Credentials	Storing passwords, tokens, or keys in code or configuration files can allow attackers who gain access to the source or binary to immediately exploit those credentials for unauthorized system or data access.	High	Use environment variables or secure credential storage (e.g., vaults). Regularly rotate secrets and keys. Implement code scanning tools to detect hard-coded credentials.
Default or Guessable Passwords	Using manufacturer default credentials or weak, guessable passwords can allow attackers to gain unauthorized access.	High	Enforce password complexity requirements. Prompt users to change default credentials upon first use. Implement account lockout policies and MFA.
OS Command Injection	Happens when an attacker can run arbitrary code on the target system by exploiting flaws in input validation, deserialization, or command execution within the application.	High	Strictly validate and sanitize all user-supplied data. Avoid unsafe APIs (e.g., direct calls to OS shells). Containerize or sandbox risky code paths to limit damage.
SQL Injection	Occurs when malicious SQL statements are injected into a query via user input, potentially allowing attackers to read, modify, or delete database information.	High	Use parameterized queries or stored procedures. Implement input validation and sanitization. Enforce least-privilege DB access.
LDAP Injection	Similar to SQL injection, this happens when untrusted input is injected into an LDAP statement, potentially altering directory queries and allowing attackers to bypass authentication or retrieve sensitive information from an LDAP server.	Moderate to High	Sanitize and encode user input used in LDAP queries. Use parameterized LDAP queries (where available). Implement strict access controls on directory services.
Cross-Site Scripting (XSS)	Allows attackers to inject client-side scripts into web pages viewed by other users, potentially stealing session tokens, redirecting users, or performing unauthorized actions.	High	Employ output encoding (e.g., HTML-escape user inputs). Use secure frameworks/libraries to handle templates. Validate all user data.
Race Conditions / Concurrency Issues	Occur when multiple processes or threads access shared resources in a way that can lead to unexpected behavior (e.g., overwriting data, inconsistent updates), potentially causing data integrity issues or unauthorized actions.	Moderate	Use proper locking or synchronization mechanisms. Validate shared resource states before and after updates. Employ transactional operations where possible.
Logging Sensitive Data	Storing personally identifiable information (PII), session tokens, or passwords in logs can expose them to unintended parties if log files are compromised or improperly accessed.	Moderate	Sanitize or mask sensitive fields before logging. Restrict access to log files and encrypt logs at rest. Implement log retention policies and secure disposal.
Cross-Site Request Forgery (CSRF)	Tricks an authenticated user's browser into sending malicious requests to a site they are logged into, allowing unauthorized actions or data manipulation.	Moderate	Use anti-CSRF tokens in forms. Implement same-site cookie attributes and headers. Require re-authentication for sensitive actions.
Server-Side Request Forgery (SSRF)	Allows an attacker to trick the server into making unintended requests to internal or external services, which can expose internal network resources or sensitive information.	Moderate	Validate and sanitize all URLs or endpoints. Restrict outbound traffic with allowlists/firewalls. Use network segmentation to limit internal resource exposure. Disable unneeded protocols.
Insecure Deserialization	Happens when untrusted or tampered serialized data is accepted and deserialized without proper validation, potentially allowing code injection or object manipulation.	Moderate	Use formats that support integrity checks (e.g., JSON + signatures). Validate all serialized data before deserialization. Restrict or disable object deserialization if possible.
Directory Traversal	Attackers manipulate file paths (e.g., using ../ sequences) to access files or directories outside the intended scope, potentially reading sensitive files or executing arbitrary scripts.	Moderate	Validate and sanitize all user-input file paths. Use strict server-side path handling (disallow ../ in user input). Implement principle of least privilege for file system access.
XML External Entities (XXE)	When an application parses XML that includes external entity references, attackers can exploit these references to access local files, cause denial of service, or perform SSRF (Server-Side Request Forgery) attacks.	Moderate	Disable DTDs (Document Type Definitions) if not needed. Use secure XML parsers that do not allow external entity expansion. Validate all XML inputs and monitor for suspicious references.
Unvalidated Redirects & Forwards	Occurs when an application redirects or forwards users to another page or site, and the target is not validated. Attackers can use this to phish users or launch other malicious exploits.	Moderate	Avoid using redirects/forwards unless essential. Validate destination URLs against an allow-list. Display clear warnings if redirects are necessary.
Denial of Service (DoS)	Involves overwhelming a server, network, or service (e.g., by sending excessive requests), making the application unavailable to legitimate users.	Moderate	Implement rate limiting and throttling. Use load balancers or CDNs to distribute traffic. Monitor for unusual traffic patterns and activate mitigation strategies (e.g., WAF rules).
Insufficient Logging & Monitoring	Occurs when security-related events are not logged or monitored, hindering the ability to detect or respond to breaches effectively.	Moderate	Implement centralized logging (e.g., SIEM). Establish clear alerting and incident response procedures. Regularly review and audit logs.

AWS

Threat	Description	Severity Rating	Suggested Controls
IAM Policy Misconfiguration	Overly permissive IAM policies (e.g., iam:FullAccess) can grant users or roles more privileges than needed, increasing the blast radius if credentials are compromised.	High	Adopt least-privilege principles (restrict privileges to what is strictly needed). Use AWS Managed Policies or well-tested custom policies. Continuously review IAM roles and policies for unnecessary or high-risk permissions.
API Gateway Misconfiguration	Failing to enable authorization (IAM, Cognito, or custom authorizers) or leaving endpoints wide open can let attackers call APIs without permission, leading to data leaks or unintended actions.	High	Require authentication and authorization for all API methods. Use WAF or Shield for DDoS protection. Enforce rate limiting with usage plans. Log and monitor API activity with Amazon CloudWatch or Kinesis.
Exposed AWS Access Keys	Storing or accidentally publishing AWS secret/access keys (e.g., in public GitHub repos, Docker images) can let attackers gain unauthorized access to AWS resources.	High	Rotate keys frequently and use AWS Secrets Manager or AWS Systems Manager Parameter Store. Configure automated scans for key exposure (e.g., Git secrets scanning). Use IAM Roles instead of static keys whenever possible.
Unencrypted Data at Rest	Not using encryption for data stored in S3, EBS volumes, RDS databases, or other storage services may expose sensitive information if the underlying storage is compromised.	High	Use AWS KMS-managed or customer-managed keys for EBS, RDS, and S3 encryption. Enforce encryption at rest using IAM policies and AWS Config rules. Periodically validate that encryption is enabled across all storage resources.
S3 Bucket Misconfiguration	When S3 buckets are left publicly readable/writable or have overly permissive Access Control Lists (ACLs) or bucket policies, attackers can access, modify, or delete data.	High	Use S3 Block Public Access settings. Enforce least-privilege IAM policies for bucket access. Enable Server Access Logging on buckets. Regularly audit S3 permissions with AWS Config or third-party tools.
EC2 Snapshot Exposures	Snapshots of EBS volumes made public (intentionally or accidentally) can reveal sensitive data (customer info, system credentials, etc.).	High	Mark snapshots as private by default and limit who can share them. Regularly audit snapshot sharing settings using AWS Config or custom scripts. Encrypt EBS volumes and snapshots with AWS KMS.
Route 53 DNS Misconfiguration or Hijacking	If domain ownership or DNS settings are compromised (e.g., via stolen registrar credentials), attackers can redirect traffic to malicious sites, impacting availability and data integrity.	High	Use Route 53 DNSSEC to protect zone integrity. Lock domain registrar accounts and enable MFA. Regularly audit DNS changes via CloudTrail and set up alerts for unauthorized modifications.
Insecure Serverless (Lambda) Configuration	Poorly configured AWS Lambda functions (e.g., excessive IAM privileges, exposed environment variables containing secrets) can give attackers a foothold into the AWS environment if a function is exploited.	Moderate to High	Grant least-privilege IAM roles to Lambda functions. Store sensitive data in AWS Secrets Manager or Parameter Store instead of environment variables. Use VPC connectivity only if needed; restrict outbound traffic where possible.
Misconfigured Amazon EKS or ECS Clusters	When container orchestration services are not locked down (e.g., open dashboard endpoints, unprotected metadata services, weak IAM roles for tasks/pods), attackers can escalate privileges within the cluster or gain unauthorized access to containers or data.	Moderate to High	Restrict cluster access (e.g., API server) to trusted networks. Use IAM Roles for Service Accounts in EKS. Leverage security groups, network policies, and pod security policies. Keep container images updated and scanned.
ECR (Elastic Container Registry) Exposed	Making ECR repositories publicly accessible or misconfiguring policies may allow attackers to pull or push malicious images, risking compromise of containerized workloads.	High	Set ECR repos to private and use IAM roles for access. Scan images for vulnerabilities (AWS ECR image scanning). Restrict cross-account access to ECR repos. Use lifecycle policies to remove old or vulnerable images.
EC2 Metadata Exposure	An attacker who gains access to the instance can query the instance metadata service (IMDS) to retrieve temporary credentials or sensitive data (e.g., IAM role tokens), leading to privilege escalation.	Moderate	Use Instance Metadata Service v2 (IMDSv2) which requires session-oriented requests. Limit access to IMDS from inside the instance via host-based firewalls. Enforce strong boundary controls (e.g., WAF, Security Groups).
Overly Permissive Security Groups	When security groups allow inbound or outbound traffic from any IP (e.g., 0.0.0.0/0) or broad port ranges, it can expose instances or services to the internet, increasing the risk of intrusion.	Moderate to High	Implement least-privilege network design (restrict ports/IP ranges). Automate checks using AWS Config rules (e.g., disallow open Security Groups). Use a VPC with subnets and Network ACLs for layered defense.
RDS Security Oversights	Publicly accessible RDS instances or default credentials/configurations can allow unauthorized access to databases, risking a data breach.	Moderate to High	Disable public access to RDS wherever possible. Use security groups to limit inbound connections. Enforce encryption at rest and in transit (SSL/TLS). Apply principle of least privilege for database users and roles.
Insecure VPC Configuration	Poorly configured VPCs (e.g., improper route tables, no subnet separation for public-facing vs. private resources) can expose internal services and data to the public internet.	Moderate	Separate public and private subnets, use NAT Gateways or VPC Endpoints. Restrict inbound/outbound traffic with Network ACLs and Security Groups. Monitor and audit VPC Flow Logs for suspicious traffic.
CloudFormation Template Vulnerabilities	Hard-coded credentials, improper resource configurations, or excessive IAM permissions in templates can create systemic security holes if deployed.	Moderate to High	Remove any hard-coded credentials or secrets. Use AWS IAM to manage required permissions at the resource level. Validate templates with tools like cfn-lint or AWS CloudFormation Guard. Keep CloudFormation templates versioned.
CloudFront Misconfiguration	Incorrect CloudFront distributions (e.g., allowing HTTP instead of HTTPS, no origin access control) can expose data in transit or allow unauthorized content tampering.	Moderate	Enforce HTTPS-only viewers and origin connections. Use Origin Access Control/Identity (OAC/OAI) to lock down S3 buckets. Configure WAF rules to filter malicious traffic.
AWS WAF Misconfiguration	A misconfigured Web Application Firewall (WAF) might allow malicious traffic through or incorrectly block legitimate traffic, undermining security and availability.	Moderate	Continuously tune WAF rulesets (e.g., AWS Managed Rules, custom rules). Test thoroughly in a staging environment before production. Integrate WAF logs with SIEM solutions to monitor for unusual traffic.
KMS Key Policy Loopholes	Poorly defined or overly broad Key Management Service (KMS) key policies can let unauthorized IAM principals use encryption keys, leading to data exfiltration or the inability to decrypt business-critical data.	Moderate to High	Define explicit KMS key policies; avoid using wildcard principals (*). Regularly review who can use and administer KMS keys. Rotate keys based on compliance requirements and use AWS Config rules to track policy changes.
AWS Secrets Manager Misconfiguration	Storing secrets without proper rotation, or granting wide access to secrets, can let attackers exploit credentials or tokens.	Moderate to High	Enforce automatic rotation of database credentials, API keys, etc. Use strict resource-based policies to limit who can retrieve secrets. Monitor AWS Secrets Manager logs (e.g., CloudTrail) to detect suspicious secret accesses.
AWS Elastic Beanstalk Misconfiguration	Default or permissive Elastic Beanstalk environments may expose logs, environment variables, or admin consoles.	Moderate	Restrict environment access and application URLs behind AWS WAF or an ALB with secure security groups. Store sensitive configs in AWS Secrets Manager or Parameter Store. Configure health checks and monitoring for anomalies.

Azure

Threat	Description	Severity Rating	Suggested Controls
Compromised Azure AD account	An attacker gains access to an Azure AD user or admin account and controls subscriptions or data.	High	Enforce MFA, conditional access, passwordless auth, disable legacy protocols.
Stolen service principal or client secret	Leaked or hard-coded client secrets allow unauthorized automation or API access.	High	Use managed identities, Key Vault secret rotation, audit App Registrations.
Over-privileged RBAC roles	Excessive permissions on users or service principals increase attack surface.	High	Implement least privilege, review RBAC assignments, use PIM for JIT access.
Public Storage Account containers	Blob containers set to public allow data leakage.	High	Disable public access, use Private Endpoints, monitor anonymous access.
Key Vault public endpoint exposure	Vault accessible from internet without network restrictions.	High	Restrict via Private Endpoint and access policies, enable firewall rules.
Missing patch management on VMs	Outdated images expose known vulnerabilities.	High	Use Update Management, hardened base images, Defender for Cloud.
NSG overly permissive rules	Open inbound/outbound traffic allows lateral movement or external exposure.	High	Restrict NSG rules, apply least privilege networking, log NSG flows.
Misconfigured Azure Firewall / WAF	Weak or absent layer-7 filtering allows attacks through web endpoints.	Moderate	Enable WAF with OWASP rules, restrict inbound IPs, monitor logs.
Shared admin accounts	Shared credentials limit accountability and increase compromise risk.	Moderate	Use individual accounts, enforce PIM, disable shared secrets.
Missing diagnostic / activity logs	Incomplete logging delays incident detection.	Moderate	Enable Azure Monitor, send logs to Sentinel, ensure retention policies.
Exposed management ports (RDP/SSH)	Directly exposed ports to internet allow brute force or remote access.	High	Use Just-in-Time (JIT) VM access, restrict IPs, require VPN.
Misconfigured App Service auth	Web apps not enforcing authentication allow data exposure.	High	Enable Azure AD or OAuth auth, require HTTPS, disable anonymous access.
Data not encrypted at rest	Storage or DB without encryption enable data theft.	High	Use Azure Storage Service Encryption, TDE for SQL, customer-managed keys.
Weak key rotation policy	Keys and secrets not rotated regularly remain vulnerable.	Moderate	Automate rotation, use Managed Identities, audit expiry dates.
Insufficient backup protection	Backup storage can be deleted or overwritten by attacker.	Moderate	Enable soft delete and immutable backups, restrict delete permissions.
Unrestricted outbound internet access	Workloads can reach arbitrary endpoints, risk of data exfiltration.	Moderate	Use NSG egress restrictions, proxy/firewall, Defender for Cloud egress alerts.
Lack of tagging / asset inventory	Untracked resources create blind spots for security monitoring.	Low-Moderate	Enforce tagging policy, use Azure Policy for compliance and inventory.
Resource locks missing	Critical resources can be deleted by mistake or attacker.	Moderate	Apply resource locks (CanNotDelete), audit removal attempts.
Misconfigured Azure Policy compliance	Policies not enforced allow non-compliant deployments.	Moderate	Use initiative assignments, deployIfNotExists rules, monitor compliance.
Insecure API Management configuration	APIs expose sensitive backend endpoints.	High	Use OAuth 2.0, validate JWT tokens, enable rate limiting and logging.

GCP

Threat	Description	Severity Rating	Suggested Controls
Leaked service account JSON key	Static credentials leaked allow full API access.	High	Avoid long-lived keys, prefer Workload Identity, rotate and disable unused keys.
Public Cloud Storage bucket	Bucket misconfigured for public access leaks data.	High	Disable public ACLs, enforce uniform bucket-level access, use IAM only.
Over-privileged IAM roles	Excessive permissions allow privilege escalation.	High	Apply least privilege, audit IAM bindings, use organization-level policies.
Exposed GKE cluster master endpoint	Control plane open to internet allows exploitation.	High	Use private clusters, restrict control plane CIDR, enable authorized networks.
Vulnerable container images	Unscanned or outdated images enable exploits.	Moderate-High	Use Artifact Registry scanning, Binary Authorization, image signing.
Misconfigured firewall rules	Broad ingress/egress in VPC exposes internal resources.	High	Apply least-privilege rules, audit VPC Firewall Rules Logs.
Weak service account key rotation	Keys not rotated or revoked after use.	Moderate	Automate rotation, disable manual key creation.
Insufficient Cloud Audit Logs	Missing logs prevent detection of unauthorized activity.	Moderate	Enable all audit logs (ADMIN_READ, DATA_WRITE/READ), export to SIEM.
Missing VPC Service Controls	Data exfiltration from sensitive projects via API endpoints.	High	Define VPC-SC perimeters, restrict private connectivity.
Shared projects for dev/prod	Cross-environment access leads to data leakage.	Moderate	Separate projects by environment, use org folders and policies.
Weak organization policy enforcement	Unrestricted resource creation leads to compliance gaps.	Moderate	Apply org-policy constraints (e.g., allowed images, regions).
No encryption on persistent disks	Data at rest exposed if disk copied or stolen.	High	Enable CMEK, enforce encryption on all storage.
Unrestricted Cloud Functions endpoints	Public invocations enable abuse or data leakage.	Moderate-High	Restrict via IAM, require authentication, validate inputs.
Insecure BigQuery dataset sharing	Datasets shared publicly or with broad access.	High	Restrict dataset access to groups, audit access lists.
Weak password / OAuth consent misuse	Users authorize malicious OAuth apps.	Moderate	Enforce OAuth consent screen verification, educate users, limit scopes.
Disabled Cloud KMS key rotation	Old encryption keys increase risk of compromise.	Moderate	Automate key rotation, monitor key age and use.
Unpatched GCE VMs	Vulnerable images exploited remotely.	High	Enable OS patch management, use VM Manager compliance reports.
Disabled Cloud Armor / WAF	Public web endpoints lack DDoS protection.	Moderate	Deploy Cloud Armor, use rate limiting, geo-blocking.
Lack of DLP controls for sensitive data	PHI/PII stored in GCS or BQ without DLP checks.	Moderate	Enable Cloud DLP scans, classify data, enforce alerts.
Ineffective monitoring and alerting	Security events unmonitored, delays incident response.	Moderate	Enable Security Command Center, integrate SIEM, define alerting policies.

HIPAA

Threat	Description	Severity Rating	Suggested Controls
Unauthorized access to PHI	Users gain PHI access without legitimate need.	High	Enforce RBAC, MFA, least privilege, regular access reviews.
PHI transmitted without encryption	Unencrypted transmission exposes PHI to interception.	High	Enforce TLS 1.2+, VPNs for remote connections, disable insecure protocols.
PHI stored without encryption	PHI at rest left unencrypted on disks or backups.	High	Apply AES-256 encryption, use HSM/KMS, limit key access.
Weak or absent key management	Poor key lifecycle handling enables decryption by attackers.	High	Enforce KMS rotation, separation of duties, key usage logging.
Incomplete audit trails	Lack of access logs hinders detection of misuse.	Moderate-High	Enable detailed auditing, retain per HIPAA retention period, SIEM correlation.
Insider misuse of PHI	Employees intentionally or accidentally leak PHI.	High	Implement DLP, least privilege, user behavior analytics, training.
Inadequate BAA coverage	Third-party vendors lack Business Associate Agreements.	High	Execute BAAs, verify compliance, maintain vendor inventory.
Insufficient breach notification plan	Delayed or missing notifications after incident.	Moderate	Define breach policy, response timelines, stakeholder roles.
Insecure disposal of PHI	Data remnants on retired media lead to disclosure.	Moderate	Apply secure erasure, degaussing, verified destruction processes.
Backup media unprotected	Unencrypted backups can be lost or stolen.	High	Encrypt backups, isolate physically/logically, test restores.
PHI in logs or telemetry	Logging inadvertently captures PHI.	Moderate	Redact sensitive fields, sanitize logs before aggregation.
Over-exposed cloud storage	Misconfigured cloud bucket exposes PHI publicly.	High	Apply strict ACLs, disable public access, continuous monitoring.
Lack of access recertification	Access rights not periodically reviewed.	Moderate	Perform quarterly recertifications, auto-remove inactive accounts.
Weak endpoint security	Endpoints storing PHI lack AV or encryption.	Moderate-High	Deploy EDR, enforce device encryption, patch management.
No segregation of environments	Mixing test and production PHI data risks leaks.	Moderate	Use anonymized data in test, enforce environment separation.
Missing DLP email controls	PHI sent via unsecured email channels.	Moderate-High	Implement DLP scanning, encrypt outbound emails.
Poor identity lifecycle management	Orphaned accounts retain PHI access.	Moderate	Automate provisioning/deprovisioning, sync with HR system.
Weak physical access controls	Unauthorized individuals can access servers storing PHI.	High	Secure server rooms, badge systems, CCTV, visitor logs.
Ineffective training & awareness	Staff unaware of HIPAA obligations.	Moderate	Mandatory annual HIPAA/security training, phishing simulations.
No formal risk assessment	Organization lacks periodic HIPAA risk analysis.	Moderate	Perform annual risk assessments, track remediation, document results.

Privacy

Threat	Description	Severity Rating	Suggested Controls
Unlawful data collection	Data collected without proper consent or legal basis.	High	Implement consent management, lawful basis registry, periodic audits.
Excessive data retention	Personal data kept longer than necessary.	Moderate	Define retention schedules, automate deletion, document justification.
Inadequate data minimization	Collecting more personal data than required.	Moderate	Apply data minimization policies, perform DPIA.
Lack of user consent tracking	No record of user consent for processing.	High	Maintain consent logs, enable withdrawal mechanisms.
Cross-border data transfer non-compliance	Data transferred to non-approved countries without safeguards.	High	Use SCCs, BCRs, or equivalent legal frameworks.
Insufficient anonymization/pseudonymization	Poor de-identification leads to re-identification risk.	Moderate-High	Apply irreversible anonymization, monitor re-ID risk.
Unauthorized data sharing with third parties	Sharing personal data without data sharing agreement.	High	Require DPAs with vendors, limit purpose, perform due diligence.
Weak access controls on personal data	Overly broad access to user data.	High	Enforce least privilege, MFA, regular access review.
Incomplete breach notification process	No timely notification to regulators or users.	Moderate-High	Define breach workflow, retain notification templates, test process.
Insufficient privacy-by-design	New features ignore privacy principles.	Moderate	Perform DPIAs early in design, embed privacy review in SDLC.
Insecure data deletion	Deleted records remain recoverable.	Moderate	Apply secure wipe and verification, validate backups.
Data subject request mishandling	DSRs (access, deletion) not handled correctly.	Moderate	Define DSR process, track requests, verify identity.
Inaccurate data records	Stale or incorrect data kept, violating accuracy principle.	Low-Moderate	Implement correction workflows, periodic data validation.
Missing records of processing activities (ROPA)	No central inventory of personal data flows.	Moderate	Maintain updated ROPA, assign owners, include purposes and retention.
Unencrypted personal data	Data at rest or in transit unencrypted.	High	Enforce encryption across all data layers.
Poor vendor oversight	Vendors mishandle data without oversight.	Moderate	Conduct periodic audits, require security assessments.
Lack of DLP monitoring	Data exfiltration goes undetected.	Moderate	Deploy DLP on endpoints, email, and cloud storage.
Misconfigured cookie consent	Cookies dropped before consent given.	Low-Moderate	Implement compliant consent banners, periodic scanning.
Weak anonymization in analytics	Personal identifiers persist in analytics data.	Moderate	Tokenize IDs, remove PII before analytics ingestion.
Employee misuse of personal data	Insider misuses access to personal information.	Moderate-High	Monitor access, enforce least privilege, provide privacy training.

Low-Code / No-Code Platforms

Threat	Description	Severity Rating	Suggested Controls
Insecure data connections	Connectors expose sensitive data via weak auth.	High	Enforce OAuth, avoid storing credentials, review connectors.
Overly broad sharing of apps	Apps shared publicly expose internal data.	High	Limit sharing to groups, enforce enterprise sharing policy.
Lack of governance over app creation	Citizen developers deploy unvetted apps.	Moderate-High	Establish CoE, approval workflow, app cataloging.
Hard-coded secrets in formulas	Credentials embedded in app logic.	High	Use environment variables, secure vault integrations.
Insecure API calls	Direct API calls from client expose backend.	Moderate	Use backend proxy, restrict keys, enforce HTTPS.
No version control / rollback	Lack of versioning leads to undetected malicious updates.	Moderate	Implement app lifecycle management and version tracking.
Weak access control model	Role-based permissions not enforced properly.	Moderate-High	Apply RBAC, verify least privilege, disable guest access.
Lack of logging or audit trail	No audit records for app execution or data access.	Moderate	Enable platform audit logging, export to SIEM.
Unsanctioned integrations	Users connect apps to unapproved SaaS.	Moderate	Use allowlist connectors, CASB monitoring.
Data exfiltration via connectors	Data sent to personal cloud accounts.	High	Restrict connector usage, monitor flows, implement DLP.
Insecure public forms	Anonymous submissions used for injection attacks.	Moderate	Validate inputs, use CAPTCHA, monitor spam.
Shadow IT through personal accounts	Employees use personal tenants for business apps.	Moderate	Disable personal app publishing, enforce org-managed tenants.
Missing lifecycle management	Apps persist after owner leaves.	Moderate	Assign app ownership policies, periodic orphaned app cleanup.
Unreviewed external components	Reused community components contain vulnerabilities.	Moderate	Maintain approved component library, perform dependency scans.
Insecure data sources	Apps connected to databases without encryption.	High	Require encrypted connections, managed identities.
No segregation of dev/test/prod	Same environment used for all stages.	Moderate	Create isolated environments, implement promotion workflow.
Lack of training on security patterns	Citizen devs unaware of security implications.	Moderate	Provide secure development training and guidelines.
Poor backup and recovery	App configurations lost during outage.	Low-Moderate	Enable automated backups, document recovery procedures.
Data privacy non-compliance	Apps collect personal data without consent.	Moderate	Embed privacy review, use approved templates.
Disabled audit export	Security events not exported to monitoring.	Low-Moderate	Integrate with SIEM or central log management.

STRIDE

Threat	Description	Severity Rating	Suggested Controls
Credential spoofing	Attacker impersonates user or service using stolen credentials.	High	MFA, passwordless auth, detect impossible travel.
API key reuse or theft	Reused API keys allow impersonation.	High	Rotate keys, bind to IP/range, enforce OAuth2.
Session hijacking	Stolen session tokens used for spoofing.	High	Use secure cookies, short-lived tokens, token binding.
Data tampering in transit	Unencrypted traffic modified by MITM.	High	Enforce HTTPS/TLS1.2+, HSTS, integrity checks.
Configuration tampering	Attacker changes system settings or security controls.	Moderate	Implement configuration baselines, alert on changes.
Malicious code injection	Code or script tampering changes app behavior.	High	Validate inputs, code signing, use CI/CD integrity checks.
Log repudiation	User denies action due to missing or tampered logs.	Moderate	Use tamper-evident logs, immutable storage.
Inadequate audit logging	Logs missing user IDs/time, no accountability.	Moderate	Ensure detailed audit logs, correlate with identity provider.
Unencrypted sensitive data	Data leakage via plain text storage or transmission.	High	Encrypt data at rest/in transit, apply key management.
Insecure backup exposure	Backup copies stolen or publicly accessible.	Moderate	Encrypt backups, restrict access, offsite secure storage.
Excessive information disclosure	Error messages reveal stack traces or secrets.	Moderate	Sanitize errors, disable verbose debug in production.
Denial of Service (DoS) attack	Resource exhaustion leads to downtime.	High	Implement rate limiting, auto-scaling, WAF/CDN.
Application-level DoS	Logic flaws allow repeated expensive operations.	Moderate	Optimize code, limit concurrent sessions, caching.
Flooding or volumetric DDoS	Network flooding overwhelms services.	High	Use DDoS protection service, geo-blocking, throttling.
Privilege escalation via misconfig	Misconfigured roles allow privilege gain.	High	Apply least privilege, review IAM/RBAC roles.
Exploiting unpatched vulnerabilities	Attackers elevate privileges through old CVEs.	High	Patch management, vulnerability scanning.
Insecure dependency injection	Vulnerable libraries exploited for EoP.	Moderate	Use dependency scanning, pin versions.
Weak boundary controls	Network segmentation failure enables lateral movement.	Moderate-High	Enforce segmentation, zero-trust network.
Missing anti-repudiation measures	Lack of digital signatures allows transaction denial.	Moderate	Implement signing and verification, use tamper-proof logs.
Ineffective monitoring for STRIDE categories	No specific detection for spoofing/tampering/disclosure.	Moderate	Map detections to STRIDE matrix, use MITRE ATT&CK coverage.

RaD-TM Threat Templates: Azure, GCP, HIPAA, Privacy, Low-Code/No-Code, STRIDE

---

Threat Template: Azure

Scope / Context: Deployment of workloads and services in Microsoft Azure (IaaS / PaaS / SaaS)

Threat	Description	Default Severity	Suggested Controls
Compromised Azure AD account	An attacker gains access to an Azure AD user or admin account and controls subscriptions or data.	High	Enforce MFA, conditional access, passwordless auth, disable legacy protocols.
Stolen service principal or client secret	Leaked or hard-coded client secrets allow unauthorized automation or API access.	High	Use managed identities, Key Vault secret rotation, audit App Registrations.
Over-privileged RBAC roles	Excessive permissions on users or service principals increase attack surface.	High	Implement least privilege, review RBAC assignments, use PIM for JIT access.
Public Storage Account containers	Blob containers set to public allow data leakage.	High	Disable public access, use Private Endpoints, monitor anonymous access.
Key Vault public endpoint exposure	Vault accessible from internet without network restrictions.	High	Restrict via Private Endpoint and access policies, enable firewall rules.
Missing patch management on VMs	Outdated images expose known vulnerabilities.	High	Use Update Management, hardened base images, Defender for Cloud.
NSG overly permissive rules	Open inbound/outbound traffic allows lateral movement or external exposure.	High	Restrict NSG rules, apply least privilege networking, log NSG flows.
Misconfigured Azure Firewall / WAF	Weak or absent layer-7 filtering allows attacks through web endpoints.	Moderate	Enable WAF with OWASP rules, restrict inbound IPs, monitor logs.
Shared admin accounts	Shared credentials limit accountability and increase compromise risk.	Moderate	Use individual accounts, enforce PIM, disable shared secrets.
Missing diagnostic / activity logs	Incomplete logging delays incident detection.	Moderate	Enable Azure Monitor, send logs to Sentinel, ensure retention policies.
Exposed management ports (RDP/SSH)	Directly exposed ports to Internet allow brute force or remote access.	High	Use Just-in-Time (JIT) VM access, restrict IPs, require VPN.
Misconfigured App Service auth	Web apps not enforcing authentication allow data exposure.	High	Enable Azure AD or OAuth auth, require HTTPS, disable anonymous access.
Data not encrypted at rest	Storage or DB without encryption enable data theft.	High	Use Azure Storage Service Encryption, TDE for SQL, customer-managed keys.
Weak key rotation policy	Keys and secrets not rotated regularly remain vulnerable.	Moderate	Automate rotation, use Managed Identities, audit expiry dates.
Insufficient backup protection	Backup storage can be deleted or overwritten by attacker.	Moderate	Enable soft delete and immutable backups, restrict delete permissions.
Unrestricted outbound internet access	Workloads can reach arbitrary endpoints, risk of data exfiltration.	Moderate	Use NSG egress restrictions, proxy/firewall, Defender for Cloud egress alerts.
Lack of tagging / asset inventory	Untracked resources create blind spots for security monitoring.	Low-Moderate	Enforce tagging policy, use Azure Policy for compliance and inventory.
Resource locks missing	Critical resources can be deleted by mistake or attacker.	Moderate	Apply resource locks (CanNotDelete), audit removal attempts.
Misconfigured Azure Policy compliance	Policies not enforced allow non-compliant deployments.	Moderate	Use initiative assignments, deployIfNotExists rules, monitor compliance.
Insecure API Management configuration	APIs expose sensitive backend endpoints.	High	Use OAuth 2.0, validate JWT tokens, enable rate limiting and logging.

Full Example

Threat Modeling for "Transfer Funds Between Accounts" in a Banking Application.

Produce a Graphical Representation

Feature

• Functionality: Allows users to transfer funds between their accounts.

Inputs and Outputs

• Inputs

  • User has already logged in

  • Source and destination account numbers

  • Transfer amount

• Outputs

  • Confirmation of the transaction

  • Error messages for invalid inputs or failed transfers

Feature Use Case (High-Level)

1. User logs in with valid credentials.

2. User navigates to "Transfer Funds."

3. User selects source account, destination account, and amount.

4. Application validates the input (checking sufficient funds, source and destination accounts, etc.).

5. Application processes the transfer, updates the database, and returns a confirmation message.

6. Application displays transaction confirmation and stores a record.

Model Diagram

Identify Trust Boundaries

Public Network → DMZ VPC

• Entities: A web browser (untrusted client) communicating with an AWS Application Load Balancer (ALB).

• Rationale: The boundary between the public internet (anyone can connect) and the organization's first layer of infrastructure (the DMZ). The ALB terminates incoming HTTPS connections, providing a secured entry point.

DMZ VPC → Private VPC

• Entities: The Application Load Balancer forwarding requests to the Java Web App running on AWS ECS in the Private VPC.

• Rationale: Only traffic that passes ALB rules and security checks enters the Private VPC. This boundary ensures requests have been filtered (e.g., via security groups, ALB listeners) before reaching internal services.

Private VPC → Database VPC

• Entities:

  • Java Web App (ECS) and the Fund Transfer Service (AWS Lambda) in the Private VPC

  • AWS RDS MySQL database in the Database VPC

• Rationale: The database resides in a more restricted VPC, typically with tighter network and IAM constraints. Traffic crossing from the Private VPC to the Database VPC must satisfy additional security conditions (e.g., security group rules, IAM auth, or TLS connections). This boundary reflects heightened trust and data sensitivity.

Identify Threats Using Threat Templates

Threat Template: PCI DSS

Threat	Description	Default Severity	Applicable Components
Inadequate Data Encryption	Sensitive payment data is not properly encrypted both at rest and in transit, making it vulnerable to interception or theft.	High	Application Load Balancer Java Web App Fund Transfer Service SQL Database
Inadequate Network Security	Network defenses are insufficient, enabling attackers to penetrate and access payment data.	High	Application Load Balancer Java Web App Fund Transfer Service SQL Database
Weak Authentication Mechanisms	Authentication processes are weak or improperly implemented, allowing unauthorized users to bypass security controls.	High	Java Web App Fund Transfer Service SQL Database
Lack of Segregation of Duties	Lack of proper role-based access control and segregation of duties increases the risk of insider threats and unauthorized actions.	High	Java Web App SQL Database
Inadequate Logging and Monitoring	Systems do not have sufficient logging and monitoring in place to detect and respond to security incidents involving payment data.	High	Java Web App Fund Transfer Service SQL Database
Insufficient Incident Response	Lack of a robust incident response plan hinders timely and effective response to breaches or security incidents involving payment data.	High	Global
Lack of Regular Security Assessments	Organizations do not perform regular security assessments and vulnerability scans to identify and remediate security weaknesses.	High	Global
Inadequate Change Management	Changes to systems and processes are not properly managed, potentially introducing new vulnerabilities or misconfigurations that affect payment data security.	High	Global
Insecure Backup Practices	Backups containing payment data are not securely stored or encrypted, risking unauthorized access and data breaches.	High	SQL Database

Threat Template: Secure Code Implementation

Threat	Description	Default Severity	Applicable Components
Logic Bugs	Errors in application logic can lead to subversion of security requirements, potentially allowing unauthorized actions with an impact specific to the application in scope.	High	Java Web App Fund Transfer Service
Broken Access Control	Involves flaws where application logic does not properly enforce user roles or permissions, letting unauthorized users access restricted resources or perform privileged actions.	High	Java Web App Fund Transfer Service SQL Database
Insecure Direct Object References (IDOR)	Occurs when an application exposes references to internal implementation objects (like database records, file names, URIs) without proper checks, allowing attackers to manipulate these references to access unauthorized data.	High	Java Web App
Cryptographic Failures	Results from using weak or outdated algorithms, improper key management, or failing to encrypt sensitive data at rest or in transit.	High	Java Web App Fund Transfer Service
Hard-coded Credentials	Storing passwords, tokens, or keys in code or configuration files can allow attackers who gain access to the source or binary to immediately exploit those credentials for unauthorized system or data access.	High	Java Web App Fund Transfer Service
Default or Guessable Passwords	Using manufacturer default credentials or weak, guessable passwords can allow attackers to gain unauthorized access.	High	Java Web App Fund Transfer Service SQL Database
OS Command Injection	Happens when an attacker can run arbitrary code on the target system by exploiting flaws in input validation, deserialization, or command execution within the application.	High	Java Web App Fund Transfer Service
SQL Injection	Occurs when malicious SQL statements are injected into a query via user input, potentially allowing attackers to read, modify, or delete database information.	High	Java Web App Fund Transfer Service
Cross-Site Scripting (XSS)	Allows attackers to inject client-side scripts into web pages viewed by other users, potentially stealing session tokens, redirecting users, or performing unauthorized actions.	High	Java Web App
Race Conditions / Concurrency Issues	Occur when multiple processes or threads access shared resources in a way that can lead to unexpected behavior (e.g., overwriting data, inconsistent updates), potentially causing data integrity issues or unauthorized actions.	High	Java Web App Fund Transfer Service
Logging Sensitive Data	Storing personally identifiable information (PII), session tokens, or passwords in logs can expose them to unintended parties if log files are compromised or improperly accessed.	Moderate	Java Web App Fund Transfer Service
Cross-Site Request Forgery (CSRF)	Tricks an authenticated user’s browser into sending malicious requests to a site they are logged into, allowing unauthorized actions or data manipulation.	High	Java Web App
XML External Entities (XXE)	When an application parses XML that includes external entity references, attackers can exploit these references to access local files, cause denial of service, or perform SSRF (Server-Side Request Forgery) attacks.	Moderate	Fund Transfer Service
Unvalidated Redirects & Forwards	Occurs when an application redirects or forwards users to another page or site, and the target is not validated. Attackers can use this to phish users or launch other malicious exploits.	Moderate	Java Web App
Denial of Service (DoS)	Involves overwhelming a server, network, or service (e.g., by sending excessive requests), making the application unavailable to legitimate users.	High	Application Load Balancer
Insufficient Logging & Monitoring	Occurs when security-related events are not logged or monitored, hindering the ability to detect or respond to breaches effectively.	Moderate	Java Web App Fund Transfer Service

Threat Template: AWS

Threat	Description	Default Severity	Applicable Components
IAM Policy Misconfiguration	Overly permissive IAM policies (e.g., iam:FullAccess) can grant users or roles more privileges than needed, increasing the blast radius if credentials are compromised.	High	Java Web App Fund Transfer Service
API Gateway Misconfiguration	Failing to enable authorization (IAM, Cognito, or custom authorizers) or leaving endpoints wide open can let attackers call APIs without permission, leading to data leaks or unintended actions.	High	Fund Transfer Service
Exposed AWS Access Keys	Storing or accidentally publishing AWS secret/access keys (e.g., in public GitHub repos, Docker images) can let attackers gain unauthorized access to AWS resources.	High	Java Web App Fund Transfer Service
Unencrypted Data at Rest	Not using encryption for data stored in S3, EBS volumes, RDS databases, or other storage services may expose sensitive information if the underlying storage is compromised.	High	Java Web App SQL Database
EC2 Snapshot Exposures	Snapshots of EBS volumes made public (intentionally or accidentally) can reveal sensitive data (customer info, system credentials, etc.).	High	Java Web App
Route 53 DNS Misconfiguration or Hijacking	If domain ownership or DNS settings are compromised (e.g., via stolen registrar credentials), attackers can redirect traffic to malicious sites, impacting availability and data integrity.	High	Global
Insecure Serverless (Lambda) Configuration	Poorly configured AWS Lambda functions (e.g., excessive IAM privileges, exposed environment variables containing secrets) can give attackers a foothold into the AWS environment if a function is exploited.	High	Fund Transfer Service
Misconfigured Amazon EKS or ECS Clusters	When container orchestration services are not locked down (e.g., open dashboard endpoints, unprotected metadata services, weak IAM roles for tasks/pods), attackers can escalate privileges within the cluster or gain unauthorized access to containers or data.	Moderate	Java Web App
ECR (Elastic Container Registry) Exposed	Making ECR repositories publicly accessible or misconfiguring policies may allow attackers to pull or push malicious images, risking compromise of containerized workloads.	Moderate	Java Web App
EC2 Metadata Exposure	An attacker who gains access to the instance can query the instance metadata service (IMDS) to retrieve temporary credentials or sensitive data (e.g., IAM role tokens), leading to privilege escalation.	Moderate	Java Web App
Overly Permissive Security Groups	When security groups allow inbound or outbound traffic from any IP (e.g., 0.0.0.0/0) or broad port ranges, it can expose instances or services to the internet, increasing the risk of intrusion.	High	Java Web App Fund Transfer Service SQL Database
RDS Security Oversights	Publicly accessible RDS instances or default credentials/configurations can allow unauthorized access to databases, risking data breach.	High	SQL Database
Insecure VPC Configuration	Poorly configured VPCs (e.g., improper route tables, no subnet separation for public-facing vs. private resources) can expose internal services and data to the public internet.	Moderate	Java Web App Fund Transfer Service SQL Database
CloudFormation Template Vulnerabilities	Hard-coded credentials, improper resource configurations, or excessive IAM permissions in templates can create systemic security holes if deployed.	Moderate	Java Web App Fund Transfer Service
CloudFront Misconfiguration	Incorrect CloudFront distributions (e.g., allowing HTTP instead of HTTPS, no origin access control) can expose data in transit or allow unauthorized content tampering.	Moderate	Application Load Balancer
AWS WAF Misconfiguration	A misconfigured Web Application Firewall (WAF) might allow malicious traffic through or incorrectly block legitimate traffic, undermining security and availability.	Moderate	Application Load Balancer
KMS Key Policy Loopholes	Poorly defined or overly broad Key Management Service (KMS) key policies can let unauthorized IAM principals use encryption keys, leading to data exfiltration or the inability to decrypt business-critical data.	Moderate	Global
AWS Secrets Manager Misconfiguration	Storing secrets without proper rotation, or granting wide access to secrets, can let attackers exploit credentials or tokens.	Moderate	Java Web App Fund Transfer Service

Identify Controls Using Threat Templates

Threat Template: PCI DSS

Threat	Suggested Controls	Applicable Components	Controls Implemented?	Rationale
Inadequate Data Encryption	PCI DSS Requirement 3: Encrypt stored payment data using strong cryptography (e.g., AES-256). Requirement 4: Encrypt transmission of payment data across open, public networks using TLS 1.2 or higher. Requirement 3: Implement robust key management practices, including key rotation and secure storage.	Application Load Balancer	Yes	TLS 1.2 is enforced, but removing older ciphers is scheduled for the next maintenance window.
		Java Web App	Yes	TLS 1.2 is enforced.
		Fund Transfer Service	Yes	TLS 1.2 is enforced.
		SQL Database	Partially	TLS 1.2 is enforced, but RDS encryption is not configured.
Inadequate Network Security	PCI DSS Requirement 1: Install and maintain a firewall configuration to protect payment data. Requirement 1: Implement network segmentation to isolate payment data environments (CDE) from other networks. Requirement 1: Regularly review and update firewall and router configurations.	Application Load Balancer	Partially	AWS Web Application Firewall (WAF) purchase is planned but not deployed yet.
		Java Web App	Yes	AWS security groups and VPC segregation are configured.
		Fund Transfer Service	Yes	AWS security groups and VPC segregation are configured.
		SQL Database	Yes	AWS security groups and VPC segregation are configured.
Weak Authentication Mechanisms	PCI DSS Requirement 8: Enforce multi-factor authentication (MFA) for all access to the CDE. Requirement 8: Implement strong password policies, including complexity and rotation. Requirement 8: Ensure that default passwords are changed and not used in production environments.	Java Web App	Partially	MFA is live, but new password complexity settings are rolling out next quarter.
		Fund Transfer Service	Yes	Mutual TLS authentication is implemented.
		SQL Database	Yes	A company-wide approved authentication solution is implemented.
Lack of Segregation of Duties	PCI DSS Requirement 7: Define and enforce role-based access controls (RBAC) to ensure separation of duties. Requirement 7: Regularly review user roles and permissions to prevent excessive access. Requirement 7: Implement least privilege principles across all systems handling payment data.	Java Web App	Yes	RBAC has been reviewed and approved by the internal security team.
		SQL Database	Yes	A single user with lowest privileges is configured in the database.
Inadequate Logging and Monitoring	PCI DSS Requirement 10: Implement logging mechanisms to capture all access to network resources and payment data. Requirement 10: Use a Security Information and Event Management (SIEM) system to aggregate and analyze logs. Requirement 10: Regularly review and analyze logs for suspicious activities and anomalies.	Java Web App	No	SIEM solution is configured in a test environment, with production rollout expected next quarter.
		Fund Transfer Service	No	SIEM solution is configured in a test environment, with production rollout expected next quarter.
		SQL Database	No	SIEM solution is configured in a test environment, with production rollout expected next quarter.
Insufficient Incident Response	PCI DSS Requirement 12.10: Develop and maintain an incident response plan. Requirement 12.10: Conduct regular incident response drills and tabletop exercises. Requirement 12.10: Ensure proper communication channels and roles are defined for incident management.	Global	No	No plan for incident response is in place.
Lack of Regular Security Assessments	PCI DSS Requirement 11.2: Perform quarterly vulnerability scans and annual penetration tests. Requirement 11.2: Use automated tools to identify and remediate vulnerabilities. Requirement 11.2: Track and resolve security weaknesses in a timely manner based on risk prioritization.	Global	Partially	Automated scans and tools are not configured, but a penetration test is scheduled once the functionality is completed.
Inadequate Change Management	PCI DSS Requirement 6.4: Implement a change control process for all system components. Requirement 6.4: Ensure that all changes are tested and approved before deployment. Requirement 6.4: Maintain documentation for all changes, including approvals and testing results.	Global	Partially	An internal Git repository is in place and pre-approved CI/CD pipelines are used. However, the documentation of the new functionality is lacking.
Insecure Backup Practices	PCI DSS Requirement 9.9: Protect all backup media and ensure that it is stored securely. Requirement 9.9: Encrypt backup data to protect it from unauthorized access. Requirement 9.9: Regularly test backup restoration processes to ensure data integrity and availability.	SQL Database	No	A policy revision is underway to incorporate encryption and stricter access controls for backup media.

Threat Template: Secure Code Implementation

Threat	Suggested Controls	Applicable Components	Controls Implemented?	Rationale
Logic Bugs	Conduct thorough code reviews and testing to identify and fix logic errors. Use automated tools to detect logical flaws and ensure secure application logic.	Java Web App	Partially	The peer code review is scheduled but has not yet been completed.
		Fund Transfer Service	Yes	This component has undergone thorough peer review and an independent third-party secure code review.
Broken Access Control	Implement server-side authorization checks Follow the principle of least privilege Use robust role-based or attribute-based access controls	Java Web App	Yes	Each endpoint has been reviewed and tested for authorization checks.
		Fund Transfer Service	Yes	A single user with lowest privileges is configured for the lambda service.
		SQL Database	Yes	A single user with lowest privileges is configured in the database.
Insecure Direct Object References (IDOR)	Implement access control checks at every layer (object-level authorization) Use randomized or hashed references (not easily guessable) Validate user permissions before returning data	Java Web App	Yes	A web filter has been implemented in front of each endpoint to validate object-level authorization.
Cryptographic Failures	Use modern, reputable encryption libraries (e.g., AES-256, RSA-2048) Securely store and rotate keys	Java Web App	Yes	Only company-wide approved cryptographic libraries are used.
		Fund Transfer Service	Yes	Only company-wide approved cryptographic libraries are used.
Hard-coded Credentials	Use environment variables or secure credential storage (e.g., vaults) Regularly rotate secrets and keys Implement code scanning tools to detect hard-coded credentials	Java Web App	No	Database credentials are still stored in configuration files, but there is a plan to switch to environment variables in the next release.
		Fund Transfer Service	Yes	The AWS SecretsManager service is used.
Default or Guessable Passwords	Enforce password complexity requirements Prompt users to change default credentials upon first use Implement account lockout policies and MFA	Java Web App	Partially	MFA is live, but new password complexity settings are rolling out next quarter.
		Fund Transfer Service	Yes	Mutual TLS authentication is implemented.
		SQL Database	Yes	A company-wide approved authentication solution is implemented.
OS Command Injection	Strictly validate and sanitize all user-supplied data Avoid unsafe APIs (e.g., direct calls to OS shells) Containerize or sandbox risky code paths to limit damage	Java Web App	No	The component does not involve any operating system interactions.
		Fund Transfer Service	No	The component does not involve any operating system interactions.
SQL Injection	Use parameterized queries or stored procedures Implement input validation and sanitization	Java Web App	No	Native queries are widely used.
		Fund Transfer Service	Yes	Parameterized queries are in place.
Cross-Site Scripting (XSS)	Employ output encoding (e.g., HTML-escape user inputs) Use secure frameworks/libraries to handle templates Validate all user data	Java Web App	Partially	CSP is implemented on most pages, and full DAST scans are scheduled after all form changes are completed.
Race Conditions / Concurrency Issues	Use proper locking or synchronization mechanisms Validate shared resource states before and after updates Employ transactional operations where possible	Java Web App	No	No tests have been conducted for thread-safe methods, and no third-party secure code review has been performed.
		Fund Transfer Service	Yes	This component has undergone an independent third-party secure code review, with a focus on race condition potential issues.
Logging Sensitive Data	Sanitize or mask sensitive fields before logging Restrict access to log files, and encrypt logs at rest Implement log retention policies and secure disposal	Java Web App	Yes	No sensitive data is logged.
		Fund Transfer Service	Yes	No sensitive data is logged.
Cross-Site Request Forgery (CSRF)	Use anti-CSRF tokens in forms Implement same-site cookie attributes and headers Require re-authentication for sensitive actions	Java Web App	Yes	Anti-CSRF tokens are implemented in each form.
XML External Entities (XXE)	Disable DTDs (Document Type Definitions) if not needed Use secure XML parsers that do not allow external entity expansion Validate all XML inputs and monitor for suspicious references	Fund Transfer Service	Yes	XML parser is properly configured.
Unvalidated Redirects & Forwards	Avoid using redirects/forwards unless essential Validate destination URLs against an allow-list Display clear warnings if redirects are necessary	Java Web App	No	Redirect URLs are not validated against an allow-list.
Denial of Service (DoS)	Implement rate limiting and throttling Use load balancers or CDNs to distribute traffic Monitor for unusual traffic patterns and activate mitigation strategies (e.g., WAF rules)	Application Load Balancer	Partially	AWS Web Application Firewall (WAF) purchase is planned but not deployed yet.
Insufficient Logging & Monitoring	Implement centralized logging (e.g., SIEM) Establish clear alerting and incident response procedures Regularly review and audit logs	Java Web App	No	SIEM solution is configured in a test environment, with production rollout expected next quarter.
		Fund Transfer Service	No	SIEM solution is configured in a test environment, with production rollout expected next quarter.

Threat Template: AWS

Threat	Suggested Controls	Applicable Components	Controls Implemented?	Rationale
IAM Policy Misconfiguration	Adopt least-privilege principles (restrict privileges to what is strictly needed) Use AWS Managed Policies or well-tested custom policies Continuously review IAM roles and policies for unnecessary or high-risk permissions	Java Web App	No	High-privilege policies found for the Java Web App; scheduled to be tightened next sprint.
		Fund Transfer Service	Yes	The IAM policy has been reviewed and approved by the internal security team.
API Gateway Misconfiguration	Require authentication and authorization for all API methods Use WAF or Shield for DDoS protection Enforce rate limiting with usage plans Log and monitor API activity with Amazon CloudWatch or Kinesis	Fund Transfer Service	Yes	Mutual TLS authentication and rate limiting have been implemented, and all API activities are now streamed to CloudWatch.
Exposed AWS Access Keys	Rotate keys frequently and use AWS Secrets Manager or AWS Systems Manager Parameter Store Configure automated scans for key exposure (e.g., Git secrets scanning) Use IAM Roles instead of static keys whenever possible	Java Web App	Partially	Discovered two exposed keys in a deprecated repo; rotation under way. IAM roles are partially implemented.
		Fund Transfer Service	Yes	A thorough review of code repositories found no exposed keys.
Unencrypted Data at Rest	Use AWS KMS-managed or customer-managed keys for EBS, RDS, and S3 encryption Enforce encryption at rest using IAM policies and AWS Config rules Periodically validate that encryption is enabled across all storage resources	Java Web App	Yes	EBS volumes fully encrypted.
		SQL Database	No	The RDS instance is not encrypted.
EC2 Snapshot Exposures	Mark snapshots as private by default and limit who can share them Regularly audit snapshot sharing settings using AWS Config or custom scripts Encrypt EBS volumes and snapshots with AWS KMS	Java Web App	No	Still using manual snapshots; auto-auditing rules will be introduced in the next operational sprint.
Route 53 DNS Misconfiguration or Hijacking	Use Route 53 DNSSEC to protect zone integrity Lock domain registrar accounts and enable MFA Regularly audit DNS changes via CloudTrail and set up alerts for unauthorized modifications	Global	No	DNSSEC is planned but not enabled yet. Registrar accounts are locked with MFA, but DNS change alerts are pending setup.
Insecure Serverless (Lambda) Configuration	Grant least-privilege IAM roles to Lambda functions Store sensitive data in AWS Secrets Manager or Parameter Store instead of environment variables Use VPC connectivity only if needed; restrict outbound traffic where possible	Fund Transfer Service	Yes	Sensitive data is stored in AWS Secrets Manager and IAM policy has been reviewed and approved by the internal security team.
Misconfigured Amazon EKS or ECS Clusters	Restrict cluster access (e.g., API server) to trusted networks Use IAM Roles for Service Accounts in EKS Leverage security groups, network policies, and pod security policies Keep container images updated and scanned	Java Web App	Partially	Kubernetes network policies are partially applied. Plan to enable pod security policies next sprint.
ECR (Elastic Container Registry) Exposed	Set ECR repos to private and use IAM roles for access Scan images for vulnerabilities (AWS ECR image scanning) Restrict cross-account access to ECR repos Use lifecycle policies to remove old or vulnerable images	Java Web App	Yes	ECR is private with strict cross-account rules. Image scanning is automated, lifecycle policy removing images older than 90 days.
EC2 Metadata Exposure	Use Instance Metadata Service v2 (IMDSv2) which requires session-oriented requests Limit access to IMDS from inside the instance via host-based firewalls Enforce strong boundary controls (e.g., WAF, Security Groups)	Java Web App	Partially	IMDSv2 enabled on new EC2 instances. Firewalls will be configured next quarter.
Overly Permissive Security Groups	Implement least-privilege network design (restrict ports/IP ranges) Automate checks using AWS Config rules (e.g., disallow open Security Groups) Use a VPC with subnets and Network ACLs for layered defense	Java Web App	Yes	AWS security groups and VPC segregation are properly configured.
		Fund Transfer Service	Yes	AWS security groups and VPC segregation are properly configured.
		SQL Database	Yes	AWS security groups and VPC segregation are properly configured.
RDS Security Oversights	Disable public access to RDS wherever possible Use security groups to limit inbound connections Enforce encryption at rest and in transit (SSL/TLS) Apply principle of least privilege for database users and roles	SQL Database	Partially	RDS is in a private subnet with SSL enforced. Database roles were locked down last month. The RDS encryption will be enabled next week.
Insecure VPC Configuration	Separate public and private subnets, use NAT Gateways or VPC Endpoints Restrict inbound/outbound traffic with Network ACLs and Security Groups Monitor and audit VPC Flow Logs for suspicious traffic	Java Web App	Yes	VPC Flow Logs are enabled; analyzing data for anomalies. Subnet is properly segmented.
		Fund Transfer Service	Yes	VPC Flow Logs are enabled; analyzing data for anomalies. Subnet is properly segmented.
		SQL Database	Yes	VPC Flow Logs are enabled; analyzing data for anomalies. Subnet is properly segmented.
CloudFormation Template Vulnerabilities	Remove any hard-coded credentials or secrets Use AWS IAM to manage required permissions at the resource level Validate templates with tools like cfn-lint or AWS CloudFormation Guard Keep CloudFormation templates versioned	Java Web App	Partially	cfn-lint integrated into CI/CD. Still finding a few templates with leftover credentials references.
		Fund Transfer Service	Yes	cfn-lint integrated into CI/CD.
CloudFront Misconfiguration	Enforce HTTPS-only viewers and origin connections Use Origin Access Control/Identity (OAC/OAI) to lock down S3 buckets Configure WAF rules to filter malicious traffic	Application Load Balancer	Partially	HTTPS enforced for all viewers. AWS Web Application Firewall (WAF) purchase is planned but not deployed yet.
AWS WAF Misconfiguration	Continuously tune WAF rulesets (e.g., AWS Managed Rules, custom rules) Test thoroughly in a staging environment before production Integrate WAF logs with SIEM solutions to monitor for unusual traffic	Application Load Balancer	Partially	AWS Web Application Firewall (WAF) purchase is planned but not deployed yet. No custom rules or SIEM integration yet. Staging environment scheduled for the next sprint.
KMS Key Policy Loopholes	Define explicit KMS key policies; avoid using wildcard principals (*) Regularly review who can use and administer KMS keys Rotate keys based on compliance requirements and use AWS Config rules to track policy changes	Global	Partially	Some keys use overly broad policies. Key rotation plan proposed; awaiting compliance team’s sign-off.
AWS Secrets Manager Misconfiguration	Enforce automatic rotation of database credentials, API keys, etc. Use strict resource-based policies to limit who can retrieve secrets Monitor AWS Secrets Manager logs (e.g., CloudTrail) to detect suspicious secret accesses	Java Web App	No	The AWS Secrets Manager is not used.
		Fund Transfer Service	Partially	Automatic rotation set for some secrets, but older secrets remain static. Reviewing resource-based policies for tighter access.

Rate and Prioritize Threats

Threat Template: PCI DSS

Threat	Applicable Components	Rationale & Next Steps	Threat Status	Severity
Inadequate Data Encryption	Application Load Balancer	TLS 1.2 is enforced, but removing older ciphers is scheduled for the next maintenance window.	Mitigated	-
	Java Web App	TLS 1.2 is enforced.	Mitigated	-
	Fund Transfer Service	TLS 1.2 is enforced.	Mitigated	-
	SQL Database	TLS 1.2 is enforced, but RDS encryption is not configured.	Open	High
Inadequate Network Security	Application Load Balancer	AWS Web Application Firewall (WAF) purchase is planned but not deployed yet.	Open	Moderate
	Java Web App	AWS security groups and VPC segregation are configured.	Mitigated	-
	Fund Transfer Service	AWS security groups and VPC segregation are configured.	Mitigated	-
	SQL Database	AWS security groups and VPC segregation are configured.	Mitigated	-
Weak Authentication Mechanisms	Java Web App	MFA is live, but new password complexity settings are rolling out next quarter.	Open	Moderate
	Fund Transfer Service	Mutual TLS authentication is implemented.	Mitigated	-
	SQL Database	A company-wide approved authentication solution is implemented.	Mitigated	-
Lack of Segregation of Duties	Java Web App	RBAC has been reviewed and approved by the internal security team.	Mitigated	-
	SQL Database	A single user with lowest privileges is configured in the database.	Mitigated	-
Inadequate Logging and Monitoring	Java Web App	SIEM solution is configured in a test environment, with production rollout expected next quarter.	Open	Moderate
	Fund Transfer Service	SIEM solution is configured in a test environment, with production rollout expected next quarter.	Open	Moderate
	SQL Database	SIEM solution is configured in a test environment, with production rollout expected next quarter.	Open	Moderate
Insufficient Incident Response	Global	No plan for incident response is in place.	Open	High
Lack of Regular Security Assessments	Global	Automated scans and tools are not configured, but a penetration test is scheduled once the functionality is completed.	Accepted	Moderate
Inadequate Change Management	Global	An internal Git repository is in place and pre-approved CI/CD pipelines are used. However, the documentation of the new functionality is lacking.	Accepted	Low
Insecure Backup Practices	SQL Database	A policy revision is underway to incorporate encryption and stricter access controls for backup media.	Open	Moderate

Threat Template: Secure Code Implementation

Threat	Applicable Components	Rationale & Next Steps	Threat Status	Severity
Logic Bugs	Java Web App	The peer code review is scheduled, but has not yet been completed.	Open	High
	Fund Transfer Service	This component has undergone thorough peer review and an independent third-party secure code review.	Mitigated	-
Broken Access Control	Java Web App	Each endpoint has been reviewed and tested for authorization checks.	Mitigated	-
	Fund Transfer Service	A single user with lowest privileges is configured for the lambda service.	Mitigated	-
	SQL Database	A single user with lowest privileges is configured in the database.	Mitigated	-
Insecure Direct Object References (IDOR)	Java Web App	A web filter has been implemented in front of each endpoint to validate object-level authorization.	Mitigated	-
Cryptographic Failures	Java Web App	Only company-wide approved cryptographic libraries are used.	Mitigated	-
	Fund Transfer Service	Only company-wide approved cryptographic libraries are used.	Mitigated	-
Hard-coded Credentials	Java Web App	Database credentials are still stored in configuration files, but there is a plan to switch to environment variables in the next release.	Open	Moderate
	Fund Transfer Service	The AWS SecretsManager service is used.	Mitigated	-
Default or Guessable Passwords	Java Web App	MFA is live, but new password complexity settings are rolling out next quarter.	Open	Moderate
	Fund Transfer Service	Mutual TLS authentication is implemented.	Mitigated	-
	SQL Database	A company-wide approved authentication solution is implemented.	Mitigated	-
OS Command Injection	Java Web App	The component does not involve any operating system interactions.	Accepted	-
	Fund Transfer Service	The component does not involve any operating system interactions.	Accepted	-
SQL Injection	Java Web App	Native queries are widely used.	Open	High
	Fund Transfer Service	Parameterized queries are in place.	Mitigated	-
Cross-Site Scripting (XSS)	Java Web App	CSP is implemented on most pages, and full DAST scans are scheduled after all form changes are completed.	Open	Moderate
Race Conditions / Concurrency Issues	Java Web App	No tests have been conducted for thread-safe methods, and no third-party secure code review has been performed.	Open	High
	Fund Transfer Service	This component has undergone an independent third-party secure code review, with a focus on race condition potential issues.	Mitigated	-
Logging Sensitive Data	Java Web App	No sensitive data is logged.	Mitigated	-
	Fund Transfer Service	No sensitive data is logged.	Mitigated	-
Cross-Site Request Forgery (CSRF)	Java Web App	Anti-CSRF tokens are implemented in each form.	Mitigated	-
XML External Entities (XXE)	Fund Transfer Service	XML parser is properly configured.	Mitigated	-
Unvalidated Redirects & Forwards	Java Web App	Redirect URLs are not validated against an allow-list.	Open	Moderate
Denial of Service (DoS)	Application Load Balancer	AWS Web Application Firewall (WAF) purchase is planned but not deployed yet.	Open	High
Insufficient Logging & Monitoring	Java Web App	SIEM solution is configured in a test environment, with production rollout expected next quarter.	Open	Moderate
	Fund Transfer Service	SIEM solution is configured in a test environment, with production rollout expected next quarter.	Open	Moderate

Threat Template: AWS

Threat	Applicable Components	Rationale & Next Steps	Threat Status	Severity
IAM Policy Misconfiguration	Java Web App	High-privilege policies found for the Java Web App; scheduled to be tightened next sprint.	Open	Moderate
	Fund Transfer Service	The IAM policy has been reviewed and approved by the internal security team.	Mitigated	-
API Gateway Misconfiguration	Fund Transfer Service	Mutual TLS authentication and rate limiting have been implemented, and all API activities are now streamed to CloudWatch.	Mitigated	-
Exposed AWS Access Keys	Java Web App	Discovered two exposed keys in a deprecated repo; rotation under way. IAM roles are partially implemented.	Open	High
	Fund Transfer Service	A thorough review of code repositories found no exposed keys.	Mitigated	-
Unencrypted Data at Rest	Java Web App	EBS volumes fully encrypted.	Mitigated	-
	SQL Database	The RDS instance is not encrypted.	Open	High
EC2 Snapshot Exposures	Java Web App	Still using manual snapshots; auto-auditing rules will be introduced in the next operational sprint.	Open	Moderate
Route 53 DNS Misconfiguration or Hijacking	Global	DNSSEC is planned but not enabled yet. Registrar accounts are locked with MFA, but DNS change alerts are pending setup.	Open	Moderate
Insecure Serverless (Lambda) Configuration	Fund Transfer Service	Sensitive data is stored in AWS Secrets Manager and IAM policy has been reviewed and approved by the internal security team.	Mitigated	-
Misconfigured Amazon EKS or ECS Clusters	Java Web App	Kubernetes network policies are partially applied. Plan to enable pod security policies next sprint.	Open	Low
ECR (Elastic Container Registry) Exposed	Java Web App	ECR is private with strict cross-account rules. Image scanning is automated, lifecycle policy removing images older than 90 days.	Mitigated	-
EC2 Metadata Exposure	Java Web App	IMDSv2 enabled on new EC2 instances. Firewalls will be configured next quarter.	Mitigated	-
Overly Permissive Security Groups	Java Web App	AWS security groups and VPC segregation are properly configured.	Mitigated	-
	Fund Transfer Service	AWS security groups and VPC segregation are properly configured.	Mitigated	-
	SQL Database	AWS security groups and VPC segregation are properly configured.	Mitigated	-
RDS Security Oversights	SQL Database	RDS is in a private subnet with SSL enforced. Database roles were locked down last month. The RDS encryption will be enabled next week.	Open	High
Insecure VPC Configuration	Java Web App	VPC Flow Logs are enabled; analyzing data for anomalies. Subnet is properly segmented.	Mitigated	-
	Fund Transfer Service	VPC Flow Logs are enabled; analyzing data for anomalies. Subnet is properly segmented.	Mitigated	-
	SQL Database	VPC Flow Logs are enabled; analyzing data for anomalies. Subnet is properly segmented.	Mitigated	-
CloudFormation Template Vulnerabilities	Java Web App	cfn-lint integrated into CI/CD. Still finding a few templates with leftover credentials references.	Open	High
	Fund Transfer Service	cfn-lint integrated into CI/CD.	Mitigated	-
CloudFront Misconfiguration	Application Load Balancer	HTTPS enforced for all viewers. AWS Web Application Firewall (WAF) purchase is planned but not deployed yet.	Open	Moderate
AWS WAF Misconfiguration	Application Load Balancer	AWS Web Application Firewall (WAF) purchase is planned but not deployed yet. No custom rules or SIEM integration yet. Staging environment scheduled for the next sprint.	Open	Moderate
KMS Key Policy Loopholes	Global	Some keys use overly broad policies. Key rotation plan proposed; awaiting compliance team’s sign-off.	Open	Moderate
AWS Secrets Manager Misconfiguration	Java Web App	The AWS Secrets Manager is not used.	Open	Moderate
	Fund Transfer Service	Automatic rotation set for some secrets, but older secrets remain static. Reviewing resource-based policies for tighter access.	Accepted	Low

Document Results

Threat Template: PCI DSS

Summary of Findings

• The PCI DSS Threat Template applied to the "Transfer Funds" functionality identified 18 threats, of which:

  • 12 are mitigated.

  • 3 are partially mitigated.

  • 3 are unmitigated.

Severity Report

High Severity:

1. Inadequate Data Encryption (SQL Database)

   • Issue: RDS not encrypted.

   • Mitigation: Enable AWS KMS encryption; enforce with AWS Config.

2. Insufficient Incident Response (Global)

   • Issue: No formal incident response plan.

   • Mitigation: Develop/implement plan; conduct tabletop exercises.

Moderate Severity:

1. Inadequate Network Security (Application Load Balancer)

   • Issue: WAF planned, not deployed.

   • Mitigation: Deploy AWS WAF; configure baseline rules.

2. Weak Authentication Mechanisms (Java Web App)

   • Issue: MFA is live; password complexity pending.

   • Mitigation: Enforce strong password policies.

3. Inadequate Logging & Monitoring (Java Web App)

   • Issue: SIEM in test only.

   • Mitigation: Move SIEM to production; centralize log alerts.

4. Insecure Backup Practices (SQL Database)

   • Issue: Unencrypted backups, incomplete policy.

   • Mitigation: Encrypt backups; finalize revised backup policy.

Threat Template: Secure Code Implementation

Summary of Findings

• The Secure Code Implementation Threat Template applied to the "Transfer Funds" functionality identified 27 threats, of which:

  • 18 are mitigated.

  • 4 are partially mitigated.

  • 5 are unmitigated.

Severity Report

High Severity:

1. Logic Bugs (Java Web App)

   • Issue: Code review not completed.

   • Mitigation: Finish peer review; consider static/dynamic analysis.

2. SQL Injection (Java Web App)

   • Issue: Wide use of native queries.

   • Mitigation: Parameterize queries; validate input.

3. Race Conditions (Java Web App)

   • Issue: No concurrency tests or secure code review.

   • Mitigation: Add thread-safety tests; consider third-party audits.

Moderate Severity:

1. Hardcoded Credentials (Java Web App)

   • Issue: Credentials remain in config files.

   • Mitigation: Migrate to environment variables or Secrets Manager.

2. Default/Guessable Passwords (Java Web App)

   • Issue: MFA live; password rules pending.

   • Mitigation: Enforce password complexity.

3. Cross-Site Scripting (XSS) (Java Web App)

   • Issue: Partial CSP; no final DAST scan.

   • Mitigation: Complete CSP coverage; run DAST scans.

4. Unvalidated Redirects & Forwards (Java Web App)

   • Issue: No allow-list.

   • Mitigation: Validate redirect URLs or domains.

5. Denial of Service (DoS) (Application LB)

   • Issue: WAF not deployed.

   • Mitigation: Deploy AWS WAF or Shield; implement rate limiting.

6. Insufficient Logging & Monitoring (Java Web App)

   • Issue: SIEM not in production.

   • Mitigation: Deploy SIEM fully; monitor logs actively.

Threat Template: AWS

Summary of Findings

• The AWS Threat Template applied to the "Transfer Funds" functionality identified 27 threats, of which:

  • 16 are mitigated.

  • 6 are partially mitigated.

  • 5 are unmitigated.

Severity Report

High Severity:

1. IAM Policy Misconfiguration (Java Web App)

   • Issue: High-privilege policies remain.

   • Mitigation: Adopt least-privilege; remove wildcards.

2. Exposed AWS Access Keys (Java Web App)

   • Issue: Keys found in deprecated repo.

   • Mitigation: Rotate/revoke exposed keys; implement secret scans.

3. Unencrypted Data at Rest (SQL Database)

   • Issue: RDS not encrypted.

   • Mitigation: Enable encryption with AWS KMS.

4. CloudFormation Template Vulnerabilities (Java Web App)

   • Issue: Leftover credentials in templates.

   • Mitigation: Remove hard-coded secrets; consider CloudFormation Guard.

Moderate Severity:

1. EC2 Snapshot Exposures (Java Web App)

   • Issue: Manual snapshots; no auto-audits.

   • Mitigation: Automate snapshots; mark as private by default.

2. Route 53 DNS Misconfiguration (Global)

   • Issue: DNSSEC not enabled; no DNS change alerts.

   • Mitigation: Enable DNSSEC; set up CloudTrail alerts.

3. CloudFront Misconfiguration (ALB)

   • Issue: HTTPS enforced; WAF not deployed.

   • Mitigation: Deploy WAF; lock down origins with OAI.

4. AWS WAF Misconfiguration (ALB)

   • Issue: No custom rules or SIEM integration.

   • Mitigation: Deploy WAF in staging; tune rules; integrate logs.

5. KMS Key Policy Loopholes (Global)

   • Issue: Overly broad policies; rotation plan pending.

   • Mitigation: Remove wildcards; enable regular rotation.

6. AWS Secrets Manager Misconfiguration (Java Web App)

   • Issue: Not using Secrets Manager.

   • Mitigation: Migrate credentials to Secrets Manager; enforce rotation.

Low Severity:

1. Misconfigured Amazon EKS or ECS Clusters (Java Web App)

   • Issue: Partial network policies; no pod security policies.

   • Mitigation: Complete network/pod security policies; scan images regularly.