How easily do you trust something? Depending on your experiences you may range from “very trusting” all the way to “only as far as I can throw it”. Peoples experiences with devices and software can color their trust in technology. Someone on a security team or on a group that has had to clean up after a breach is probably less trusting than the average person. Which can be a good thing when that skepticism and cynicism translates to reduced risk. But how does that all play out in a different kind of arena?
Who Do You Trust?
I had a chance to sit in on a great presentation in January during Networking Field Day Exclusive with Cisco’s Service Provider organization. Dan Backman is a super great presenter and I’ve had the pleasure of seeing him talk many times. Check out this video from the event where he discusses Service Provider Security:
Dan came over to Cisco after they acquired Skyport Systems in early 2018. The presentation covers a lot of the things that Skyport was working on with regards to trust and device security.
When you think about, most data breaches are designed to steal as much information as possible. As Dan puts it, they’re “robberies”. Once the APT or vector is found there has to be an accounting of the data that they were after. It’s a “one-and-done” kind of thing. But with service provider networks, the network itself is the target. You can get access to all the data flowing across the network if you manage to compromise one router in the chain. As an analogy, enterprise data breaches are like stealing a package from someone’s front porch. Compromising a service provider network is like getting a job as a delivery driver so you can steal the best packages out of all the ones you see.
Enterprises spend a fortune trying to keep the robbers out with software and hardware solutions designed to tell you when someone is sniffing around. But those solutions can only really tell you when something happens based on data being transferred. Like the T-Rex in Jurassic Park, these security solutions can only see movement. It doens’t help you if the device doing the moving is compromised.
You may recall a story from Bloomberg late last year that claimed SuperMicro implanted a chip at the behest of the Chinese government to spy on US companies. While the reporting in that story has been discussed at length and no evidence of the chip has been found so far, the real frightening thing is that companies realized in that moment that if there was some kind of deep hardware breach of their devices they would have no idea what was going on. If someone managed to violate the device below the software detection level no one would be able to find it until it was way too late.
Chain of No Fools
So, how is Cisco proposing to stop all of this? Well, building the Skyport technology into the IOS-XR platform is a great first step. Dan talks at length about security the UEFI boot process to ensure that an image is validated from the moment. Note the word choice there: validated. Validation is an entirely new level of trust. Trust simply means “I believe what you say”. Validation means “Prove to me that you are what you say”. Validation takes nothing for granted. Validation forces the devices to prove their identity before they are allowed to continue.
Validation is great because it detects things as soon as they happen. We are slowly starting to rely more on validation in our daily lives. Email alerts for large credit card transactions. Two-factor authentication. These are the things that force us to confirm intent. They keep us safe from bad actors attempting to impersonate us. Validation in a boot process ensures that the image the device is booting is secure. It ensures the hardware is working from a known-good state and that proper modules and such are being loaded.
When most people think about service provider networks, they imagine giant data centers in colocation facilities. But a lot of service provider equipment lives on the edge of their network in customer environments. And if a determined hacker wanted to jump into a low-security facility and grab configuration or data from a router locked in a supply closet somewhere it could very likely happen. They could even attach bad hardware dongles or even boot the router with a custom firmware image designed to give them backdoor access.
Cisco’s Secure boot ensures that not only are the software images loaded into runtime validated correctly, but that no other illicit firmwares could be loaded. They must pass the validation check against a root anchor. It’s a lot like the modern iPhone. You can’t boot a custom firmware because it fails the validation check. That’s good when you don’t want anything but trusted software running on your devices.
More than that, Cisco works from known-good validations. Those aren’t blacklists. Those are validated references that are accepted. Blacklists are more focused on blocking bad actors. But you can only block the bad actors you know about. Even a whitelist approach is bad because it doesn’t scale. You can’t hope to approve every possible corner-case. With a validated design approach you can keep adding new validations to the database and they will all be queried when a new configuration comes up and is confirmed. It’s the best way to keep new hardware and new software versions under control while still maintaining a modicum of security on your device boot process.
Bringing It All Together
I could go on and on about Dan Backman’s presentation about device trust and validation. They Skyport team was working on some great things before their acquisition, many of which were recorded at Tech Field Day events. Continuing this research at Cisco means integrating these great ideas into a wide variety of hardware platforms and securing a huge portion of the service providers on the Internet. I’m looking forward to seeing where Cisco takes this technology.
- Does SPB Mean “Secure Path Bridging”? - February 12, 2020
- Cloud Isn’t Your Key To Compliance - February 10, 2020
- Breaking IoT Security - February 7, 2020
- Answers at Your Fingertips with Forward Networks - February 4, 2020
- Priming Your Application Performance with Intel Application Device Queues - January 29, 2020
- Is Cisco SD Access Intent Based Networking? - January 28, 2020
- Captivating Wireless Connectivity with Cisco OpenRoaming - January 22, 2020
- Does the Apple Airport Extreme Use VLANs? - January 21, 2020
- Predicting Data Patterns with Cradlepoint - January 16, 2020
- How Do RFC3161 Timestamps Work? - January 15, 2020