Many products today are migrating from proprietary development to off-the-shelf operating environments. This is a cheaper and faster way to market thanks to mature development tools and well-packaged and supported OEM toolkits provided by Microsoft and Linux developers. This trend is generally good for both vendors and end-users alike, as products can be on the market in much shorter time with much better quality. Unfortunately, different end-user and vendor issues have begun to manifest themselves as the result of this migration.
The basic problem is that a device built on a widely-distributed operating system will execute code introduced to the system, whether authorized or not. As a result, these devices and the data they contain are vulnerable to exploits of the underlying standard operating system. In addition, embedded devices often are connected to networks within corporate or governmental IT environments. As a result, they are subject to the same control constraints, such as security and compliance regulations, including those mandated by the Federal Information Security Management Act (FISMA) and the Sarbanes-Oxley Act (SOX). The business and regulatory risk to the end-user is just as burdensome as the demand on the manufacturer to initially harden and continually patch the device OS.
For example, a meeting service vendor has to sell a stand-alone meeting server to the government because the vendor's hosted meeting service does not meet the security requirements mandated by FISMA. The only way the government can use this vendor's meeting technology is to buy a server dedicated to the vendor's meeting solution. Even the dedicated server has to adhere to very stringent security criteria, and, because it is based on an open environment, meeting those criteria is very difficult. If it were built on a proprietary environment, this wouldn't be a problem, but then the vendor wouldn't be able to provide the product cost-effectively. To meet the certification requirements, this vendor needs to leverage its standard product into a "black box" upon which only authorized code can run.
Our next vendor offers an ATM built on Windows XP. This networked ATM is subject to the same security and compliance audits as any other part of the bank's infrastructure. To meet security audit requirements, the ATM has to be at a certain patch level. This presents multiple challenges for the ATM vendor, service provider and banking client. The solution is to ship the ATM in a state that is not identifiable as a device based on Windows or Linux. In short, ship a "compliance-ready" black-boxed ATM.
As inexpensive and efficient as it is to build open OS-based devices, when vendors put them into the IT environment, they are subject to another level of security and compliance criteria. With new IT control solutions, manufacturers can leverage the cost-effectiveness and economies of scale of working on open environments and, at the same time, deploy their devices in a manner consistent with a proprietary operating environment, freeing themselves from most control issues.
Our industry is on track to develop all devices on a standard environment. Innovative technology is giving us the ability to turn a wide-open "white" box into an "airtight" black box while leveraging the benefits and avoiding the pitfalls of an open environment. Until now, deploying a device in an open environment meant a loss of control. New IT control solutions promise — and deliver — total control of the runtime environment without compromising development efficiency.
Tweet This
1 
