What’s the difference between software threats, attacks, and vulnerabilities?
While working on Improving Web Application security, we found a lot of confusion, so we came up with a simple way to quickly communicate the terms.
Threats, Attacks, Vulnerabilities and Countermeasures Defined
- Threat – A negative effect or undesired event. A potential occurrence, often best described as an effect that might damage or compromise an asset or objective. It may or may not be malicious in nature.
- Vulnerability – A weakness in some aspect or feature of a system that makes an exploit possible. Vulnerabilities can exist at the network, host, or application levels and include operational practices.
- Attack (or exploit) – An action taken that uses one or more vulnerabilities to realize a threat. This could be someone following through on a threat or exploiting a vulnerability.
- Countermeasure – Addresses a vulnerability to reduce the probability of an attack or the impact of a threat. They do not directly address threats; instead, they address the factors that define the threats. Countermeasures range from improving application design, or improving your code, to improving an operational practice.
Examples of Threats, Attacks, Vulnerabilities, and Countermeasures
You can use threats, attacks, vulnerabilities and countermeasures to organize your security information.
Here’s an example of organizing threats, attacks, vulnerabilities and countermeasures for Input/Data validation:
Threats/Attacks for Input/Data Validation
- Buffer overflows
- Cross-site scripting
- SQL injection
- Canonicalization attacks
- Query string manipulation
- Form field manipulation
- Cookie manipulation
- HTTP header manipulation
Vulnerabilities for Input/Data Validation
- Using non-validated input in the Hypertext Markup Language (HTML) output stream
- Using non-validated input used to generate SQL queries
- Relying on client-side validation
- Using input file names, URLs, or user names for security decisions
- Using application-only filters for malicious input
- Looking for known bad patterns of input
- Trusting data read from databases, file shares, and other network resources
- Failing to validate input from all sources including cookies, query string parameters, HTTP headers, databases, and network resources
Countermeasures for Input/Data Validation
- Do not trust input
- Validate input: length, range, format, and type
- Constrain, reject, and sanitize input
- Encode output