What does secure by design vulnerability mean? Is this an oxymoron?
In a pre-print paper titled, “Insecure by Design in the Backbone of Critical Infrastructure,” security researchers at Forescout and a professor for secure IT systems at Technical University of Clausthal, Germany, identify 53 CVEs (Common Vulnerabilities and Exposures) in products from the makers of industrial technology. Some of these vulnerabilities were trivial and others were critical. All of these products were certified as IEC 62443 compliant – the Cybersecurity standards for OT (operational Technology) devices. The report reaches the conclusion that “despite a decade of efforts in improving OT security, the OT install base is still suffering from insecure-by-design issues even for products that are security certified.”
The makers of these products may disagree, and there are always gray areas when it comes to what constitutes certification for a set of standards, but it begs the question, is secure by design enough when it comes to devices?
Just like a person, devices go through a lifecycle, it’s pretty safe to say that your initial birth certificate doesn’t define you as your life status changes. When you get your driver’s license that’s a different set of credentials, as is a passport, an access card for your office, and so on. For a device, an initial birth certificate provisioned during the manufacturing process may make sense to the manufacturer, but when that device is sold to an end customer, its identity needs to be updated with those credentials. Simply assuming it’s safe because it has a certification badge is a terrible approach…we all know what it means to assume.
As cyber attackers become more sophisticated in their methods, the security that the device was built with will not offer the full amount of protection it will need to stay protected throughout its lifetime. From the time the device is issued its birth certificate, to when it is provisioned in the end users’ network, to when it is decommissioned, the device will have been updated and patched a number of times to protect it from outside threats.
Consider this from the perspective of a CTO for a publicly traded company managing critical infrastructure: over time they’ve probably acquired several other organizations which includes previously existing infrastructure, maybe they’ve even seen the number of vulnerabilities and threats rise. With the new cybersecurity rules in place, when there is a significant breach, they’ll have to report details to the Board and perhaps even publicly. Is it enough to assume that all the company’s connected infrastructure is protected by the original manufacturer’s basic protection? This doesn’t consider the changes all devices undergo throughout their operating lifetime…the customizations, the enterprise connections, etc.
Connected devices need a platform that can track all these lifecycle changes without the need for human intervention, inclusive of any “secure by design” credentials, but accounting for additional operating credentials, device-bound data, connections to other platforms, Edge requirements, and so on. This is especially important in mixed IT/OT environments with different levels of connectivity and control, because relying on manual processes opens organizations up to error, which leads to vulnerabilities.
To learn more about end-to-end device security, read our paper on the 9 Core Capabilities, and join the conversation by registering for our upcoming virtual summit with presentations from across the industry focused on securing your supply chain.
Please wait while you are redirected to the right page...