Advanced Security Concepts (Standard 2009)

4/24/2012

Microsoft Corporation

November 2009

Summary

Windows Embedded Standard 2009 offers developers a componentized version of the Windows XP operating system. You can choose exactly those components required to complete your design requirements with a reduced footprint. This article presents a technical overview of important security considerations in the componentized environment offered by Windows Embedded Standard 2009.

Introduction

Unique Security and Reliability Benefits

Security Considerations for Baseline Configurations

Embedded Device Threats and Vulnerabilities

Mapping Security Features to Components

Security Review Checklist

Conclusion

Introduction

Windows Embedded Standard 2009 is based on the same binary files as Windows XP Professional. Windows Embedded Standard 2009 enables you to rapidly develop reliable and full-featured connected devices.

The Windows Embedded Standard 2009 component database includes approximately 15,000 components. You can build Windows Embedded Standard 2009 run-time images that range from basic kernel-only configurations with minimal security requirements, to full-featured devices that contain networking, multimedia, security, and other features typically found on a computer with Windows XP Professional installed.

Unique Security and Reliability Benefits

Windows Embedded Standard 2009 inherits all of the security features available in Windows XP Professional. In addition, Windows Embedded Standard 2009 offers the following benefits:

1. Less code — You can omit components that are not required by your product, therefore reducing operating system (OS) complexity and increasing reliability.
2. Less hardware — You can include only the hardware you need in your design to increase reliability. This also translates into a more secure system because there are fewer hardware access points.
3. Total control of access points — You can control the input and output devices exposed to the user, which allows you to specify the devices you want to support. The embedded device can also be configured as a closed system, which means devices can be selectively supported. For example, you can prevent the support of externally accessible devices such as USB devices, mouse, keyboard, game controllers, floppy-disk drive, and networking through careful selection of device-driver components.
4. Single-purpose configuration — You can configure your device to serve a single purpose. You can control which applications run on the device and whether third-party applications can be installed, therefore reducing the possibility of application-compatibility problems or security attacks.
5. Reduced network vulnerability — You can reduce your security vulnerability by selecting only those components you require for your target device. For example, unless it is required for maintenance purposes, you can remove network Telnet functionality, which might otherwise offer an attacker an entry point.
6. Prevent modifications to system data or applications — You can use the Enhanced Write Filter (EWF) or the File-Based Write Filter (FBWF) component to make a read-only storage volume appear to the OS as a read/write device. This is accomplished by redirecting disk-write activity to an alternate, writable storage location, such as system memory, or to a special disk-overlay partition. For example, the El Torito CD-ROM boot component, when used with EWF configured to redirect disk-write activity to system memory, allows you to boot from a read-only CD-ROM.
7. Prevent installation of rogue applications — You can use EWF or FBWF to prevent installation of rogue applications, and prevent other permanent configuration changes. If the design contains no read/write storage device, the design is considered stateless between boots because the system is guaranteed to boot the same way each time. Any changes made to the OS between boots are maintained only in system memory and lost when the system restarts. For example, this technique is used in gaming devices, which are required by law in some states, to retain no information between system boots.
8. Backup and restore benefits — The following two benefits allow you to create a more secure backup and restore environment:
   1. Faster system backup and restore. Backup and restore are typically faster and more reliable because of the reduced storage footprint of your device.
   2. Default restore. When used, the stateless El Torito CD-ROM system automatically causes the system to restore to its original state when the system is rebooted or power cycled. This eliminates special backup and restore procedures and the corresponding security concerns associated with backup and restore.
9. Does not require moving parts — You can make your design more rugged by using storage devices that do not have hard drives, such as Disk-On-Chip, flash devices, and other silicon-based storage devices.
10. Simplified design, test, and validation — A reduced footprint design reduces system testing, allowing you to allocate more time for testing your embedded application.

Security Considerations for Baseline Configurations

You can use Target Designer to build your base design configuration by using one of the following baseline configurations:

1. Kernel-only — The Kernel-only configuration does not support the Microsoft Win32 application programming interface (API) and contains no built-in security features or tools.
2. Minlogon — The Minlogon configuration uses a less robust logon process compared to Winlogon. By default, Minlogon does not include the Local Security Authority Subsystem process (LSASS).
   Make sure that you do not require LSASS user authentication before choosing Minlogon.
   Without LSASS, Minlogon lacks the interactive logon and authentication features that are present in standard Windows XP Professional, and always logs on the user as the SYSTEM user.
   Target Designer can include the LSASS component in your run-time image even though you selected the Minlogon component. This happens if other components have a dependency on LSASS, or if you manually added the LSASS component.
   The LSASS component has a low display visibility setting so you must reduce the visibility level to see it displayed in Target Designer. For more information, see the Windows Embedded Standard 2009 Help documentation.
3. Winlogon — The Winlogon configuration uses the standard Windows logon process that ships with Windows XP Professional.
   In Windows XP Professional, Session Manager (Smss.exe) is the first user-mode process created in the system. Session Manager in turn launches the Windows subsystem process and the standard Windows logon process. The standard Windows logon process requires LSASS.
   LSASS is a user-mode process responsible for the following areas:
   1. The local system security policy, such as which users are allowed to log on to the computer, password policies, privileges granted to users and groups, and the system security auditing settings.
   2. User authentication.
   3. Sending security audit messages to the event log.

Certain components that you add to your design might require the Winlogon baseline configuration, even if you originally specified the kernel-only, or Minlogon, configuration. These components express their requirement as a component dependency on Winlogon, which will result in the Winlogon component being automatically added to your design when you run a Target Designer dependency check.

The following table shows the available design templates and whether they support Minlogon or Winlogon.

When choosing your design template, you should consider the following questions:

1. Who is your target user, and what level of access security is required?
2. If the device contains sensitive data, how is the data being secured or protected from being corrupted or compromised?
3. What security measures are in place with respect to any additional device(s) or user(s) that it communicates with?
4. In what ways could a malicious entity have physical access to the device? Is it adequately secured?

For more information, see the Windows Embedded Standard 2009 Help documentation.

Embedded Device Threats and Vulnerabilities

The book Writing Secure Code, by Michael Howard and David LeBlanc, offers practical information about secure design, secure coding, and testing techniques.

To implement the mitigation techniques in the book, you should map Windows XP security features to components as described in Mapping Security Features to Components.

Using the STRIDE model described in Writing Secure Code, the following table shows the major security threats and the corresponding Windows XP Professional security features that you can use to mitigate risk.

Mapping Security Features to Components

Windows Embedded Standard 2009 supports the same configurable security options as Windows XP Professional. Default security settings are defined in Defltwk.inf. To see how custom security settings can be applied to an embedded device, see Security in the System Design Guide.

The following tables contain information associated with Windows XP security features and how they relate to components. A feature requires a component that owns the key binary file as well as the component's dependencies.

Some of the listed components might not be visible. If that's the case, you will need to reduce the visibility in Target Designer in order to see them.

This section discusses these topics:

Authentication Support

Authorization Support

API Support

Tamper-Resistance and Data-Privacy Features on the Storage Media

Tamper-Resistance and Data-Privacy Features on the network

Wireless Security Support

Internet Connection Security Support

Security Management Support

Authentication Support

Authentication is a process where one user or device proves his or her identity to another principal, a user, or a device. The following table shows how authentication features are mapped to components.

Credential Security Service Provide (CredSSP) — CredSSP is a new Security Service Provider (SSP) that is available in Windows XP SP3 via the Security Service Provider Interface (SSPI). CredSSP enables an application to delegate user credentials from the Client (via Client-side SSP) to the target Server (via Server-side SSP). Windows XP SP3 uses only the Client side SSP implementation currently used by Remote Desktop Protocol (RDP) 6.1 Terminal Services (TS). This implementation can be used by any third-party application willing to use the client-side SSP to interact with applications that are running server-side SSP implementations on Vista or Windows Server 2008.

Note   CredSSP is turned off by default in Windows Embedded Standard 2009.

Authorization Support

Once a principal, a user, or a computer is authenticated the authorization process establishes what that principal is allowed to do. The following table shows how authorization support features are mapped to components.

API Support

You can take advantage of the full-featured security API support built into Windows XP. The following table shows how API support features are mapped to components.

Microsoft Cryptographic Module — Implements and supports the SHA2 hashing algorithms (SHA256, SHA384, and SHA512) in X.509 certificate validation. This has been added to the crypto module rsaenh.dll.

XP SP2 crypto modules Rsaenh.dll, Dssenh.dll, and Fips.sys had been certified according to FIPS 140-1 specifications. The Federal Information Processing Standard (FIPS) 140-1 standard has been replaced by FIPS 140-2, and these modules have been validated and certified according to this standard. For more information, see the Microsoft Kernel Mode Cryptographic Module.

Tamper-Resistance and Data-Privacy Features on the Storage Media

The level of file system security in your embedded run-time configuration is largely established by the file-system components you choose. The following table shows how tamper-resistance and data-privacy features on the storage media are mapped to components.

Tamper-Resistance and Data-Privacy Features on the network

The level of network security in your embedded run-time image is largely established by the network components you choose. The following table shows how tamper-resistance and data-privacy features on the network are mapped to components.

Wireless Security Support

Wireless networking offers a new set of security issues to consider. The following table shows how 802.11 / Wireless security support features are mapped to components.

Internet Connection Security Support

There are many ways you can take advantage of full-featured Internet connection security support. The following table shows how Internet connection security support features are mapped to components.

Security Management Support

In Windows Embedded Standard 2009, you can use the full set of management tools available in Windows XP Professional. The following table shows how security management support features are mapped to components.

For more information, see the Windows Embedded Standard 2009 Help documentation.

Security Review Checklist

You can use the following list to help you address security issues relevant to your Windows Embedded Standard 2009 device and its applications:

1. As you develop the specification and applications for your run-time image, use the security resources noted in this article.
2. Read about the latest Microsoft security and Quick Fix Engineering (QFE) updates at this Microsoft Web site.
3. Read the security information in the Windows Embedded Standard 2009 online Help.
4. Include only those driver components and applications required by your embedded device.
5. Include Windows Security Center and Windows Firewall.
6. Reduce the network port usage in your design. Remove all network interfaces that might serve as a security threat. For example, if they are not required, remove the Telnet and Simple Network Management Protocol (SNMP) components.
7. Ensure there are no other physical hardware interfaces that might serve as an access point for a malicious attack.
8. Consider using NTFS file system (NTFS), which offers secure access control lists (ACLs) for your data files. Use the Encrypted File System (EFS) feature for local encryption of data files. Use WebDAV/Web Folders if you need EFS-protected files to be securely encrypted over a network.
9. Use Internet Connection Firewall (ICF) to protect against unsafe or unauthorized network traffic.
10. Review privileges required by principals.
11. Use Software Restriction Policies. For more information, see Using Software Restriction Policies to Protect Against Unauthorized Software.
12. Read the Internet Explorer hardening document: Internet Explorer Desktop Security Guide.
13. Read the Windows XP Service hardening guide: Services and Service Accounts Security Planning Guide.

Conclusion

What you have learned

By using the components and techniques outlined in this article, you can create reduced-footprint devices that have enhanced security.

For more information about network security, see Writing Secure Code, by Michael Howard and David Leblanc, Microsoft Press, 2002, and Programming Windows Security, by Keith Brown, Addison Wesley Longman, Inc., 2000.

The following Web sites might offer additional security information:

1. For general information about security, see this Microsoft Web site.
2. For information about the Windows Embedded product, see this Microsoft Web site.
3. For information about developer issues, see the MSDN Library.
4. For information about Windows XP, see this Microsoft Web site.
5. For more information about Windows Embedded Standard 2009 security, see Security in the product documentation.

Contributors to this paper include, but are not limited to, the Windows Embedded, Security, and Componentization teams.