Post a Comment
Feature
Threat modeling is the key to better security
Starting with a detailed data-flow diagram, you can use threat modeling to identify and prioritize potential security holes in embedded-system designs.
By Steven Yee, BSQUARE Corp -- EDN, 12/7/2007
Embedded devices face more threats that ever, ranging from hackers who target your specific businesses to careless users who use easy-to-guess passwords like "1234."
The risks are also higher than ever. Tough legal requirements in the financial and health care sectors can mean prison time and severe fines for failing to protect confidential information. Even in industries without these regulations, a security breach can be devastating.
While no device can ever be 100 percent secure, security can be dramatically improved by carefully analyzing the risks, discovering all potential flaws, and clearly and thoroughly documenting your efforts.
This article describes threat modeling, a process that Microsoft uses to identify threats in its products. The authors of the recent Microsoft book, The Security Development LifeCycle, said that if they could do only one thing to improve security, it would be threat modeling. Here is how to put it to use to improve the security of your embedded device projects.
Threat modeling begins with the data-flow diagram for your system, which illustrates all input and output by your embedded device. It shows when a user enters data, when and how the device displays information and generates report, and where and how information is stored.
It is quite likely that this diagram will be prepared as part of the development effort. If not, it is still worthwhile to prepare a data-flow diagram for your security efforts. That is because every point on the data-flow diagram represents a potential security hole. The data-flow diagram helps you visualize where the threats could be. These diagrams also help testers
For simple systems, you may need just one diagram. For complicated systems, it may be easier to identify threats if you make one overview diagram, and several detailed diagrams for individual features.
No security plan is complete without a list of the assets you need to protect. This list should include the device itself, all the data stored on the device, and all of the data that it is capable of accessing remotely.
Your asset table should include a brief description of each asset, and in the case of the data, the minimum security privilege that should be required to access it.
Your asset list will prove helpful in brainstorming potential security issues with your device, and will help you set your priorities for eliminating those security holes.
Once you have identified your threats, in the threat-modeling process, threats are documented in a tree structure diagram called threat tree. The overall threat is at the base of the tree. The steps hackers can take to exploit that threat or the way that the data can otherwise be exposed are documented as branches from the trunk.
There are two ways of creating threat trees and neither is perfect. There are trade-offs, and the approach you take will largely be decided by the amount of time you have to create the threat trees and the amount of detail you need.
|
One approach is to make the threat trees feature-based. The trunk of every tree is a particular feature of your application. For example, if your device exports data to central database, you would start with that particular feature and add branches for every way that data could be exploited with it.
The advantage of this method is that it is probably the most comprehensive. It forces you to look at every feature under a microscope. The problem is that detail takes a tremendous amount of time to generate, a huge issue when development resources are especially scarce. Many developers who use this model of threat trees document only their most sensitive features.
I prefer to use what is known as a scenario-based, or application-level, approach. Instead of evaluating one particular feature, you examine a particular risk, for example, that your inventory data could be exposed.
This approach causes you to look at the application more through the user's point of view. In addition to creating branches for possible faults in the application, you also add branches to identify ways in which the user could accidentally expose data. For instance, you would likely add a branch looking at the possibility that a hacker could guess the user's password.
The scenario-based approach can help you develop features and other safeguards that you may not have come up with by looking at the code along. This approach also makes it much easier to communicate threats to executives. Improving security costs money, and executives are much more likely to give you the money you need for your security work if they understand exactly what the threats are. It is for that reason that I also make sure that the trunk of each of my threat trees are written from a business-case point of view.
Whichever approach you take in building your threat trees, it is important that you categorize and rate every threat. An effective security plan is based on much research. Unless you set your priorities as you document your threats, you will waste much time evaluating and re-evaluating threats throughout your development cycle.
At first, it may not seem important to categorize, but different threats pose vastly different risks for businesses. If you are building a simple data collection device, you may not care if a hacker is able to elevate his privileges on that one unit. If that device provides remote access to sensitive business information, you would feel otherwise. Labels allow you to spot at a glance the issues that are most important to you.
In threat modeling, threats are classified using a system called STRIDE, which stands for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. Assign the label that best describes the threat.
Spoofing is the ability of an attacker to pose as another user or as a different system. Tampering involves changing data to do harm. Repudiation is the hacker's ability to cover his tracks, making it impossible to prove a crime. Information disclosure simply involves accessing or publishing data that's supposed to be kept private. Denial of service prevents authorized users from accessing the system. Elevation of privilege allows a hacker to assume a much higher trust level – with more privileges.
Following STRIDE, it is also important to quantify the threat. In short, how likely is a hacker to exploit a security hole and how much damage could he do? The DREAD system attempts to answer those questions at a glance.
DREAD stands for Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability. As its name implies, "damage potential" is an indication of the absolute damage that can result from a vulnerability. "Reproducibility" measures how hard it is to duplicate the problem. "Exploitability" considers how hard hackers would have to work to take advantage of the threat. "Affected users" considers what percentage of your users would be affected. "Discoverability" considers the likelihood that hackers or others would discover the vulnerability if it wasn't fixed.
After considering those issues, assign a threat risk rating. Some experts recommend assigning a numeric score between 1 and 10. I have had better success with a more simple rating system consisting of "low", "medium" and "high." These ratings are easy for anyone to understand and you don't waste any time trying to figure out whether something should be rated a 7 or an 8.
While the amount of detail you need to document varies based on your time constraints and needs, you should make sure to document every security threat you have identified – even if the threat poses little or no risk to the device as you currently plan it.
Needs change over time. A device that may be used for data collection in its current version could be expanded to access data from a remote database. Security issues that may not concern you with the current version could become a major risk if not addressed before such an upgrade. You do not necessarily need to fix that threat now, but if you document that it exists, you significantly reduce the risk of overlooking it later.
You should log every security problem into your bug database and assign it for correction. You can always defer work on it, but, again, there is no good reason not to document any security threat.
A thorough security effort is growing more vital for any embedded device project. It requires tremendous attention to detail from everyone on the project team as well as the support of managers and any involved third-parties. But the work of the team is only as good as the quality of the information it has to work with.
You need thorough documentation as to how the device functions, paying close attention to any weak areas. And you need to document every security threat you discover, even if it doesn't seem important today. It may be a critical issue tomorrow. And Threat modeling is a great process to help you address and evaluate all risks.
| Author Information |
 Steven Yee has a B.S. in Computer Science from the University of Washington and is a Software Architect and Engineering Manager in the BSQUARE Professional Engineering Service Group. His team consults extensively with Microsoft Windows Mobile and other Windows Embedded original equipment manufacturers (OEMs) including Palm and Motorola. His technical focus is application development including mobile security, remote management, data synchronization, mobile commerce, managing security for multiple users and user interface design. You can contact Steven at steveny@bsquare.com. |
