Re: computer/vulnerability database

[etd <etd () nomejortu com>]

Hi,

My first thoughts about the vuln. db included tables for: hosts,
protocols (tcp/udp/icmp/..), services-ports. Then to each service you
could add notes (and each note belonged to a category). This
crystallised  in the 1.x release of an open source tool called dradis
(i). It is a tool we use when doing security reviews, the result looked
something like (ii).

However, soon we found that while this architecture was great for
network-level pentests, it wasn't ideal for application security, you
ended app with one host, port 80, an then a huge list of notes. Say for
instance you have to different apps in the same host and port and want
to keep track vulnerabilities for both of them, this needs to be done at
a note level (maybe add '/app1/' and '/app2/' categories and assign
notes to each). So we did the architecture over to try to make the tool
useful for any type of security assessment / vulnerability tracking.
Now, in the 2.x branch, we have 'nodes' and 'notes'. A node can be
anything, a host, a port, an application level, and each node has many
notes. The result in (iii), there is also a flash video of the web
interface (iv).

The bottom line is, if you want your tool to be useful in a number of
assessments (apps, wifi, etc.) and not only in network-level ones, the
underlaying database has to be a little more flexible.

Hope this helps,

etd


  (i) http://dradis.sourceforge.net/
 (ii) http://dradis.nomejortu.com/images/screenshot/client_v1.1_04.png
(iii) http://dradis.nomejortu.com/images/screenshot/client_v2.0-vegas_01.png
 (iv) http://dradis.nomejortu.com/videos/dradis2-01.html

John Kinsella wrote:
> I wrote most of the vuln reporting module at my last gig.  This depends
> a little on if you're reporting for internal use, or in a consulting
> role, but here's the things people are interested in, in general:
>  * Unique identifier for vuln: some sort of 3rd party ID that you can
> look up to provide specifics about the vuln.  Either an CVE ID, OSVDB
> ID, Bugtraq ID, Secunia, etc.
>  * When the vuln was detected
>  * Vuln severity
>  * Valuation of machine - this plays in with CVSS
> http://www.first.org/cvss/cvss-guide.html
>  * Ability to mark a finding a false positive would be handy
>  * Ability to make notes also would be handy
>
> So, what this leaves you with is 3 tables:
>  * Machine definition
>  * Vuln definition
>  * Link between those two tables
>
> For bonus points, I could see having a 4th table that could allow you to
> group collections of vuln instances together.
>
> Anybody think there's interest in coming up with a formal spec for this?
> Just thinking randomly, I could see either a module for drupal, or some
> sort of stand-alone vuln tracker package...actually something like that
> must exist, already?
>
> OSVDB's schema is pretty well done - overkill for what you want, but
> will get the brain thinking: http://osvdb.org/database_info
>
> (NIST's isn't bad, either...)
>
> John
>
> On Jan 9, 2009, at 5:01 AM, Shenk, Jerry A wrote:
>
> > Does anybody have any thoughts about a database for an audit to contain
> > current vulnerability issues and subsequent updates?
> >
> > I imagine that it should have at least two tables - one table for
> > computers and another table for vulnerabilities.  Obviously, each
> > computer can have multiple vulnerabilities and it would be nice to be
> > able to generate a report for each vulnerability.  I also think it would
> > be good to have the ability to note when vulnerabilities are resolved as
> > an additional note.
> >
> >
> > **DISCLAIMER
> > This e-mail message and any files transmitted with it are intended for
> > the use of the individual or entity to which they are addressed and
> > may contain information that is privileged, proprietary and
> > confidential. If you are not the intended recipient, you may not use,
> > copy or disclose to anyone the message or any information contained in
> > the message. If you have received this communication in error, please
> > notify the sender and delete this e-mail message. The contents do not
> > represent the opinion of D&E except to the extent that it relates to
> > their official business.