Appendix B

Threat Modeling—Zion, Inc.

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:

• Customers should be able to search for products and place their orders using the Web store or by calling the sales office.
• Before a customer places an order, a customer account needs to be created.
• Customer must pay with a credit card or debit card.
• Customers must be logged in before they are allowed to personalize their preferences.
• Customers should be able to write reviews of only the products they purchase.
• Sales agents are allowed to give discounts to customers.
• Administrators can modify and delete customer and product information.

Your request for pertinent documentation yields the following statements and requirements:

• The Web store will need to be accessible from the Intranet as well as the Internet.
• The Web store will need to be designed with a distributed architecture for scalability reasons.
• User will need to authenticate to the Web store with the user account credentials, which, in turn, will authenticate to the backend database (deployed internally) via a Web services interface.
• User account information and product information will need to be maintained in a relational database for improved transactional processing.
• Credit card processing will be outsourced to a third-party processor.
• User interactions with the Web store will need to be tracked.
• The database will need to be backed up periodically to a third-party location for disaster recovery (DR) purposes.
• ASP.Net using C# and the backend database can be either Oracle or Microsoft SQL Server.

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: Secure #1 market leader position for gaming products and services.
• Objective 2: Provide secure service to existing and prospective customers.
• Objective 3: Provide uninterrupted service to existing and prospective customers.
• Objective 4: Provide an enhanced user experience to existing and prospective customers.

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

• Identify the physical topology: Zion, Inc.’s Web store will be deployed as an Internet-facing application in the DMZ with access for both internal and external users. Physically, the application will be entirely hosted on an application server hosted in the DMZ, with access to a database server that will be present internally as depicted in Figure B.1.
• Identify the logical topology: Zion, Inc.’s Web store will be logically designed as a distributed client/server application with distinct presentation, business, data, and service tiers as depicted in Figure B.2. Clients will access the application using their Web browsers on their desktops, laptops, and mobile devices.
• Determine components, services, protocols, and ports that need to be defined, developed, and configured for the application: Users will connect to the Web application over port 80 (using http) or over port 443 (using https). The Web application will connect to the SQL server database over port 1433 (using TCP/IP). When the users use a secure transport channel protocol such as https over 443, the SSL certificate is also deemed a component and will need to be protected from spoofing threats. Figure B.3 illustrates the components, services, protocols, and ports for Zion, Inc.’s Web store.
• Identify the identities that will be used in the application: User will authenticate to the Web application using forms authentication (user name and password), which, in turn, will authenticate to the SQL Server 2008 database (deployed internally) via a Web services application using a Web application identity as depicted in Figure B.4.
• Identify human and nonhuman actors of the system: The requirements state that
  • Customers should be able to search for products and place their orders using the Web store or by calling the sales office.
  • Sales agents are allowed to give discounts to customers.
  • Administrators can modify and delete customer and product information.
  • The database will need to backed up periodically to a third-party location for disaster recovery (DR) purposes.

  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.

• Identify data elements: Some of Zion, Inc.’s Web store data elements that need to be modeled for threats of disclosure, alteration, and destruction include customer information (account information, billing address, shipping address, etc.), product information (product data, catalog of items, product pricing, etc.), order information (data of order, bill of materials, shipping date, etc.), and credit card information (credit card number, verification code, expiration month and year, etc.). Because the Web store will be processing credit card information, customer card data information will need to be protected according to the PCI DSS requirements.
• Generate a data access control matrix: The data access control matrix gives insight into the rights and privileges (create, read, update, or delete [CRUD]) that the actors will have on the identified data elements as depicted in Figure B.6. The same should be performed for any service roles in the application.
• Identify the technologies that will be used in building the application:
  • Customer requirements stated that the Web application will need to be in ASP.Net using C#, while there was a choice of database technology between Oracle and Microsoft SQL Server. Figure B.7 depicts the choosing of the Internet Information Server as the Web server to support ASP.Net technology and the choosing of the SQL Server as the backend database. Whether ASP.Net will use the .Net 3.5 or .Net 4.0 framework and if the SQL server will be version 2005 or version 2008 are important determinations to make at this point to leverage security features within these frameworks or products.
• Identify external dependencies: External dependencies include the credit card processor and the third-party backup service provider as depicted in Figure B.8.
• The output of this activity is the architectural makeup of the application.

In the modeling phase of the threat modeling exercise, the following activities are conducted.

Step 3: Decompose the Application

• Identify trust boundaries: A trust boundary is the point at which the trust level or privilege changes. For the Zion, Inc.’s Web store, trust boundaries exist between the external (Internet) and the DMZ and between the DMZ and the internal (Intranet) zones.
• Identify entry points: Entry points are those items that take in user input. Each entry point can be a potential threat source and so each must be explicitly identified and safeguarded. Entry points in a Web application could include any page that takes in user input. Some of the entry points identified in the Zion, Inc.’s Web store include the following:
  • Port 80/443
  • Logon Page
  • User Preferences Page
  • Product Admin Page
• Identify exit points: Exit points are those items that display information from within the system. Exit points also include processes that take data out of the system. Exit points can be the source of information leakage and need to be equally protected. Some of the exit points identified in the Zion, Inc.’s Web store include the following:
  • Product Catalog Page
  • Search Results Page
  • Credit card verification processes
  • Backup processes
• Identify data flows: DFDs and sequence diagrams assist in understanding how the application will accept, process, and handle data as it is marshaled across different trust boundaries. Some of the data flows identified in Zion, Inc.’s Web store include the following:
  • Anonymous user browses product catalog page → Adds to Cart → Creates Account → Submits Order
  • User Logs In → Updates Preferences → User Logs Out
  • Administrator Logs In → Updates Product Information
• Identify privileged code: Code that allows elevation of privilege or the execution of privileged operations is identified. All administrator functions and critical business transactions are identified.
• Document the security profile: This involves identification of the design and implementation mechanisms that impact the security of the application as depicted in Table B.1.

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

1. Delphi ranking
2. Average ranking
3. Probability × Impact (P × I) ranking

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.)