Threat Model Name:
Owner:
Reviewer:
Contributors:
Description:
Assumptions:
External Dependencies:
| Not Started | 21 |
| Not Applicable | 0 |
| Needs Investigation | 0 |
| Mitigation Implemented | 18 |
| Total | 39 |
| Total Migrated | 0 |
| Not Started | 21 |
| Not Applicable | 0 |
| Needs Investigation | 0 |
| Mitigation Implemented | 18 |
| Total | 39 |
| Total Migrated | 0 |
| Category: | Elevation Of Privilege |
| Description: | An attacker may pass data into nsg-AppGateway in order to change the flow of program execution within nsg-AppGateway to the attacker's choosing. |
| Justification: | RBAC managed using AAD, user roles defined in deployment documentation. |
| Category: | Elevation Of Privilege |
| Description: | Browser Client may be able to remotely execute code for nsg-AppGateway. |
| Justification: | Client side connection requires SSL. RBAC managed using AAD, user roles defined in deployment documentation. |
| Category: | Elevation Of Privilege |
| Description: | nsg-AppGateway may be able to impersonate the context of Browser Client in order to gain additional privilege. |
| Justification: | RBAC managed using AAD, user roles defined in deployment documentation. |
| Category: | Denial Of Service |
| Description: | An external agent interrupts data flowing across a trust boundary in either direction. |
| Justification: | DDOS prevention provided by Azure services |
| Category: | Denial Of Service |
| Description: | nsg-AppGateway crashes, halts, stops or runs slowly; in all cases violating an availability metric. |
| Justification: | DDOS prevention provided by Azure services |
| Category: | Repudiation |
| Description: | nsg-AppGateway claims that it did not receive data from a source outside the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data. |
| Justification: | ASE and WAF configured to manage requests from the trust boundries. Data by use valid SSL certificate |
| Category: | Spoofing |
| Description: | Browser Client may be spoofed by an attacker and this may lead to unauthorized access to nsg-AppGateway. Consider using a standard authentication mechanism to identify the source process. |
| Justification: | Connection requires valid SSL certificate, RBAC enforced for users |
| Category: | Tampering |
| Description: | If nsg-AppGateway is given access to memory, such as shared memory or pointers, or is given the ability to control what App Services Environment executes (for example, passing back a function pointer.), then nsg-AppGateway can tamper with App Services Environment. Consider if the function could work with less access to memory, such as passing data rather than pointers. Copy in data provided, and then validate it. |
| Justification: | RBAC managed using AAD, user roles defined in deployment documentation. |
| Category: | Tampering |
| Description: | Packets or messages without sequence numbers or timestamps can be captured and replayed in a wide variety of ways. Implement or utilize an existing communication protocol that supports anti-replay techniques (investigate sequence numbers before timers) and strong integrity. |
| Justification: | RBAC managed using AAD, user roles defined in deployment documentation. |
| Category: | Tampering |
| Description: | Attackers who can send a series of packets or messages may be able to overlap data. For example, packet 1 may be 100 bytes starting at offset 0. Packet 2 may be 100 bytes starting at offset 25. Packet 2 will overwrite 75 bytes of packet 1. Ensure you reassemble data before filtering it, and ensure you explicitly handle these sorts of cases. |
| Justification: | RBAC managed using AAD, user roles defined in deployment documentation. |
| Category: | Repudiation |
| Description: | App Services Environment claims that it did not receive data from a source outside the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data. |
| Justification: | ASE and WAF configured to manage requests from the trust boundries. Data by use valid SSL certificate |
| Category: | Information Disclosure |
| Description: | Custom authentication schemes are susceptible to common weaknesses such as weak credential change management, credential equivalence, easily guessable credentials, null credentials, downgrade authentication or a weak credential change management system. Consider the impact and potential mitigations for your custom authentication scheme. |
| Justification: | RBAC managed using AAD, user roles defined in deployment documentation. |
| Category: | Denial Of Service |
| Description: | App Services Environment crashes, halts, stops or runs slowly; in all cases violating an availability metric. |
| Justification: | DDOS prevention provided by Azure services |
| Category: | Denial Of Service |
| Description: | An external agent interrupts data flowing across a trust boundary in either direction. |
| Justification: | DDOS prevention provided by Azure services |
| Category: | Elevation Of Privilege |
| Description: | App Services Environment may be able to impersonate the context of nsg-AppGateway in order to gain additional privilege. |
| Justification: | RBAC managed using AAD, user roles defined in deployment documentation. |
| Category: | Elevation Of Privilege |
| Description: | nsg-AppGateway may be able to remotely execute code for App Services Environment. |
| Justification: | RBAC managed using AAD, user roles defined in deployment documentation. |
| Category: | Elevation Of Privilege |
| Description: | An attacker may pass data into App Services Environment in order to change the flow of program execution within App Services Environment to the attacker's choosing. |
| Justification: | RBAC managed using AAD, user roles defined in deployment documentation. |
| Category: | Denial Of Service |
| Description: | An external agent prevents access to a data store on the other side of the trust boundary. |
| Justification: | <no mitigation provided> |
| Category: | Denial Of Service |
| Description: | An external agent interrupts data flowing across a trust boundary in either direction. |
| Justification: | <no mitigation provided> |
| Category: | Denial Of Service |
| Description: | Does DevOps Engineer or Contoso Database take explicit steps to control resource consumption? Resource consumption attacks can be hard to deal with, and there are times that it makes sense to let the OS do the job. Be careful that your resource requests don't deadlock, and that they do timeout. |
| Justification: | <no mitigation provided> |
| Category: | Information Disclosure |
| Description: | Credentials held at the server are often disclosed or tampered with and credentials stored on the client are often stolen. For server side, consider storing a salted hash of the credentials instead of storing the credentials themselves. If this is not possible due to business requirements, be sure to encrypt the credentials before storage, using an SDL-approved mechanism. For client side, if storing credentials is required, encrypt them and protect the data store in which they're stored |
| Justification: | <no mitigation provided> |
| Category: | Repudiation |
| Description: | Contoso Database claims that it did not write data received from an entity on the other side of the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data. |
| Justification: | <no mitigation provided> |
| Category: | Repudiation |
| Description: | Consider what happens when the audit mechanism comes under attack, including attempts to destroy the logs, or attack log analysis programs. Ensure access to the log is through a reference monitor, which controls read and write separately. Document what filters, if any, readers can rely on, or writers should expect |
| Justification: | <no mitigation provided> |
| Category: | Repudiation |
| Description: | Does the log capture enough data to understand what happened in the past? Do your logs capture enough data to understand an incident after the fact? Is such capture lightweight enough to be left on all the time? Do you have enough data to deal with repudiation claims? Make sure you log sufficient and appropriate data to handle a repudiation claims. You might want to talk to an audit expert as well as a privacy expert about your choice of data. |
| Justification: | <no mitigation provided> |
| Category: | Repudiation |
| Description: | Do you accept logs from unknown or weakly authenticated users or systems? Identify and authenticate the source of the logs before accepting them. |
| Justification: | <no mitigation provided> |
| Category: | Repudiation |
| Description: | If you have trust levels, is anyone other outside of the highest trust level allowed to log? Letting everyone write to your logs can lead to repudiation problems. Only allow trusted code to log. |
| Justification: | <no mitigation provided> |
| Category: | Tampering |
| Description: | Data flowing across HTTPS may be tampered with by an attacker. This may lead to corruption of Contoso Database. Ensure the integrity of the data flow to the data store. |
| Justification: | <no mitigation provided> |
| Category: | Tampering |
| Description: | SQL injection is an attack in which malicious code is inserted into strings that are later passed to an instance of SQL Server for parsing and execution. Any procedure that constructs SQL statements should be reviewed for injection vulnerabilities because SQL Server will execute all syntactically valid queries that it receives. Even parameterized data can be manipulated by a skilled and determined attacker. |
| Justification: | Auditing and Threat Detection (Prevention mode) is enabled on SQL Database |
| Category: | Tampering |
| Description: | Log readers can come under attack via log files. Consider ways to canonicalize data in all logs. Implement a single reader for the logs, if possible, in order to reduce attack surface area. Be sure to understand and document log file elements which come from untrusted sources. |
| Justification: | <no mitigation provided> |
| Category: | Spoofing |
| Description: | Contoso Database may be spoofed by an attacker and this may lead to data being written to the attacker's target instead of Contoso Database. Consider using a standard authentication mechanism to identify the destination data store. |
| Justification: | <no mitigation provided> |
| Category: | Spoofing |
| Description: | DevOps Engineer may be spoofed by an attacker and this may lead to unauthorized access to Contoso Database. Consider using a standard authentication mechanism to identify the source process. |
| Justification: | <no mitigation provided> |
| Category: | Elevation Of Privilege |
| Description: | An attacker may pass data into OMS Instance in order to change the flow of program execution within OMS Instance to the attacker's choosing. |
| Justification: | <no mitigation provided> |
| Category: | Elevation Of Privilege |
| Description: | DevOps Engineer may be able to remotely execute code for OMS Instance. |
| Justification: | <no mitigation provided> |
| Category: | Elevation Of Privilege |
| Description: | OMS Instance may be able to impersonate the context of DevOps Engineer in order to gain additional privilege. |
| Justification: | <no mitigation provided> |
| Category: | Denial Of Service |
| Description: | An external agent interrupts data flowing across a trust boundary in either direction. |
| Justification: | <no mitigation provided> |
| Category: | Denial Of Service |
| Description: | OMS Instance crashes, halts, stops or runs slowly; in all cases violating an availability metric. |
| Justification: | <no mitigation provided> |
| Category: | Repudiation |
| Description: | OMS Instance claims that it did not receive data from a source outside the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data. |
| Justification: | <no mitigation provided> |
| Category: | Tampering |
| Description: | If DevOps Engineer is given access to memory, such as shared memory or pointers, or is given the ability to control what OMS Instance executes (for example, passing back a function pointer.), then DevOps Engineer can tamper with OMS Instance. Consider if the function could work with less access to memory, such as passing data rather than pointers. Copy in data provided, and then validate it. |
| Justification: | <no mitigation provided> |
| Category: | Spoofing |
| Description: | DevOps Engineer may be spoofed by an attacker and this may lead to unauthorized access to OMS Instance. Consider using a standard authentication mechanism to identify the source process. |
| Justification: | <no mitigation provided> |