With RSA Singapore now in the books, it’s time to look back on the event and a core theme of experiential learning. The stage was set for this with IBM’s Diana Keely highlighting how today’s attacks are rather reminiscent of successful tactics from the past — a form of cyber groundhog day. She highlighted a number of vectors that should be table stakes for any organization, but we collectively seem to fall victim to despite their age. Breakout sessions were full of examples of various successful attacks that could’ve been prevented had either proper security reviews or application hygiene been performed.
A perfect example of learning from the past are the attacks attributed to the Mirai bot network. Mirai successfully exploited a security vulnerability first disclosed in 2004 that was predicated on well known passwords. We should all know that widely deployed products with well-known default passwords are likely to get compromised rather quickly. We should also all know that whenever we decide that something “isn’t a security issue” and defer addressing it, at some point in the future it’ll become a major issue that could tarnish a company’s brand.
Hubris has an alarming tendency to bite in rather Karma like fashion. Over the years we’ve seen marketing organizations create campaigns touting their security prowess, only to attract unwanted attention. The poster child for this would be Oracle’s “Unbreakable” campaign, which while well intentioned backfired dramatically.
It’s against the backdrop that on the show floor I encountered one of Black Duck’s competitors claiming a solution with perfect accuracy in identifying threats. This competitor has a well known brand outside of open source risk management, and is attempting to become relevant in our space. I’m not going to name them because I don’t want to focus negative attention on them and accidentally invite malicious actions on either them or their customers. My intent is more to remind our readers that when perfection is claimed; it often becomes quite tarnished quickly, and that managing open source isn’t a trivial function.
Application Development in 2017
With open source development practices the norm for all application development in 2017, any open source security solution needs to face the reality that open source development isn’t as simple as closed source development. Identification of component usage is challenged by core practices like forking, parallel development streams, volunteer developers, backports and merges of development paths. Forks can become shipping product for legitimate reasons, and major components often have thousands of forks. There are often sound reasons for a given fork, and absent context, it's exceedingly difficult to properly identify a fork.
Open Source Security Management
These statements are true of pure open source development, but are critical when it comes to open source security and managing risk. Imagine a security disclosure against a major component such as OpenSSL. That disclosure is going to impact a number of versions, but between those versions there were likely hundreds to thousands of forks. Which fork is in your environment? Was a backported patch applied to a version by a given distribution channel — say that of a Linux distribution? How many different versions of OpenSSL are actually in use in your environment?
This is a difficult problem to solve for, and unfortunately there are many organizations that simply don’t understand the complexity of the problem. Purporting “perfect accuracy” only creates a false sense of security, which can result in serious consequences. For practical purposes, perfect accuracy can only be obtained at a specific point in time and with a specific data set. Modify that data set in the slightest, and absent context your accuracy will change. This nuance isn’t something that can or should be part of a marketing message, but is a reality.