From: Andre Gironda (andreg@gmail.com)
Date: Thu Feb 28 2008 - 20:58:27 EST
On Thu, Feb 28, 2008 at 3:52 AM, Robert E. Lee <robert@outpost24.com> wrote:
> A better use of time for most companies would be to use a thorough
> vulnerability assessment and management solution. VAM solutions can:
Using VAM might be bad terminology. Only one vendor uses this
terminology. If the world revolved around StillSecure's VAM product,
and HP SPI Dynamics' APM product (for web applications) - then
everybody who used these products would be secure. This is not the
case.
> * Identify new vulnerabilities - far more than an exploit framework
Cassandra, Advchk, SIGVI, OSVDB 2.0 can make this easier to work with.
https://cassandra.cerias.purdue.edu
http://freshmeat.net/projects/advchk/ (the main site is often down)
http://sigvi.sourceforge.net
I prefer these methods as the primary source of new vulnerability
information, as they are very passive and do not require a lot of
customization. They make you less interrupt-driven.
Second sources of information should include: Google Alerts, Google
Reader RSS, and Google Blog Search RSS. Relying completely on Google
is probably a bad idea, so other OSINT sources can also be used. The
primary keywords and feeds that these services can aggregate include
the obvious places: Full-Disclosure, Bugtraq/SecurityFocus, Secunia,
NIST NVD, OSVDB, SecurityTracker, SecuriTeam, PacketstormSecurity, et
al.
Running a constant scan (or daily, weekly, monthly scan) is not highly
recommended by myself. First of all, it's impact-oriented and can
cause more problems that it solves. Secondly, there is the notion of
strike-back. Scanners are extremely delicate software that require
strong assurance. They do a lot of scraping of content, which
involves crawling and parsing using a variety of file formats and
protocols. This makes them not only the most vulnerable pieces of
software on your network (maybe besides AV or patch management
solutions), but probably also the most likely to be targeted by
intelligent adversaries.
Even viewing the reports from any "vulnerability/exploitation"
management product/service is a "UXSS with local file access
submarine" waiting to happen. I use MOICE to open Office 2007
documents, which I prefer to be in 2007 XML format. Having a separate
blow-away account and/or virtual machine just to view PDF's doesn't
seem like a bad idea in this day-and-age. Adobe doesn't seem to care
that their Reader product is one of the most insecure applications on
the planet - and you can bet that Apple, Linux, and Foxit based PDF
readers have the same problems or worse. Even XML/HTML/CSS/JS/Flash
based reports should scare you because of XSS, HTMLi/CSSi, XXE, et al.
I use a pedantically configured NoScript, LocalRodeo, and multiple
Firefox profiles, but this is beyond most people.
> * Assign vulnerability related tasks to the responsible Sys Admins
Or defect tracking reports to developers in the case of custom
applications, such as web applications.
I know that mappings between ISO27k, ITIL, and COBIT exist, so this
sort of structure is going to be most useful to solve these
organizational issues for companies under SOX 404 or those considering
following it. I've seen a few places that do this, including the most
recent book on "Sarbanes-Oxley: IT Compliance Using Open-Source Tools,
Second Edition" as well as this resource (I found it from Andy
Jaquith's good Security Metrics book) -
http://www.isaca.org/Template.cfm?Section=Home&CONTENTID=22493&TEMPLATE=/ContentManagement/ContentDisplay.cfm
I think Trac is a fairly nice workflow, wiki, and defect-tracking
system in one. However, I'm really partial to using MediaWiki,
WordPress, and Joomla for damn near everything application-related
these days. I read and follow Blogsecurity.net
Also - I'd prefer something a bit more proactive then "assign some
dood a way to fix something that shouldn't have been messed up in the
first place". If the dood was "responsible", he (or she) wouldn't
have make the mistake and allowed a vulnerability (especially a
critical one) in a key piece of an infrastructure or application.
> * Allow for retesting of the device/vulnerability to ensure the it was
> properly mitigated
Regression testing is one of my favorite topics (although Refactoring
is my new favorite topic - actually no it's Requirements). I based
the Continuous-Prevention Security Lifecycle (CPSL) on the idea of
"continuous-prevention development". The difference between
continuous-prevention development and regression testing is that
continuous-prevention asserts for the defect's fix. In this way, you
automatically fix defects and trap on related defects. When done in
unit testing, this can only really help with input validation and
special character whitelists/blacklists, but other security properties
can be tested in-container using the dependency injection design
pattern aka IoC (Inversion of Container). I described this sort of
process in my recent talks at Shmoocon and Toorcon.
However, I hadn't thought of how these concepts would translate to the
classic "known vulnerability" assessment and management world.
> * Show trending over time
Balanced scorecards and enterprise management dashboards are some of
the best ways to show trending over time. Andrew Jaquith and Gunnar
Peterson talk about these in their books, blogs, and articles. Even
Mike Rothman gets in on this every once in awhile, and he mentions how
to deal with measurements in his Pragmatic-CSO book. Most people that
I know avoid the words, "Six Sigma", but it's probably because they
don't know what the name really means.
Cheers,
Andre
------------------------------------------------------------------------
This list is sponsored by: Cenzic
Need to secure your web apps NOW?
Cenzic finds more, "real" vulnerabilities fast.
Click to try it, buy it or download a solution FREE today!
http://www.cenzic.com/downloads
------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:58:26 EDT