HP OSMS white paper: Security of Open Source Middleware Stacks

Figure 7 Threat Risk to Hardened System
It is unwise to assume that there is plenty of time to deploy security patches after they are available. The
vulnerability life cycle can be well underway and unpatched systems are extremely vulnerable, so you
should always apply security patches immediately.
Unfortunately, significant numbers of systems remain unpatched after a patch is available. The failure to
apply patches in a timely manner unnecessarily extends the window of opportunity for attackers to exploit
vulnerabilities.
Patching otherwise reliable systems represents a degree of risk. Introducing new software through a patch
represents an unknown effect to the reliability of computer systems. This risk should be weighed against
the security risk represented by the unpatched software. Testing for undesirable side effects reduces the
risk of patch side effects and should be mandatory for any critical systems. However, timing is also a factor
because the delay between vulnerability disclosure and patch application increases security risk.
Tracking Vulnerability
Unlike proprietary software produced by a single entity, cooperating entities manage open source software
development. This allows the open source community to be agile during the development process because
each package developer can work independently. However, there is no omnipotent overseer ensuring the
proper management of security processes.
Knowing whether a particular system, component, or library is vulnerable is critical in determining the
current risks a system faces. The downside of the open source independent infrastructure is the lack of
easy management of software vulnerabilities. Though there are various agencies that track vulnerabilities,
it is problematic to determine definitively if an individual system is vulnerable at any given moment.
For example, a search for a component by package name and version produces naming conflicts. The
CERT database attempts to correct this issue. However, the latency between the first report of a vulnerability
and the appearance in this database poses significant exposure to new exploits, such as zero day attacks.
The open source development process is observable, so one solution available to system managers is to
monitor the developer bulletin boards for critical system components and track vulnerabilities as they
flow through the layers of open source organizations. Typically, vulnerabilities begin with an initial bug
report submitted to the package maintainer, who confirms the submission, produces a security vulnerability
announcement, creates a patch, and adds it to the current stable stream. Linux distributions then apply
this fix to the OS packages in their distribution and make their own announcement.
Waiting for this patch announcement can leave a system vulnerable for an unnecessary period. Learning
of a vulnerability as quickly as possible enables the implementation of other countermeasures. For example,
Essential Security 15