Learning from KRACK and ROCA: Here’s how to equip your firm
Last week’s news introduced us to another pair of vulnerabilities hitting right at the foundation of everything we place our trust in. Named KRACK and ROCA, these flaws target specific facets of Wi-Fi networks and cryptographic keys, meaning that attackers can potentially sneak into networks we consider private, and decipher things we consider secret.
Who’s affected?
If you’re in enterprise IT, you’re likely familiar with the cycle of waiting for a patch, then planning and coordinating the rollout of the patch across your estate. What’s interesting in this case is that a lot of the space to be covered includes non-PC devices, so you have to figure out how those will get patched too. (Your plan covers that, right?)
If you’re building your own software—whether for a website, a mobile application, an IoT device, or a connected car—the situation is more complex. Depending on how you built it, you might be waiting for an update from your software or platform supplier (whether commercial or open source). If you don’t have an over-the-air (OTA) or other online update mechanism to push patches out, you may even be initiating a painful product recall, service bulletin, or replacement.
Of course, hindsight is 20/20, but let’s take a look beyond all the technical excitement that comes along with these types of deep crypto and network problems and analyze what should happen now.
Ask questions and make a plan
Before you decide to build, buy, or otherwise create your product or service, ask the right questions. What’s inside this thing? What are we buying? There are tools, of course, that can help you answer these questions: Software composition analysis can look inside both source code and binary packages and determine what’s in them, with high levels of accuracy. You can also ask your software suppliers to provide you a list of what’s inside their code, better known as a software bill of materials (BOM). You might learn, for example, that without even realizing it, you’re incorporating a Wi-Fi package or cryptography firmware that’s affected. We increasingly see companies, regulators, and indeed entire industries moving to make BoMs a requirement for third-party software provision.
Make sure somebody asks the “wrong” questions too. Consider the corner cases, the failures and threats that may occur at every layer, and how you’ll protect yourself in the worst-case scenario. Maybe an attack like KRACK will upset your world and expose data in transit on the network—but that should be fine, since your threat model already told you that TLS was a good idea. Oops, ROCA undermines your TLS? Well, if your data is really sensitive, you have large-enough keys to start with—and just in case, your PKI infrastructure should kick in and allow you to revoke and replace anything affected here too. Synopsys does application risk assessments for our customers all the time to uncover these types of gotchas. We also help organizations learn how to do it themselves, with our eLearning programs to teach developers how to adopt the type of adversarial thinking that attackers have.
Explore security training for every role with Synopsys eLearning.
Plan what to test and how to respond. Maybe you’re building your own wireless stack after all—in which case, it might be a good idea to adopt techniques such as fuzzing, which will find flaws similar to KRACK and ROCA you might have introduced in your own flavor of wireless networking support. Likewise, for all software code you write yourself, techniques such as code review, static analysis, and penetration testing are a no-brainer.
Of course, it goes without saying that in an ideal world, these strategies would all be baked into an end-to-end program. So plan which technique makes the most sense where, where the most value is, and where you are best placed to deal with the results efficiently. We find that the “shift left” mind-set is critical here; there is no point in doing your first static analysis just a week before you roll out your product, for example, so why not make static analysis part of every build or every developer’s daily routine? Likewise, many organizations maintain a collection of preapproved components—whether libraries, specific versions of libraries, or even supporting toolchains—and build checks and balances to make sure that nothing unexpected can be introduced without the right approvals being in place.
Be prepared and run the plan
Even with your plan completed, the inevitable will happen. The trick is to transform your plan from an emergency response to a well-oiled routine, and we believe this is where the leaders in the industry really set themselves apart.
Through the Building Security In Maturity Model (BSIMM) data we collect, we see that 84% of firms have at least started to think about incident response procedures to address software security flaws when they come up. Are you one of them? If so, when you’re faced with a situation like the one today, your process should kick in, and you’ll use your global bill of materials (generated from your SCA tool, we hope) to create and cross-reference a list of affected products. Sadly, the BSIMM tells us only 40% of firms maintain an inventory of their applications—which undoubtedly makes this process much more challenging.
In some cases, you can’t fix it yourself. Referring to the BSIMM again, we see only 8% of firms communicate standards and expectations regarding patches and so on to their suppliers when they do business. In an ideal world, obligations would be clear, and you’d have a solid timeline for when to expect a patch. But without these obligations enshrined in specifications, requirements, and eventually contracts, you’re really exposed to the risk.
Learn and improve
With the news of Equifax suffering such a severe impact from an outdated version of Apache Struts, BlueBorne hitting many embedded systems—from internet-connected fridges and toasters to cars—and now these new vulnerabilities, one thing is clear: You should expect to run your plan more often. How did it go for you this time? What can you learn?
Surprising, still, is that only 9% of the firms we interview for the BSIMM tell us they have a way to control open source risk. Compare this with our State of Software Composition Analysis report from 2017, where we saw that 64% of applications contained some open source and almost 50% of applications we analyzed contained components more than 4 years old—many with known security vulnerabilities. This tells us there is a huge opportunity to learn.
If you aren’t one of the firms equipped to respond to these recent flaws, maybe their compound effect is the motivation you need to build a software security initiative. The good news is Synopsys can help. Our portfolio of program development services—starting with the BSIMM and continuing all the way through the maturity curve into designing bespoke open source and third-party software management—can help you build out your security program.
Although it’s easy to get alarmed by the latest turbulence or pothole, incidents like these serve to remind us that software security truly is a journey.
*UPDATE*
The following Synopsys services can help your firm manage the risks associated with these flaws:
