Export (0) Print
Expand All

Security Considerations for Your Image

4/24/2012

Microsoft Corporation

March 2009

This technical article contains information about security considerations for your Windows Embedded Standard image.

Security is a high profile topic in technology today. Many developers may wonder about how secure a Windows Embedded Standard image can be compared to Windows XP Professional, which is a common target for viruses, malicious users, and general malware. Because Windows Embedded Standard uses the Windows XP binaries, but can assemble an image that has some Windows features but not other features, it can be unclear whether Windows Embedded Standard has the same vulnerabilities or not. There are several locations in the embedded run-time image development cycle where security issues can be addressed.

Because Windows Embedded Standard uses the same binaries as Windows XP Professional it can be vulnerable to the same attacks. However, because Windows Embedded Standard can be customized, and different Windows features included or excluded, it potentially can be more secure than Windows XP Professional. If a Windows feature that is the target of common attacks, such as Internet Explorer, is not included in the image then those binaries will not be available for the attacker to manipulate. Generally the smaller the device, the more secure it is. However, depending on its purpose, it is not always possible to create a small image. Sometimes adding features to the device will help in managing security, such as Windows Firewall, Group Policy components, or Enhanced Write Filter.

Another important aspect of planning the security of your device is deciding on a servicing strategy. Consider whether the operating system image or applications will ever be updated, or if only a new image will be deployed to the device in the future. If the device will be updated, determine how these updates will be applied. You may have to include additional components in the image for servicing, for example Device Update Agent (DUA) or the System Center Manager Configuration (ConfigMgr) 2007 Prerequisites macro component. Your servicing strategy must account for what you want to update, for example applying Windows security updates only, or updating both the operating system and the applications that are running on the device.

The functionality and purpose of the device, the environment it has to function in, and security should all be part of the planning process. There are trade-offs between all three. Things to consider include the following:

  • Media
    Some examples are as follows:
    • An image on bootable CD-ROM means that no malicious data can be written to the disk in the field. However, it has limited space and is not intuitive to create.
    • Remote Boot can help with security as the device pulls down a master image at every restart. Therefore, any malicious data will be on the device for only a short time. But the drawback is that remote boot is only unicast, and a central server is required to host the images.
  • Networking
    Some examples are as follows:
    • A device may have to be on a network, but restricting it to a closed network or intranet may help provide security benefits.
    • Consider which network protocols and components to include in the device. For example, consider using IPsec, define which users need Remote Registry Access, or which user groups can use Terminal Services.
  • Usage
    Some examples are as follows:
    • A kiosk that caters to many users, but user data is discarded after each user session.
    • The device needs the administrator to have access to additional features that the user should not have access to.

Some components can be included in an image to improve the security of the overall device. These may include the following:

  • NTFS file system
    This supports encryption on files and folders. NTFS also enables an administrator to set individual user and group permissions on files, folders, and shares. The drawback is that NTFS writes to disk frequently, this may be a factor if the image is run from Compact Flash.
  • User accounts
    You can add multiple user accounts to the configuration and specify which user group each should be part of (administrator, user, or guest). This defines what permissions are applied. Of course, strong passwords should be configured for these user accounts.
  • Autologon
    You can specify that a particular user is automatically logged into the system on start; this applies the restrictions of that user group. Passwords can be set to never expire in this case.
  • User Interface Core
    Settings can be configured in this component to restrict access to OS features on the Start menu. For example, you can decide not to Show Control Panel on Start Menu, Show All Programs on Start Menu, or Show Shut Down on Start Menu. You can select Prohibit access to Control Panel and Prohibit access to Hot keys.
  • Windows Logon (Standard)
    Using Winlogon will apply all the Windows logon security checks (LSASS authentication and so on). Winlogon does have more dependencies and increases footprint size. Many applications and Windows features do require Windows logon to be on the system.
  • Windows Firewall
    By default, the Windows Firewall component is brought into any configuration that includes any kind of networking. The firewall can be configured in Target Designer to open only selected ports or to enable only certain applications to run. This is a powerful way to lock down a device from many common attacks. If you want to configure the firewall only after you deploy the device, then you must include the Windows Firewall Control panel in the configuration, because it is not brought into the configuration by a dependency check. We highly recommend that this component remain in the configuration to provide protection for the networked device. However, if you choose to remove it, in the settings of the Core Networking component, clear the Windows Firewall\Internet Connection Sharing (ISC) check box before you run a dependency check for the first time.
  • Write filters
    The Enhanced Write Filter and File Based Write Filter components give you a way to protect the disk from writes. If these are enabled they will redirect any writes from applications, users, or OS features to an overlay. These writes can be discarded on a restart of the system. In this manner, the integrity of the OS image is not comprised. However, the filters are not a foolproof way of protecting the device. For example, an administrator of the device can decide to commit data in the overlay to the disk. If there is malicious data in the overlay then it will be committed to the disk, compromising the device. If not committed, the same malicious data can be broadcast to other computers on a network for as long as the data is still in the overlay, in other words, until the system is restarted.
  • Group Policy
    In a domain environment the same group policies that secure a Windows XP Professional computer can also be applied to and managed on a Windows Embedded Standard device that contains the Group Policy components.
  • Pagefile
    By default, a page file is not included in a configuration. This is for footprint reasons, but can also be viewed as a security improvement.
  • DEP
    Windows Embedded Standard can exercise Data Execution Prevention (DEP), frequently called No Execute. (DEP) is a processor feature that prevents the execution of code in memory regions that are marked as data storage. Hardware-enforced DEP detects code that is running from these locations and raises an exception when execution occurs. Software-enforced DEP can help prevent malicious code from overrunning a data buffer with code and then executing the code. It is configured in the settings of the HAL component in Target Designer.

Windows Embedded Standard also has the same cryptographic, authentication, and security management features as Windows XP Professional.

It is always possible to further secure the device by using custom components. Some vendors (CA, MacAfee) do offer support for embedded. However, you can also componentize any antivirus application and include it in the configuration. Using write filters together with an antivirus application can be challenging as the antivirus signatures must be updated regularly and these updates committed to the disk. Antivirus or third-party firewall applications can be run on an image after it is deployed, provided all the dependencies for the application are included in the run-time image.

Custom components can be used to apply custom security templates and also custom shells to a device. Custom security templates can be used to control password policies, user permissions, and network security. Administrators can run different shells for different users. This provides an administrator access to more OS features, but restricts the average user to only one or two applications. Usually the line-of-business application is used as the shell, interacting with the Windows OS features behind the scenes.

There may be security tasks that can only be done after the run-time is deployed to the target device. These include the following:

  • Disable services that are not required, with the net command.
  • Disable File and Print sharing if this functionality is not required on the device.
  • Close ports if this was not done in the Windows Firewall component in Target Designer.
  • Enable encryption, and set file permissions and folder permissions.
  • Enable the write filters.
  • Apply the appropriate wireless encryption permissions.

Some best practices to follow when you use the device:

  • Clear the overlay cache, if you are using one of the write filters, before you apply any updates to make sure that no malicious data is committed to disk.
  • Clear the pagefile before shutdown (if there is a pagefile).
  • Update antivirus files regularly. File Based Write Filter enables certain files and folders to be written to disk even when the filter is enabled, by using exception lists. Adding the antivirus signature files to the exception list will make sure that they can be kept up to date.
  • Restart devices that have the write filters enabled, or are deployed using remote boot, if you suspect the network was infected. This clears the RAM cache in the case of the write filter images, and pulls down a clean run-time image from the server in the case of remote boot.
  • Thoroughly test any update before you apply it to production images.

There are some embedded-specific things to consider when planning security for your device. If you use the EEF Minlogon instead of Winlogon, all processes will run as Local System. This means that full access to the system is available to anyone. There is no concept of users on a Minlogon system. Therefore permissions cannot be set for files and folders, and some features may not work correctly, for example Terminal Services.

Windows Embedded Standard images also have no file protection. This means that even system files can be overwritten. There is also no concept of rolling back updates after they are applied. This is because the original file is overwritten and not saved anywhere on the system.

What you have learned

By using the information in this article, you should now have a better understanding of security considerations in Windows Embedded Standard.

For more information, see the technical article, Advanced Security Concepts (Standard 2009), at this Microsoft Web site.

You can also view the video tutorial on Windows XP Embedded with SP2 Security Feature Enhancements at this Microsoft Web site.

Show:
© 2015 Microsoft