Mitigating impacts (advanced)¶

Even if a program is very well implemented, it may still contain errors. Therefore, it is important to build additional layers of defence. This can be achieved, for example, through the surrounding software, hardware, operating system, compiler, or even a virtual machine. It is therefore important to consider the program in its operating environment and build protections around it as well.

Runtime detection (advanced)¶

Runtime detection is, at least in principle, effective, because errors are detected and can even be prevented before damage occurs. However, this typically happens by interrupting program execution. Runtime detection can, for example, monitor memory areas and prevent invalid memory accesses, monitor operating system memory regions, or enforce correct use of data flows. During testing, performance is usually not an issue, allowing errors to be detected effectively. For efficiency reasons, runtime detection in production environments must typically be less strict.

Automated diversification (advanced)¶

Exploiting vulnerabilities requires knowledge of the specific implementation or execution environment. For example, exploiting memory management vulnerabilities requires knowledge of the operating environment, and exploiting SQL injection requires knowledge of database details. One way to defend against such attacks is to diversify implementation-specific details. This prevents a single attack from working broadly across all systems. In addition, testing by an attacker becomes more difficult. If diversification is implemented well, an attack developed for one target will likely not work on another system. An example of automated diversification is ASLR (Address Space Layout Randomization, ASLR). In this way, memory structures are not located at fixed addresses.

Restricting privileges (advanced)¶

An important way to reduce the impact of a vulnerable program is to limit its ability to cause harm. In practice, this is achieved by restricting permissions in one way or another.

One way to limit program execution is to place it in a so-called sandbox. In a sandbox, program execution is isolated into its own environment, so that a vulnerability or error does not cause problems outside the sandbox. Exceptions include vulnerabilities in the sandbox itself, such as those found in the Java Virtual Machine. A sandbox can be implemented in many ways, such as using a virtual machine, software-based isolation, or process management.

Compartmentalisation can also be used to restrict program privileges. In this approach, a program is divided into parts, and the permissions between them are restricted. Typical examples include access controls enforced by the operating system and database systems.

Software integrity checks (advanced)¶

The integrity of a program or its data can be verified using checksums or hashes. Ideally, these checks are implemented in a way that prevents attacker interference. This is the goal, for example, in trusted computing implementations (see in more detail in connection with operating systems).

Summary of vulnerabilities (advanced)¶

The table below summarises different classes of vulnerabilities as well as typical methods for their prevention, detection, and impact mitigation.

Summary¶
Vulnerability classification	Prevention	Detection	Impact mitigation
Memory management vulnerabilities	Choice of programming language, coding guidelines	Static and dynamic detection	Memory protection, e.g. at the operating system level, sandboxes
Input construction vulnerabilities	Coding guidelines	Taint analysis	Runtime detection
Race condition vulnerabilities	Coding guidelines, concurrency rules, setting process permissions		sandbox
API vulnerabilities	Verifying API security, keeping libraries up to date	Static analysis	Compartmentalisation
Side-channel vulnerabilities	Coding guidelines	Static analysis	Isolation

In addition, it is important to remember that testing is an essential part of vulnerability detection.