Are you familiar with Meltdown? How about Spectre? No, they are not a pair of James Bond movies. They are newly documented hardware vulnerabilities that have left nearly every computer processor made since 1995 exposed.
Each flaw was identified by multiple independent parties within a bizarre span of two months, even though these flaws have existed for more than two decades. Meltdown breaks the isolation between user applications and the operating system, allowing programs to access any memory on the device. With operating system patches, Apple and Android have already acted to try to mitigate the risk associated with Meltdown.
Though it is harder to exploit, Spectre is the more difficult vulnerability class to address. This type of attack breaks the isolation between applications, tricking an otherwise error-free program into mining the memory of another application. There are two variants of Spectre: #1 is a bounds check bypass and #2 is a branch target injection.
Leading manufacturers of processors like Intel, AMD, and ARM have been quick to release multiple microcode and firmware updates to try to remedy different variants of Meltdown and Spectre. Operating system and browser updates have proven effective at mitigating Spectre so far. Google, who helped first identify these vulnerabilities, has released a white paper on a software-based fix for Spectre called Retpoline, which has shown better relative performance than other attempts.
As new attack variants are identified, more updates and patches are being launched. Ultimately, the only true fix is a hardware update which will take some time to fully rollout.
So, how did we get here?
The Increasing Cybersecurity Threat to Hardware
Spectre is an indirect result of speculative execution, a process meant to expedite the execution of code by computing results out of order. This out-of-order flexibility opened the door for the possibility that malicious code could be used to trick the processor into accessing a portion of memory that it didn’t have access to. A team trying to improve the performance of its hardware accidently opened up a major security vulnerability. Should they have seen the potential tradeoff then? It did take two decades for someone to notice, so it is difficult to pass judgement.
When most people think of cybersecurity, they likely picture black hat hackers working in a dark room trying to “break into the mainframe”. In this case, the vulnerability was a hardware and design flaw, which means:
- No immediate software patch can totally fix the problem
- No amount of pure code review would have prevented a cybersecurity threat like this
- No monitoring system could have caught this security flaw
For these reasons and more, hardware security threats are becoming a bigger and bigger concern, especially for companies who are prime targets for attacks. In the Aerospace & Defense industry right now, companies are concerned that cyberattacks could actually lead to hardware flaws. By breaking into a company’s design and development systems, all a hacker needs to do is tweak specifications slightly and the result can be devastating. These counterfeit parts are especially difficult to defend against because supply chains can include hundreds of suppliers. One weak link can break the end product.
Then, how do you tackle this problem? There’s no one panacea for these challenges, but companies must take steps to improve cross-functional communication and verify quality reviews at each step of development. That means establishing an end-to-end peer review process that has the capacity to review and finalize requirements, capture changes between design documents, and mark defects in source code.
Outlining a Quality-First Process from Scratch
For most companies right now, their design, development, and testing process are disjointed. Drafts and deliverables are dispersed between excel files, word files, email threads, CAD and analysis tools, requirements management tools, and source code repositories. Which tool is actually responsible for ensuring quality? Each has quality-centric features (spell check, pull requests, etc.), but none of these are the source of truth for quality.
A designated peer review solution standardizes the reviews that are already taking place, captures audit-ready reporting and metrics, and serves as a cross-functional quality gate. A team could say that prior to a design being finalized, they want to tag-in at least one person from the security and development teams to do a review. Before a testing team finalizes a test plan, bring in the compliance team to get their feedback.
Imagining End-to-End Peer Review
It may sound like a pipedream. Your company may need to wade through the inertia that accompanies legacy systems and existing workflows to get there. Regardless of the ROI, it is a lot to configure across teams. That’s why whatever tool you choose needs to be flexible enough to match (and improve) your existing peer review process.
It’s a difficult ask. There are peer code review tools, but most can’t handle documents. There are document review tools, but they can’t handle source code.
Our peer code and document review solution, Collaborator, is one of the only tools that can serve as a peer review platform across the entire product development lifecycle. Because it has a command line interface and 17 built-in tool integrations, Collaborator is flexible enough to plug in to the tools, systems, and workflows that your teams are already using or maybe would prefer to use. If you are interested, you can start a free trial or learn more here.
Keeping Up with Meltdown
On March 8th, Jonathan Fortunati and I will be hosting a webinar titled, “What Meltdown and Spectre Mean for Cybersecurity in 2018”. If you are interested in hearing more on this topic, you can sign up to attend this upcoming webinar. Hope to see you there!