Why agencies need to get to the source (of the source code)
Posted on: June 1, 2016

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.

Read more of LGS’ David Lau’s piece on Federal Times.

Want to know more?
CONTACT OUR TEAM
Ready to grow your career?
apply today

Hide Form -