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).