Security: A Fundamental Quality Characteristic
The distinction between the reliability and security aspects of computer systems often boils down to how the systems respectively handle correct and incorrect inputs.
- Correct processing of correct inputs is fundamental to the reliability of the software in carrying out its intended purpose.
- Correct processing of incorrect inputs is fundamental to the security of software in preventing unauthorized access or modification of data or compromise of computing systems.
Common Weakness Enumeration
The Common Weakness Enumeration is a joint MITRE/SANS project to identify, classify and document the common security weaknesses of modern computing systems together with recommended best practices to address these weaknesses.
The CWE is a very large maintained database of types of software and/or hardware weakness in computing system. Each entry describes a type of programming practice that leads to specific security concerns. The database contains detailed descriptions of hundreds of vulnerabilities and related concepts.
For example, consider CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection'). This relates to vulnerabilities that have the following elements.
- Software executes a string as a command such as an operating system command.
- The command is executed in an environment which has elevated priveleges (such as root access).
- The command string is built by string concatenation or other means including data from some untrusted source.
Here is a simple example C program taken from the CWE database.
int main(int argc, char** argv) {
char cmd[CMD_MAX] = "/usr/bin/cat ";
strcat(cmd, argv[1]);
system(cmd);
}
Suppose that the purpose of this program is to display the contents of files,
including even system files that may require root access to display.
The program be compiled into an object file "showfile" with setuid root
priveleges. Then the command showfile /etc/passwd can display
password entry information, as expected.
But the problem with showfile is that the command string may be something other than a simple file name. Consider the following command.
showfile "a; rm -rf /"
In this case, the operating system then executes the command /usr/bin/cat a; rm -rf /, which first displays the contents of file "a" and then goes on to delete the entire file hierarchy (which succeeds because of root privelege)>
Three Classes of Security Issue
There are many different ways of classifying security issues. Three broad classes include:
- Insecure interaction between components. These weaknesses relate to flaws in how networked components interact with each other, potentially allowing malicious agents to compromise systems.
- Unsafe resource management. These weaknesses relate to failures to correctly manage and limit access to system resources.
- Compromised defenses. These weaknesses relate to failures to follow best practices in the very security measures that are intended to defend systems from outside threats.
Insecure Interaction Between Components
- SQL Injection CWE-89. This weakness relates to the inclusion of user or external input into the formation of an SQL command.
Examples. - OS Command Injection CWE-78. Like SQL injection, this weakness again relates to insecure use of user or external input, this time in the context of creating an operating system command.
Examples. - Cross-Site Scripting CWE-79. User or external input to scripts on one site may generate web pages that can compromise another site.
Examples. Wikipedia.
Unsafe Resource Management
- Buffer Overflow CWE-120. If the size of input strings is not checked before copying, data may be copied beyond reserved buffer areas.
Examples. - Path Traversal CWE-22. User or external paths with "../" sequences may allow access to restricted directories.
Examples. - Uncontrolled Format String CWE-134.
Examples.
Compromised Defenses
- Missing Authentication for Critical Function CWE-306.
Examples. - Missing Authorization CWE-862.
Examples. - Use of Hard-coded Credentials CWE-798.
Examples.
Other CWE Categorizations
- Language-based categorizations:
- Top 25 Most Dangerous Software Weaknesses
Security Practices
Mitigating the Top 25 Weaknesses
To address the security weaknesses represented by its top 25 list, the CWE site also offers a list of its top 9 mitigations, the monster mitigations.
- M1 Establish and maintain control over all of your inputs.
- M2 Establish and maintain control over all of your outputs.
- M3 Lock down your environment.
- M4 Assume that external components can be subverted, and your code can be read by anyone.
- M5 Use industry-accepted security features instead of inventing your own.
- GP1 (general) Use libraries and frameworks that make it easier to avoid introducing weaknesses.
- GP2 (general) Integrate security into the entire software development lifecycle.
- GP3 (general) Use a broad mix of methods to comprehensively find and prevent weaknesses.
- GP4 (general) Allow locked-down clients to interact with your software.
Default Deny: Whitelists instead of blacklists
- Whitelists identify explicitly resources that are permitted access, while blacklists identify resources that are denied access.
- Blacklist approaches can be used to counter known threats as they arise; simply deny service to the address associated with the threat.
- But blacklist approaches are inherently reactive: providing security against a threat only after it is known to exist and has been identified.
- Whitelists provide much greater security through a policy of default deny: only allow access to known resources.
Secure Coding Practices
The Software Engineering Institute at Carnegie Mellon University has a series of secure coding standards that address specific known problems in particular programming languages as well as general security recommendations.
Language-Based Secure Coding Standards
Language-Independent Coding Practices
The CERT Top 10 Secure Coding Practices represent best language-independent practices for building security into software systems by design.