Cyberattacks carry tremendous potential for destruction, particularly when they are aimed at the devices that run our networks. By controlling network devices, attackers gain the ability to monitor and control network traffic, redirect users to alternate websites and launch attacks against other devices to which they would otherwise not have access. Routers, switches, and firewalls have become prime targets for malicious attacks, and without the security protections such as virus scanning that end devices have, many network devices are at an increased risk of attack or compromise.
The software running on virtually all network equipment is built from millions of lines of source code — just a single router or switch could have anywhere from two to over 20 million lines of code. These are the programming instructions written in languages (such as C or Java) that control almost every aspect of network devices — from authenticating users, to determining which connections to allow or disallow, interfaces, protocol stacks, firewalls, encryption, servers, clients and alerts — even which LEDs to light up and when to flash.
Every line of source code was written by someone — but by who, where and when?
Security implications of the global coding supply chain
In today's competitive marketplace, reducing development costs is a major initiative for all companies. To help keep costs low, large pools of offshore resources are often used, in addition to short-term contract employees to help supplement staff.
Because coding projects can span the course of several years, hundreds of people may have contributed to the code base by the time the project is complete. This leaves the door open for the accidental introduction of security vulnerabilities, as well as intentional malicious acts such as the inclusion of a weak encryption algorithm or a backdoor to allow unauthorized access to the system.
Such a backdoor implant was discovered late last year in a major manufacture's router, allowing the attackers unauthorized access to the devices and the ability to install additional malware components.
Security implications of open source components
The use of open source components has also become commonplace to save organizations time and money. Not only is open source developed by hundreds of people working in locations around the world, but it poses additional challenges since each open source code component has its own unique supply chain within the greater supply chain of the product into which it's incorporated — and the use of open source components is only going to increase over time.
The tracking of which open source components are used, what vulnerabilities were in the version used and which products need to be updated with the latest fixes makes code management even more complicated. Currently, only the original equipment manufacturer is capable of tracking this, since they are the only ones who know what software goes into their products.
Take the Heartbleed bug in OpenSSL for example. It was introduced in March 2012 by a simple one-line mistake in the code and wasn't discovered and patched until April 2014, two years later. A quick scan shows that in April 2016, two years after it was discovered, there are still over 200,000 internet facing machines that are using the vulnerable versions of OpenSSL.
Embedded systems such as routers and switches are not like your home computer, where you can click the "Check for Updates" icon and get the latest software updates. Newer versions of open source code must be integrated into the embedded software base. This process can take significant developer time and effort, which comes at a cost to the parent company. There is also a lapse between the detection of a vulnerability and the time when updates are made to the open source code and the embedded software, QA testing is performed, customer acceptance testing is performed and the revised version of software is available for general use — still requiring a painful upgrade process for the end users. That process could take a year or even two depending on where it falls in the development cycle.
Current mandates and legislation aren't enough
What can be done about the security of the global chain of custody in the code that powers our networks? Current security standards and certifications (e.g. Common Criteria, JITC Certification and FIPS 140-2) are a great start, but they are not enough.
Legislation was introduced in 2014 (H.R 5793) that would require companies to track all open source and third party software used in their products and verify they are free from security vulnerabilities, but it has not yet been approved — partly because that level of security assurance is legally and financially burdensome. Similar to ingredient labels on our food products, software would be labeled with its open source "ingredients."
Unfortunately, managing the security of devices isn't this easy. Versions of open source and the vulnerabilities against them are moving targets. For example, since the Heartbleed vulnerability was reported, 14 versions of OpenSSL have been released and an additional 64 vulnerabilities have been found. Multiply this by the thousands of open source components and we can see the problem quickly grow.
Security for the software running these network devices must be built into the software supply chain, but that requires a unique set of skills and resources, including expensive security testing of software and hardware, access to network device hardware and source code and the resources to make software security evaluation a perpetual process.
Cybersecurity is not a static threat barrier. It is an arms race in which the defenses have to keep up with ever-evolving threats. Those defenses are made stronger through a defense-in-depth approach to the network, the security of devices that make up that network and the integrity of the source code that powers them.
David Lau is a senior software development manager at LGS Innovations and serves as the technical manager for the company's CodeGuardian group, which is responsible for securing critical network infrastructure.