CERIAS - Center for Education and Research in Information Assurance and Security

Skip Navigation
CERIAS Logo
Purdue University
Center for Education and Research in Information Assurance and Security

Cassandra Vulnerability Updates

Share:

The Cassandra system has been much more successful and long lasting than I first imagined.  Being inexperienced at the time, there were some things I got wrong, such as deleting inactive accounts (I stopped that very quickly as it made many people unhappy or unwilling to use the service), or deleting accounts that bounced several emails (several years ago this was changed to simply invalidating the email address).  Recently I improved it by adding GPG signatures.  Email notifications from Cassandra are now cryptographically signed. The public key is available on the standard public key servers, such as the MIT server.


Things can still be improved


I initially envisioned profiles as being updated regularly, perhaps with automated tools listing the applications installed on a system.  I also thought that there were many applications without vulnerability entries in MITRE’s CVE, the National Vulnerability Database (NVD, used to be named ICAT), or Secunia so I needed to let people enter product and vendor names that weren’t linked to any vulnerabilities.  However, I found that there was little correlation between the names of products in these sources, as well as between those provided by scanning tools or entered manually by users.  ICAT in particular used to be quite bad for using inconsistent or misspelled names.  Secunia does not separate vendor names from products and uses different names than the NVD, so Cassandra has to guess which is which based on already known vendor and product names.  Because of this, Secunia entries may need reparsing when new names are learned.  So, users could get a false sense of security by entering the name of the products they use, but never get notified because of a mismatch!  On top of it, bad names are listed by the autocomplete feature, so users can be mislead by someone else’s mistakes or misfortune.  A Cassandra feature that helped somewhat with this problem was the notion of canonical and variant names.  All variants point to a single canonical name for a vendor or a product.  However, these need to be entered manually and maintained over time, so I didn’t enter many.

It gets worse.  Profiles are quite static in practice;  this leads to other problems.  Companies merge, get bought or otherwise change names. Sometimes companies also decide to change the names of their products for other reasons, or names are changed in the NVD. So, profiles can silently drift off-course and not give the alerts needed. All these factors result in product or vendor names in Cassandra that don’t point to any vulnerability entries.  I call these names “orphans”;  I recently realized that Cassandra contained hundreds of orphaned names.


And they will be improved


I am planning on implementing two new features in Cassandra:  Profile auto-correction and product name vetting.

  • Auto-correction: If Cassandra recognizes a name change in the NVD or Secunia, or if it changes the way it recognizes vendor names from products in Secunia, it will attempt to change matching entries in your profiles.
  • Vetting: all the product names in Cassandra will be verified to point to at least one entry in the NVD or Secunia; those that don’t and can’t be updated will get deleted. This means that when you create a new profile, Cassandra won’t suggest an “orphaned” name. If your profile contains an orphaned name that gets deleted, you should receive an email if you have email notifications turned on.

Note that you should still verify your profiles periodically, because Cassandra will not detect all name changes—this is difficult because a name change may look just like a new product.  If you have a product name that isn’t in Cassandra, I suggest using the keywords feature.  Cassandra will then search the title and description of the entries to find matches (note to self: pehaps keywords should search product and vendor names as well—that would help catch all variants of a name.  Also, consider using string matching algorithms to recognize names).

Comments

Posted by Pascal Meunier
on Thursday, July 19, 2007 at 06:38 AM

I had better ideas. 

For vetting, when looking for matches in a profile, if a profile entry doesn’t match any vulnerability or advisory at all (previously emailed or not, recent or not), then I’ll email the owner if email notifications have been allowed, saying there’s a problem with the profile.  Daily, I’ll also delete application and vendor names that are unused and not pointing to any vulnerabilities or advisories.  This is a gentler way of doing it that will also solve the problem.

For auto-correction, I could detect all changes by periodically checking the entire NVD database against Cassandra.  Product or vendor names that have disappeared could indicate a name change.  This way I can make sure that all name changes are detected.

Any comments or suggestions before I proceed?

Posted by Pascal Meunier
on Friday, July 20, 2007 at 07:47 AM

I have deleted unused products and vendors that don’t point to NVD entries or Secunia advisories.  Users should also now get notices about entries in their profiles that don’t point to any NVD entries or Secunia advisories.

Posted by Pascal Meunier
on Friday, July 27, 2007 at 02:36 AM

After sending warnings for several days, I have set the scripts to email reminders of problems in profiles only every two weeks.  There’s no point to flooding people’s email boxes, and if they haven’t taken action by now, continuing to send emails won’t help.

Leave a comment

Commenting is not available in this section entry.