The Internet and communication charge in the late ’90s was a great rebirth for embedded systems. Many device manufacturers look to add connectivity features to their devices. As we have moved into the 21st century we see that connectivity has increased the need for better security. The recent virus and worm attacks on popular computing platforms are forcing developers to rethink security as they develop their systems. Windows XP has received the most press since it is the most popular OS in the world, but other platforms large and small are just as vulnerable. Many software vendors are taking great pains to ensure software security.
There were three goals that went into Windows XP Service Pack 2 (SP2): (1) security, (2) security and (3) security. For the most part, SP2 is better protected than its predecessors—improved firewall, holes plugged up in Distributed Component Object Model (DCOM) and Remote Procedure Call (RPC), the new addition of Data Execution Prevention and improvements to Internet Explorer. Windows XP Embedded (XPe) is a componentized version of Windows XP Pro. XPe SP2 includes the same upgrades as the desktop counterpart, but XPe developers need to define how security is going to be implemented since they can control the features that are put into an image.
Overall, security is subjective. The more secure a system is the more inflexible the system becomes. For example, there are many ways to gain access to a building, but as security is increased (keys, swipe cards, biometrics, traps in the air ducts, sensors, cameras, etc.) the more inflexible it becomes. The same can be said for software systems. It comes down to how you approach security. Peter Norton’s Complete Guide to Microsoft Windows XP, suggests that you think of security as three ring levels: Local, Network and Internet (Figure 1). Windows XP Embedded has the same security features as Windows XP Pro, thus the same thinking can be applied to Windows XP Embedded.
Implementing security for XP Embedded adds new challenges. XPe developers are typically building a device, which means building a product for a customer. Building devices for customers presents three scenarios (maybe more) that impact the decisions on security. If you’re building a device for a specific customer, it means working with the customer directly and directly implementing their security policies as spelled out by that customer.
On the other hand, you may be building a device for different customers and you may not know what each customer’s security implementation is. Very probably everyone’s security implementation is going to be different. The developer has to be able to configure the XPe image to support different customers. This means addressing such questions as how the device can be set up at the customer site, who performs the setup and who implements the security.
In either case, customers can change their security policies. The XPe device has to be designed so that it can be changed. Again, it is important to determine who makes these changes, how they make these changes, whether there is a shell for administrators that is different from users and what access users may have on the system.
Local – The Simple Stuff
Security starts with the device itself and then moves out. There are some obvious concepts that everyone can implement. These are basic but necessary. And there are other security implementations that are new and a little more involved. The first step is to create a custom shell for users. The shell acts like a first line of defense. And, of course, add a virus protection software solution.
Then you need to limit what the device does. The ability to control what goes into an image is a big advantage for XPe developers. In line with this, you should remove any unnecessary hardware components. For example, if a CF reader slot is not going to be used, the CF driver should be removed from the system. If you need USB support for a multimedia device, but don’t want users saving information to storage devices, remove USB mass storage support.
To protect a drive, use the Enhanced Write Filter (EWF). EWF can prevent rogue programs from corrupting files on the drive. The overlays can keep rogue programs from being part of the protected OS. For a RAM overlay, it takes just a reboot to get rid of a program that finds its way into the system. For Disk overlay, it just takes lowering the overlay level without a commit.
The NT file system is integrated with XP security to help prevent access to files and folders on the system. NTFS offers secure access control lists (ACLs) for your data files. Use the Encrypted File System (EFS) feature for local encryption of data files. And, of course, write secure code to eliminate security holes within your own applications. There are books that discuss the issue of writing secure code and mitigating the risks to the system.
Data Execution Prevention (DEP)
Still at the local ring, firewalls and antivirus solutions prevent malicious programs from being installed on a computer. However, malicious applications can still sneak by and cause system-level damage. Some viruses and other security threats attack by running malicious code in memory locations that only Windows and other programs should be using. This type of threat causes damage by taking over one or more memory locations in use by a program. Then the attack spreads and harms other programs, files and even your e-mail contacts.
Data Execution Prevention (DEP) helps to prevent these types of attacks by going one step further; DEP monitors memory to see if programs are using system memory safely. If a program tries to run code—malicious or not—from a protected location, DEP closes the program and notifies the user of the issue. Think of DEP as the inner most ring to the security system. You can find DEP support in XPe SP2 in the computer (HAL) components.
Every Windows system has a set of security policies. On your desktop, you can access the local security policies using the Local Policies MMC snap-in found under the Administrative Tools in the Control Panel. You can change the local policies to lockdown/secure the XP Pro desktop system. Policies can be set to determine such things as who has drive access, folder access, what services are running, password strength, how old a password can be and network access options.
When you build an image with XPe SP2, there are some loosely defined default security settings. These security settings are defined in Defltwk.inf file. To create custom policies you use an XP Pro desktop and the MMC tool to create a new custom security template file. The template has many policies that can be set. Table 1 describes the different policies.
Once you have created a custom template file, a special SLD and component needs to be created. The component must include the custom template file and a command directive to run secedit.exe to install the custom template during the first boot agent process. When the XPe image is finally configured the custom security policies will be in place.
Network and Internet
The second ring deals with connectivity to the network. The most improved feature in XPe SP2 is the Windows Firewall. The original firewall had limited flexibility. You had to know the ports an application required to allow an application to access the network. With the new firewall, all you have to do is add the name of the application (xyz.exe) or service to the exception list and the application can access the network. You don’t have to know anything about the application ports, but you take a risk that the application could have vulnerabilities. Authorization can be defined in the Windows Firewall component within Target Designer before the image is built or after the image is running (Figure 2).
The Internet is the last of the three security rings. Internet Explorer (IE) is the most notable application that accesses the Internet. Kiosks, set-top boxes and applications wanting to use HTML/XML technologies for a display are going to use web-browser support. There are other applications like Outlook Express and FTP.EXE that access the Internet in some form, but IE gets the highest visibility. There are several Internet security options that can be set to enable or disable pop-ups, imaging and videos, scripting, ActiveX controls and more (Figure 3).
On a desktop system, the settings are stored per user in the registry under HKey_Current_User. One can set up the desktop so everyone has the same settings. With the help of Group Policy editor, the common settings are stored in HKey_Local_Machine. Group Policy editor may or may not be in the XPe image, but with the help of a custom component with these registry resources, you can preset IE security keys so any user will have the same settings.
Security is a continuous topic of discussion because if there is a will there is a way. Taking the three-ring security approach gives you a plan to shape the XPe image to lower the security risk. XP Service Pack 2 took some time to be delivered so the holes that you don’t have control over should be plugged. The new security features in SP2 have greatly enhanced the flexibility so you can implement the necessary security without compromising the functionality of the device.
SJJ Embedded Micro Solutions
San Diego, CA.