# RaD-TM — Rapid Developer-driven Threat Modeling | Contributor | E-Mail | |-----------------|-----------------------------------| | Alan Pestrin | | | Andrea Scaduto | | | Andrea Cardaci | | | Andrew Hainault | | | Grant Ongers | | | Stefano Ciccone | | ## 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
ThreatDescriptionSeverity RatingSuggested Controls
Compromised Azure AD accountAn attacker gains access to an Azure AD user or admin account and controls subscriptions or data.HighEnforce MFA, conditional access, passwordless auth, disable legacy protocols.
Stolen service principal or client secretLeaked or hard-coded client secrets allow unauthorized automation or API access.HighUse managed identities, Key Vault secret rotation, audit App Registrations.
Over-privileged RBAC rolesExcessive permissions on users or service principals increase attack surface.HighImplement least privilege, review RBAC assignments, use PIM for JIT access.
Public Storage Account containersBlob containers set to public allow data leakage.HighDisable public access, use Private Endpoints, monitor anonymous access.
Key Vault public endpoint exposureVault accessible from internet without network restrictions.HighRestrict via Private Endpoint and access policies, enable firewall rules.
Missing patch management on VMsOutdated images expose known vulnerabilities.HighUse Update Management, hardened base images, Defender for Cloud.
NSG overly permissive rulesOpen inbound/outbound traffic allows lateral movement or external exposure.HighRestrict NSG rules, apply least privilege networking, log NSG flows.
Misconfigured Azure Firewall / WAFWeak or absent layer-7 filtering allows attacks through web endpoints.ModerateEnable WAF with OWASP rules, restrict inbound IPs, monitor logs.
Shared admin accountsShared credentials limit accountability and increase compromise risk.ModerateUse individual accounts, enforce PIM, disable shared secrets.
Missing diagnostic / activity logsIncomplete logging delays incident detection.ModerateEnable 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.HighUse Just-in-Time (JIT) VM access, restrict IPs, require VPN.
Misconfigured App Service authWeb apps not enforcing authentication allow data exposure.HighEnable Azure AD or OAuth auth, require HTTPS, disable anonymous access.
Data not encrypted at restStorage or DB without encryption enable data theft.HighUse Azure Storage Service Encryption, TDE for SQL, customer-managed keys.
Weak key rotation policyKeys and secrets not rotated regularly remain vulnerable.ModerateAutomate rotation, use Managed Identities, audit expiry dates.
Insufficient backup protectionBackup storage can be deleted or overwritten by attacker.ModerateEnable soft delete and immutable backups, restrict delete permissions.
Unrestricted outbound internet accessWorkloads can reach arbitrary endpoints, risk of data exfiltration.ModerateUse NSG egress restrictions, proxy/firewall, Defender for Cloud egress alerts.
Lack of tagging / asset inventoryUntracked resources create blind spots for security monitoring.Low-ModerateEnforce tagging policy, use Azure Policy for compliance and inventory.
Resource locks missingCritical resources can be deleted by mistake or attacker.ModerateApply resource locks (CanNotDelete), audit removal attempts.
Misconfigured Azure Policy compliancePolicies not enforced allow non-compliant deployments.ModerateUse initiative assignments, deployIfNotExists rules, monitor compliance.
Insecure API Management configurationAPIs expose sensitive backend endpoints.HighUse OAuth 2.0, validate JWT tokens, enable rate limiting and logging.
### GCP
ThreatDescriptionSeverity RatingSuggested Controls
Leaked service account JSON keyStatic credentials leaked allow full API access.HighAvoid long-lived keys, prefer Workload Identity, rotate and disable unused keys.
Public Cloud Storage bucketBucket misconfigured for public access leaks data.HighDisable public ACLs, enforce uniform bucket-level access, use IAM only.
Over-privileged IAM rolesExcessive permissions allow privilege escalation.HighApply least privilege, audit IAM bindings, use organization-level policies.
Exposed GKE cluster master endpointControl plane open to internet allows exploitation.HighUse private clusters, restrict control plane CIDR, enable authorized networks.
Vulnerable container imagesUnscanned or outdated images enable exploits.Moderate-HighUse Artifact Registry scanning, Binary Authorization, image signing.
Misconfigured firewall rulesBroad ingress/egress in VPC exposes internal resources.HighApply least-privilege rules, audit VPC Firewall Rules Logs.
Weak service account key rotationKeys not rotated or revoked after use.ModerateAutomate rotation, disable manual key creation.
Insufficient Cloud Audit LogsMissing logs prevent detection of unauthorized activity.ModerateEnable all audit logs (ADMIN_READ, DATA_WRITE/READ), export to SIEM.
Missing VPC Service ControlsData exfiltration from sensitive projects via API endpoints.HighDefine VPC-SC perimeters, restrict private connectivity.
Shared projects for dev/prodCross-environment access leads to data leakage.ModerateSeparate projects by environment, use org folders and policies.
Weak organization policy enforcementUnrestricted resource creation leads to compliance gaps.ModerateApply org-policy constraints (e.g., allowed images, regions).
No encryption on persistent disksData at rest exposed if disk copied or stolen.HighEnable CMEK, enforce encryption on all storage.
Unrestricted Cloud Functions endpointsPublic invocations enable abuse or data leakage.Moderate-HighRestrict via IAM, require authentication, validate inputs.
Insecure BigQuery dataset sharingDatasets shared publicly or with broad access.HighRestrict dataset access to groups, audit access lists.
Weak password / OAuth consent misuseUsers authorize malicious OAuth apps.ModerateEnforce OAuth consent screen verification, educate users, limit scopes.
Disabled Cloud KMS key rotationOld encryption keys increase risk of compromise.ModerateAutomate key rotation, monitor key age and use.
Unpatched GCE VMsVulnerable images exploited remotely.HighEnable OS patch management, use VM Manager compliance reports.
Disabled Cloud Armor / WAFPublic web endpoints lack DDoS protection.ModerateDeploy Cloud Armor, use rate limiting, geo-blocking.
Lack of DLP controls for sensitive dataPHI/PII stored in GCS or BQ without DLP checks.ModerateEnable Cloud DLP scans, classify data, enforce alerts.
Ineffective monitoring and alertingSecurity events unmonitored, delays incident response.ModerateEnable Security Command Center, integrate SIEM, define alerting policies.
### HIPAA
ThreatDescriptionSeverity RatingSuggested Controls
Unauthorized access to PHIUsers gain PHI access without legitimate need.HighEnforce RBAC, MFA, least privilege, regular access reviews.
PHI transmitted without encryptionUnencrypted transmission exposes PHI to interception.HighEnforce TLS 1.2+, VPNs for remote connections, disable insecure protocols.
PHI stored without encryptionPHI at rest left unencrypted on disks or backups.HighApply AES-256 encryption, use HSM/KMS, limit key access.
Weak or absent key managementPoor key lifecycle handling enables decryption by attackers.HighEnforce KMS rotation, separation of duties, key usage logging.
Incomplete audit trailsLack of access logs hinders detection of misuse.Moderate-HighEnable detailed auditing, retain per HIPAA retention period, SIEM correlation.
Insider misuse of PHIEmployees intentionally or accidentally leak PHI.HighImplement DLP, least privilege, user behavior analytics, training.
Inadequate BAA coverageThird-party vendors lack Business Associate Agreements.HighExecute BAAs, verify compliance, maintain vendor inventory.
Insufficient breach notification planDelayed or missing notifications after incident.ModerateDefine breach policy, response timelines, stakeholder roles.
Insecure disposal of PHIData remnants on retired media lead to disclosure.ModerateApply secure erasure, degaussing, verified destruction processes.
Backup media unprotectedUnencrypted backups can be lost or stolen.HighEncrypt backups, isolate physically/logically, test restores.
PHI in logs or telemetryLogging inadvertently captures PHI.ModerateRedact sensitive fields, sanitize logs before aggregation.
Over-exposed cloud storageMisconfigured cloud bucket exposes PHI publicly.HighApply strict ACLs, disable public access, continuous monitoring.
Lack of access recertificationAccess rights not periodically reviewed.ModeratePerform quarterly recertifications, auto-remove inactive accounts.
Weak endpoint securityEndpoints storing PHI lack AV or encryption.Moderate-HighDeploy EDR, enforce device encryption, patch management.
No segregation of environmentsMixing test and production PHI data risks leaks.ModerateUse anonymized data in test, enforce environment separation.
Missing DLP email controlsPHI sent via unsecured email channels.Moderate-HighImplement DLP scanning, encrypt outbound emails.
Poor identity lifecycle managementOrphaned accounts retain PHI access.ModerateAutomate provisioning/deprovisioning, sync with HR system.
Weak physical access controlsUnauthorized individuals can access servers storing PHI.HighSecure server rooms, badge systems, CCTV, visitor logs.
Ineffective training & awarenessStaff unaware of HIPAA obligations.ModerateMandatory annual HIPAA/security training, phishing simulations.
No formal risk assessmentOrganization lacks periodic HIPAA risk analysis.ModeratePerform annual risk assessments, track remediation, document results.
### Privacy
ThreatDescriptionSeverity RatingSuggested Controls
Unlawful data collectionData collected without proper consent or legal basis.HighImplement consent management, lawful basis registry, periodic audits.
Excessive data retentionPersonal data kept longer than necessary.ModerateDefine retention schedules, automate deletion, document justification.
Inadequate data minimizationCollecting more personal data than required.ModerateApply data minimization policies, perform DPIA.
Lack of user consent trackingNo record of user consent for processing.HighMaintain consent logs, enable withdrawal mechanisms.
Cross-border data transfer non-complianceData transferred to non-approved countries without safeguards.HighUse SCCs, BCRs, or equivalent legal frameworks.
Insufficient anonymization/pseudonymizationPoor de-identification leads to re-identification risk.Moderate-HighApply irreversible anonymization, monitor re-ID risk.
Unauthorized data sharing with third partiesSharing personal data without data sharing agreement.HighRequire DPAs with vendors, limit purpose, perform due diligence.
Weak access controls on personal dataOverly broad access to user data.HighEnforce least privilege, MFA, regular access review.
Incomplete breach notification processNo timely notification to regulators or users.Moderate-HighDefine breach workflow, retain notification templates, test process.
Insufficient privacy-by-designNew features ignore privacy principles.ModeratePerform DPIAs early in design, embed privacy review in SDLC.
Insecure data deletionDeleted records remain recoverable.ModerateApply secure wipe and verification, validate backups.
Data subject request mishandlingDSRs (access, deletion) not handled correctly.ModerateDefine DSR process, track requests, verify identity.
Inaccurate data recordsStale or incorrect data kept, violating accuracy principle.Low-ModerateImplement correction workflows, periodic data validation.
Missing records of processing activities (ROPA)No central inventory of personal data flows.ModerateMaintain updated ROPA, assign owners, include purposes and retention.
Unencrypted personal dataData at rest or in transit unencrypted.HighEnforce encryption across all data layers.
Poor vendor oversightVendors mishandle data without oversight.ModerateConduct periodic audits, require security assessments.
Lack of DLP monitoringData exfiltration goes undetected.ModerateDeploy DLP on endpoints, email, and cloud storage.
Misconfigured cookie consentCookies dropped before consent given.Low-ModerateImplement compliant consent banners, periodic scanning.
Weak anonymization in analyticsPersonal identifiers persist in analytics data.ModerateTokenize IDs, remove PII before analytics ingestion.
Employee misuse of personal dataInsider misuses access to personal information.Moderate-HighMonitor access, enforce least privilege, provide privacy training.
### Low-Code / No-Code Platforms
ThreatDescriptionSeverity RatingSuggested Controls
Insecure data connectionsConnectors expose sensitive data via weak auth.HighEnforce OAuth, avoid storing credentials, review connectors.
Overly broad sharing of appsApps shared publicly expose internal data.HighLimit sharing to groups, enforce enterprise sharing policy.
Lack of governance over app creationCitizen developers deploy unvetted apps.Moderate-HighEstablish CoE, approval workflow, app cataloging.
Hard-coded secrets in formulasCredentials embedded in app logic.HighUse environment variables, secure vault integrations.
Insecure API callsDirect API calls from client expose backend.ModerateUse backend proxy, restrict keys, enforce HTTPS.
No version control / rollbackLack of versioning leads to undetected malicious updates.ModerateImplement app lifecycle management and version tracking.
Weak access control modelRole-based permissions not enforced properly.Moderate-HighApply RBAC, verify least privilege, disable guest access.
Lack of logging or audit trailNo audit records for app execution or data access.ModerateEnable platform audit logging, export to SIEM.
Unsanctioned integrationsUsers connect apps to unapproved SaaS.ModerateUse allowlist connectors, CASB monitoring.
Data exfiltration via connectorsData sent to personal cloud accounts.HighRestrict connector usage, monitor flows, implement DLP.
Insecure public formsAnonymous submissions used for injection attacks.ModerateValidate inputs, use CAPTCHA, monitor spam.
Shadow IT through personal accountsEmployees use personal tenants for business apps.ModerateDisable personal app publishing, enforce org-managed tenants.
Missing lifecycle managementApps persist after owner leaves.ModerateAssign app ownership policies, periodic orphaned app cleanup.
Unreviewed external componentsReused community components contain vulnerabilities.ModerateMaintain approved component library, perform dependency scans.
Insecure data sourcesApps connected to databases without encryption.HighRequire encrypted connections, managed identities.
No segregation of dev/test/prodSame environment used for all stages.ModerateCreate isolated environments, implement promotion workflow.
Lack of training on security patternsCitizen devs unaware of security implications.ModerateProvide secure development training and guidelines.
Poor backup and recoveryApp configurations lost during outage.Low-ModerateEnable automated backups, document recovery procedures.
Data privacy non-complianceApps collect personal data without consent.ModerateEmbed privacy review, use approved templates.
Disabled audit exportSecurity events not exported to monitoring.Low-ModerateIntegrate with SIEM or central log management.
### STRIDE
ThreatDescriptionSeverity RatingSuggested Controls
Credential spoofingAttacker impersonates user or service using stolen credentials.HighMFA, passwordless auth, detect impossible travel.
API key reuse or theftReused API keys allow impersonation.HighRotate keys, bind to IP/range, enforce OAuth2.
Session hijackingStolen session tokens used for spoofing.HighUse secure cookies, short-lived tokens, token binding.
Data tampering in transitUnencrypted traffic modified by MITM.HighEnforce HTTPS/TLS1.2+, HSTS, integrity checks.
Configuration tamperingAttacker changes system settings or security controls.ModerateImplement configuration baselines, alert on changes.
Malicious code injectionCode or script tampering changes app behavior.HighValidate inputs, code signing, use CI/CD integrity checks.
Log repudiationUser denies action due to missing or tampered logs.ModerateUse tamper-evident logs, immutable storage.
Inadequate audit loggingLogs missing user IDs/time, no accountability.ModerateEnsure detailed audit logs, correlate with identity provider.
Unencrypted sensitive dataData leakage via plain text storage or transmission.HighEncrypt data at rest/in transit, apply key management.
Insecure backup exposureBackup copies stolen or publicly accessible.ModerateEncrypt backups, restrict access, offsite secure storage.
Excessive information disclosureError messages reveal stack traces or secrets.ModerateSanitize errors, disable verbose debug in production.
Denial of Service (DoS) attackResource exhaustion leads to downtime.HighImplement rate limiting, auto-scaling, WAF/CDN.
Application-level DoSLogic flaws allow repeated expensive operations.ModerateOptimize code, limit concurrent sessions, caching.
Flooding or volumetric DDoSNetwork flooding overwhelms services.HighUse DDoS protection service, geo-blocking, throttling.
Privilege escalation via misconfigMisconfigured roles allow privilege gain.HighApply least privilege, review IAM/RBAC roles.
Exploiting unpatched vulnerabilitiesAttackers elevate privileges through old CVEs.HighPatch management, vulnerability scanning.
Insecure dependency injectionVulnerable libraries exploited for EoP.ModerateUse dependency scanning, pin versions.
Weak boundary controlsNetwork segmentation failure enables lateral movement.Moderate-HighEnforce segmentation, zero-trust network.
Missing anti-repudiation measuresLack of digital signatures allows transaction denial.ModerateImplement signing and verification, use tamper-proof logs.
Ineffective monitoring for STRIDE categoriesNo specific detection for spoofing/tampering/disclosure.ModerateMap 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** ![Model diagram](assets/images/diagram.svg) ### 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.