Security as a Fundamental Aspect of Quality

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.

Top 25 Security Issues in Modern Systems

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. Overall the weaknesses are grouped into three broad classes.

• 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

1. SQL Injection [CWE-89]. This weakness relates to the inclusion of user or external input into the formation of an SQL command.
   Examples.
2. 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.
3. Cross-Site Scripting [CWE-79]. User or external input to scripts on one site may generate web pages that can compromise another site.
   Examples.
4. Unrestricted File Upload [CWE-434].
   Examples.
5. Cross-Site Request Forgery [CWE-352].
   Examples.
6. Open Redirect [CWE-601].
   Examples.

Unsafe Resource Management

1. Buffer Overflow [CWE-120]. If the size of input strings is not checked before copying, data may be copied beyond reserved buffer areas.
   Examples.
2. Path Traversal [CWE-22]. User or external paths with "../" sequences may allow access to restricted directories.
   Examples.
3. Code Download [CWE-494].
   Examples.
4. Untrusted Code [CWE-829].
   Examples.
5. Unsafe Library Functions [CWE-676].
   Examples.
6. Incorrect Buffer Size Calculation [CWE-131].
   Examples.
7. Uncontrolled Format String [CWE-134].
   Examples.
8. Integer Overflow or Wraparound [CWE-190].
   Examples.

Compromised Defenses

1. Missing Authentication for Critical Function [CWE-306].
   Examples.
2. Missing Authorization [CWE-862].
   Examples.
3. Use of Hard-coded Credentials [CWE-798].
   Examples.
4. Missing Encryption of Sensitive Data [CWE-311].
   Examples.
5. Reliance on Untrusted Inputs in a Security Decision [CWE-807].
   Examples.
6. Execution with Unnecessary Privileges [CWE-250].
   Examples.
7. Incorrect Authorization [CWE-863].
   Examples.
8. Incorrect Permission Assignment for Critical Resource [CWE-732].
   Examples.
9. Use of a Broken or Risky Cryptographic Algorithm [CWE-327].
   Examples.
10. Improper Restriction of Excessive Authentication Attempts [CWE-307].
    Examples.
11. Use of a One-Way Hash without a Salt [CWE-759].
    Examples.

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

• C
• C++
• Java
• Perl

Language-Independent Coding Practices

The CERT Top 10 Secure Coding Practices represent best language-independent practices for building security into software systems by design.