I recently was investigating an open source software package and my Norton 360 Virus Scanner alerted me to some malware. I was bothered by the fact the initial search query came from a site I generally trusted. Then as I dug deeper, Google-ing more, I encountered a warning message from Google that the link was potentially harmful. First of all, thanks Google. Second of all, I wanted to know if the problem was actually due to the software, which was a well-known package hosted on many web sites.
I went to the National Vulnerability Database website, which is operated by the National Institute of Standards and Technology (NIST) with the intention of searching for any vulnerability associated with this software. What is the National Vulnerability Database? The quote below is from their website here.
NVD is the U.S. government repository of standards based vulnerability management data. This data enables automation of vulnerability management, security measurement, and compliance (e.g. FISMA).
This is a very large database to track active issues in software that can leave a computer system vulnerable. This database is frequently used by web security professionals to mitigate the risk that installed software can present to the security of a computing environment. It’s also used by companies that make virus scanning software and other tools used to discover threats to a computer system. Think of McAfee and Symantec.
It’s interesting to note, upon reviewing the information provided there, that this database has over 51 thousand vulnerabilities in it and is accumulating computer vulnerabilities at the rate of 13 per day.
CVE, A Common Language to Describe Vulnerabilities
Also one of the most important aspect of implementing this database is the framework of a common language to describe vulnerabilities. Databases need unique keys to relate to other records and if you want to build a good database of vulnerabilities you need a unique number for each vulnerability. Enter the CVE, a common language used to identify type of problems in software.
This standard is known a CVE or “Common Vulnerabilities Enumeration” or “Common Vulnerabilities and Exposures“. CVE is essentially a construct that allows two or more databases which contain common vulnerabilities to communicate better. The CVE is managed by the non-profit MITRE corporation.
So when you locate a vulnerability it should have a “CVE” number associated with it. Using this number you can then locate any known methods to reduce or eliminate the vulnerability. There are products and services built around the CVE Identification number which you can locate here at the MITRE web site page of CVE Products and services.
National Vulnerability Database Free Search Tool
So, using the NVD site, I used their free search tool to get more information. A search using the name of the software showed several 26 results.Then I found the specific result that seemed to invite the malware in the first place. So, to make a short story even shorter, I found the software mentioned and the specific vulnerability. At that point I knew I had to find out how to mitigate the risk of using this software and specifically, what remedies could be applied. The best resource for this kind of information should come from the vendor of the software itself.
open source software / total cost of ownership
The particular tool I was looking at was built all on open source software. The vendor provided some pay as you go technical support at $100 per ticket. You could also pay for custom development, which was $80 per hour for custom programming services. So these additional costs have to go into the final estimate of the ‘total cost of ownership’.
I’ve seen instances where software that was purchases for an organization that was based on open source and appeared to be very low-cost however over time the actual cost of owning the product turned out to be quite a lot more than originally expected.
Off the Shelf Software
This is one of the core issues of ‘off the shelf’ versus custom development. Development can be expensive. Yet sometimes off the shelf software is much more expensive than originally estimated for. That also has to figure into the equation.
In any case, before your organization picks a particular piece of software, as part of your due diligence look into any vulnerabilities that may exist. You should even do this (at least) annually since new vulnerabilities are found every day.