Security in Intelligent Systems

As the “attack space” increases with the number of connected intelligent systems, so does the need to design in security precautions from the early stages of design.

By Cheryl Coupe, Editor

International Data Corporation (IDC) has stated that the market for intelligent systems – those that are enabled with high-performance microprocessors, connectivity and high-level operating systems – will grow from 19 percent of all major electronic-system unit shipments in 2010 to more than one-third of all systems by 2015. According to the report, Intelligent Systems: The Next Big Opportunity, the segment of intelligent systems from traditional embedded markets already exceeds the segment based on shipments from PCs, servers and mobile phones combined.

That’s a lot of opportunity for developers of new, intelligent embedded systems. It’s also a lot of opportunity for the bad guys.

Connected, Managed and Secure
Eric O’Brien, director of product management for the McAfee embedded security division, talks about this in terms of the increase in “attack space” as the number of intelligent connected devices grows. McAfee embedded security – along with the Intel Intelligent Systems Group (ISG) with which it’s aligned – has developed a mantra to address this attack space: connected, managed and secure. As devices become more connected, they become addressable in ways that they previously were not. Managing the device includes managing the security and setting policy for a range of protections, including protecting the device, protecting the device user, protecting the device owner and protecting the device traffic. Intel bought McAfee two years ago to support its strategies to address the billions of new Internet-ready devices, including mobile and wireless devices, TVs, cars, medical devices and ATMs – as well as the accompanying surge in cyber threats. Since then, McAfee has adapted and added to its legacy strengths in malware protection to apply its security expertise to machine-to-machine and other intelligent embedded systems.

McAfee embedded security addresses a range of protection models.

For protecting equipment such as medical devices, ATMs and military and aerospace systems, O’Brien explains that a whitelisting or lock-down approach often makes the most sense. For intelligent devices with single or limited functions, whitelisting ensures that the only software allowed is what the manufacturer and the OEM specify, and that those files can only change in a way that is established by owner or manufacturer policy. Tools such as McAfee’s ePolicy Orchestrator (ePO) allow the customer to manage those devices, from discovering connected devices, to ensuring they’re within policy and noting deviations from that policy. For example, banks can manage all of their ATMs, ensure that they’re running the latest locked-down, whitelisted software and stop any deviation outside of established policy. This can help avoid even non-malicious offenses, such as a “helpful” technician attempting to update software outside of his or her purview.

At the user level, the focus is on securing the data and providing access control; this is where McAfee’s legacy brand has a long-standing foothold. For embedded and machine-to-machine (M2M) applications, as well as within the enterprise, users and owners are separate entities with different requirements. This is where compliance and control tools come into play, to make sure devices meet established rules (which may be regulatory or internal) to maintain compliance. Connected devices can be checked to ensure the devices are compliant, are running only permitted software and have updated security software before the device is permitted to access the network.

There are a number of technologies to help protect device traffic, which includes traditional malware protection, firewalls, gateways and intrusion protection systems. Technologies such as McAfee’s Global Threat Intelligence (GTI) provide a real-time assessment of the reputation of any device with an IP address or URL to identify it as bad, good or unknown, which can guide safe-connection rules.

Design in Security from the Beginning
O’Brien emphasizes that security decisions need to be made early in the design cycle, not as an after-thought. Developers need to decide up front if security is an issue in any of the described areas: device, user, owner or traffic. This requires an in-depth understanding of the final application and a question-and-answer process to narrow down the best approach. Does the device need to run multiple applications in an ad hoc fashion? If not, a lock-down approach is worth considering. Are regular software updates required? If so, whitelisting may not be the best solution. Do I need to worry about protecting the data? In some cases it may be enough to lock down the device, while in other cases data is the primary concern. Are there compliance issues? Does device traffic need to be authenticated? How will data be communicated?

Design decisions for security begin at the choice of CPU, through board design, selection of operating system and ultimately what applications need to run. Security considerations for many intelligent systems should be as fundamental to development decisions as cost of goods and power issues. The Intel/McAfee alliance is aimed at driving security more deeply into these early decisions, ultimately leveraging hardware capabilities at the chip level. McAfee and Intel have already joined forces to develop McAfee Deep Defender, which sits between the processor and the OS to help protect system software that resides in physical memory from advanced stealth behaviors used by rootkits and APTs.

While security technologies continue to advance to meet new threats, awareness of the importance of designing for security isn’t moving as fast. According to O’Brien, a recent McAfee survey indicates that the industry by and large is still in the “thinking-about-it” stage. Now that the number of intelligent connected devices outstrips the number of people in the world, O’Brien expects to see security awareness accelerate within the design process, but it may require some pain to occur for that to happen. While there are strict regulations in some industries already – banking and financial services regulations help guide ATM security design, for instance – other industries haven’t yet felt enough pain, either from an industry (public embarrassment or cost) or regulatory perspective. Many of those are still putting their toes in the water from a security design perspective.

A Frost & Sullivan report by senior industry analyst Vikrant Gandhi addresses many of these concerns. In M2M Security – The Need for a Holistic Approach, Gandhi says, “an organization could have extremely strict guidelines for protecting the M2M cloud platforms, but could be let down by the device manufacturers who could themselves be constrained due to specific technical and economical reasons and have ended up setting the bar really low for secure communications.” Gandhi also points to regulatory and industry pressures as positive influences on security. For instance, the financial services industry has strict regulations to mitigate fraud, and healthcare follows legislation such as HIPAA in the U.S. In industrial automation and control, well-publicized incidents such as the Stuxnet worm have brought security issues to the forefront, but other industries may not have hit a tipping point yet.

Part of this may relate to cost. If consumers and OEM customers don’t perceive a high enough value to security, it can be hard for manufacturers to justify the additional design costs. And the concept of value is a shifting target. In McAfee’s survey, a question about how important security was to OEMs and consumers received consistently high responses (important to very important). But responses to a follow-up question regarding their willingness to pay for security shifted from the upper ranges of importance to middle-of-the-road. This is similar to the progression that occurred in PC security, as it moved from a nice-to-have to full-on required and mandated from a C-level function in most organizations. O’Brien sees a similar type of acceleration occurring in M2M security, but greater awareness – and recognition of value – is still needed.



Cheryl Berglund Coupé is editor of EECatalog.com. Her articles have appeared in EE Times, Electronic Business, Microsoft Embedded Review and Windows Developer’s Journal and she has developed presentations for the Embedded Systems Conference and ICSPAT. She has held a variety of production, technical marketing and writing positions within technology companies and agencies in the Northwest.