0

Half Year Report 2011 Date: 14th July 2011

1

Abstract The first part of this report investigates the evolving threat of software portfolios typically found in organisations. Today, cybercriminals bypass traditional perimeter defences by means of the automated mass production of attack variants – thereby initiating an arms race with defenders. Security patches are found to be an effective means to escape the arms race as they remediate the root cause of compromise. Quantifying the dynamics of critical programs in software portfolios of up to 5,000 programs over the last few years identifies an increasing gap of unmitigated risk if the patching strategy covers Microsoft products only. Timely patching of the software portfolio of any organisation is like chasing a continually moving target. A comparison of different patching strategies under the assumption of limited resources demonstrates that an intelligent patching strategy is an effective approach for reducing vulnerability risks: An 80% reduction in risk can be achieved by either patching the 12 most critical or the 37 most prevalent programs in a sample portfolio. Furthermore, for the majority of vulnerabilities there are patches available on the day of disclosure, which puts another perspective on the threat of 0-days. The second section of this report presents global vulnerability data from the last five years and documents trends on a year-to-year basis as of June 2011. Comparing the data from the last two 12 month periods as of June 2011 as well as the extrapolated trend for 2011 indicates a slow decrease in the global number of vulnerabilities.

Key findings

Security patches are found to be an effective means to escape the arms race, as they remediate the root cause of compromise.

Quantifying the dynamics of critical programs in software portfolios of up to 5,000 programs over the last

few years identifies an increasing gap of unmitigated risk if the patching strategy covers Microsoft products only.

Timely patching of the software portfolio of any organisation is like chasing a continually moving target.

A comparison of different patching strategies under the assumption of limited resources demonstrates that

an intelligent patching strategy is an effective approach for reducing vulnerability risks.

An 80% reduction in risk can be achieved by either patching the 12 most critical or the 37 most prevalent programs in a sample portfolio.

For the majority of vulnerabilities there are patches available on the day of disclosure, which puts a different

perspective on the threat of 0-days.

Despite a slight overall decrease in the total number of vulnerabilities we have seen a significant increase from 24% to 30% for the "System Access" impact class, which is considered the most critical impact class.

There has been an increase in the number of advisories for which a patch was available at the day of

disclosure. The patch "availability rate" has increased from 47% to 55% when comparing the last 12 months with the previous 12 months. This indicates that more researchers are coordinating the disclosure.

There is currently no patch available for 26% of all advisories released during the past 24 months.

2

Table of Contents Letter from the CSO – Corporate Strategy and IT Security ............................................................................................................ 3

End-Point Security & Evolving Threats .................................................................................................................................................... 4

From a Cybercriminal’s Perspective .................................................................................................................................................... 4

Easy Prey ..................................................................................................................................................................................................... 4

Origin of Vulnerabilities .......................................................................................................................................................................... 5

Cybercriminals Do Not Need 0-day Vulnerabilities ....................................................................................................................... 5

Protecting a Moving Target .................................................................................................................................................................... 7

Comparing Patching Strategies.............................................................................................................................................................. 8

Patch Availability ..................................................................................................................................................................................... 11

Risk of Testing vs. Risk of Patching .................................................................................................................................................... 11

Cost of a Failed Patch ............................................................................................................................................................................ 12

Global Vulnerability Trends ...................................................................................................................................................................... 12

Secunia Vulnerability Intelligence ........................................................................................................................................................ 12

History and Vulnerability Trends for 2011 ...................................................................................................................................... 13

Secunia Advisories .................................................................................................................................................................................. 13

Common Vulnerabilities and Exposures (CVE) .............................................................................................................................. 13

Secunia Vulnerability Counts ............................................................................................................................................................... 14

Analysis ...................................................................................................................................................................................................... 14

Types of Vulnerabilities ......................................................................................................................................................................... 15

Attack Vector .......................................................................................................................................................................................... 15

Criticality .................................................................................................................................................................................................. 16

Impact ........................................................................................................................................................................................................ 16

Solution Status & Patch Availability .................................................................................................................................................... 17

Summary ................................................................................................................................................................................................... 19

I. Appendix .................................................................................................................................................................................................... 20

Vulnerability Criticality Classification ................................................................................................................................................ 20

Attack Vector Classification ................................................................................................................................................................ 21

Vulnerability Criticality Classification ................................................................................................................................................ 22

About Secunia .............................................................................................................................................................................................. 23

3

Letter from the CSO – Corporate Strategy and IT Security During the past months, we have witnessed high profile companies falling victims to malicious attacks with devastating effects. OSF DataLossDB and Zone-H continuously report about companies and sites of all sizes that have been compromised. In the consumer sphere we see that hundreds of thousands, if not millions, of machines are "participating" in botnets controlled by criminals. Finally, or rather unfortunately, we are now at the point where both "hacktivism" and criminal activities are not just a small part of IT operation costs; it directly affects business operations, the brand, and in some cases even share prices. We can only hope that all the recent events cause more board members to demand IT security on the agenda and to be part of the corporate strategy - and not just yet another footnote in IT operations. With this Half Year Report we highlight some interesting numbers about vulnerabilities, the Achilles Heel of any network, and shed light upon some possible alternative approaches to Vulnerability Management, which may inspire organisations to use their resources more efficiently when prioritising and applying security updates. Stay Secure, Thomas Kristensen CSO

4

End-Point Security & Evolving Threats From a Cybercriminal’s Perspective To apprehend a threat it is always a good strategy to understand it from the opponent’s perspective. As a first order approximation, it could be stated that the opportunity for cybercriminals is a function of the number of hosts and the number of vulnerabilities present on these hosts:

Opportunity = #Hosts x #Vulnerabilities The number of hosts certainly correlates with the number of users with Internet access. It is estimated that around 2 billion users will have access to the Internet by the middle of 2011. This represents 28% of the Earth’s population, or an increase of more than 400% in the last decade. With such a huge amount of Internet users, it becomes clear that end-points are being increasingly targeted as even the smallest rate of success of an attack translates into a considerable number of compromised systems. Furthermore, business and private end-points alike are very rewarding targets for cybercriminals as:

End-points are difficult to secure End-points are extremely dynamic environments with numerous programs and plug-ins installed. Paired with unpredictable usage patterns by users, this makes them formidable targets that are difficult to defend.

End-points are valuable End-points are where the most valuable data is found to be the least protected. By definition, end-points have access to all data needed to conduct an organisation’s business.

Everyone is a target Every end-point represents a valuable target for cybercriminals, even if no sensitive data is present. The end-point’s computing power and bandwidth provide valuable resources, for example as an infection point, proxy, or for distributed password cracking services.

Easy Prey The second variable in this model is the number of vulnerabilities per host. To measure this number, data gathered from over 3 million users of the Secunia Personal Software Inspector (PSI)1, a free, lightweight scanner that identifies and patches insecure programs on end-points, is used. To assess the evolving risk, a representative end-point comprising the operating system (Windows XP) and a software portfolio with the Top-50 most prevalent programs found in the field, is tracked. The Top-50 software portfolio is a conservative approach as 50% of users are found to have more than 66 programs installed2. The Top-50 software portfolio contains software from 14 different vendors; namely 26 programs from Microsoft and 24 programs from third-parties (non-Microsoft vendors). Data from this analysis reveals an alarming trend: the number of vulnerabilities affecting this typical end-point increased from 225 in 2007 to 729 in 2010, or by 71% in the last year, as illustrated in Figure 1 and reported in detail in the Secunia Yearly Report for 20103.

1 Secunia Personal Software Inspector (PSI): http://secunia.com/psi 2 ‘The security exposure of software portfolios’, Secunia: http://secunia.com/gfx/pdf/Secunia_RSA_Software_Portfolio_Security_Exposure.pdf 3 Secunia Yearly Report 2010: http://secunia.com/company/yearly_report

5

Third-party programs are

responsible for 69% of

the vulnerabilities on a typical end-point.

Figure 1 - History of the number of vulnerabilities affecting a typical end-point with Windows XP (left), distribution of the origin of vulnerabilities in 2010: OS operating system, MS Microsoft programs, TP Third-party programs (right)

Origin of Vulnerabilities A breakdown of these vulnerabilities by origin reveals the driver behind this trend. The right panel of Figure 1 shows that vulnerabilities in third-party programs (TP) by far outnumber vulnerabilities in the operating system (OS) or vulnerabilities in the Microsoft programs (MS). The share of vulnerabilities found in the operating system and the Microsoft programs, versus all vulnerabilities found on the end-point, almost halved from 55% in 2006 to 31% in 2010. Thus, while patching the operating system and all Microsoft products on a typical end-point remediated 55% of the vulnerabilities in 2006, the same patching strategy remediated only 31% of the vulnerabilities in 2010. To fully patch a typical end-point, the user (or administrator of the system) has to master at least 14 different update mechanisms, as the Top-50 software portfolio comprises programs from 14 different vendors. With one update mechanism, namely “Microsoft Update”, the operating system and the 26 Microsoft programs can be patched to remediate 31% of the vulnerabilities. In addition to this, another 13 update mechanisms are needed to patch the remaining 24 third-party programs to remediate 69% of the vulnerabilities. This complexity to stay secure will undoubtedly leave a large number of systems incompletely patched – and thus vulnerable. Measurements support this belief. For example, research for Q4 2010 shows that, typically, 2% of the Microsoft programs are found to be insecure, while 6-12% of the third-party programs are insecure. Cybercriminals Do Not Need 0-day Vulnerabilities Figure 1 also reveals that timely patching of all Microsoft programs and the operating system does not disrupt cybercriminals’ opportunities at all. There remain plenty of opportunities for system compromise in the 69% of third-party program vulnerabilities. Furthermore, it becomes clear that cybercriminals do not need precious 0-day

6

Cybercriminals do not need 0-day vulnerabilities – there are always plenty

of opportunities in unpatched programs.

exploits at all – at any given time there will always be a large number of systems present with numerous unpatched programs. The Top-50 portfolio is representative of a single end-point. However, in a typical organisational infrastructure it is common to find hundreds or even thousands of different programs installed. The larger the organisation, the more complex the infrastructure becomes due to numerous departments and their diverse needs for different types of software. Figure 2 shows the evolution of the number and the origin of vulnerabilities when analysing software portfolios of increasing size up to 5,000 programs. These values are summarised in Table 1. The share of vulnerabilities present in third-party programs rises from 69% for a single end-point with 50 programs installed, to 81% for an organisation with 5,000 programs in its infrastructure. While most vulnerabilities are due to popular programs, we continually find programs with vulnerabilities when increasing the size of the portfolio. As seen in Figure 2, the number of vulnerabilities in Microsoft levels out early while the number of vulnerabilities in third-party programs continues to grow with the increasing size of the portfolio.

Programs in Portfolio

#Programs #Vulnerabilities in 2010 MS TP OS MS TP Total

100 43 57 100 138 650 (73%) 888

200 59 141 100 145 751(75%) 996

500 96 404 100 150 848 (77%) 1,098

1,000 137 863 100 156 878 (77%) 1,134

2,000 186 1,814 100 156 991(79%) 1,247

3,000 220 2,780 100 160 1,037 (80%) 1,297

4,000 240 3,760 100 162 1,072 (80%) 1,334

5,000 259 4,741 100 162 1,092 (81%) 1,354

Table 1 - Number of programs and origin of vulnerabilities for increasing software portfolios Traditionally, organisations perceive the operating system and Microsoft products to be the primary attack vector, thereby largely ignoring third-party programs in their risk matrixes. Thus, the prioritisation of patching most Microsoft products and perhaps a few third-party products is often found to be an established strategy. This strategy may have proved effective in the past to achieve the desired level of risk. However, data shows that the dynamics of the threat environment over the last five years results in an increasing gap of unmitigated risk if the patching strategy remains unchanged. The larger the software portfolio, the lower the share of Microsoft programs in the portfolio and the share of vulnerabilities due to Microsoft programs. For example, by patching all Microsoft programs including the operating system in an organisation with a portfolio of 1,000 programs leaves 878 or 77.5% of the vulnerabilities unpatched.

7

An organisation with 1,000 programs patching

all Microsoft OS+ products misses 77.5% of

the vulnerabilities.

Figure 2 – Evolution of the number and the origin of vulnerabilities for increasing software portfolio sizes up to 5,000 programs

Protecting a Moving Target For typical organisations patching all programs is operationally and economically prohibitive. Furthermore, identifying and patching the right programs to achieve the largest reduction in risk is a significant challenge. From a security perspective, it is a bad investment to only deploy a patch for a program with vulnerabilities that are “Not critical” or “Less critical” while programs with “Highly critical” vulnerabilities remain unpatched. Identifying the critical programs (affected by either “Highly” or “Extremely critical” vulnerabilities) worth patching is similar to chasing a moving target. While some programs are vulnerable in several consecutive years, many programs are only vulnerable in some years while not in others. Figure 3 measures the percentage of critical programs identified in 2009 that were not critical in the previous year (2008) or in the following year (2010), for different portfolio sizes. For example, the portfolio of the 200 most prevalent programs had 41, 37, and 39 critical programs in 2008, 2009, and 2010. A considerable 30% of the 37 critical programs in 2009 were not considered critical in the previous year (2008) or in the following year (2010), as shown in Figure 3. This result clearly demonstrates the dynamics of the threat and makes clear that the approach of statically defining the critical programs worth patching is ineffective as the selection is already considerably off target the next year. While “only” 37 out of the 200 programs were considered critical in 2009, identifying those 37 programs still implies monitoring all 200 programs in the portfolio. This ratio rises to over 50% for portfolios with more than 1,000 programs. Thus, the larger the software portfolio in an organisation, the more important a dynamic approach to identify the critical programs becomes. It also becomes clear that a manual approach to identifying critical programs soon becomes unfeasible with the limited resources typically available.

8

A moving target 30% of the programs considered security

critical in one year were not critical in the

previous year.

Figure 3 – Percentage of critical programs in 2009 that are not affected by “Highly” or “Extremely critical” vulnerabilities in the

previous year (2008) or in the following year (2010). Even programs with low prevalence or market share are frequently found to be considered critical in some years. Today’s attacks typically use a large number of different exploits to open up attacks against a wide range of vulnerable programs. Different exploits are tried in sequence until one succeeds in compromising a vulnerable program; a process which is fully automated. New exploits are simply loaded as plug-ins, thereby ensuring that attackers can quickly and easily adapt to diverse target environments. Thus, less prevalent programs can also lead to compromise as these are not ruled out by cybercriminals. As of June 2011, for example, the publicly available and easy to use Metasploit Exploitation Framework4 comes with more than 850 exploits against products from more than 200 different vendors. More than 200 of these exploits target programs on the Microsoft Windows platform. Comparing Patching Strategies What, then, is the optimal strategy to achieve the largest reduction in risk for a given investment of security resources? Let us assume that an organisation with 200 programs in its infrastructure already patches the operating system, which is reasonable with the availability of “Microsoft Update”, and has the resources to additionally patch 10 different programs. The challenge is to identify and patch the “right” 10 programs out of the 200 – it is this approach that results in the largest reduction of risk. To analyse the effectiveness of different patching approaches, two strategies of selecting 10 out of 200 programs to be patched every year over a five year period, are compared:

4 Metasploit: http://www.metasploit.com/

9

Strategy Criteria

Top-10 by share Every year patch the Top-10 programs with the largest market share found on end-points.

Top-10 by risk Every year patch the Top-10 most critical programs based on the criticality of vulnerabilities.

Figure 4 - Comparison of the resulting risk remediation over six years by A) patching the Top-10 most prevalent programs, or B) by patching the Top-10 most critical programs every year

Figure 4 shows the risk remediated by the two patching strategies, compared to the total risk of all vulnerabilities in the 200 programs of the portfolio. The risk is calculated as the weighted sum of the criticality of the vulnerabilities found in the programs: Risk = 4 x # {“Extremely” + “Highly critical” vulnerabilities} + 2 x # {“Moderately critical” vulnerabilities} + 1 x # {“Not critical” vulnerabilities} Vulnerability data and criticality ratings are taken from Secunia’s vulnerability database5. The results are insensitive to the weight factors as long as higher criticalities are attributed increasing weights. Results show that the total risk of the 200 programs in the software portfolio increased manyfold since 2005 as expected. These results are also compatible with the findings reported in Figure 1. Surprisingly, the choice of patching strategy has a considerable effect on how much risk can be remediated by patching 10 programs every year. Averaged over the last six years, patching the Top-10 most critical programs remediates 71% of the total risk while patching the

5 Secunia Advisories Terminology: http://secunia.com/advisories/terminology/

10

Top-10 most prevalent programs remediates 31% of the risk, or 2.3 times less. Over the last six years, the strategy of patching the Top-10 most critical programs every year covered 18 different programs in total, which further supports the notion of the moving target.

Patching Strategy Metric Top-10 by share Top-10 by risk

Average percentage of risk remediated over the last six years 31% 71%

Total number of different programs patched over the last six years 10 18

Total number of ”Highly” & “Extremely critical” vulnerabilities patched over the

last six years 1,077 2,249

Thus, knowing what to patch is crucial in light of limited security resources. While patching the same number of programs per year at roughly the same expense, the optimal strategy results in 2.3 more risk remediated. A considerable increase in security with limited resources is entirely possible, but requires the identification of the most critical programs. Prioritisation or knowing what to patch pays off considerably. This is further highlighted by Figure 5 which plots the percentage of risk remediated by the two strategies when patching N out of the 200 programs.

Figure 5 - Risk remediated by A) patching the Top-N most prevalent programs or B) by patching the Top-N most critical

programs in 2010

11

Do more with less Get an 80% reduction in risk by patching the 12 most critical, or the 37

most prevalent

programs.

65% of the vulnerabilities affecting a typical end-

point had a patch available on the day of

vulnerability disclosure.

In 2010, about 50 of the 200 programs had vulnerabilities. The challenge therefore remains in identifying the critical programs out of the 200, which implies constant monitoring of all 200 programs for security vulnerabilities. Figure 5 clearly demonstrates that the strategy of selecting the N programs to be patched has a considerable effect on the risk that can be remediated. If risk requirements demand that at least 80% of the risk has to be remediated, this can be achieved by either patching the Top-12 most critical programs or by patching the Top-37 most prevalent programs, as seen in Figure 5. The dynamics of a software portfolio, shown in Figure 3, paired with the rapid changes in the threat environment, imply a dynamic approach to ensure that organisations patch what is most critical from the risk and compliance perspective. The continued manual tracking of the criticality of vulnerabilities affecting all programs used in an organisation is cost prohibitive. However, solutions exist to automate this task and the cost of such solutions has to be weighed against the increase in security that can be achieved with less resources. Automatization of this process becomes more important with the increasing number of programs in an organisation, as shown in Figure 2 and Figure 3. Patch Availability The limited feasible protection against 0-day exploits6, paired with extensive media coverage, often leads to an overreaction of this threat. However, research indicates that for all vulnerabilities affecting a typical end-point in 2010, 65% had a patch available on the day of disclosure and 75% had a patch available within 10 days of disclosure. The mere possibility of 0-day exploits, a force majeure, does not justify ignoring 65% of the cases where effective remediation is possible and at users’ fingertips. Thus, organisations can hardly hide behind the threat of 0-days when a solution is available for 65% of vulnerabilities. Risk of Testing vs. Risk of Patching Testing security patches before deployment is a crucial step to identify and prevent potential issues or incompatibilities introduced by the patch. However, extensive testing that considerably delays the deployment of critical security patches leads to an increased risk of system compromise. Research shows that the availability of exploit material increases significantly within days of vulnerability disclosure7. From the risk management perspective, the cost of testing paired with the increased risk of compromise while available patches are delayed, versus the cost of recovering from a failed patch times the risk of a failed patch, has to be weighed up: {Cost of Test} + PC x {Cost of Compromise} vs. PFP x {Cost of a Failed Patch} PC Probability of compromise PFP Probability of issues with a patch The risk of a patch that causes incompatibilities or disrupts existing business processes after patch deployment drives the commitment of resources into testing. Assuming that the testing of patches identifies potential issues with a patch with 100% certainty, the cost of testing is justified by the averted cost of recovering from a failed patch. Testing can start with the availability of a patch. Upon the availability of a patch the vulnerability is made public and the availability of exploit material increases significantly, which in turn increases the probability of compromise PC. Furthermore, the cost of compromise and recovery from compromise is typically higher and raises more questions the longer a patch is available but not deployed. Thus, the true cost of testing increases with the increased risk of compromise.

6 Exploits taking advantage of a vulnerability before information of the vulnerability is publicly disclosed and a patch is available are commonly referred to as 0-day exploits 7 ‘Modelling the Security Ecosystem, Workshop on Economics and Internet Security’, Techzoom, 2008: http://www.techzoom.net/papers/weis_security_ecosystem_2009.pdf

12

Cost of a Failed Patch The cost of recovery from a failed patch certainly depends on the type of program being patched. If, for example, a patch of server software on which many services depend has issues, the cost of recovery can become high as compatibility issues are likely. This makes rolling back the patch and recovering from the issue extremely difficult. Therefore, extensive testing is more than justified. However, if a patch for a typical desktop program, for example, has issues, the damage is usually minimal and a roll back is easy and quickly completed. Furthermore, there are alternative programs to provide the functionality. Thus, for many programs, the cost of recovery (times the small probability of an issue with a patch, PFP) does not justify the expenditure and additional risk of extensive testing. This is especially true as the delayed roll out of the patch poses a considerable risk. Programs on end-points are especially at risk of compromise due to the many attack vectors and the activity of the end-users. Server software, on the other hand, is typically better protected as the server does not surf the Internet, receive mails, or open different types of documents. It is therefore advisable to reconsider the testing procedures and take the different types of programs, and their potential options to recover from a failed patch, into consideration. It is likely that for many programs, the achieved reduction of risk through expedited roll out of security patches more than pays off when compared with the rather small risk of recovering from a patch with issues. Furthermore, the resources saved from this strategy can help to speed up the testing of more complex programs.

Global Vulnerability Trends Secunia Vulnerability Intelligence Vulnerabilities in software continue to be a major contributor to the risks people face when using the Internet. This section provides an insight into the last five years of the security ecosystem with respect to vulnerabilities in software and then focuses on the year-on-year evolution of vulnerability data, comparing the data of the last two 12 month periods as of June 2011. Tracking vulnerabilities and the state of software security, the Secunia Vulnerability Intelligence database contains information about more than 29,000 products and 4,000 vendors; a formidable data-set to follow and assess the evolution of software security in an increasingly networked environment. The database validates, verifies, and tests the vulnerability information gathered with consistent and standard processes, which have been constantly refined over the years. Besides the number of vulnerabilities in a specific group of programs, this report also investigates the evolution and the distribution of important vulnerability aspects; such as the criticality, the impact, the attack vector, the type of vulnerabilities, and the availability of patches. The security of information technology and computer networks is affected by a wide variety of factors and processes, which, together, make up a complex and adaptive system. Whenever a new vulnerability is discovered, various parties with different and often conflicting motives and incentives become engaged in a complex way. In the last decade, the number of players and their roles and interactions within the security ecosystem has evolved considerably. A variety of legislative and social issues directly influence the processes of vulnerability research, detection, publication, and response. Vendors, developers, customers, cybercriminals, and the security community have divergent perspectives on the impact of vulnerabilities. The processes and interactions between these factors are driven by the continuous discovery of new vulnerabilities and the subsequent constant need of the public (the software users) for vulnerability intelligence and patches. An investigation into all vulnerabilities covering all products over a period of time reveals the evolution of the prevalence and interactions of some of these processes on a global scale. Such information is valuable to assess and better understand the global state and evolution of software security. However, insights gained by examining all products are not necessarily applicable or particularly relevant to a specific group of software users. As organisations or individuals rarely deploy all software products available on the market, it

13

is equally important and beneficial to focus the analysis on a specific and representative portfolio of products. In both business and private life, the largest group of Internet users are individuals working daily on their end-points. History and Vulnerability Trends for 2011 Vulnerability statistics covering all products are a valuable benchmark for assessing the state and the evolution of software and the security ecosystem as a whole. However, assessing the development of software security is a complex undertaking. Several metrics are therefore plotted in Figure 6 to provide insight into the evolution of vulnerabilities in software. The analysis covers the last five years from 2006 to 2010 and an extrapolation for 2011 to assess the trend based on the data available up to June 2011. The metrics used are the number of Secunia Advisories, the Secunia Vulnerability Count, and the number of Common Vulnerabilities and Exposures (CVEs) per year:

Secunia Advisories Whenever a new vulnerability is reported a Secunia Advisory is released after verification of the information. A Secunia Advisory provides details, including description, risk rating, impact, attack vector, recommended mitigation, credits, references, and more for the vulnerability including additional details discovered during verification and testing, thus providing the information required to make appropriate decisions about how to protect systems. After the first publication the status of the vulnerability is tracked throughout its lifecycle and updates are made to the corresponding Secunia Advisory as new relevant information becomes available. For example, when the vendor releases a patch for the vulnerable product the status of the Security Advisory is changed to “patched”. A Secunia Advisory is released or updated whenever new information becomes available, enabling the administrator of the vulnerable software to take appropriate action when needed. Several vulnerabilities released at the same time (if these vulnerabilities affect the same product and result in one administrative action) are reported in one Secunia Advisory. Likewise, several Secunia Advisories are released for a vulnerability affecting different products and requiring different administrative actions. Vulnerabilities are not reported in beta versions of programs. The number of Secunia Advisories published in a given period of time is a first order approximation of the number of security events in that period. Security events stand for the number of administrative actions required to keep the specific product secure throughout a given period of time.

Common Vulnerabilities and Exposures (CVE) Common Vulnerabilities and Exposures (CVE) is a dictionary of publicly known information security vulnerabilities and exposures. CVE has become a de facto industry standard used to uniquely identify vulnerabilities which have achieved wide acceptance in the security industry. Using CVEs as vulnerability identifiers allows correlating information about vulnerabilities between different security products and services. CVE information is assigned in Secunia Advisories. For example, “CVE-2011-0786” identifies a vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 6, as described in the Secunia Advisory SA44784 released on June 8th, 2011. If CVE information becomes available after the release of a Secunia Advisory, it will be updated. CVE information is published in the National Vulnerability Database (NVD). Many CVE identifiers published by the NVD were not assigned to Secunia Advisories because they represented vulnerabilities in beta and development software, and were non-issues, e.g. fake and duplicate issues. Thus, the number of CVE identifiers reported by the NVD is always higher than the number assigned to Secunia Advisories. In Figure 6 the number of CVEs assigned in the Secunia Vulnerability Database is plotted alongside the NVD for comparison.

14

Secunia Vulnerability Counts When writing up a Secunia Advisory, a vulnerability count is added to each Secunia Advisory to indicate the number of vulnerabilities covered by the Secunia Advisory. Using this count for statistical purposes is more accurate than, for example, counting CVE identifiers, which is often used as the best indicator available. The intention of CVE identifiers is, however, not to provide reliable vulnerability counts, but is instead a very useful, unique identifier for identifying one or more vulnerabilities and correlating them between different sources. The problem in using CVE identifiers for counting vulnerabilities is that CVE abstraction rules may merge vulnerabilities of the same type in the same product versions into a single CVE, resulting in one CVE sometimes covering multiple vulnerabilities. This may result in lower vulnerability counts than expected when basing statistics on the CVE identifiers. Using vulnerability counts is, however, also not ideal as this is assigned per advisory. This means that one advisory may cover multiple products, but multiple advisories may also cover the same vulnerabilities in the same code-base shared across different programs and even different vendors. Despite a vulnerability count being a technically more accurate metric, CVE identifiers are used as a representation of the number of vulnerabilities in this report because these can be counted "uniquely" and CVE is the de facto industry standard for correlating different sources.

Figure 6: History of vulnerability metrics since 2006. Values for 2011 are extrapolated from the data up to June 2011 Analysis On average 3,554 Secunia Advisories were released per year from 2006 to 2010 with a standard deviation of 322 Secunia Advisories (9% of the average). As seen in Figure 6, there is no significant trend in the number of Secunia Advisories over the last years. However, a year-on-year analysis comparing the data of the last two 12 month periods (July 2009 to June 2010 and July 2010 to June 2011) indicates a decrease in the number of Secunia Advisories from 3,459 to 3,361, or -3%. This analysis excluded “update for” Secunia Advisories for Linux distributions as these mostly are “duplicates” of already disclosed vulnerabilities for “upstream” products.

15

The number of CVEs is most valuable for assessing the risk of software used operationally as Secunia validates all vulnerability information before publication (thereby rejecting non-issues, false positives, or vulnerabilities in beta programs). On average 4,609 CVEs were reported per year in the Secunia Advisories from 2006 to 2010 with a standard deviation of 727 CVEs (16% of the average). Comparing the last two 12 month periods, the number of CVEs assigned to Secunia Advisories decreased from 3,985 to 3,709, or by -7%. Based on the data from the first half of 2011, around 3,676 CVEs are expected by the end of the year, or a 3% decrease compared to the average number recorded during the last five years. Over the last years the number of CVEs exhibits a slow but steady downward trend from a maximum of 5,538 CVEs in 2006. It should also be noted that there were 704 (out of 1,551) Secunia Advisories issued in 2011 (January to June) for which no CVE identifier is currently available. These will be updated as CVE identifiers become available. There were also around 238 CVE identifiers issued during 2011 which were not assigned to Secunia Advisories because they represented vulnerabilities in beta and development software, and were non-issues, e.g. fake and duplicate issues. On average, 22% of the CVE identifiers issued by the NVD were not assigned to Secunia Advisories over the last five years. While the number of Secunia Advisories estimates security events (the number of administrative actions needed to assess or maintain software), the number of CVEs can be used as an approximation of the number of unique vulnerabilities affecting the products observed.

Metric Average 2006-2010 2010 Trend

2011

Secunia Advisories 3,554 3,648 3,102

Vulnerabilities (CVEs Secunia) 4,609 3,974 3,676

Vulnerabilities (CVEs NVD) 5,873 4,667 4,152

Types of Vulnerabilities This section provides information on a year-on-year analysis of Secunia Advisories and vulnerabilities, comparing the evolution over the two recent 12 month periods; July 2009 to June 2010 and July 2010 to June 2011. This analysis further examines important vulnerability aspects such as the criticality, the impact, the attack vector, and the availability of patches in these periods. Attack Vector The attack vector describes the way an attacker can trigger or reach the vulnerability in a product. The attack vector is classified as “Local system”, “Local network”, or “From remote”. The classification of attack vectors, along with a description of how they are used in Secunia Advisories, is listed in the Appendix of this report. Figure 7 plots a breakdown of the data by attack vector as the number of Secunia Advisories in the last and the preceding 12 months. It can be observed that “From remote” is consistently and by far the most prevalent attack vector with an 80% share, down from 85%. “Local system” attributes increased from 8% to 12% and “Local network” increased from 7% to 8%. While the majority of the vulnerabilities are exploitable from remote, this type decreased by 5% on a year-on-year basis. The numbers referring to Figure 7 are summarised in Table 2.

16

Figure 7: Year-on-year comparison of the attack vector, vulnerability criticality, and vulnerability impacts in a number of Secunia Advisories

Criticality The criticality of vulnerabilities is rated on a five-level criticality scale ranging from “Not critical” to “Extremely critical”. The criticality of a vulnerability is based on the assessment of the vulnerability’s potential impact on a system, the attack vector, mitigating factors, and if an exploit exists for the vulnerability and is being actively exploited prior to the release of a patch. The Appendix of this report lists the criticality classification together with a description of how they are used to rate the risk of a vulnerability. Figure 7 shows that in the last 24 months more than 50% of the Secunia Advisories were rated “Highly” or “Moderately critical”, while around 38% were rated “Less critical” and less than 1% were rated as ”Extremely critical”. The share of "Moderately critical” vulnerabilities decreased by -6.9% resulting in a 4.3% increase of "Highly” and "Extremely critical” vulnerabilities and a 2.7% increase of "Less” and "Not” critical vulnerabilities. Overall, the criticality of the vulnerabilities increased slightly on a year-on-year basis. The criticality of vulnerabilities depends considerably on the mix of products being examined. Figure 7 analyses the criticality distribution over all products. The same methodology can be applied to a specific group of products to provide an accurate picture of the risk profile due to vulnerabilities in these products. Impact The "Impact” metric classifies the impact of the successful exploitation of a given vulnerability on the affected system. The impact classification ranges from consequences such as “Exposure of system information” to “System access” and is listed in the Appendix of this report. As with the criticality rating, the impact rating depends considerably on the type or mix of software examined. Figure 7 plots the distribution of the five most prevalent impact classes observed in the period from July 2011 to June 2011 and compares the numbers with the data of the preceding 12 months. The most prevalent impact class is "System access” which increased by 6.3% to 30.2% over the last 12 months. This increase is at the cost of a decrease in all other impact classes except "Cross Site Scripting”. ”Cross Site Scripting” has the second largest prevalence with 23.7%, which indicates the continued security challenges posed by web applications.

17

Metric in Percent of Secunia Advisories

Period Jul 09-Jul 10

Period Jul 10-Jun 11

YoY Trend

Attack Vector - From Remote 85% 80% -5.5% - From local network 8% 12% +4.4% - Local System 7% 8% +1.1% Criticality - Extremely 0.3% 0.6% +0.3% - Highly 15.6% 19.5% +4.0% - Moderately 41.3% 34.3% -6.9% - Less 37.9% 38.9% +1.0% - Not 5.0% 6.7% +1.7% Impact - System access 23.9% 30.2% +6.3%

- Denial of Service (DoS) 17.5% 15.8% -1.7%

- Exposure of sensitive information 17.5% 15.9% -1.7% - Manipulation of data 17.7% 14.4% -3.3% - Cross Site Scripting 23.4% 23.7% +0.3%

Table 2: Attack Vector, Vulnerability Criticality, and Vulnerability Impact summary Solution Status & Patch Availability The remediation available for vulnerabilities is an important aspect of security measured as solution status. If a patch from the vendor is available the solution status of a Secunia Advisory is marked “vendor patch”. Otherwise the solution status is marked “unpatched” or “partial fix”. A “partial fix” depicts a solution that is available but in one way or another is incomplete. It either covers only a subset of the vulnerabilities or it does not fix the vulnerability on all affected versions of the program. The “solution status” is updated as new information becomes available. For the two recent 12 month periods, the left panel of Figure 8 reports the solution status on the disclosure date of the Secunia Advisory and the right panel reports the distribution of the delay for the patches released after the vulnerability disclosure. As the solution status is reported on the day of disclosure, the number of advisories with status marked “vendor patch” indicates that the vendor had prior information about the vulnerability and was able to coordinate the release of the patch with the public disclosure of the vulnerability. This policy, called “coordinated disclosure”, asks security researchers to submit their vulnerability discoveries directly to the affected vendor, and then hold off on disclosing details until a patch is available. Over the last 24 months, as of June 2011, for 51.9% of the Secunia Advisories a patch was available on the day of disclosure, for 21.7% a patch was made available later, and for 26.4% no patch was released at all. Note that a Secunia Advisory disclosed in June 2011 that gets patched in July or later is counted as “unpatched” as, at the release of this report, only patches made available before July 2011 can be considered. It can be observed that for an increasing number of advisories there is a patch available on the day of disclosure. The share increased on a year-on-year basis by 7.9% from 47.9% to 55.9%, or on average 51.9% over the last 24 months. Thus, for more than half of all vulnerabilities reported in a Secunia Advisory there was a patch available on the day of

18

publication of the vulnerability. This share is also an estimate for the prevalence of the “coordinated disclosure” process.

Figure 8: Year-on-year comparison of the solution status and the distribution of the waiting time for patches

The right panel of Figure 8 shows the delay from disclosure to patch release for all Secunia Advisories for which the vendor had no patch available on the day of disclosure. This analysis includes all patches released over the last 24 months. Figure 8 shows that a patch was typically available within 30 days of disclosure for more than half of the remaining advisories. However, about a third of these Secunia Advisories were still unpatched after 60 days.

19

Summary To reduce risks with limited resources, it is important to know the potential targets, the capabilities and limitations of traditional defences, and where to effectively complement defences. Security patches are found to be a primary and effective means to escape the arms race with cybercriminals, as patches remediate the root cause of compromise. This research has demonstrated that an intelligent patching strategy is an effective approach for reducing vulnerability risks, as well as for maximising operational efficiency with minimal costs. Following the explosive increase in the number of vulnerabilities (all metrics) that took place in the few years preceding 2006, Secunia’s data now indicates a steadier, slightly decreasing rate in recent years of between 70%-80% of the 2006 maximum values. Comparing the data from the last two 12 month periods as well as the extrapolated trend for 2011 indicate a slow decrease. Furthermore, the remaining high numbers evident in this analysis show that software vendors are still unable to release vulnerability free software at large – highlighting the continued need for effective vulnerability management for all types of software in use.

20

I. Appendix Vulnerability Criticality Classification

Extremely Critical (5 of 5)

Typically used for remotely exploitable vulnerabilities that can lead to system compromise. Successful exploitation does not normally require any interaction and exploits are in the wild. These vulnerabilities can exist in services like FTP, HTTP, and SMTP or in certain client systems like email programs or browsers.

Highly Critical (4 of 5)

Typically used for remotely exploitable vulnerabilities that can lead to system compromise. Successful exploitation does not normally require any interaction but there are no known exploits available at the time of disclosure. Such vulnerabilities can exist in services like FTP, HTTP, and SMTP or in client systems like email programs or browsers.

Moderately Critical (3 of 5)

This rating is also used for vulnerabilities allowing system compromise on LANs in services like SMB, RPC, NFS, LPD and similar services that are not intended for use over the Internet. Typically used for remotely exploitable Denial of Service vulnerabilities against services like FTP, HTTP, and SMTP, and for vulnerabilities that allow system compromises but require user interaction.

Less Critical (2 of 5) Typically used for cross-site scripting vulnerabilities and privilege escalation vulnerabilities. This rating is also used for vulnerabilities allowing the exposure of sensitive data to local users.

Not Critical (1 of 5)

Typically used for very limited privilege escalation vulnerabilities and locally exploitable Denial of Service vulnerabilities. This rating is also used for non-sensitive system information disclosure vulnerabilities (e.g. remote disclosure of installation path of applications).

Table 1: Vulnerability criticality rating as used in Secunia Advisories

21

Attack Vector Classification

Local System Local System describes vulnerabilities where the attacker is required to be a local user on the system to trigger the vulnerability.

From Local Network

From Local Network describes vulnerabilities where the attacker is required to be situated on the same network as a vulnerable system (not necessarily a LAN). This category covers vulnerabilities in certain services (e.g. DHCP, RPC, administrative services) that should not be accessible from the Internet, but only from a local network or optionally from a restricted set of external systems.

From Remote

From Remote describes other vulnerabilities where the attacker is not required to have access to the system or a local network in order to exploit the vulnerability. This category covers services that are acceptable to be exposed and reachable to the Internet (e.g. HTTP, HTTPS, SMTP). It also covers client applications used on the Internet and certain vulnerabilities where it is reasonable to assume that a security conscious user can be tricked into performing certain actions.

Table 2: Vulnerability attack vector classification used by Secunia

22

Vulnerability Criticality Classification

Brute force Used in cases where an application or algorithm allows an attacker to guess passwords in an easy manner.

Cross-Site Scripting (XSS)

Cross-Site Scripting vulnerabilities allow a third party to manipulate the content or behaviour of a web application in a user's browser, without compromising the underlying system. Different Cross-Site Scripting related vulnerabilities are also classified under this category, including "script insertion" and "cross-site request forgery". Cross-Site Scripting vulnerabilities are often used against specific users of a website to steal their credentials or to conduct spoofing attacks.

DoS (Denial of Service) This includes vulnerabilities ranging from excessive resource consumption (e.g. causing a system to use a lot of memory) to crashing an application or an entire system.

Exposure of sensitive information

Vulnerabilities where documents or credentials are leaked or can be revealed either locally or remotely.

Exposure of system information

Vulnerabilities where excessive information about the system (e.g. version numbers, running services, installation paths, and similar) are exposed and can be revealed remotely and in some cases locally.

Hijacking This covers vulnerabilities where a user session or a communication channel can be taken over by other users or remote attackers.

Manipulation of data

This includes vulnerabilities where a user or a remote attacker can manipulate local data on a system, but not necessarily be able to gain escalated privileges or system access. The most frequent type of vulnerabilities with this impact is SQL-injection vulnerabilities, where a malicious user or person can manipulate SQL queries.

Privilege escalation

This covers vulnerabilities where a user is able to conduct certain tasks with the privileges of other users or administrative users. This typically includes cases where a local user on a client or server system can gain access to the administrator or root account, thus taking full control of the system.

Security Bypass

This covers vulnerabilities or security issues where malicious users or people can bypass certain security mechanisms of the application. The actual impact varies significantly depending on the design and purpose of the affected application.

Spoofing This covers various vulnerabilities where it is possible for malicious users or people to impersonate other users or systems.

System access This covers vulnerabilities where malicious people are able to gain system access and execute arbitrary code with the privileges of a local user.

Unknown Covers various weaknesses, security issues, and vulnerabilities not covered by the other impact types, or where the impact isn't known due to insufficient information from vendors and researchers.

Table 3: Vulnerability impact classification used by Secunia. A given vulnerability might be assigned to more than one impact class to accurately reflect its impact

23

About Secunia Secunia is the leading provider of IT security solutions that help businesses and private individuals globally manage and control vulnerability threats and risks across their networks and endpoints. This is enabled by Secunia's award-winning Vulnerability Intelligence, Vulnerability Assessment, and Patch Management solutions that ensure optimal and cost-effective protection of critical information assets. Secunia’s proven, complementary portfolio; renowned for its reliability, usability, and comprehensiveness, aids businesses in their handling of complex IT security risks and compliance requirements across industries and sectors – a key component in corporate risk management assessment, strategy, and implementation. As a global player within IT security and Vulnerability Management, Secunia is recognised for its market-driven product development; having revolutionised the industry with verified and actionable Vulnerability Intelligence, simplified Patch Management, and automatic updating of both Microsoft and third party programs. Secunia plays an important role in the IT security ecosystem, and is the preferred supplier for enterprises and government agencies worldwide, counting Fortune 500 and Global 2000 businesses among its customer base. Secunia has operations in North America, the UK, and the Middle East, and is headquartered in Copenhagen, Denmark. For more information, please visit http://secunia.com/ Copyright 2011 Secunia. All rights reserved. This report may only be redistributed unedited and unaltered. This report may be cited and referenced only if clearly crediting Secunia and this report as the source. Any other reproduction and redistribution in print or electronically is strictly prohibited without explicit permission.

Secunia Weidekampsgade 14A DK-2300 Copenhagen S Denmark

Email: info@secunia.com Phone: +45 7020 5144 Fax: +45 7020 5145