Vulnerability root-causes and mitigation

The subject of vulnerability root-causes is important to help designers, developers, and administrators to avoid faults that can lead to vulnerabilities. Vulnerability mitigation refers to the actions in place to identify and correct vulnerabilities in the system in order to increase its security. These notions are important to our thesis as this helps users to improve system security and obtain a better security measurement in our security benchmark methodology.

According to (Neves et al. 2006), vulnerabilities are usually created during the development phase of the system, or during operation. These vulnerabilities can be introduced accidentally or deliberately, with or without malicious intent. However, vulnerability can also be caused by an improper system design. For example, if a proper authorization requirement is not defined and designed, developers may develop code that correctly implements a flawed design, leading to a system that allows unauthorized access in restricted areas. The integration of third-party off-the-shelf components is another cause for vulnerabilities. Component integration may also introduce vulnerabilities in the larger system due to interface mismatches that may be exploited by attacks (Weyuker 1998). This is usually the result of components designed or developed with no security concerns in mind, as well as the lack of proper security testing prior to the component integration into the software product.

Several vulnerability root-causes models have been proposed in the last years (e.g., (Piessens 2002)). (Tsipenyuk, Chess, and McGraw 2005) proposed a taxonomy of security errors named as the seven pernicious kingdoms. In this context, “security errors” refer to programming errors that lead to vulnerabilities. The seven-kingdom taxonomy focuses on collecting common errors and explaining them in a way that makes sense to software developers. The main benefit of this approach is to make developers aware of these errors so that they can develop software free of vulnerabilities. The seven kingdoms are as follows: input validation and representation (metacharacters, alternate encodings, and numeric representations), API abuse (the caller fails to honor its end of the contract), security features (authentication, access control, confidentiality, cryptography, and privilege management), time and state (deadlock, insecure temporary file), errors, code quality (memory leak, null deference), encapsulation (drawing strong boundaries around things to avoid, for example, system information leak), environment. To demonstrate how to classify security errors into the proposed kingdoms, the authors used information from the 19 Deadly Sins of Software Security (M. Howard, LeBlanc, and Viega 2005) and the OWASP (The Open Web Application Security Project) Top 10 Most Critical Web Application Vulnerabilities (OWASP 2012), as can be seen in Table 2-1.

Although security awareness has increased over the years, it is still very difficult to prevent vulnerabilities in the system originated from code defects/software errors. More specifically, studies have been conducted to estimate the number of average defects per thousand lines of code. (Hatton 2007) estimated one defect per 10 thousand executable code lines for mission and business critical software. The 2009 Coverty report uncovered one defect in every four thousand lines of Open source code (Coverity 2009). In 2011, Coverity analyzed over 37 million lines of code from 45 of the most active projects in Coverity Scan (Coverity 2011). The average defect density, or the number of defects per thousand lines of code, across the top 45 active open source projects in Coverity Scan is 0.45. This considerable reduction over the last two years in the defect density is due to the fact that open source software developers are more aware of the common defects that they made in their codes.

In the context of software security, (A. Ozment and Schechter 2006) found out that, for OpenBSD operating system, software defects that could compromise system security and that were introduced prior to the release of the initial version have an average lifetime of 2.6 years. In this study, the density of vulnerabilities per thousand lines of code ranged from 0 to 0.033. Although this seems to be a very low number for an open-source operating system, it is important to remark

that a single risky vulnerability, if successfully exploited, can totally compromise the security of the whole system.

In order to help developers to avoid software errors that can lead to serious vulnerabilities in software, (SANS Institute 2012), (MITRE Corp. 2012), and many top software security experts in the US and Europe proposed a list of the Top 25 Most Dangerous Software Errors (B. Martin et al. 2010). Some of these vulnerabilities (e.g., improper neutralization of special elements used in a SQL Command), if successfully exploited, allow attackers to completely take over the software, steal data, or prevent the software from working at all.

Initiatives to eliminate or reduce the number of software vulnerabilities present in a system are shown in literature in a variety of forms, which are:

- Security training. Designers and developers should have a security mindset (Schneier 2009). A developer that ignores the common software bugs that could lead to vulnerabilities will certainly write a vulnerable Table 2-1. Mapping Security Errors to the Seven Pernicious Kingdoms and to the OWASP Top 10 Vulnerabilities

(Tsipenyuk, Chess, and McGraw 2005)

KINGDOMNS 19 SINS OWASP TOP 10

Input Validation and Representation

Buffer overflows, command injection, cross-site scripting, format string problems, integer range errors, SQL

Injection

Buffer overflow, cross- site scripting flaws, injection flaws, unvalidated input API Abuse Trusting network address information -

Security Features

Failing to protect network traffic, failing to protect and store network data, failing to use cryptographically strong random numbers, improper file access, improper use of SQL, use of weak password-based

systems, unauthenticated key exchange

Broken access control, insecure storage

Time and State Signal race conditions, use of “magic” URLS and hidden forms

Broken authentication and session management Errors Failure to handle errors Improper error handling

Code Quality Poor usability Denial of service

Encapsulation Information leakage -

Environment - Insecure configuration

code. Guidance on how to design a secure computer system, or how to write a secure code can be found at (Venkat Pothamsetty 2005) and (Thompson and Chase 2007).

- Vulnerability scanners are tools aimed at detecting vulnerabilities present in the system code. If the source code is available, there are tools that can search for common vulnerabilities patterns in the code. A review of automated tools for security is described in (McGraw 2008). Examples of code vulnerability finder tools are (HP Fortify 2012), (Ounce Labs 2012) and (Pixy 2012). If the source code is unavailable, there are tools such as penetration testing that look for vulnerabilities by analyzing the result of attacks. If an attack compromises system security, then vulnerability should exist.

- System security patches and security configuration are usually provided by vendors to fix known vulnerabilities of widely used software. It is an elementary precaution to keep a system patched and properly configured to avoid attacks exploiting known vulnerabilities. In general, default configuration is not the best approach to keep a server protected. Web servers with default configuration, for example, may have template web sites with Cross-site scripting vulnerabilities. More specifically, Apache Tomcat 4.1.0 through 4.1.39 contains an example of calendar application that contains XSS vulnerabilities (CVE-2009-0781). To help end-users with system security configuration, the US government created the National Checklist Program (NCP 2012), which provides detailed low level guidance on setting the security configuration of operating systems and applications.