Let’s Talk About Securing the Device

By AJ Shipley

AJ Shipley Blog Photo

In my previous blog post, I touched on the key variables influencing how we approach device security.  In this blog post, I’ll focus the discussion on securing the device.  Before I do, I want to touch briefly on what was a key take away for me from last month’s RSA conference in San Francisco.  This year, the focus was more on big data, the collection of data from connected devices, and analysis of that data to identify malicious or unusual activity.  This is absolutely the correct approach to pro-actively and pre-emptively identify security threats, but it is important to remember that if the device that is providing the data is not secure, you cannot trust the data the device is providing, and most importantly, you cannot trust the device to carry out the actions that the data analysis indicates is required.

At a very high level, I approach security, and security decisions, from two different points of view.  You can either secure the network infrastructure, or you can secure the devices that attach to that infrastructure and communicate with each other.  While nobody would argue that great security requires securing both the infrastructure and the devices, there are different considerations that come with both approaches. 

Infrastructure security has a number of tried and true approaches, and a very mature market full of various products, that provide confidentiality, integrity, and assurance of the data that is traversing it.  Products like firewalls and other security gateway devices provide controls on what traffic is allowed to traverse and what is not.  SIEM’s provide identification of suspicious traffic flows and seek to correlate those flows with contextual information.  Traffic shaping, and other quality of service type constructs, ensure the timely delivery and availability of data necessary for good security.

What’s important to point out though, is that there are a whole host of security concerns and potential vulnerabilities that are exposed before a device ever gets close to communicating with another device over the network infrastructure.  Device security, and the protection of the data at rest, in use, and in motion, that originate from the devices, must be addressed with multiple layers of security features on the device.  Those security features must start from the time that power is applied to the device to the time that it is retired from service and ultimately destroyed or disposed of.

Secure devices involve building a chain of trust across the device stack, and anchoring that chain of trust with a root of trust that is immutable, or cannot change.  The following diagram is a an architecture agnostic view of a secure device, and what is important to remember is that regardless of the underlying hardware architecture, or the associated operating system architecture, the point is that a secure device requires multiple layers that extend the trust anchor from the hardware, into the operating system, across the middleware and communication stacks, and into the application space.  And we can’t forget the importance of both a secure development process, and secure development tools that are critical in building a secure device, as well as the need to test for security throughout the development lifecycle and prior to deployment.

Device security image

I’ll conclude by saying that the operating system holds the key to delivering a secure platform.  Whether you want to take advantage of hardware security capabilities such as secure boot, hardware based key-stores, or anti-tamper technologies; or you need operating system security constructs such as access control and least privilege; or as you move up the device stack to include secure middleware, such as host based intrusion prevention systems and firewalls, or secure communication stacks like IPSec, SSL/TLS, or SSH, or application security features including application sandboxing, whitelisting, or verification of signed applications – the list goes on, but in all of these instances, the common denominator  is the need for a robust and reliable operating system. 

In my next post, I’ll dive into some of the more technical aspects of device security…more to come.

For additional information from Wind River, visit us on Facebook.