Administrivia: Response to OIS Draft on "Security Vulnerability and Response Process"

• Previous message: Russ: "Revised: Microsoft Security Bulletin - MS03-013"
• Next in thread: Thor Larholm: "Re: Administrivia: Response to OIS Draft on "Security Vulnerability and Response Process""
• Reply: Thor Larholm: "Re: Administrivia: Response to OIS Draft on "Security Vulnerability and Response Process""
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date:         Thu, 5 Jun 2003 13:42:49 -0400
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

If you've ever wondered why its so hard for Software companies to write
secure code, a quick look at the "Security Vulnerability Reporting and
Response Process" draft from the Organization for Internet Safety;

http://www.oisafety.org/process.html

might give you some ideas (don't go for the PDF unless you're prepared
to wait 10 minutes for each page to be displayed after you scroll.) With
57 things a "Finder" can/should do, and 89 things a "Vendor" could/might
do, the attempt by Vendors to overly burden the process with minute
detail is laughable.

I attempted to establish the "Responsible Disclosure Forum" first back
in May of 2001. Within that context, I promoted the adoption of certain
rules or a code of conduct, but its emphasis was on Vendors as opposed
to Finders. Finders, as we all know, can do anything they want. Only if
they feel Vendors are being responsive will the desire to work with them
increase. I proposed rewards for Finders who upheld the Responsible
Disclosure creed, and a large select-yet-open peer organization to
review initial reports. Full details can be seen at;

http://www.ntbugtraq.com/RDForum.asp

I'm amazed that something which never got any acceptance by any of the
players in the RFC attempt, nor this process document, has so many
similarities to both documents.

I was never contacted for comments on this latest effort, maybe it was
because they already knew my opinions and had incorporated them into
their thinking going into their effort...or maybe they just don't like
me...;-]

That said, I thought I would offer up my comments for your perusal.

The document is intended for companies or professional researchers (of
which I'll include those academia researchers who's only profit is their
degree or doctorate). Using some numbers I was once given by Elias Levy
at SecurityFocus.com, ~51% of vulnerabilities are reported by
individuals, not companies or professional researchers. The proposal
offers no incentives to these individuals whatsoever, and therefore
falls short of meeting the basic needs for any formality to this
process.

Its "Primary Purpose" is for Vendors, not consumers, nor the Internet,
nor the people who discover vulnerabilities outside of corporations paid
to do this work. Am I the only one to laugh at the irony, the
presumption, that these Vendors are willing to publish? Not only are
their products defective; they've sold them far and wide; people have
come to rely upon them, but now they believe the most effective way at
minimizing the risks they've placed you at is to encumber people who
spend their own personal, unrewarded, time with a plethora of procedures
and protocol for communication.

It is certainly reasonable for Vendors to expect they will receive some
notice, and enough details that the reasonably intelligent, and highly
paid staff at the Vendor will be able to figure out whether there's a
vulnerability or not.

It is equally reasonable that anyone who discovers a way for a remote
attacker to control thousands, if not millions, of Windows boxes
globally be rewarded for not irresponsibly disclosing such information.
But instead of rewards, the Vendors propose that unless the report is
filed properly, the individual may not receive any confirmation, or
communication.

Its "Secondary Purpose" suggests its going to "facilitate 3rd party
efforts to provide supplementary information and protection" and
"facilitate long-term research into software development techniques and
processes", but nothing I could see in the draft actually addresses
either of these points.

To specifics;

1.3 Use of this Reference Process

Its a 37 page process, and yet they expect Finders, Vendors, and
Coordinators to "clearly note all areas where their process differs from
this one". Ergo discoverers are going to have to pour through 37 pages
to see what they can expect, at each Vendor, or for each Coordinator,
and note what may be very subtle differences in any of the 146 "Process"
steps. Ridiculous.

Like RFCs, everyone involved will be able to claim compliance with the
"Reference Process" because you can do any or none of it. Since there
are no rights or obligations, it really boils down to whether or not you
as an individual wish to do this extra work for Vendors for nothing. As
a Vendor, there's very little you actually have to do in order to try
and convince your customers you're participating, and the Media will be
hard pressed to know whether you do or don't.

1.4 Scope

Its only for software and firmware, not hardware, networks, etc... Why??
There's no penalties for not participating, why wouldn't this proposal
cover all aspects of computing security...or are they working on a
different one for hardware, networks, etc...??

1.7 Process Maintenance

They propose updating the requirements no less than every 2 years, which
in practice will become 3-4 years if we go based on the software
industries track-record for providing maintenance releases on a
schedule. I guess "Internet-time" has been redefined.

2.1 Participants

Consumers and Media should be listed as participants too, but I guess
the Vendors figure Consumers and Media full under their purview.

2.3 Timeline

7 days to acknowledge receipt is ridiculous if Vendor has provided "an
easily discoverable location on their web site" for reporting such
issues. Worse, if the Vendor doesn't respond, its incumbent upon the
Finder to send a specially formatted email to the Vendor to "Request for
Confirmation"...duh...for which the Vendor is given another 3 days to
respond. So, at a minimum, it could be 7 days just for confirmation,
more likely 10, and possibly a lot longer if the Finder doesn't pester
the unresponsive Vendor.

The timeline should follow the same timeline that the Vendor provides to
its Premium customers for trouble ticket resolution, and treat the
Finder as such, otherwise it would be easier for the Finder to report
the flaw to the Vendor's biggest customer and let that customer pursue
the fix.

The 30 days to completion doesn't start until the Vendor acknowledges
the Finder's Vulnerability Summary Report (VSR). IOWs, it may well be 40
days (minimum) all of the time. They are, it seems, oblivious to the
fact that its unresponsiveness and the long time to release that cause
so many disclosures prior to fix. If a minimum of 40 days from discovery
to fix is a good minimum to you, please stand up.

So then there's a 30 day "grace-period" prior to more details being
published by anyone, except if you're sharing the information with
"people and organizations that play a critical role in advancing the
security of users, critical infrastructures, and the Internet"...and
they are? CNN? NYT? WSJ?

3. Discovery Phase

"Vendors finding security vulnerabilities in their own products is
outside the scope of this document"...why? Is the "security of users,
critical infrastructures, and the Internet" at less risk when the
discovery is made internally?

The Finder is expected to "perform some due diligence prior to
continuing on through the vulnerability reporting process", determining
whether the vulnerability is already known (how can they know, it may
have been discovered internally by the Vendor!), whether there's a fix
already available (again, how do they know?), and whether the
vulnerability affects the "default or a reasonable configuration of the
software". This last one is the best, the Finder is supposed to figure
out what is reasonable for all of a Vendors customers?? If only we all
had access to such great marketing demographics.

3.1.3

Actually encourages development of proof-of-concept code, great!

4.1 Contacting the Vendor

Non-email methods of contacts should be completely discouraged. We all
love the black hole of a Vendor feedback form on a website, don't we.
They provide no copy of the information for the Finder and no method of
verifying whether the report was actually delivered, let alone read.
Further, there is no way for the Finder to ensure their data is
unaltered on its way to the security individual or group, nor can they
be assured it will not be viewed by others en-route.

4.2.6

"If the Finder does not receive acknowledgment within seven (7) calendar
days of sending the RFCR, the Finder may, at its discretion, take the
steps described in the section titled "Resolving Communications
Difficulties and Deadlocks"."

The section referred to as "Resolving Communications Difficulties and
Deadlocks" is actually titled; "Resolving Conflicts, Deadlocks, and
Communications Breakdowns", so we start with a communication
difficulty...;-]

4.3 Public Notification of VSR

The Vendor gets the right to notify its customers during the
Notification phase prior to Investigation by the Vendor, but the Finder
does not have this right, despite the fact the Finder is supposed to
have verified their claims? This makes no sense. So much for coordinated
simultaneous disclosure discussed further on in the document, the Vendor
may choose to usurp you.

5. Investigation Phase

If Vendor is unresponsive, its up to Finder to notify Vendor that it
will be terminating the communications. IOWs, at the end of it all the
Vendor has a statement from Finder that they (Finder) is terminating
communications, rather than Vendor simply being in default.

5.4.2 Consultations During the Investigation

GOOD! Finder is not expected to provide additional details about the
flaw beyond the initial VSR if they choose not to or don't have the time
to.

5.5.2 Findings

Finder has to provide specific step-by-step instructions on how to
reproduce, but Vendor doesn't have to provide similar step-by-step
procedures they attempted in their testing.

5.5.4.2 Disproof

"Test results showing that the behavior only occurs when the product is
configured in a way that itself violates normal security practices and
exposes the system to significant risk."

This is crap. "Normal security practices" should not be considered a
valid reason for stating that something is not a security vulnerability.
Only if the "Normal default configuration/installation" does not expose
the vulnerability could the Vendor argue lowering the priority. If it is
possible for the product to be used in the fashion the Finder describes,
it should be considered a security vulnerability. Priority is the way to
address this, not "Disproof".

"Analysis of the attack scenario, showing that the behavior could not be
realistically exploited or could only be exploited in cases where the
system was already insecure by necessity."

Again, same as above. If a consumer chooses to use a machine insecurely,
they do so with either no knowledge they are using it insecurely (e.g.
typical home user), or, because they have weighed the risks associated
with the insecure installation. If a new vulnerability occurs only when
the system is insecurely used, this cannot be "Disproof" that the
vulnerability is, in fact, not a vulnerability. It is another data point
for the consumer to consider. Ergo, its still a vulnerability.

If a vulnerability relies upon the use of another vulnerability in order
to function, then that should be grounds for "Disproof". This has not
been listed.

6.1 Diagnosis

Finder was expected to determine if a fix already exists, but Vendor is
tasked with doing so in 6.1.1 and 6.1.2 anyway.

6.2 Remedy Types

"For instance, if a maintenance update were due to be released
imminently, it might be appropriate to use it as the vehicle for fixing
a particular security vulnerability. In contrast, if the maintenance
update were many months from release, the same vulnerability might
warrant a patch or a configuration change."

This is crap. Service Packs or Maintenance Releases should never be used
as the only vehicle for security fixes. Security fixes should always be
made available as "patches" so that anyone using an affected product is
not compelled to install a service pack or maintenance release as the
only method of obtaining a security fix. Testing of security fixes
should be left to the security issue only, not combined with 10's or
100's of other issues which would also need to be tested prior to
applying the security fix.

6.4 Internationalization

"If the affected products are available in multiple languages, the
Vendor shall ensure that a remedy is delivered for each of the supported
languages."

This should either be simultaneously, or, in priority order where the
Vendor states in advance the priority it places on each language
version.

6.6.4 Synchronization

"If the Vendor chooses to release its remedy independently, it shall
limit the information it publishes about the vulnerability, in order to
avoid putting at risk other users who may not have a remedy available."

How do you do this in open source efforts where all it takes is a DIFF
to determine the changes?

6.7 Timeframe

30 days should start from the day the Finder submits the report to the
Vendor, not the day the Vendor acknowledges receipt of the VSR. Why make
the process so Vendor biased?...oh, yeah, right, you're all Vendors!!

6.7.4

"The Vendor may, at its discretion, publish a workaround as an interim
remedy. However, the Vendor shall do so only if, in its judgment, the
workaround is sufficiently non-disruptive that it is likely to be
adopted by a significant percentage of users and publishing the
workaround will not disclose details that would enable the vulnerability
to be exploited."

If the workaround has been proposed by the Finder, and not solely
developed by the Vendor, then the Vendor should give the Finder the
right to first publish the workaround together with some reasonable
information about the vulnerability. Credit should not cede to the
Vendor by virtue of the fact they cannot effect a patch in a reasonable
amount of time.

7.3.15 Security Advisory

Why is it the responsibility of the Finder to include references to the
Vendors information, but not vice-versa? Shouldn't the Vendor be
compelled equally?

8. Conflict Resolution and Third Parties

Well, let's just say this whole section is somewhat laughable.

Cheers,
Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor

oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Delivery co-sponsored by TruSecure
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
FREE 14-DAY TRIAL of New Threat & Vulnerability Notification Service

TruSecure's new IntelliShield(tm) web-based threat and vulnerability
service isn't your typical alert service. Supported by TruSecure's vast
intelligence resources - including the ICSA Labs - IntelliShield's early
warning, analysis, decision support, and threat management tools provide
organizations with unmatched intelligence to better protect critical
information assets. Experience it for yourself - just click below to begin
your FREE, NO OBLIGATION 14-day trial today!

http://www.trusecure.com/offer/s0074/

oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

• Previous message: Russ: "Revised: Microsoft Security Bulletin - MS03-013"
• Next in thread: Thor Larholm: "Re: Administrivia: Response to OIS Draft on "Security Vulnerability and Response Process""
• Reply: Thor Larholm: "Re: Administrivia: Response to OIS Draft on "Security Vulnerability and Response Process""
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]