Securing Mobile and Embedded Devices: Encryption is not Security - Embedded.com

Securing Mobile and Embedded Devices: Encryption is not Security

Ask some developers and device makers about the security of theirmobile and embedded devices and they're likely to tell you about theirencryption strength. Then they will probably stop talking.

Such an approach is seriously lacking. You could have the mostadvanced car alarm in the world, but it would be completely worthlessif you leave the keys in the door. While no system is ever 100 percentsecure, you'll get the best results from a comprehensive securityeffort that addresses all of the factors, including technical limits,hackers, and the behavior of your users.

Encryption is just one tool for addressing security issues. It'simpossible to know what tool is right for the job unless you've done acomprehensive security analysis. Developers working on new products oradding features go through a formal design process with extensivereview by team members before writing any code. A similar process isessential for addressing ” and preventing ” serious security issues inmobile devices.

Step 1: Figure Out What You Needto Protect
The first step in securing a mobile device is figuring out where itneeds to be protected. There's no shortage of threats and the key toany security mitigation effort is to do a comprehensive job at thisstage. You cannot develop an effective mitigation plan without firstknowing what work you need to do.

Detailed data-flow diagrams are essential at this stage. It's quitelikely that data-flow diagrams were created in the design process. Evenif they weren't, it is well worth the effort to have the projectdeveloper create one. You cannot do an effective security analysiswithout one.

Simply put, a data-flow diagram shows how data flows through aninformation system. Among other things, it shows when a user entersdata, when reports are generated, and where data is stored. Yourdiagram should show any time data is entered, imported, exported,saved, generated, or transferred.

For simple systems, you may just need one data-flow diagram. Formore complicated systems, you may find it more useful to create a veryhigh-level diagram to represent the device overall, and severalhighly-detailed diagrams for each subsystem.

Figure1. Conext diagram for a Smartphone management system

The developer with the most intimate knowledge of the device shouldbe the one to prepare the context diagram as every point on it is anarea of potential concern. If you fail to list any data-flow point,your security analysis will be incomplete and you may end up leaving ahuge security hole in your final design. The quality of work at thisstage will largely drive the quality of your mitigation efforts.

Figure 1 above shows asample context diagram for a Smartphone management system. The contextdiagram depicts the external entities that access the Smartphone. (This context diagram is based on a diagramfrom Threat Modeling,by Frank Swiderski and Window Snyder published byMicrosoft Press in 2004 .)Step 2: Identify Threats
Just as a data-flow diagram illustrates how information travels througha system, threat trees illustrate how security can be breached. Anindividual threat tree highlights a security issue, tracing a path fromthe general concern to the actual breach. You should create separatethreat trees for each security issue.

At the base of the threat tree ” which is usually at the top of thediagram ” is the general threat, such as “hacker accesses salesdatabase.” While some security experts say it is okay to do otherwise,in my experience, I have found that the base should always be writtenfrom a business perspective. You should never list a specific technicalproblem as the base threat.

Figure 2 below illustrates asample threat tree for a Smartphone. (Thisthreat tree is based on the example used in the book, Threat Modeling,by Frank Swiderski and Window Snyder published by Microsoft Press in2004. )

Figure2. Threat tree for a Smartphone

Tying the threat to a business issue makes it much easier tocommunicate. If top managers don't understand the threat, it will bemuch harder for you to win funding and other resources you need toaddress it. Also, writing the threat from a business perspective helpsmake sure it gets appropriate attention. If the description at the baseof your threat tree is complicated and/or vague, it can be tough todetermine how much attention that issue really needs. Anybody,regardless of technical background, should be able to understand theroot threat.

From the root threat, add attack paths. These branches and leavesvisually represent how security can be compromised. For example,continuing with the sales database example, you may want to addbranches for accessing the database remotely or through the device. Forthe latter of those two points, you may want to add leaves for”guessing the password” and “finding the data in the cache.”

It's important to document all threats ” even those that may poseonly minimal risk now. Needs change over time. While very little datamay be exposed through a particular security threat today, verysensitive data could be at risk in the future. Additionally, thesethreat trees may be used as the starting point for a security analysisfor a future device or upgrade.

Threat trees, like the data-flow diagrams, are best created by thedeveloper, who has the most insight into how the system'svulnerabilities. The developer's threat trees, however, should bereviewed by the entire development team, including quality assurancespecialists. Get the team to brainstorm threats and ways that hackerscould exploit vulnerabilities. It's impossible for one person to thinkof everything. This team approach will give you much better coveragethan if the developer worked alone.

Step 3: Figure Out What It's Worth
In order to determine what to do about a threat, it's important todocument what exactly that threat is. Different threats impactdifferent businesses in different ways, and it's helpful to categorizeeach threat.

For example, medical providers are subject to HIPAA's strictrequirements that demand protections over patients' records. A securitybreach could result in a $250,000 fine and a 10-year prison term. TheFDIC has stringent requirements for financial services companies.Preventing such data breaches must be a top priority for thosebusinesses. Other businesses may not have that kind of sensitive dataon mobile devices, but would be heavily impacted by anydenial-of-service threat.

The STRIDE system gives you an at-a-glance categorization of eachthreat. STRIDE stands for Spoofing, Tampering, Repudiation (the ability of a hacker to cover his tracks ),Information disclosure, Denial of service, and Elevation of privilege.Show in Table 1  below isan overview of the STRIDE system. STRIDE was firstintroduced in the book Writing SecureCode, Second Edition (Microsoft Press, 2003), by MichaelHowardand David LeBlanc.

The STRIDE system helps you classify the threats, but it doesn'tassociate a value associated with the threats. For example a Denial ofservice attack can have a much higher impact to an e-commerce web sitethen to a standalone handheld device. Classifying the threats makes iteasier for others on the team (e.g.the Marketing Manager or Product Manager ) to review the threats.

Spoofing is the ability of an attacker to pose as another user or asa different system. Tampering involves changing data to do harm.Repudiation is the hacker's ability to cover his tracks, making itimpossible to prove a crime. Information disclosure simply involvesaccessing or publishing data that's supposed to be kept private. Denialof service prevents authorized users from accessing the system.Elevation of privilege allows a hacker to assume a much higher trustlevel ” with more privileges.

You should assign one (or more) of those labels to each threat thatyou have identified. Even if you don't use this system, you should tryto label your threats in some way. It makes it easier to prioritizeyour security efforts and communicate the risks to others on your teamand in the company. This system can also be useful to testers enablingthem to focus their efforts.Step 4: Calculate the Odds
In addition to understanding what the threat is, it's also important toconsider the likelihood that it will be a problem. A flaw may have thepotential for bringing down your network for several hours, but theproblem is almost impossible to reproduce, your security efforts may bespent handling larger risks.

The DREAD rating system is one way for measuring the potential ofany problem. With STRIDE, we categorized the type of damage that couldbe done by a particular threat. With DREAD, we categorize thelikelihood that that damage will occur. The goal is to understand themotivation behind each threat and how difficult it is to break-in.

DREAD stands for Damage potential, Reproducibility, Exploitability,Affected users, and Discoverability. As its name implies, “damagepotential” is an indication of the absolute damage that can result froma vulnerability.

“Reproducibility” measures how hard it is to duplicate the problem.”Exploitability” considers how hard hackers would have to work to takeadvantage of the threat. “Affected users” considers what percentage ofyour users would be affected. “Discoverability” considers thelikelihood that hackers or others would discover the vulnerability ifit wasn't fixed.

With the DREAD rating system, you consider each of those elementsand assign an overall DREAD score. Some experts recommend creating aformula that results in assigning a numeric DREAD ranking. I thinkthat's too complicated.

I've had much more success assigning more general risk rankings,such as low, medium, and high. Surprisingly, these more general ratingsare actually much clearer, making it much easier to communicate withother members of your team and outside parties.

The general ratings also save time and eliminate confusion. It takestime to go back to the documentation to see what a 4 really means. Theminor differences between a 4 and a 5, for example, leaves too muchroom for different interpretations, and doesn't help you understand anybetter that what we're really talking about are medium-grade threats.

Once you have determined your rating, it's helpful to go back toyour threat tree and color code it. You can quickly see, for instance,that a red threat is a high priority item.Step 5: Put Together a Plan
Once you have identified your threats and prioritized them, it's timeto put together a plan to mitigate them. There are several methods ofmitigating threats.

All threats should be entered into Excel or database software. Thereare also tools that help you capture the data. For example, Microsofthas a free Threat Modeling tool that you can download – visitwww.bsquare.com/getthreattoolfor more information. This tool allowsyou to easily sort the threats. Your mitigation plan for each threatshould directly translate into coding work items. Just as a designdocument translates directly into development work, your securitymitigation plan needs to do the same. Your mitigation plan is merely aspecialized design document.

Threats can also be addressed through coding techniques, such aspasswords, local authentication, encryption, secure networking, trustlevels, access controls, digital certificates, in-ROM provisioning,digital rights management, and secure boot loaders.

Sometimes, you may need to integrate other software products orcomponents like anti-virus, firewall, anti-spyware, anti-phishing,intrusion detection and behavior blocking products or virtual privatenetworking and smart card technologies.

Make sure that you create work items for even minor items – itemsthat you may not have time to address. I've had great success enteringthe mitigation plan into a bug database. You should still enter minoritems. You can repeatedly postpone work on them, just as you would aminor bug. By entering it into the database, however, you will not beable to forget about it. That's especially important if the design orfeature set changes and that issue becomes more of a problem in thefuture.

Also, make sure you share your mitigation plan with your qualityassurance engineers. This plan will give them valuable information todesign tests that cover the most important issues.

Conclusion
Mobile security threats are growing – not shrinking – and acomprehensive solution resulting from solid research and implemented byall players is the only effective way to respond. It's impossible tomake any system completely secure, but a comprehensive securityanalysis during the design and development phases of a project allowsyou to direct your efforts where they will have the greatest impact andwill also ensure that you don't overlook major holes.

Steven Yee is a Software Architectand Engineering Manager in the BSQUAREProfessional Engineering Service Group. His team consults extensivelywith Microsoft Windows Mobile and other Windows Embedded OriginalEquipment Manufacturers (OEMs) including companies like Palm andMotorola. Previously, Steven was the Program Manager for Windows LiveOneCare, the first Microsoft Security and PC management product. He wasalso Program Manager for the Windows Security Center in the Windows XPSP2 release. Additionally, he is a Certified Information SystemSecurity Professional and has performed security assessments forvarious banks and accounting firms in the Seattle area. He teaches aclass on security for BSQUARE.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.