Software Integrity Blog


RSA 2018 recap: Detecting vulnerabilities and avoiding snake oil

The message at RSA 2018 was clear: stronger regulations and stiffer penalties haven’t slowed data breaches. It’s time to look at the cost of noncompliance.

RSA 2018 recap: Detecting vulnerabilities and avoiding snake oil

With RSA 2018 behind us, a recap is in order. For any readers who have never attended the RSA Conference (RSA) in North America, it’s worth setting the stage. For practical purposes, RSA is the premier technology security conference. There are tens of thousands of attendees, well over a dozen conference tracks, and the show floor itself spans two buildings. Exhibitors range from the NSA and FBI (love their dogs, by the way), through service providers like CenturyLink and AT&T, major technology vendors like F5 and Trend Micro, to smaller vendors around the edges of the expo halls.

RSA 2018 was an excellent opportunity for me to catch up with former colleagues and understand how their journeys through technology are progressing. I also had a chance to catch up with friends at competitors’ booths to see how their employers’ products and services have evolved. Walking the show floor, you see consistent themes around security and crazy giveaways. One vendor had a person dressed as a snake oil salesman, while another was giving away bobbleheads. How many attendees went home wondering whether the bobblehead they collected is indicative of how confident they should be in that vendor’s solution? It truly is enough to make your head spin.

With that as the backdrop, I’d like to tackle one very important security topic—vulnerability detection. A vulnerability is quite simply a weakness that can be exploited to cause unintentional outcomes. Vulnerabilities exist in all technologies, which is why security people like to talk about “defense in depth.” The defense-in-depth paradigm asserts that if exploiting a given weakness requires you to first exploit weaknesses in multiple unrelated systems, the success rate for the intended exploit goes down significantly.

A fairly relatable analogy for defense in depth

If you wanted to rob an apartment without being identified, you first need access to the apartment building and then must determine which units are rented out but whose occupants aren’t at home and who have valuables worth stealing. Each of these steps can be thought of as part of the overall apartment building security system. Unfortunately, most of them can also be bypassed if the thief first steals a car with a remote garage door opener inside and information about the owners’ address. The garage door opener enables the thief to bypass the physical security of the building. If the car isn’t close to the building address, possessing the car lowers the probability the unit is occupied. The type of vehicle also provides clues to the wealth of its owner, which gives clues to what valuables might be available. All that remains is to access the apartment. The vehicle also conveniently helps with transporting the loot.

As you see, defense in depth only works in the absence of additional information about the weaknesses, which may create a false sense of security. The more layers present, the greater the probability one will either be readily bypassed or be subject to exploitable vulnerabilities. The key to vulnerability management is to first understand the value present in the system being exploited. Unfortunately, we need only go to a flea market or yard sale to see value is in the eye of the beholder. Or in the context of software—your definition of “valuable” is different from the attackers’, and they get to decide what and when to hack.

Open source versus commercial code

To balance that out, you must know both what software you have deployed and what software is available for deployment. In a datacenter all physical assets are tracked—software should be no different. Software can be patched, so you need to know where every component comes from and the patch delivery model for those components. If you have open source components in your systems (and I guarantee you do somewhere), knowing where the code originated is critical. Open source is different from commercial code because there is rarely a vendor pushing out vulnerability patches. If you’re not directly engaged with the sources of your open source components, you’re likely behind on patches.

Access and audit controls

Once you know what software you have, you can start to put access and audit controls in place. Perimeter defenses come next, but please don’t rely on those defenses as they probably won’t help much if the attack is from an internal system. In other words, remember that the attackers define the rules. Build out the attack scenarios, but don’t forget to keep your inventory of dependencies up-to-date. The best way to accomplish that is to automate the discovery step. Place scan tools in your CI pipelines. Automatically scan all container images that enter your container orchestration system—regardless of whether you trust the source registry or not. Embed dependency management into your virtual machine (VM) deployment life cycle. Create automated entity relationship maps between your systems and any external systems. Performing these automated actions will help not only in vulnerability identification but also during audits and remediation activities.

Security vendor or security partner?

Over the coming weeks, RSA 2018 attendees will be inundated with sales calls. The salespeople will try and convince you they’ve got security solved. The reality is the best software security comes from those actively investing in pushing the state of the art—not the ones with the best price. You want security vendors who will grow with you and stand behind you. Ask hard questions. Appliance and packaged software vendors should be up-front with their patch models and software life cycle. Similarly, vendors with hosted or SaaS solutions should be up-front with what data they receive and what they do with the data. If you’re sending sensitive data to a third party, or information about your datacenter and its dependencies, their data management policies must align with yours. After all, an attacker might first extract your data from a SaaS vendor and use it to bypass some of your layers of defense.

Bobbleheaded snake oil salespeople are everywhere. If their claims sound too good to be true, they just might be. If their message sounds just like everyone else’s, start asking some hard questions. Global regulations are getting stronger, and penalties are getting stiffer. We’ve already had too many data breaches in 2018. The best way to get your security policies and layers sorted is by moving past the cost of acquisition and looking at the cost of noncompliance.

Make security your competitive advantage


More by this author