Software Bugs: To Disclose or Not to Disclose

It’s the age-old battle of security: to disclose or not to disclose

software defects.

The proverbial pendulum of opinion has been swinging back and forth on

this issue for decades, and it’s not likely to stop any time soon. The

issue reappeared just recently when an ISS employee was prohibited from

speaking at a conference on the topic of a security vulnerability in

Cisco’s IOS operating system.

Here’s my take on it…

First off, it’s not a simple yes or no issue. There are different shades

of gray here, folks. At the two ends of the extreme we have no disclosure

and ‘spontaneous disclosure’. Neither of these are even worthy of serious

consideration in any practical sense, since neither produce any sort of

positive results.

The litmus test of positive results that I’ve always used over the years

is this: Does publicizing the details of this vulnerability make the

problem smaller or bigger? We’re talking big picture now.

It’s been my experience that not releasing information on a vulnerability

invariably results in a larger problem than the one we started with.

This is primarily because the people who need to know about the

vulnerability most — the end users and system administrators — aren’t

armed with the appropriate information to make informed decisions on when

and how to update their systems.

In my book, that is unconscionable.

At the other extreme, it’s also been my experience that spontaneous

disclosure — releasing everything about a vulnerability the moment or so

that it’s discovered — also results in a larger problem than the one we

started with. The end users and system administrators often don’t have

practical solutions or workarounds (for instance, turning off email is

not an acceptable business solution in almost every case). Similarly, the

product vendors are forced to slap together a quick patch that may or may

not address the root cause (no pun intended) of the problem. We’ll delve

into this further in a moment…

So, both of these options are non-starters. If we accept these arguments,

then it becomes a question of how we release information and what

information we release. That’s where my opinion differs from that of a

lot of the practitioners out there.

There are a few published and ad hoc processes for responsible disclosure

of vulnerability information. My biggest gripe with them is that they

don’t take into account the software engineering that needs to take place

at the vendor level to appropriately address the problem. In particular,

most call for a static, predetermined time period between notifying the

product vendor and the public release of information about the

vulnerability. That model is horribly flawed.

Setting a Deadline

My rationale is as follows. At the top-most level, software security

defects fall into two general categories: design flaws and implementation

bugs. It’s the implementation bugs that we hear the most about in popular

literature. They include buffer overflows, SQL insertion, cross-site

scripting, and the like. The most common cause of these problems is

inadequate filtering of user data inputs.

Many, but not all, implementation bugs can be fixed quite simply and

easily. A poorly constructed string manipulation function in C, for

example, can be made secure in just a line or two of remedial coding.

On the other hand, design flaws can be much more pernicious. The fix to a

design flaw by its very definition requires the developer to change the

application’s design. A design change can have far-reaching

ramifications. Think basic software engineering principles here.

To responsibly make a security change to an application’s design requires

the same degree of engineering scrutiny, testing, etc., that goes into

designing the application in the first place, lest even nastier flaws

(and perhaps even implementation bugs) appear as a result.

It all comes down to this… Some software defects can be fixed quickly

and easily, while others can require great deals of engineering effort to

be properly fixed. There is a broad spectrum of effort levels required to

fix any particular vulnerability.

So, you see, setting an arbitrary time period for disclosing a

vulnerability is not responsible at all.

Instead, the period of time should vary depending on the nature of the

vulnerability itself. Forcing some time period into the process is like

holding the proverbial gun to the head of the product vendor, and that

can’t possibly result in the sorts of patches we all want for our

systems.

Even if you work with a product vendor to negotiate an appropriate amount

of time for disclosing a vulnerability, the next issue in disclosing

responsibly is what information to disclose. Most CERT-like organizations

have formats for vulnerability advisories that do a good job here.

The most controversial topic here is how far to go in disclosing. For

example, is it reasonable to disclose an example of how to exploit the

vulnerability? Again, I look to my litmus test, and I err on the

conservative side: It makes the overall problem bigger to disclose

example exploit code. Now, I realize that a lot of you are hissing and

spitting at me right now, and I can accept that criticism. My opinion is

unchanged by it, however.

There are good ways and bad ways of disclosing vulnerability information.

If we all share the goal of having secure applications that have had

their known defects fixed, then it’s in our collective best interest to

allow the product vendor the necessary time to properly engineer and test

security patches. Otherwise, we’re condemned to an existence of getting

security patches that have been developed under duress, cause other

problems, or just plain old don’t work right.

Come to think of it, that is a pretty accurate description of many of the

patches that we see from all too many of our software product vendors,

and that’s no coincidence.

RELATED NEWS AND ANALYSIS

• Huawei’s AI Update: Things Are Moving Faster Than We Think

  FEATURE |  By Rob Enderle,
  December 04, 2020

• Keeping Machine Learning Algorithms Honest in the ‘Ethics-First’ Era

  ARTIFICIAL INTELLIGENCE |  By Guest Author,
  November 18, 2020

• Key Trends in Chatbots and RPA

  FEATURE |  By Guest Author,
  November 10, 2020

• Top 10 AIOps Companies

  FEATURE |  By Samuel Greengard,
  November 05, 2020

• What is Text Analysis?

  ARTIFICIAL INTELLIGENCE |  By Guest Author,
  November 02, 2020

• How Intel’s Work With Autonomous Cars Could Redefine General Purpose AI

  ARTIFICIAL INTELLIGENCE |  By Rob Enderle,
  October 29, 2020

• Dell Technologies World: Weaving Together Human And Machine Interaction For AI And Robotics

  ARTIFICIAL INTELLIGENCE |  By Rob Enderle,
  October 23, 2020

• The Super Moderator, or How IBM Project Debater Could Save Social Media

  FEATURE |  By Rob Enderle,
  October 16, 2020

• Top 10 Chatbot Platforms

  FEATURE |  By Cynthia Harvey,
  October 07, 2020

• Finding a Career Path in AI

  ARTIFICIAL INTELLIGENCE |  By Guest Author,
  October 05, 2020

• CIOs Discuss the Promise of AI and Data Science

  FEATURE |  By Guest Author,
  September 25, 2020

• Microsoft Is Building An AI Product That Could Predict The Future

  FEATURE |  By Rob Enderle,
  September 25, 2020

• Top 10 Machine Learning Companies 2020

  FEATURE |  By Cynthia Harvey,
  September 22, 2020

• NVIDIA and ARM: Massively Changing The AI Landscape

  ARTIFICIAL INTELLIGENCE |  By Rob Enderle,
  September 18, 2020

• Continuous Intelligence: Expert Discussion [Video and Podcast]

  ARTIFICIAL INTELLIGENCE |  By James Maguire,
  September 14, 2020

• Artificial Intelligence: Governance and Ethics [Video]

  ARTIFICIAL INTELLIGENCE |  By James Maguire,
  September 13, 2020

• IBM Watson At The US Open: Showcasing The Power Of A Mature Enterprise-Class AI

  FEATURE |  By Rob Enderle,
  September 11, 2020

• Artificial Intelligence: Perception vs. Reality

  FEATURE |  By James Maguire,
  September 09, 2020

• Anticipating The Coming Wave Of AI Enhanced PCs

  FEATURE |  By Rob Enderle,
  September 05, 2020

• The Critical Nature Of IBM’s NLP (Natural Language Processing) Effort

  ARTIFICIAL INTELLIGENCE |  By Rob Enderle,
  August 14, 2020