Re: vulnerability database

[emerson.c.tan () CA ARTHURANDERSEN COM (Emerson Tan)]

> > I am in the process of creating a database of vulnerabilities/exploits.
> > I was wondering if anyone, who as attempted such a task, could give me
> > some description of their past experiences.  To start, advice/tips on
> > how to effectively structure the schema and where some good sources of

> How to structure the schema is directly related to what use you'll make
> of the db.
> One thing i'd do no matter what the db will be used for, is to isolate
> the purely technical information in just a few tables, here im assuming
> that the db is not containing just vuln/exploit information but other
> things that relate those to the real world.

The primary purposes of a database like this is to give poor sysadmins and IT
manager types the info they need to assign priorities when it comes to fixing
security problems, and also informing developers of outstanding issues withthe
code they are responible for authoring.

Therefore it's going to need to be really simple in one respect (so non techie
types can use it to establish how at risk they are) and really deep in another
so that developers and other deep tech types can use it to actually fix the
problems. Therefore I going to suggest some 'features':

- Management Information Table: Arbitary general risk rating of the problem into
high, medium and low, Platform, Application, and Versions affected. Importantly
I would also put a potential 'business impact' field in there. This would be
useful in prioritising which vunerabilities get fixed first. Sticking a vendor
response field in there would also bring non responsiveness to the attention of
business types who might be able to get vendors to actually respond to these
issues by applying pressure. Metrics and trend information should be dumped here
too, as I suspect that for most of the readers of the technical information this
is going to be irrelvant.

-Exploit information and source code: This obviously needs to be there so
Sysadmins can test it against their own boxes and so developers can understand
the nature of the problem.

-Fix / Workaround Information: Obvious really.

-Moderated Disscussion: I would stick this in so that people who think they have
a potential solution or a new take on the problem can post their thoughts to
somewhere where others can work on it. While this is no replacement for lists
like bugtraq, I think it would be helpful for those with neither the time or who
are unwilling to spend the effort wading through list archives to try and get
specfic information about a particular problem.

> > OTOH, the common usage of a 'risk factor' associated with
> > vulnerabilities
> > makes no sense, the risk and impact is always dependant of the
> > particular characteristics of the organization with the vulnerable
> > systems.

The metrics to work out business impact are relatively well understood and I
think while, highly dependent on the nature of the organisation, it would be
possible to put into general terms the imapct on businesses depending on their
dependence on the affected system. While it will be very difficult to put
figures on impact, I think it will be possible to put in rounded terms.

> > data for DB population can be found.  Also, are there any publically
> > available vuln./exp. DB's either provided by commercial businesses or
> > alternative sources?

checkout:
http://www.securityfocus.com/vdb
http://cve.mitre.org
http://xforce.iss.net

quite a few vendors are working on products like these, but a database like this
really needs to be in the public domain, with no one sponsor or owner. While
it's probably the basis of a viable commercial service, it should be in the
public domain, as demonstrated recently, security is everybodies concern, not
just those with the ability to pay.

Emerson

*******************Internet Email Confidentiality Footer*******************

Privileged/Confidential Information may be contained in this message.  If you
are not the addressee indicated in this message (or responsible for delivery of
the message to such person), you may not copy or deliver this message to anyone.
In such case, you should destroy this message and kindly notify the sender by
reply email. Please advise immediately if you or your employer do not consent to
Internet email for messages of this kind.  Opinions, conclusions and other
information in this message that do not relate to the official business of my
firm shall be understood as neither given nor endorsed by it.