How Trustworthy Networking Thwarts Security Attacks

Part 2 of the Series: Trustworthy Networking is Not Just Technological, It’s Cultural

A trustworthy hardware and software networking solution is one that does what it is expected to do in a verifiable way. Implementing a network with trustworthy solutions, that are designed in from the very beginning, help ensure a signed, sealed, and verifiable network infrastructure. In part one of this series on trustworthy networking, I discussed “The Technology of Trust” and how specific capabilities are engineered into hardware and software to secure network devices and software from unauthorized tampering, manipulation, and counterfeit. From building a chain of trust with embedded secure ASICs in hardware, creating software using a secure development lifecycle, to managing Common Vulnerabilities and Exposures (CVEs) with Product Security Incident Response Teams (PSIRT), trustworthiness needs to be pervasive throughout the products and organizational culture.

In this post we are going to examine trustworthy networks from the perspective of defenses against security hacks and attacks. How do the components of trustworthy systems foil attacks before they even begin, or limit the damage that they can do given a foothold through unsecure network devices?

Trustworthy Networks Defend Against Security Attacks

As CISO’s are well aware, there are many ways to gain unauthorized access to unsecured network devices. In the last decade, network devices, such as routers and switches, became more of a target as the devices began to be built on commodity hardware with various amounts of open source code integrated in the Network Operating System. This opens up several avenues of attack. For example, as we discussed in Part 1, persistent malware can survive hard resets because the malicious code can alter the BIOS or even the lower level bootloaders to gain control of the root. Without built-in protection at the hardware root layer that prevents altered low-level code from loading and infecting the entire OS, detecting and eliminating persistent malware infections is next to impossible.

There are three categories of defenses for threats against network devices:

• Runtime Defenses protect against the injection of malicious code into running network software, making it very difficult for attackers to exploit known vulnerabilities in software and hardware configurations.
• Secure Device Onboarding protects against tampered, tainted, or counterfeit devices that can harbor malicious code fresh out of the box or be infected during configuration.
• Secure Boot guards against advanced persistent threats (APT) that attack the boot code and take over operation of routers and switches.

We’ll examine how these three safeguards act interdependently to provide multi-layer protection against a variety of threats.

Runtime Defenses Prevent Memory Attacks

One of the most prevalent attacks—forcing a buffer overflow to assume control of a device—is also one of the oldest. Yet it still is in use because some networking devices engineered as commodities do not incorporate the more advanced runtime defensive measures that prevent successful buffer overflow attacks. Runtime defenses such as ASLR, BOSC and Safe C, and X-Space, make it much more difficult for attackers to exploit vulnerabilities in running software like a network operating system or networking protocols. Using different yet complementary techniques, runtime defenses prevent successful injection of malicious executable code, inserting larger than expected data packets into memory, and leveraging predictable memory layouts.

Address Space Layout Randomization (ASLR) is a defense that initiates before the OS even loads. It randomizes portions of a devices’ memory layout using fuzzy logic algorithms, preventing an attacker from designing malware that depends on a known memory arrangement. For example, every Cisco Catalyst switch (of the same type) is configured with the same factory memory layout. When powering up, ASLR kicks in and randomizes a portion of memory, resulting in each switch having a different running memory configuration. An attack designed to use the factory memory layout, or a memory layout on an attacker’s device, will be thwarted by the ASLR re-configuration. Since memory layout changes whenever a device boots, creating a persistent attack on an ASLR device becomes very difficult.

Built-in Object Size Checking (BOSC) and Safe C are two runtime defense that work together to manage how incoming data is copied into memory. An attack that relies on forcing a larger amount of malicious code, via a routing packet or a CLI command, into a smaller chunk of memory to cause a buffer overflow error is stopped by implementing BOSC in combination with compatible compiler technology. In cases where the compiler cannot predict the destination buffer size, Safe C libraries are implemented to provide additional protection from buffer overflow attacks.

X-Space, or executable space protection, is frequently supported by a CPU-maker’s architecture to prevent executable code that is hidden in data streams from executing in memory spaces. Enforcing X-Space in network devices marks memory regions as non-executable so that malicious code hidden in packets cannot be executed in those memory regions, adding another layer of protection to make it difficult for attackers to exploit buffer overruns. Designs for network devices should specify X-Space capable CPUs to take advantage of this additional runtime defense.

Each of these runtime defenses must be implemented by design into routers and switches in a way that cannot be circumvented. How can you be sure that network devices have not been altered to bypass built-in security measures such as runtime defenses? With secure root of trust and secure boot, two pillars of Cisco trustworthy security that ensure secure device onboarding and defenses against persistent threats.

Secure Device Onboarding Ensures Authenticity

One of the advantages of adopting a software-defined network architecture is the ability to use zero touch provisioning (ZTP) and Plug and Play (PnP) services to configure remote network devices. The devices, such as routers and switches, can be shipped directly to a branch office site, powered on by a non-technical employee, and remotely configured by an IT expert from a cloud management portal. But between manufacturing, warehousing, shipping, and installation, how does IT know if the device has been altered in any way? Is there a way to prevent an unauthorized device from trying to spoof network controllers and intercept network device configuration data, which contains sensitive customer information?

Security embedded in hardware is the literal key to ensuring a device being installed and configured is genuine and untainted. A secure Trust Anchor Module (TAm) chip is the foundation of embedded hardware security. The Cisco TAm contains the Secure Unique Device Identifier (SUDI), as well as the ability to generate and store key pairs with cryptographic services including random number generation (RNG).

SUDI and secure boot are particularly important for configuring networking devices with ZTP, providing assurance that both the hardware is certified as original and software being loaded is uncompromised. Before a router or switch can load the BIOS and network operating system, the unit must first prove to the network controllers that it is a verifiable Cisco hardware component by submitting the encrypted SUDI to the domain controllers—either Cisco ACI, Cisco Data Center Network Manager, Cisco DNA Center, or Cisco vManage. An unauthorized device cannot get past this stage as it has no knowledge of the SUDI, encryption keys, and certificates.

Once the hardware’s certificate is validated, the BIOS and bootloader are verified by additional encrypted certificates to ensure the code is untampered before running. Finally, the network operating system kernel loads and the router receives a configuration file to join the orchestration fabric. Every step of this process is protected with encrypted certificates and secure tunnels for end-to-end trusted provisioning.

Hardware Root of Trust Prevents Persistent Threats

Persistent threats consist of malicious code that burrows into the very root of boot software. Even a power reboot or reset may not dislodge the code if there is no hardware root of trust to detect and keep the code from running. With secure boot located in the trust anchor hardware, even code designed to be persistent will not have certificates or encryption keys to pass the pre-load tests mandated by the hardware trust chain.

Secure device onboarding and preventing persistent threats are just two reasons the root of trust of secure boot must originate in secure, tamper-proof hardware. In x86 and ARM appliances, this requires special attention to design. Some network vendors try to build secure boot from the BIOS instead of a secure hardware anchor. But once the BIOS itself is corrupted, the attackers own the device. The corrupted BIOS can, for example, be instructed to load an incorrect OS image yet report that the correct version is running. Once the BIOS of a router or switch is corrupted, the attacker can access the network at will.

Trustworthy Technologies Work in Unison

As we’ve discussed in my previous post as well as this one, the multiple security measures that Cisco develops and deploys to our customers work synergistically to create trustworthy networking. No single solution can provide a trustworthy network. Building a chain of trust includes a secure development lifecycle, a secure root of trust built into hardware, image signing, continuous monitoring of CVEs via independent PSIRTs, multiple runtime defenses, and secure device onboarding.

Most of all, the trustworthiness of network components depends on a culture committed to designing, implementing and supporting these critical elements. In the third post in this series, I’ll examine how to create, promote, and maintain a trustworthy development and support culture.

Subscribe to the Networking Blog