RSA Singapore Review - The Perils of Security Hubris

RSA Singapore Review - The Perils of Security Hubris

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.

Security Hubris

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.

The Only Leader in Software Composition Analysis Providers

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.

Sorry we missed you! We close comments for older posts, but we still want to hear from you. Tweet @black_duck_sw to continue the discussion.


Achieving Open Source Security in Container Environments

| Mar 5, 2018

Today, open source components are at the heart of most modern applications, transforming how we architect solutions in every industry. Black Duck’s 2017 Open Source Security and Risk Analysis of over 1000 commercial applications revealed that 96% of applications scanned utilized open source.

| MORE >

Why You Need to Build AppSec into Your DevOps Process

| Feb 26, 2018

Application development thrives on the use of open source components. Why? Quite simply, there are many benefits to using open source components, including the ability to leverage skill sets and expertise of the open source community, take advantage of the efforts of larger development teams, and

| MORE >

8 Takeaways from NIST’s Application Container Security Guide

| Dec 13, 2017

Companies are leveraging containers on a massive scale to rapidly package and deliver software applications. But because it is difficult for organizations to see the components and dependencies in all their container images, the security risks associated with containerized software delivery has

| MORE >