Closing the Security Gap: Automation and Trust at the Network Edge

Ulrich Kohn
Man walking over drwn bridge

Unsecure edge devices are challenging our economies and our societies. We have experienced major hacking attacks on edge devices such as cameras and DSL routers. Both attacks targeted thousands of servers at the network edge by building a botnet for the orchestration of unprecedented denial of service attacks.

Luckily, those breaches did not cause the devastating consequences they might have. But the problem has not gone away. As more and more intelligent devices are connected to a network, the potential for hacking attacks increases. We need defenses in place to mitigate these risks. This is especially relevant as those devices frequently do not operate in a controlled, trusted environment. The sheer number and widespread deployment of devices demands prevention rather than after-the-fact remediation with its high cost for in-service fixes.

The problem is not limited to consumer-grade appliances. As communication service providers (CSPs) are preparing for wide spread NFV deployment, they are investigating the potential of edge computing as a means to more flexibly provision new services. Intelligence at the network edge is a key enabler of automated processes with service activation and assurance. There is huge interest in fully automated provisioning processes eliminating the need to send service technicians on site. Instead, the customer would install and connect an edge device delivered by the service provider. All subsequent software installation, configuration, testing and provisioning processes would run automatically.

However, those operational cost savings have some downside. A service technician on site does not just commission the equipment and provision the service; he also conveys trust. The identity of the edge device is verified by the technician, who reliably provides firmware and software as well as the required credentials to access the network. In consequence, an automated process for device set-up and service provisioning will also need to address the security related responsibilities of a service technician.

Automation increases the attack surface. There are various new attack vectors which need to be considered. How can a CSP know that an attached edge device is the correct one which was delivered to the customer rather than a fake installed by a rogue user who has managed to get access to the fiber plant? How can they be sure that the software on the device was not altered on its way from the manufacturer to the customer site so that it now runs malicious code or has backdoors? And how can the CSP prevent a rogue customers from compromising the network?

Automation at the network edge creates a serious need for additional security controls. The edge device needs to be securely activated, and its operation needs to be protected from any malicious attack. There needs to be an automated replacement for the trust created by an authenticated and authorized technician. There are several ways that this can be achieved. Two methods are outlined below:

Case 1 – Edge Devices With Hardware-Coded Identification

The edge compute device comes with secret credentials stored in a security module or burned into hardware. These credentials are used to identify and authenticate the device or to sign and encrypt information exchanged between the edge device and the network. In many cases, these credentials are a private key in combination with public keys of trusted parties such as the CSP itself, software providers or the manufacturer of the edge device. A user must not be able to change this information – neither intentionally nor accidentally. This prevents a rogue user from creating a device with the same identity as well as installing un-signed software. If the device is installed by a trusted delegate of the customer authorized by the CSP, key security requirements can be met.

Case 2 – Verification Codes

The end device might be a white box without any specific means to securely identify itself with a network in an automatic way. A delegate acting on behalf of the CSP verifies the identity of the edge device. He provides a  verification and authentication code locally, which is used for identification, authentication and authorization.  This activation code can either be made available by a securely delivered  voucher, or by using a security token in combination with a password known by the delegate. The voucher or token are frequently valid for a limited period of time or a single activation process, during which a persistent security association between the edge device and the network is established.

Both methods initially establish trust between the edge device by applying secret information for authentication and authorization. Secure connections are established with the network and servers that host configuration information, firmware as well as software images in the case of NFV. Alternatively, data signed by a trustworthy party might be uploaded from an untrusted server. The edge device needs to be able to confirm the signature, which requires protected access to the public key of the signing party.

This brings us to a further requirement for operating an edge device in a secure way. A chain of trust needs to be established and maintained between those parties supporting operations and the edge device. Compromising trust can easily affect thousands of devices, necessitating implementation of revocation methods with applications in security-sensitive environments. Hence, security is not a one-time effort during installation but needs to be maintained over the lifetime of a service.

CSPs are eager to roll out services in an automated way, leveraging distributed compute platforms. Additional security controls are required as manual processes performed by trusted, authenticated and authorized technicians are replaced by automated activation procedures. Relevant cipher technology is available, but service provider will need to develop skills and processes for using that technology meeting required security assurance levels. Failure to do so will create tremendous liabilities to operators – both in terms of monetary damage as well as to their reputations.

Ulrich Kohn

Related articles