It’s the age-old battle of security: to disclose or not to disclose
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
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
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.