臺灣 - 標誌 臺灣

請確認您的貨幣選擇:

新臺幣
國際貿易術語:貨交承運人(裝運地點)
關稅、海關手續費和貨物服務稅在交貨時收取。
對於超過 NT$1,400 (TWD) 的訂單免運費
僅接受信用卡支付

美元
國際貿易術語:貨交承運人(裝運地點)
交貨時客戶負責關稅、海關規費和增值稅。
對於超過 $50 (USD) 的訂單免運費
所有支付選項均供選擇

Bench Talk for Design Engineers

Bench Talk

rss

Bench Talk for Design Engineers | The Official Blog of Mouser Electronics


Threat Modeling Your Device Operations Helps Identify Unwanted Exposure Jeff Fellinge

Threat modeling is a disciplined process designed to identify and correct potential product vulnerabilities in the early stages of design. The threat models you create describe how your product components work together with users and enumerate potential threats and countermeasures that mitigate these threats. Ideally, you’ll want to threat model each of your systems early in the design process when changes can be made at a much lower cost than when the product is complete. Threat modeling is an important component of a security development lifecycle (SDL) program and ensures your components, systems, and code are appropriately secure by design. Threat modeling is a critical exercise for both software developers and information technology systems engineers and architects. Even if you did not build the systems that you operate, regularly conducting threat-modeling exercises forces you to think like an attacker and will spark ideas to improve your product security. And of course, be sure to update your existing threat models whenever significant changes to your systems are made.

At its core, threat modeling is the process for documenting the design elements of your system and specifically the threats to those elements as seen from an attacker’s point-of-view. The process involves understanding the components and users of your systems, the boundaries between these components and users, and the attack paths—or threat vectors—likely favored by attackers. This perspective helps you take a risk-based approach to design the right safeguards and countermeasures that mitigate these threats. For example, a threat model will highlight the risks of connecting a sensitive data store adjacent to a public web server and guide the selection of appropriate logical security controls to lower that risk to an acceptable level.

Threat Model Methodologies

Even as the internet began to ramp up in the early ‘90s, researchers and scientists were already thinking about threat modeling. Early models of attack trees and threat trees were developed by enumerating system vulnerabilities and systematically examining all the ways an attacker could compromise a system. As the internet expanded and exploited vulnerabilities became an everyday problem, many companies sought to build better security into the core of their products. For example, Microsoft developed the STRIDE threat model, which became a critical component of their own secure development lifecycle. STRIDE is a systematic process to discover potential threats and recommend mitigations across six potential threat categories:

  • Spoofing
  • Tampering
  • Repudiation
  • Information disclosure
  • Denial of service
  • Elevation of privilege

There are other types of threat model methodologies, and the principles are similar. What is important is the process of asking yourself what could go wrong, and then breaking down these potential threats into categories to help you think about appropriate countermeasures. For example, you might identify the transmission of sensitive data over HTTP to a remote system as a potential information disclosure threat that could be mitigated by encrypting the network traffic.

Data Flow Diagram

An essential element to threat modeling is the data flow diagram (DFD), which includes all the important components of your system and their interaction. This diagram shows all key components and systems—whether they are spread across an on-premise and cloud infrastructure or reside on one server or within a single application. The approach and level-of-detail in your DFD depend on what you are designing. For example, if you are deploying a new video camera on your network, you might not be able to threat model the camera software itself, but you should identify all the surrounding systems that the camera needs to communicate with, what protocols it uses, and who will access it. Be sure to include this information in your DFD. And hopefully, the manufacturer of the camera has also threat modeled the development of their video software as well. For example, their software threat model might identify the internal boundaries, objects, and methods used by the software to isolate sensitive data and communicate with other objects and systems. The DFD should show the objects and their request and responses from other objects as well as clearly delineate boundaries between different groups of objects. For example, you might show the logical boundaries between your front-end web-app systems and more sensitive data stores. Add the users of your systems and specifically the actors—or threat agents—that might abuse your system to your DFD. For example, differentiate a privileged operator from a regularly credentialed employee when modeling authorization processes to your system. Identify potential bad actors in your DFD and show how they might access your system.

With your DFD that identifies the trust boundaries, communications across these boundaries, and who and what will make up these communications, you can then begin to look at the potential threats to your system.

Threat Modeling Tools

If you are new to threat modeling, identifying the right threats can be overwhelming. Fortunately, there are several threat modeling tools available to guide you through this process and help identify what kinds of threats to look for. One free and easy-to-use tool is the Microsoft Threat Modeling Tool. While this tool is targeted towards software developers and architects, it can be extended for basic IT operational models as well. The Microsoft Threat Modeling Tool is especially useful when trying to grasp the fundamentals of threat modeling quickly. Download and install the client, and within minutes you will be creating your first threat model. Follow the steps below to create a threat model using the Microsoft Threat Modeling Tool:

 

  1. Create a DFD using the graphical interface by dragging and dropping various components—such as a database, host, or mobile client—and linking them with dataflow actions.
     
  2. Lasso the objects to create a variety of boundaries. Examples of boundaries include Internet of Things (IoT) device zone, Azure trust boundary, and remote user zone.
     
  3. ​Customize these objects to reflect your own environment. For example, set a data-store object attribute to the specific version of SQL that you use.

 

When you are finished, you can run a report and the tool will use these objects, attributes, and boundaries to generate and show you a preliminary list of threats and suggested mitigations. You will want to validate its assumptions and adjust the threat model to refine it to your environment and specific use cases.

There are many other robust commercial and community threat modeling tools tailored to specific types of operational models. For example, one tool might integrate especially well with agile software development processes, and another might excel at modeling traditional information technology systems, like calling out specific firewalls and intrusion detection systems and their configurations. Some of these tools perform sophisticated attack simulations and are hosted on a collaborative, permission-based web platform that allows you to share threat-modeling data between team members easily.

Conclusion

Threat modeling is a straight forward process of identifying your system, what could go wrong with your system, and how to prevent that. However, there is a lot of nuance to creating a good threat model, and you will want to be sure your own process captures the right data so that you do not miss anything important. The threat modeling tools go a long way to help provide this framework. Remember to take advantage of the many threat modeling resources on the internet to help you design and build a process well-suited to your own environment.



« Back


Jeff Fellinge has over 25 years’ experience in a variety of disciplines ranging from Mechanical Engineering to Information Security. Jeff led information security programs for a large cloud provider to reduce risk and improve security control effectiveness at some of the world’s largest datacenters. He enjoys researching and evaluating technologies that improve business and infrastructure security and also owns and operates a small metal fabrication workshop. 


All Authors

Show More Show More
View Blogs by Date

Archives