Vendor Vulnerability Analysis – How To Part 1

In a given environment, whether small, medium, large or enterprise class, there are a multitude of systems involved in keeping the business running, and providing that connection with the customer.  Every system is a machine, and machines need servicing often.  Part of that servicing is to introduce improvements and corrective measures, especially regarding security, since that is the area that will be directly attacked in order to impact your business, provide others a competitive edge, or outright theft from your business and customers.

Long gone are the days when you could stand a server up, connect it to the internet and seldom think about that server again.  Firewalls can keep out the obvious attacks, but fixing the root cause is still the best method for avoiding disaster.

TARGETS – Opportunity & Choice

Targets of Opportunity:  These are places that are often stumbled upon when researching the reach and spread of a given vulnerability.  A researcher discovers a vulnerability that can allow them to take over entire networks.  How far and wide is the vulnerable product deployed?  Where is it directly exploitable, and what supporting mechanisms will aid in attacking protected targets?  Targets of opportunity are typically attacked because they are vulnerable to a discovered vulnerability, and may lead to simplifying the attack of a target of choice.  They are often connected to many other organizations through a variety of means and relationships.  These relationships can be exploited as easily or more so than their networks.

Targets of Choice:  Why do bank robbers rob banks?  Because that is where the money is.  Targets of choice are any business that holds items of interest and value to the attacker.  Banks are by no means the only targets of choice, any organization or government installation that holds trade or other secrets, data that can be used to gain money, information, power or an advantage over others is sought after.  Any organization that holds credit card information, personal information, identity credentials, cash or tradable commodities, provides goods and/or services (and what business doesn’t?) is at risk of having those resources targeted, harvested, and potentially stolen.


The lifecycle of a typical vulnerability is:

  • Research
  • Discovery & Announcement
  • Vulnerability Assessment
  • Mitigation Development
  • Patch Development
  • Patch Delivery
  • Patch Analysis
  • Patch Deployment
  • Deployment Validation
  • Vulnerability Verification


There are countless independent and commercial security researchers around the globe.  These are a special breed of programmers, security professionals, and enthusiasts who enjoy exploring the abilities, resilience and limitations of software and those who developed it.

Researchers will often use “fuzzers”, programs designed to provide invalid, unexpected, or random data to the inputs of a program in order to produce unexpected outputs or results.  For the purpose of security, input that crosses a trust boundary is often the most interesting.  Anytime that credentials may be exposed, an area of memory may be overwritten or read without authority, or other assets can be accessed without bounds checking will be considered security issues, and garner the most interest.


Once a researcher has discovered a vulnerability in software or systems, they have many choices to make regarding how the vulnerability will be disclosed to the vendor and the public at large.

  • Responsible Disclosure:  Responsible disclosure is a voluntary mechanism for sharing information that could otherwise be detrimental to the software vendor and those customers that make use of the software.  It implies an understanding that the vendor of the software wants to create good software, and given the opportunity, will provide a patch for proven problems in a timely manner.  The researcher will make reasonable efforts to contact the vendor and alert them to their findings.  It is good form for the vendor to acknowledge the vulnerability submission, and to provide an ETA for follow-up discussion or for fixing the vulnerability.  The researcher generally waits a set amount of time negotiated or specified at the time of disclosure before going public with their findings.  The researcher is generally looking for notoriety and recognition from the vendors and security community members for their efforts and skills, possibly promoting their security related business and seeking paid or unpaid speaking engagements.
  • Full Disclosure:  Full disclosure is not the antithesis of Responsible Disclosure.  It is more often an alternative that is followed after a vendor does not acknowledge, rebuffs or calls into doubt the reality of the vulnerability or the credibility of the researcher.  If a vendor does not acknowledge receiving a vulnerability disclosure, does not communicate with the researcher, or follow-up in a timely manner, the researcher may always take the vulnerability to the streets.  Once a serious vulnerability is public knowledge, development of exploit code for a problem that the vendor does not appear interested in begins in earnest.  The researcher is generally looking for notoriety and recognition from their peers, vendors and the general public for their efforts and skills, possible promotion of their security related business, and paid speaking engagements.
  • Paid Disclosure:  Paid disclosure is performed by commercial vulnerability clearing houses, independent and commercial researchers.  Vendors often look upon this brand of research as little more than black-mail by “hackers-for-hire”.  The researcher makes a claim, produces a report, and sometimes demonstrates the capabilities and ease of exploitation of a given vulnerability through video capture, and will disclose the code and methods used for cash.  While not as altruistic as Responsible or Full Disclosure, it is a business model, and cash is king.  The researcher is generally looking for payment from the vendor possible promotion of their security related business, and paid speaking engagements.
  • Irresponsible Disclosure:  Irresponsible Disclosure entails not disclosing a vulnerability to the public or the vendor, while sharing the knowledge with those who would do damage to the vendor and their customers.  This lack of action with the vendor means that the vulnerability stands little chance of being fixed quickly, and implies that the researcher has other, less altruistic intentions.  This is usually an indication that the researcher is motivated by notoriety or acclaim with those that they consider the computer elite, those that they would like to call their peers.  Vulnerability information is traded on the black market like hockey cards, with automatic remote code execution vulnerabilities fetching the largest paycheck.
  • Non-Disclosure:  Non-Disclosure is very similar to irresponsible disclosure.  The key differences being the lack of any announcement at all, and the motivation of the researcher to keep things quiet.  They are less driven by the need to be recognized by their heroes and peers, need less to be held in great regard for their knowledge or skills, or to be part of some group or cause.  They are typically driven by their desire for making money, either on the black market, or by exploiting the vulnerability directly, and their desire fro worldly goods and wealth. 

Vulnerability managers need to be aware of all of these discovery announcement methods, and attuned to as many as possible to stay on top of exploit development efforts and pending attacks on targets of opportunity and choice.  The more intelligence that a VM can gather regarding those factors that contribute to risk, the better the chances of avoiding a crippling attack, the loss of revenue and data, and the disaster fallout that is certain to follow.