Tip

Reassess embedded systems security in light of printer vulnerabilities

As the value of embedded systems grows, so too does awareness of their security threats. Embedded computer systems run everything, from critical infrastructure to manufacturing to scientific equipment and children's toys. Embedded systems also run mundane equipment in enterprises, including temperature sensors, sprinkler remote management systems and printers. The value of these systems has increased as more embedded devices feature computing and automation functions for improved management and performance. With the added value of connectivity has come an added risk: namely, attention from malicious actors targeting embedded systems security.

    Requires Free Membership to View

There may be more threats involving embedded systems than some enterprises realize.

In this tip, we discuss the evolving security threat posed by embedded systems on standard enterprise networks, including some recent printer security vulnerabilities and potential mitigations enterprises can put in place.

Printer vulnerabilities highlight embedded systems threat

The threat targeting embedded device systems has evolved over at least the last 20 years, since network connections were added to a variety of devices. One of the most prevalent embedded systems of the last 20 years is the printer. Adding a network connection to a printer made sharing easier but also created a new attack surface. The issue of printer security has come to the fore in recent years, first with issues affecting HP printers and, more recently, with a US-CERT advisory concerning security vulnerabilities present in Samsung printers. The Samsung warning highlighted a default password that allows an attacker to take over the printer via the Simple Network Management Protocol. SNMP vulnerabilities have been known for a long time, but are still common as the developers of new devices and software learn about security the hard way. HP printers suffered a firmware issue where malware could potentially be set up on the printer because firmware wasn't validated prior to being installed.

There may be more threats involving embedded systems than some enterprises realize. Many printers and other embedded systems store sensitive data or control critical systems; some multifunction printers, for example, store copies of print jobs on the internal hard drives, so a hard drive could be lost or stolen. Embedded systems used for controlling physical access could be compromised to allow someone to gain unauthorized physical access. Some enterprises might not have performed a risk assessment on these systems to manage the potential risk. Enterprises might also be surprised by the number of embedded systems connected to their networks. For a better idea of the scope of the threat, review the cutting edge research being performed at the Intrusion Detection Systems Group at Columbia University, which has assessed the security of many different embedded devices. Researchers John Viega and Hugh Thomson have also provided an overview of the poor state of embedded systems security.

From the editors: More on managing network devices

Considering network documentation automation? Discover the basics

Learn how to create a network endpoint security policy

Enterprises should also be aware of security issues beyond common ones with printers, such as an attacker performing a denial-of-service attack against a Voice over Internet Protocol (VoIP) phone. Tools like Cain and Abel can be used to eavesdrop on a VoIP phone call. Barnaby Jack provided one of the most spectacular embedded device security demos when he hacked an ATM at the Black Hat conference. Shodan even provides a search engine that can be used to scan the Internet for embedded devices.

Securing embedded devices

Enterprises can utilize some fairly common network security techniques to defend embedded devices, but this will not provide complete security. The Higher Education Information Security Council has a Copier and MFP Security guide, which covers steps that can be used to secure printers, along with links to further resources. An enterprise should first identify all of the embedded devices on its network. This can be achieved via network-wide vulnerability scans, where the vulnerability scanner tries to identify the operating systems on devices, identify telltale open ports on the embedded devices and pull banners from the open ports. Adding up all of these clues will help an enterprise identify its embedded devices. Once identified, the devices can be placed on private networks and access to the network can be restricted. Some enterprises might try to place these devices on air-gapped networks, but, as Stuxnet and similar targeted attacks demonstrated, not connecting to the Internet will not solve all information security problems.

There are few defense measures unique to embedded systems, mainly because most controls need to be applied at the network layer, since they are not included in the embedded systems themselves. Putting additional mitigations in place to defend against any exploit may be difficult, because manufacturers typically limit the types of changes customers can make to, or the control they have over, a device. If there are security options for a device, enterprises should include those in their standard configurations and review any security implementation guidance from the vendor. To provide the needed security functionality, vendors must catch up with security best practices in the software development realm to avoid vulnerabilities that were patched long ago in other network devices and software.

Conclusion

Along with the attention SCADA and ICS systems have received in the last year, embedded device security will prove to be a hot topic for research in the security community and a potential source of malicious activity for enterprises. The risk enterprises face from embedded devices will continue to increase as more systems are connected to networks. To manage the risk, enterprises should include embedded devices in their security planning and risk assessments.

About the author
Nick Lewis (CISSP) is an information security architect at Saint Louis University. Nick received his Master of Science in information assurance from Norwich University in 2005, and in telecommunications from Michigan State University in 2002. Prior to joining Saint Louis University in 2011, Nick previously worked at the University of Michigan and at Children's Hospital Boston, the primary pediatric teaching hospital of Harvard Medical.

This was first published in February 2013

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.