Consumers and ISPs are both waking up to the risks (e.g. personal data theft and service interruption) faced if the broadband CPE falls victim to security breaches, such as persistent malware. However, there’s still relatively little attention focused on the risk in the opposite direction – when the ISP’s own backend (or core network) is the actual target.
As I described in an earlier blog post, the ISP’s backend infrastructure must evolve to process and protect the vast array of data fed by the telemetry built-in to modern and smarter CPE, as they turn into open platforms for applications developed by the ISP as well as by third parties (and deployed through partnership with the ISP).
These value-adds can be great news for customer loyalty, ARPU and net promoter score (NPS), but they come at a cost. The new, more sophisticated services hosted by the ISP in support of their smart CPE will now expose a wider attack surface whilst hosting a treasure trove for criminals (consumer data).
Traditionally, broadband never needed or deployed strong authentication. The ISP often trusted their CPE as if it was an extension of their core network even though it is located in what effectively is a hostile environment. In those simpler times, a CPE could authenticate to the backend with as little as its MAC address.
However, weak CPE authentication suddenly becomes a big deal as the ISP’s backend grows in complexity and carries all that sensitive data being collected from the home (e.g. personal details, traffic logs, Wi-Fi passwords, video footage from security cameras, etc.).
MAC addresses have a predictable format that’s easy to replicate in an automated attack. Servers that accept MAC addresses as credentials can be easily fooled, letting attackers impersonate any other genuine subscriber (spoofing), and so exposing a wide range of data about that subscriber’s household (for instance their personal video streams).
Skilled attackers will go a step further. Armed with an identity now recognized as valid by the operator’s backend, they will now attack its service APIs, probing for vulnerabilities. API attacks are popular. Last year, 91% of organizations had API security incidents with far-reaching consequences.
API breaches are springboards for wider attacks, allowing lateral movements within the operator’s backend to attack those servers in the core network that carry data of even higher value such as credit card numbers.
A MAC address is one example of weak credential used in practice by operators to authenticate their CPE, and which can be misused in an API attack. Other types of weak CPE credentials include secrets hardcoded in router firmware, short passwords or self-signed certificates, all in various combinations.
So how can an ISP mitigate this risk and safeguard the integrity of their own network and services? The answer is to add a robust, trusted identity into each individual router. These private credentials are strong and unique to the device, making it impossible to guess or clone them as a way into the ISP’s infrastructure.
How robust should a trusted identity be? Cryptography certainly plays a big role: at the very least, an operator will want to follow best practices, phase out simple passwords for PKI certificates or cryptographic roots-of-trust, and pick good algorithms and key lengths while doing so.
However, Adi Shamir’s third law postulates that cryptography is typically bypassed, not broken. Attackers get a much better ROI on their efforts by reverse engineering devices and their firmware or by finding flaws in how keys are managed, stored, and distributed. They will not set up their own Bletchley Park to break the keys.
Defending the operator’s core network and its future service APIs from spoofing and cloning requires trusted identities into the CPE. Trust builds up from the earliest stage (e.g. at manufacturing). Modern supply chains are long, globalized, and complex. Opportunities abound for leaks and breaches even before the CPE are commissioned.
Evidence is necessary to demonstrate how certificates and keys were generated and distributed into products in a safe and controlled manner. And once installed into a device, the CPE identity should be robust against extraction, preferably via bounding to a hardware root-of-trust (not incidentally, the first property of a highly secure device in Microsoft’s security vision). Without the proper protection, these private keys become vulnerable to lifting and cloning, either via malware or by actors with physical access to the device.
As a trusted identity, it can then serve as a reliable authentication mechanism and as basis for renewability, to recover from future breaches or to introduce new security features.
Download our e-book: “Broadband CPE: An ISP’s biggest asset or its weakest link?” for more information on how IPS can ensure their CPE keys are generated, stored and provisioned security into the devices for appropriate long-term security management – even in when they’ve adopted a multi-vendor CPE procurement strategy. The e-book also contains real-life CPE security case studies and recommendations on how ISPs can protect their routers against persistent malware with code-signing.
If you need more advice on how to implement Trusted Identities in your CPE, check out our Keys & Credentials for Routers service. And if you’re not sure whether your CPE authentication processes are leaving your servers at risk, ask our team of experts to perform a detailed security assessment.