Windows Embedded
Developers Interest Group

We Dig .NET...Do you?

Welcome
   
   
 Meeting Notes: Security Analysis and Windows Embedded [mtg #35]
   
   
Author: Paul Yao - Last Update: 9/5/2007 12:47:43 PM

WE-DIG / Seattle – Meeting #35

Meeting Report by Paul Yao

 

Security Analysis and Threat Modeling

A Presentation by Steven Yee,

bSquare Corporation

 

The topic at the August 2007 meeting of WE-DIG/Seattle was security. The speaker who gave the main presentation is someone who currently works at bSquare, which is known as one of the bigger consulting shops for Windows Embedded development. At least, that is how I introduced Steven Yee at the start of the meeting. In fact, my brief introduction did not do justice to his experience and time spent working in the area of software security. Fortunately, Steven was quite happy to fill in the blanks.

 

Steven worked at Microsoft for 3+ years, as a program manager for Windows Live One Care. This Microsoft product watches over a desktop PC for a wide range of threats, from wicked malware to the semi-innocuous threat of you forgetting to back up data. After he described his experience on the Windows Live One Care team, Steven pointed out that good security practices are the same whether you are developing for the desktop or for devices. Since he was speaking at the WE-DIG/Seattle group, however, he used an example of a Windows Mobile phone. [By the way, this is similar to the talk that Steven delivered in May 2007 at the Mobile and Embedded Developers Conference (MEDC) in Las Vegas.]

 

While the media gives a lot of coverage to security failures on desktop and server systems, embedded and mobile devices are not completely immune to threats. By way of example, Steven showed a chart that listed the malware which has been identified on mobile phones. From the first virus that targeted Symbian phones in June 2004 until today, his chart showed a total of 170 different types of malware. Compared to the number of threats on desktop and server systems, this amounted to little more than a rounding error. But we should not grow complacent, because as mobile phones and other embedded devices become more sophisticated, so will the number of attacks against them increase. For example, within a week of its introduction, there was already a malware attack against the Apple iPhone.

 

Just how big an impact has there been from malware? Steven showed us a graph which suggested that the overall cost to business from malware has grown from US$ 500 million in 1995 to US$ 14.2 Billion in 2005. What exactly was covered by such a huge figure? Steven gave a list which included:

  • Recovery – time spent restoring the attacked systems,
  • Productivity – what was lost while such systems were down,
  • Direct Revenue Lost – Steven mentioned that Amazon sells something like US $1 million every hour, and so downtime for amazon.com directly translates into lost revenue (this was simply by way of example; no specific downtime for Amazon was discussed),
  • Tools – Infrastructure and utilities needed to backup, restore, and protect against future attacks,
  • Consultants – Hiring security consultants to help design and implement good security practices, and
  • Loss of customer trust – sometimes referred to as an intangible or “goodwill”, customers who have been burned will probably go look for another vendor – presumably one who is able to operate a more secure computing environment.

===== The Security Analysis Process

Steven described a five-step process for analyzing the possible threats to a system. Ideally, these steps should be undertaken during a project's design phase, when the impact on project costs and schedule are lowest. However, this approach can be retrofitted to a project that is underway or even to an existing system. These steps are integral to the Security Development Lifecycle (SDL), which describes the approach that Microsoft has adopted in developing all of its software. The five steps are as follows:

 

1)      Identify Assets to Protect

2)      Estimate the Value of the Assets

3)      Identify Potential Threats

4)      Evaluate the Likelihood of Threats

5)      Define the Mitigation Plan / Strategies

 

The more you learn about security, the more you realize that nothing is ever perfectly secure. Or, as Steven put it, security is never about protecting everything 100%. Instead, it is about identifying potential threats, weighing the costs of protection, and putting in place measures based on a systematic cost/benefit analysis. While such knowledge might make you feel uncomfortable, having a false sense of security is the greatest problem to worry about. From such a position, it would be easy to justify not doing anything to improve the situation. And yet, compared to inaction, almost any action that attempts to mitigate potential threats will improve the intrinsic security of a system.

 

To help illustrate the use of the security analysis process, Steven walked through the five steps in the context of a Windows Mobile phone. The accompanying table summarizes his comments.

 

Step

Windows Mobile Phone

1) Identify Assets to Protect

  • Cost of the device itself. And while substantial (upwards of US$ 500), the assets that truly need protecting are probably the data on the device, plus whatever network access might be possible using the device.
  • Data. Financial data such as credit card numbers, bank account information, or social security numbers. Some data may be protected by privacy laws (such as HIPAA for medical data), by corporate accountability laws (such as Sarbanes-Oxley).
  • Applications. The ability to run some applications may allow access to the data on the device, or on a corporate network.

2) Estimate the Value of the Assets

Q. Can data that is lost be recovered?

Q. How long does it take to recover the data?

Q. What is the cost to recover the data?

Q. What is the impact of disclosure of data to third parties (which may include your competitors, or bad guys intent on doing illegal activities)?

3) Identify Potential Threats

  • Device Loss. With a mobile phone, device loss is clearly a threat. By one estimate, 100,000 mobile phone were lost in London in the year 2005. In the USA, the FBI loses 3 to 4 laptops every month.
  • Data Disclosure. When a mobile phone is lost, the contents of the phone might be accessible – especially if the phone is not password protected. A device might contain emails, documents, spreadsheets, etc.

4) Evaluate the Likelihood of Threats

As Steven pointed out earlier, nothing is 100% secure. Whether owing to neglect or to malevolent intent, lapses in security do occur. There is no way to protect against every possible lapse. But because resources are limited, it is important to think about the probability of various kinds of threats, and to use such an estimate to help decide the priority by which the various threats need to be addressed.

5) Define Mitigation Strategies

The end result of this analysis will be a set of strategies, rank-ordered by priority, for mitigating each of the threats. Some suggested mitigation strategies include things like:

  • Password – use passwords for mobile phones, laptops, and other systems which contain sensitive data. Enforce a policy of automating password protection, such as with an inactivity timer.
  • Encryption – protect important data using encryption. Secure authentication is needed, of course, since encryption relies on having a method of distinguishing authorized users from unauthorized users.
  • Remote Wipe – allows a signal to be sent to destroy data on lost or stolen device.  

 

===== Mitigation Strategies for Windows Embedded

While most of the talk applied to all kinds of computing devices, Steven commented on some features which are specific to Windows Embedded operating systems. From the standpoint of security, some have argued that Windows-based desktop PCs are an attractive target because of the large installed base - 95% of desktop PCs run some version of Windows. The thinking goes that a virus that affects one Windows PC can potentially affect all Windows PC. And the large number makes them an attractive target to malware creators.

 

Unlike Windows-based desktop PCs, Windows Embedded devices are not homogenous; there is, instead, a high degree of customizability that is possible for all Windows Embedded operating systems. If you buy into the "homogenous means more vulnerable" argument, then by extension "customizable means more secure."

 

In both Windows Embedded CE and in XP Embedded, each platform can be configured with just the set of components which are required for the needs of that platform. A headless industrial controller, for example, does not need the GUI elements that Windows CE provides, and so those components can be omitted. A thin client with no need for local storage can be configured to have no available storage space. These kinds of variations help reduce the risk - but does not completely eliminate - the possibility of having malware targeted at a broad range of embedded platforms.

 

The reality, however, is that threats exist that target mobile and embedded devices. Like on desktop and server PCs, where there is something of value, someone will attempt to gain control of that value. As such, threats against mobile and embedded devices will continue to grow and evolve. Windows Embedded provides mechanisms for locking down devices, including the following:

  • Windows Embedded CE supports (but does not require) a trust model, to allow only trusted modules to run on a platform.
  • Windows XP Embedded has its Enhanced Write Filter (EWF) feature, to allow devices to be deployed with a static, unchangeable operating system image.
  • Network Firewalls – For network-connected devices, Steven suggested that firewalls are a necessity. Both Windows Embedded CE and Windows XP Embedded suppport software firewalls. For the maximum protection, a hardware firewall is also suggested.

===== Summary

Once upon a time, computer security meant simply the physical security of the hardware. Today, physical security is still important, but is insufficient by itself. Physical security must be supplemented by electronic measures – meaning both hardware and software – to more fully protect computing assets. Steven briefly mentioned something called the “Botnet”, to refer to the collection of Internet-connected computers which are “owned”, meaning controlled by someone other than their rightful owners. As long as there are assets of value, there will be someone attempting to harvest and use them. Security is not an optional or extra part of the software development process. Your software - and the hardware it runs on - has value, and it adds value; protecting that value is a necessary and crucial part of how you design, develop, and deploy your systems.

 

 

Other Resources

     Software - Microsoft Threat Analysis & Modeling Tool (click for Download page) 

     Book - Writing Secure Code, by Michael Howard and David LeBlanc

     Book - Threat Modeling, by Frank Swiderski and Window Snyder