In order to explain the threat modeling process, we will take a more practical approach of defining, modeling, and measuring the threats of a Web store for a fictitious company named Zion, Inc., that has the following requirements.
Zion, Inc. is in the business of selling and renting Zii game consoles, games, and accessories. Lately, it has been losing market share to online competitors who are providing a better customer experience than Zion’s brick and mortar establishments. Zion, Inc. wants to secure its #1 market leader position for gaming products and services. The company plans to provide a secure, uninterrupted, and enhanced user experience to its existing and prospective customers. Zion, Inc. has contracted your organization to perform a threat modeling exercise for its online strategy. You are summoned to provide assistance and are given the following requirements:
Your request for pertinent documentation yields the following statements and requirements:
We will start threat modeling Zion, Inc.’s Web store by first defining the threat model. This includes identifying the assets and security objectives and creating an overview of the application.
In the definition phase of the threat modeling exercise, the following activities are conducted.
Step 1: Identify Security Objectives and Assets
For Zion, Inc.’s Web store, we start by identifying the security objectives. From the requirements, we can glean the following objectives:
Objective 1 and Objective 4 are both more business objectives than they are security objectives, so while they are noted, we do not really address them as part of the threat model. However, Objective 2 and Objective 3 are directly related to security. To provide a secure service (Objective 2), the Web store must take into account the confidentiality, integrity, and availability of data, ensure that authentication, authorization, and auditing are in place and ensure that sessions, exceptions, and configurations are properly managed. To provide uninterrupted services (Objective 3), the Web store will have high availability requirements defined in the needs statement and SLA, which will be assured through monitoring, load balancing, replication, disaster recovery, and business continuity and recoverable backups.
Although the loss of customer data and downtime can cause detrimental and irrecoverable damage to the brand name of Zion, Inc. for this threat model, we will focus primarily on tangible assets, which include customer data, product data, and the application and database servers.
Step 2: Profile the Application
This helps us identify three human actors of the system: customers, sales agents, and administrators as depicted in Figure B.5. Nonhuman actors (not shown in the figure) can include batch processes that back up data periodically to the third-party DR location.
In the modeling phase of the threat modeling exercise, the following activities are conducted.
Step 3: Decompose the Application
Step 4: Identify Threats and Vulnerabilities
For Zion, Inc.’s threat model, although an attack-tree methodology could have been applied, it was determined that using a categorized threat list would be more comprehensive. The STRIDE threat list was used for this exercise and the results tabulated as shown in Table B.2.
In the measurement phase of the threat modeling exercise, the following activities are conducted.
Step 5: Document the Threats
Threats can be documented diagrammatically or in textual format. Zion, Inc.’s threats are documented diagrammatically as depicted in Figure B.9. An example of textually documenting the SQL injection threat is tabulated in Table B.3.
Step 6: Prioritize the Threats
The three common ways to rank threats are
Both average ranking and P × I ranking methodologies to rank threats were followed and the results tabulated for Zion, Inc.’s. The Delphi ranking exercise was conducted but because of its nonscientific approach to risk, the findings were not deemed useful. Table B.4 shows the threat ranks using the average ranking methodology. Table B.5 shows the risk rank based on P × I ranking methodology.
After the threats are prioritized, your findings and the threat model are submitted to the organization. On the basis of this threat model, appropriate controls are identified for implementation to bring the security risk of Zion, Inc.’s Web store within acceptable thresholds, as defined by the business. (See Table B.6.)
Security Profile Documentation
Security Profile |
Design/Implementation Requirement |
Confidentiality |
Customer information (PII) and credit card information should be protected in processing, transit, and storage. |
Integrity |
Only authorized users should be able to modify product information (pricing, shipping, etc.). Input parameters (search, etc.) should be validated. |
Availability |
Backup to third-party location must be in place to ensure fast recovery. |
Authentication |
Users will need to authenticate to the Web application and Web services will need to authenticate with the database using dedicated identities. |
Authorization |
Users are to be configured into roles such as sales agents and administrators and access must be controlled using RBAC mechanisms. |
Auditing |
User activity on the Web store is to be logged with the date, timestamp, and action taken. |
Management |
Session identifiers must be random to prevent session hijacking and replay attacks. Errors information must be predefined to security policy and be nonverbose. Exceptions need to be trapped and handled explicitly. Configuration information such as connection strings and application settings need to be protected using cryptographic protection and access control mechanisms. |
Threat Identification Using STRIDE Threat List
STRIDE List |
Identified Threats |
Spoofing |
Cookie replay Session hijacking CSRF |
Tampering |
Cross-Site Scripting (XSS) SQL Injection |
Repudiation |
Audit log deletion Insecure backup |
Information disclosure |
Eavesdropping Verbose exception Output caching |
Denial of service |
Web site defacement |
Elevation of privilege |
Logic flaw |
Textual Documentation of a SQL Injection Threat
Threat Description |
Injection of SQL Commands |
Threat targets |
Data access component; backend database. |
Attack techniques |
Attacker appends SQL commands to user name, which is used to form an SQL query. |
Security impact |
Information disclosure; alteration; destruction (drop table, procedures, delete data, etc.); authentication bypass. |
Safeguard controls to implement |
Use a regular expression to validate the user name. Disallow dynamic construction of queries using user supplied input without validation; use parameterized queries. |
Risk |
High |
Average Ranking
Threat |
Average Rank (Dvalue + Rvalue + Evalue + Avalue + DIvalue)/5 |
SQL injection |
2.6 (High) |
XSS |
3.0 (High) |
Cookie replay |
2.0 (Medium) |
Session hijacking |
2.0 (Medium) |
CSRF |
1.4 (Medium) |
Verbose exception |
1.8 (Medium) |
Brute-forcing |
1.8 (Medium) |
Eavesdropping |
2.0 (Medium) |
Insecure backup |
1.4 (Medium) |
Audit log deletion |
1.0 (Low) |
Output caching |
2.8 (High) |
Web site defacement |
2.2 (High) |
Logic flaws |
1.2 (Low) |
P × I Rankinga
Probability of Occurrence (P) |
Business Impact (I) |
Risk |
|
Threat |
(R + E + DI) |
(D + A) |
P × I |
SQL injection |
7 |
6 |
42 |
XSS |
9 |
6 |
54 |
Cookie replay |
6 |
4 |
24 |
Session hijacking |
7 |
3 |
21 |
CSRF |
3 |
4 |
12 |
Verbose exception |
4 |
5 |
20 |
Brute-forcing |
4 |
5 |
20 |
Eavesdropping |
5 |
5 |
25 |
Insecure backup |
5 |
2 |
10 |
Audit log deletion |
3 |
2 |
06 |
Output caching |
8 |
6 |
48 |
Web site defacement |
5 |
6 |
30 |
Logic flaws |
3 |
3 |
06 |
a High, 41 to 60; medium, 21 to 40; low, 0 to 20.
Control Identification
Threat (P × I rank) |
Controls |
XSS (54) |
Encode output; validate request; validate input; disallow script tags; disable active scripting |
Output caching (48) |
Do not cache credentials; complete mediation |
SQL injection (42) |
Use parameterized queries; validate input; do not allow dynamic construction of SQL |
Web site defacement (30) |
Load balancing and DR; disallow URL redirection |
Eavesdropping (25) |
Data encryption; sniffers detection; disallow rogue systems |
Cookie replay (24) |
Cookie-less authentication; encrypt cookies to avoid tampering |
Session hijacking (21) |
Use random and nonsequential session identifiers; abandon sessions explicitly; auto log off/on browser shutdown |
Verbose exception (20) |
Use nonverbose error message; trap, record, and handle errors; fail secure |
Brute-forcing (20) |
Do not allow weak passwords; balance psychological acceptability with strong passwords |
CSRF (12) |
Use unique session token; use referrer origin checks; complete mediation |
Insecure backup (10) |
Data encryption; SSL (transport) or IPSec (network) in-transit protection; ACLs |
Audit log deletion (06) |
Do not allow direct access to the database; implement access triple security model; separation of privilege |
Logic flaws (06) |
Design reviews |
3.144.90.182