The Heterogeneous Nature Of Security Vulnerabilities (Part 2)
By john.heimann on Aug 15, 2006
Hello, this is Eric Maurice, Manager for Security in Oracle's Global Technology Business Unit. This is the second and final part of this series on security vulnerability (see first blog entry dated July 7, 2006).
The term "vulnerability" is used interchangeably in the security industry to describe many different issues. For example, vulnerability is defined as "a weakness of an asset or group of assets that can be exploited by one or more threats" (ISO/IEC 13335-1:2004). In its general sense, the term "vulnerability" is used to describe IT infrastructure weaknesses that affect the security posture of an organization. In a narrower sense however, "software vulnerabilities" refer to issues in the code of the affected software resulting in weaknesses that could be leveraged by an attacker or by a piece of malware.
Configuration mistakes and insecure configurations contribute to creating vulnerabilities in
IT environments. Experience has shown that security organizations continue to finger point "default installation settings" as a major source of vulnerability for organizations worldwide. Therefore, providing "secure out of the box" installations and advising on the risks resulting from deviating from these secure initial settings bring customers a long way in term of helping them secure their environment.
In its narrower sense, "software vulnerabilities" are related to attributes of a specific software program. Software vulnerabilities are typically created as a result of one of the following two
- Coding error during development: the vulnerability is created because of faulty code or inappropriate input checks. For example, many buffer overflows and SQL injection vulnerabilities would fall into this category.
- Design error: the vulnerability is created because the normal operation of the software program has unintended security consequences. For example, historically a number of security flaws related to weak authentication mechanisms or unauthenticated access to certain functions would fall into this category.
While "coding errors" can typically be addressed through patches, "design errors" can be more troublesome because solving them can dramatically affect the initial design of the affected software. Solving this kind of vulnerability may sometimes require major changes to the code ase resulting in the need for issuing a major release update. Furthermore, these required changes may not always be backportable, and will require concerned customers to upgrade to the latest release of the affected software.
Design errors are somewhat less common than coding errors. In some instances, they result from voluntary design choices made as a result of poor security knowledge or common misconceptions (false paradigms) shared by the entire industry. For example, for many years, a number of distributed software programs didn't provide for the segregation of duties between the system administrator and the security administrator roles (this segregation has existed on the mainframe operating system for a long time). Today however, a number of operating systems (for example, "secure" operating systems and various access control tools on Unix) provide such segregation of duties. Nevertheless, most environments are still highly exposed when security incidents result from successful privilege escalation attacks or privileged administrator abuses or mistakes.
Software vendors can implement a number of tools to help reduce the number of vendor-induced
software vulnerabilities; for example, the use of strong coding standards and automated tests and reviews of the source code will help organization in terms of "securing" its code. Furthermore, security standards and external security validations such as Common Criteria or FIPS 140-2 are meant to require basic security functions, and evaluate security claims made by vendors. However, there is no "silver bullet" and strong software security assurance discipline can significantly raise the level of software security quality.
Far from representing a single set of concerns, the topic of security vulnerabilities encompasses many different issues. Understanding these issues is a key requirement for IT managers who need to define security policies for their organizations.
Oracle's web site provides valuable vulnerability-related information; for example:
- The Critical Patch Update and Security Alerts page on Oracle Technology Network located on
- The Security Technology Center page on Oracle
technology Network located on
access to "how to secure" installation guides and checklists.