Security considerations
Please be sure to review the following on-line content:
Security Considerations for Your Image
Common Criteria Certification: Microsoft Windows Platform Products
Best Practices for Security
Security Considerations for Windows XP Embedded Developers
Updating your devices frequently can be expensive; however, servicing can prevent even more expensive security compromises. This section provides general guidelines on how to reduce the risk of a security compromise.
Assessing your security risk
Some factors to consider when you assess your potential security risk are as follows:
Network environment. Devices that are connected to a network might be vulnerable to network-based attacks, especially if these devices have unrestricted access to the Internet. You help to mitigate this risk by connecting your devices to a corporate network, or—even better—by restricting both incoming and outgoing Internet traffic. For more information about technologies that can help you to mitigate the risk of exposure to network-based attacks, see "Building in Windows Security" and "Securing the Network" later in this document.
Physical environment. Any kind of direct physical access to your devices by a malicious user—a user who intentionally accesses a system with the intent to cause harm to the system or to use it in an unauthorized manner—presents an obvious risk. For more information about technologies that can help you to reduce this risk, see "Securing physical media" later in this document.
Data storage. Because embedded systems run operating systems that have a small footprint, it is best not to store critical data on them. Instead, store critical data on a different computer, a server that is connected to the network, or on embedded devices whose operating systems have a larger footprint. Limit the amount of data that you store on a device running Standard 2009 so that the device works normally and achieves your performance goals.
A number of security-related factors are taken into account during the design of an embedded operating system, including:
Footprint. The larger the footprint of the embedded operating system, the more surface area that is vulnerable to attack. It is recommended that you choose an operating system that has the smallest footprint possible and can still meet your needs. Devices running operating systems that have small footprints also tend to perform faster due to the small size of the media that they use, and the small number of files that they must process, load, and catalog.
Services and features. The more services and features that you enable on a device, the more surface area that is vulnerable to attack. Again, the minimum set of features and functionality that meets your needs is recommended.
Built-in security features. You can use Windows Firewall (formerly called Internet Connection Sharing and Firewall), Winlogon, Group Policy, and Access Control Lists (ACLs) to secure computers running Windows XP and also devices running Standard 2009. In Windows-based systems, an ACL is a list of access control entries that apply to an entire object, a set of the object's properties, or an individual property of an object, and that define the access granted to one or more security principals.
Mitigating your security risks
Ways that you can help mitigate security risks to your devices include the following:
Building small images. Devices with small footprints have less surface area exposed to attack. For more information about building these devices, refer to the Image Footprint Reduction section.
Managing non-essential services. Services are processes that run in the background on Standard 2009. Some services are unnecessary on certain devices and should not be built into the operating system, or should be turned off or disabled. You can also configure services to start either automatically or manually. You can configure a service to start manually, or to be managed by the device itself, if the service must be installed on the device but poses potential security vulnerability. For more information about managing base services in Standard 2009, click on this link: Services.
Using Windows Firewall/Internet Connection Sharing (formerly Internet Connection Sharing and Firewall). Standard 2009 includes Windows Firewall, a feature that can help protect your devices from network-based attacks. For more information about this technology, click on this link: Windows Firewall.
Building in Windows Security
Security features in Standard 2009 can help reduce potential data loss or compromise by either communicating directly with a device, or by communicating with a device over the network. Standard 2009 offers two distinct logon base components, with distinct security models:
The Minlogon component, which is unique to Standard 2009, provides faster boot times and a smaller operating system footprint at the expense of built-in security features. There are no users on a device that use the Minlogon component: Programs run in the Local System context, which provides all users with complete control over the operating system. Security features such as Group Policy settings (for more information on Group Policy, see the Group Policy link below), logon rights, and ACLs are not necessary in this context, because there are no users. For more information about this technology, click on this link:
Introduction to Minlogon
The Windows Logon (Standard) component, also referred to as the Winlogon, component embodies the same standard logon mechanism as used in Windows XP Professional. Devices that use Winlogon are somewhat larger and slower to boot than devices that use Minlogon; however, Winlogon uses the full spectrum of Windows security features. Security features such as Group Policy settings, user logon rights, and ACLs are implemented in this context. For more information about Winlogon, click on this link:
Responsibilities of Winlogon
Here are additional security considerations:
Microsoft Active Directory® directory service. Active Directory provides a centralized, distributed computing infrastructure with built-in security. Devices running Standard 2009 can participate in an Active Directory infrastructure by including the appropriate Active Directory components. For more information about this technology:
Active Directory Domain Services
Group Policy. If your devices run the Winlogon service, you can manage users and security groups by configuring Group Policy settings in Windows XP and Standard 2009. For more information about Group Policy:
About Group Policy
Credential management APIs (Application Programming Interfaces). Windows XP and Standard 2009 provide the APIs that you need to implement custom credentials management applications. You can use these applications to manage user credentials instead of relying on users to type their user names and passwords.
Smart cards. Standard 2009 supports smart cards, including integrated Smart Card security management and Smart Card reader device support. For more information about this technology:
The Smart Card Cryptographic Service Provider Cookbook.
Securing the network
You can use the following technologies in Windows XP and Standard 2009 to help protect your devices from network-based attacks.
Windows Firewall (formerly Internet Connection Sharing and Firewall ). The Windows Firewall is a port-based firewall service that blocks incoming traffic to your device on specific ports. Standard 2009 contains a Windows Firewall component that implements this functionality. For more information about this technology:
Windows Firewall.
Internet Protocol security (IPSec). The IP Security Tools and User Interface component provides IPSec policy management and diagnostic capabilities. The Microsoft Management Console (MMC) snap-in for the IP Security Policies allows you to configure and view both locally based and Active Directory-based IPSec policies. The MMC snap-in for IP Security Monitor displays the details about the active IPSec policy and security state. The ipseccmd commands for IPSec provide an alternative to the console-based management and diagnostic capabilities provided by the IP Security Policies and IP Security Monitor snap-ins. Ipseccmd is a scripting utility that you can use to configure IPSec policies and to display details about the state of the active IPSec policy through the command line. For more information about this technology:
How To: Use IPSec for Filtering Ports and Authentication
Kerberos. The Kerberos protocol defines how client computers communicate with a network authentication service. Client computers get tickets from the Kerberos Key Distribution Center (KDC), and then present these tickets to servers to establish connections with them. Kerberos tickets are the network credentials of client computers. For more information about this technology:
Microsoft Kerberos.
Securing physical media by using Enhanced Write Filter
Protecting the physical storage media of your devices is critical to avoiding data corruption from outside sources and computer viruses. Standard 2009 provides the Enhanced Write Filter (EWF) component to help protect your physical storage media.
EWF helps to protect the contents of a volume on the physical media by redirecting all writes to a different storage location, called an overlay. Used in this context, an overlay is similar to a transparency overlay on an overhead projector. Any change made to the overlay affects the picture as seen in the aggregate, but if the overlay is removed, the underlying picture remains unchanged. EWF can protect one or more bootable and non-bootable disk volumes, including but not limited to hard drives, flash ROMs, and CDs formatted in the El Torito format.
EWF presents a servicing challenge, however. To service the underlying operating system or application that EWF helps to protect, you must first disable EWF. This challenge is reduced by the availability of the EWF API, which provides programmatic control of EWF from inside your own applications. Find more information about EWF here: Chapter 4. Embedded Enabling Features.
Protection from computer viruses
Third party antivirus sources are available:
Windows XP Embedded Security
Runtimes and Antivirus Software
How to Install a Root Certificate into the Local Computer Trusted Root Certification Authorities store on Windows XP Embedded via a Registry Update
Subject author: Jonathan Stephens, Microsoft, Senior Support Escalation Engineer.
Updating certificate stores on Windows XP embedded may be problematic because users or administrators have little control over which components are enabled by a particular vendor. For example, on Windows XP workstations the certificate stores can be updated using the Certificates MMC snap-in which is implemented in certmgr.dll. If, however, the vendor who bundled the components for a particular implementation of Windows XP Embedded neglected to include certmgr.dll in the build the Certificates MMC snap-in will not be available.
This article describes a method whereby a certificate can be added to the Local Computer's Trusted Root Certification Authorities store if the more preferred options are not available. Any root CA certificate trusted by the local computer is also automatically trusted by any user that is logged on to that computer.
Physical Storage Locations
==========================
First, it should be understood that the Trusted Root Certification Authorities store as it appears in the Certificates MMC snap-in is a logical view. This logical view is comprised of various actual physical locations the contents of which are combined and presented to the user as a single list of certificates. The physical locations are:
1. Registry
Root CA certificates located in the Registry store are stored as binary values in the registry in the following location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates
Each root CA certificate is stored in a sub-key whose name matches the SHA1 thumbprint of the certificate. The actual contents of the certificate are stored in a REG_BINARY value called Blob located within that sub-key.
2. Enterprise
Root CA certificates that have been published to Active Directory by the Enterprise Admin are located in the Enterprise Store. These root CA certificates are written into an attribute on the certificationAuthority object for a particular CA. This certificationAuthority object is located in the following container:
CN=Certification Authorities, CN=Public Key Services, CN=Services, CN=Configuration, DC=
Certificates published in the Enterprise store are propagated to workstations and server within the Active Directory forest by Group Policy, and are cached in the following registry location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates\Root\Certificates
Each cached Enterprise root CA certificate is stored in a sub-key whose name matches the SHA1 thumbprint of the certificate. The actual contents of the certificate are stored in a REG_BINARY value called Blob located within that sub-key.
3. Group Policy
Root CA certificates can be published in a Trusted Root Certification Authorities policy and delivered to computers via Group Policy. The Trusted Root Certification Authorities policy can be accessed via the Group Policy Object Editor in the following location:
Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities
When this policy is applied to a computer, the root CA certificates are cached in the registry in the following location:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\Certificates
Each cached Enterprise root CA certificate is stored in a sub-key whose name matches the SHA1 thumbprint of the certificate. The actual contents of the certificate are stored in a REG_BINARY value called Blob located within that sub-key. As with any Group Policy, these certificates will be deleted when the computer is rebooted. If the computer is still in scope of the Group Policy that contains a root CA certificate when it restarts, the root CA certificate will again be cached in the above location.
4. Third-Party
Root CA certificates in the Third-Party store are also stored in the registry. The Third-Party store contains root CA certificates that are distributed via the Root Certificate Update Program. This Program is available for third-parties which meet the criteria to have their root CA certificates distributed with Windows and Internet Explorer. Third-Party root CA certificates are stored in the following registry location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates
Each Third-Party root CA certificate is stored in a sub-key whose name matches the SHA1 thumbprint of the certificate. The actual contents of the certificate are stored in a REG_BINARY value called Blob located within that sub-key.
Updating the Trusted Root Certification Authorities Store
========================================================
As can be seen, each physical store is ultimately backed by a registry location. This fact makes it possible to add a root CA certificate into the Trusted Root Certification Authorities store on a Windows XP Embedded device simply by importing the proper registry key. All versions of Windows XP use the same registry locations to store certificates so a root CA certificate can be exported from the registry on a Windows XP workstation and imported on Windows XP Embedded.
The following steps can be used to identify and export the registry settings that represent a particular root CA certificate from a Windows XP workstation.
On the Windows XP workstation, determine the physical location of the root CA certificate using the Certificates MMC snap-in.
1. Create a Certificates MMC snap-in for the Local Computer.
a. Click Start, and then click Run.
b. In the Open box, type mmc, and then press ENTER.
c. In the empty MMC console window, click on the File menu, and select Add/Remove snap-in.
d. Click Add.
e. In the list of snap-ins, locate Certificates, select it, and click Add.
f. Select "Computer account", and click Next.
g. Select "Local computer" and click Finish.
h. Click Close.
i. Click Ok.
2. Enable the option to view Physical stores.
a. In the tree-view pane, select and highlight "Certificates (Local Computer)."
b. Click on the View menu, and select Options.
c. Select "Physical certificate stores", and click ok.
3. Locate the root CA certificate.
a. In the tree-view pane, expand "Certificates (Local Computer)."
b. Expand "Trusted Root Certification Authorities." You will see the physical stores discussed above.
c. Expand each physical store location. If there are certificates in that location you will find a sub-folder named Certificates.
d. When you select a Certificates folder, the details pane will display the root CA certificates stored in that physical location.
If the required root CA certificate is in the Registry store continue on to step II below. If the required root CA certificate is located in one of the other physical stores you must drag the certificate from that store and drop it into the Registry store. Once the certificate information has been exported to a registry file as described below you can drag and drop the root CA certificate from the registry store to the original location.
II. Determine the SHA1 thumbprint of the required root CA certificate.
1. In the Certificates MMC snap-in double-click on the required root CA certificate.
2. Click on the Details tab.
3. In the Show drop-down box select "Properties Only."
4. In the list of fields locate and select the Thumbprint property.
5. In the text box below the list of fields, the Thumbprint of the root CA certificate will be visible.
For example: 24 5c 97 df 75 14 e7 cf 2d f8 be 72 ae 95 7b 9e 04 74 1e 85
As mentioned above, the name of the sub-key wherein the root CA certificate is stored matches the thumbprint of the certificate as found above (without spaces). In our example the name of the registry sub-key is 245c97df7514e7cf2df8be72ae957b9e04741e85.
III. Locate this entry in the registry, and export it to a Registration File (.REG).
1. Click Start, and then click Run.
2. In the Open box, type regedt32, and then press ENTER.
3. Navigate to the following registry location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\
In our example the registry location is:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\245c97df7514e7cf2df8be72ae957b9e04741e85
4. Select and highlight the sub-key.
5. Click the File menu, and then select Export.
6. Provide a folder location and file name, and click Save.
You now have a registration file that you can import into Windows XP Embedded or another Windows XP workstation.
| 