A Vulnerability Intelligence program should be a key component of any sound network security strategy.  It should dovetail with a Vulnerability Assessment process and a patching/remediation process.  While a Vulnerability Assessment process will tell you what needs to be patched, Vulnerability Intelligence should tell you what needs to be patched first and what new patches need to be evaluated.

Like any intelligence process, be it on the battlefield in the form of Military Intelligence, or in the marketplace under the guise of Competitive Intelligence, Vulnerability Intelligence follows the same cycle:

Planning and Direction
Collection
Analysis
Dissemination

The start of the cycle is Planning and Direction.  This is when management and other stakeholders define the goals of the Vulnerability Intelligence.  If not enough time is spent defining these goals success of the program is at-risk.  The goals should be defined as the questions that management and other consumers want to have answered.  For example, "Is our environment unnecessarily vulnerable?" or "What attacks are we currently vulnerable to?" are somewhat broad, especially for an intelligence program "on-the-cheap."  Target questions such as: "what patches should we be focusing on today?"  or "How vulnerable are our mailservers?" are a bit easier to deal with on a budget.  Without such focus, a team runs the risk of dealing with what is currently getting the most media attention.  Which may not exactly meet your organization's goals.  Another decision that needs to made is the timeframe for the process.  If your organization requires a long head-start or advance-warning, then on-the-cheap may not provide you with the results that you need.

The Collection phase is often the phase that gets the most attention.  This is where all of the cool toys are, and where likely spends most of their budget.  Since this is all on-the-cheap, I am going to skip subscription based services and share a couple of my secret-weapons of collection.  First, never underestimate a good RSS feed.  There are numerous free sources of vulnerability intelligence to get you started.  Many offer RSS feeds that you can consult on a daily basis.  A program that I use to maximize my collection potential is Website Watcher (although I don't like to endorse products on this forum, this tool should be considered to save you a lot of daily websurfing www.aignes.com/).  Some good initial sources to monitor are the Bugtraq database at http://www.securityfocus.com/vulnerabilities (which has an associated RSS feed) and Secunia (http://secunia.com/) which offers you the advantage of monitoring a single technology.  Other sources that you will want to monitor are the security advisories of the vendors of products that are in your environment.  Getting the information directly from the vendor is a sound counter-FUD strategy.

Analysis is where collected information become intelligence.  The two most-common Vulnerability Intelligence analysis process are: "Does this impact our environment?" and "If so, how badly?"  A good inventory of deployed technologies or access to the discovery scan results of the latest vulnerability assessment sweep is helpful.  Should that not be available, a "better-safe-than-sorry" approach could be exercised where, when in doubt, the intelligence team assumes that the product is within the firm; this approach can be wasteful of resources.  When addressing the potential impact of a vulnerability, it can be more efficient for the intelligence group to assess the vulnerability's threat to a hypothetical system, and allow the engineers in the field to apply additional tweaking of the threat posed.  I'm a fan of the Common Vulnerability Scoring System because it offers such flexibility.  The intelligence group can monitor and tune the Temporal Metrics, and the individual engineering groups can modify their Environmental Metrics.  I've also seen a two-stage approach used in some environments, where the intelligence group assesses an initial threat rating based on the potential Confidentiality/Integrity/Availability impact against a theoretical machine, and the probability of a successful impact based upon ease of exploit and level of reported exploitation in the wild.  Then the different areas within the firm, such as the DMZ, or the desktops, further evaluate the vulnerability.  It's important that the intelligence group have some feedback on these ratings to ensure that there is a consensus on the rating, and not simply a case of a single department lowering the threat-ratings to save some effort.

Every phase is critical-- Dissemination is no exception.  This is where the message is sent to your consumers.  The message will have to be tailored to your audience.  Upper management will have different concerns than your engineers, a one-size-fits-all report will likely result in disappointment.  This is where your goals come into play, take the guiding questions and use those to tailor your reports.

Which takes us back into Planning and Development; don't pass up the opportunity for feedback from your consumers.  Set benchmarks for your process' performance, and re-tune.  It's often very attractive to simply add more sources for collection, just remember that every new source is more work to be done when you do your sweep, so set criteria for purging your sources.  Revisit your intelligence goals, add new questions, and re-focus existing questions.  Some questions are going to be long-term strategic issues, others will have a more tactical focus and short lifetime, such as "Does Google Desktop present a threat to the firm?" or "Are we exposed to the Symantec Antivirus Vulnerability?"

Vulnerability Intelligence is a process, much like many other processes used to secure your environment.  Much like those processes, there are expensive solutions, and solutions available on-the-cheap.

--
Kevin Liston
kliston at isc dot sans dot org