Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


A Practical Approach to Threat Modeling : Page 2

Protecting your systems requires more than just a firewall and a password; you need a documented process.




Application Security Testing: An Integral Part of DevOps

A Threat Modeling Walkthrough
The rest of this article walks you through the threat modeling process for the sample CD Music Library web application, following the five-step process listed in the previous section. Defining Assets
An asset is an item of value, an item security efforts are designed to protect. It is usually the destruction or acquisition of assets that drives malicious intent. Obviously, assets have varying values. A collection of credit card numbers is a high-value asset, while a database that contains candy store inventory is probably a lower-value asset. The higher the asset value, the more effort an adversary will expend to gain access to it; therefore, the more resources it costs to protect.

Consider these factors when evaluating an asset:

  • Confidentiality: If compromised, does the asset present a threat of confidentiality? An example would be a database that contains client tax identification or credit card information. If an adversary were to gain access to this information, the consequences could be devastating—not only for the holders of this data but also for their clients.
  • Integrity: If compromised, does the asset present a threat of integrity? An example would be data that provides information in which the client is billed or even data that provides information in which a company makes strategic decisions.
  • Availability: If compromised, does the asset present a threat of availability? An example would be a database server that contains information in which employees are granted access to specific rooms in a building. If the server was not available to determine that the appropriate employees were allowed into the manufacturing shop, there would be a loss of untold volumes of income.
Applying the asset-definition process to the sample music CD library system resulted in identification of the assets shown in Table 1.

Table 1. Music CD Library Assets: The table shows the reasoning behind the sample system asset identification on three measures.
ID Description Confidentiality Integrity Availability
1.0 Member Data Data contains identification code as well as contact information and address information. Data is used to identify the client within the system as well as grant access to the system. If data were unavailable, the member could not login, view the music CD library, or use any feature of the system.
2.0 Music CD Inventory Data   Data is used to identify the music CDs that are potentially available for lending. If data were unavailable, members could not request a specific music CD.
3.0 Lending Status Data   Data is used to determine whether a music CD is in the warehouse or in the possession of a member. If data were unavailable, the system could not determine the location of a specific music CD.
4.0 Late Fee/Lost CD Payment History Data contains payment method information such as checking account and/or credit card account numbers. Data is used to determine whether a member has a late/lost fee and whether it has been paid. If data were unavailable, payment could not be made.

User Entities
User entities are the entities that legitimately interact with a system. These entities could be actual end users such as a system administrators, data entry users, and anonymous users. In addition, database connections used to interface with other systems are considered to be user entities. Table 2 shows the various entities identified for the sample system. Trust Levels and Boundaries
Trust levels define the minimal access granted to a user entity within a system. For example, a system administrator role may have a trust level that allows them to modify files in a certain directory on a file server, while another user entity may be restricted from modifying files.

Trust boundaries define the location where the trust level changes for a user entity. An example of a trust boundary might be an incoming data validation subsystem. After incoming data has passed validation, the system can elevate its trust level and store it in the database. Table 2 shows the user entities and trust levels for the sample system.

Table 2. Sample Music CD Library System Trust Levels: The threat modeling process identified these user entities and trust levels.
ID Description Use Trust Level
1.0 System Administrator Accesses the system to perform maintenance activities, setting modifications and issue resolution. Full access to all features and settings of the system.
2.0 Library Manager Manages the library inventory, check-in, check-out, and receives payment of late/lost fees. Access to member data, music CD library data, lending status data, and payment history data.
3.0 Member Browses inventory and requests CDs for lending. Also views/maintains personal member data. Read-only access to music CD library data and payment history data. Can modify rights to their specific member data.
4.0 Anonymous User Accesses the system to review membership policies and sign up to become a member. Can only submit a membership request, view membership policy screen, and access member login screen.

Input/Output Points
Input points are points where user entities and data enter a system. Output points are points where user entities and data exit a system. While you may not need to define trust boundaries for all input/output points, defining them during the threat modeling process is beneficial because it defines the scope of the system. All activity that occurs beyond these points may be addressed by a separate threat modeling process.

An example of an input point would be a user entity that gains access to a system's authentication screen through a web browser. The authentication screen is where the system will learn the user entity's identity and grant the appropriate trust levels to the user entity—which by definition is a trust boundary. Note that the security of the web browser itself is beyond the control of the system. An example of an output point would be an export process for a database, such as SQL Server Integration Services. The export may generate a text file containing client data in a directory on the file server for consumption by another system. Because the text file is located outside of the scope of the system being modeled it is considered an output point. Table 3 lists the input/output points identified for the sample system.

Table 3. Input/Output Points: The threat modeling process identified these input/output points for the sample music CD library system.
ID Description Input / Output
1.0 Web browser used to gain access to the features of the application. Input
2.0 System Administrator tools to gain access to the system features. For example: SQL Server Management Studio Input
3.0 Printed list of music CD requests physically pulled from the warehouse. Output
4.0 Printed receipt given to member when music CD is picked up. Output

Identifying the user entities, trust levels, boundaries, and input/output points clearly defines access to and use of the system's assets. Use Case Scenarios
Use case scenarios are often presented as a part of the development process of a system. They depict the context in which the system is to be used and how end users interact with the system. In threat modeling, use cases are valuable for testing vulnerability mitigation as well as identifying possible avenues for system security penetration.

The documentation of the system's input and output point can certainly aid in the development and authoring of use case scenarios. Table 4 lists some use case scenarios for the sample system.

Table 4. Use Case Scenarios: Use case scenarios aid in testing vulnerability mitigation and help identify possible avenues for system security penetration.
ID Description
1.0 An anonymous user accesses the system through a web browser. The user does not have a member id. After reviewing the membership policies, the user accesses the member sign-up screen, populating all required fields and submitting the information. At that point, the user exits the system to obtain a member ID sent by the system to the user-specified e-mail address.
2.0 An anonymous user accesses the system through a web browser. The user, having a member ID, accesses the login screen and enters the member id and password. The login is successful. The user navigates to the music CD library and enters a partial band or artist name in the search textbox and clicks the Submit button. The system finds CDs that contain the entered value in the band or artist's name, and presents those to the user.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.
Thanks for your registration, follow us on our social networks to keep up-to-date