Preventative Control

From The Secure Arc Wiki

Jump to: navigation, search
Go to Asset DefinitionGo to Asset ValueGo to ExposuresGo to ExposuresGo to ExposuresGo to ExposuresGo to ExposuresGo to ExposuresGo to Asset VulnerabilitiesGo to Asset ImpactGo to ThreatsGo to Deterrent ControlGo to Detective ControlYou Are HereGo to Corrective ControlGo to CountermeasuresGo to CountermeasuresGo to CountermeasuresGo to CountermeasuresGo to CountermeasuresGo to CountermeasuresGo to CountermeasuresBack up to Security Controls

Preventative Controls address the Vulnerability itself, specifically the exploitability of the Vulnerability. Relating this back to the assessment of the Vulnerability, coming up with Preventative Controls can take one of two approaches:

  1. Apply a fix and the Vulnerability no longer exists
  2. Apply Security Controls to adjust the exploitability of the Vulnerability


Official Fix

The first approach is clearly the best as it leaves no room for the Vulnerability to be exploited, however this is not always achievable because there may simply be no official fix for the problem or the Vulnerability may actually be part of a business process that needs to be accepted and can therefore only be mitigated.

Even if a fix is available, all options should be presented so that the most economical choice can be selected. An official fix may require the system to be unavailable for days or weeks for regression testing and may have other costs, both of time and money, that need to be factored into the selection.

This leads us to the second form of mitigating preventative controls.

Mitigating Controls

In contrast to an official fix, a mitigating preventative control needs to address one or more of the Exploitability factors of the CVSS assessment of the Vulnerability. These include:

  • Access Vector - How close the attacker needs to be
  • Access Complexity - How easy it is to get to the Vulnerability
  • Authentication - How many times the attacker needs to authenticate to get to the Vulnerability

Each of these factors have very explicit options to choose from. Take a look at the current values associated with each of them and consider what options are available that would allow you to make better selections from that list.

Access Vector

For example, if the Vulnerability in question is a bug in an ssh daemon residing on an internet facing web server, you could potentially reduce the Access Vector from Network to Adjacent or even Local by denying access to the ssh port from outside of the local network with a simple firewall rule change.

This alone would significantly reduce the exploitability of the Vulnerability.

Access Complexity

A common, but relatively unknown problem when using a Reverse Proxy that maintains it's own authenticated session independently of a back end application server is that by default logging out of the 'application' only actually logs you out of the Reverse Proxy. The Application Server session typically still exists and expects to timeout, however the session cookies tying the web browser to the Application Server session are often still present in the browser even after the user has logged out.

In a scenario where a user only logs out of the Reverse Proxy and a second user utilizing the same web browser logs in as themselves, the application server will see the previous user's session cookies and hand over their session to the new user.

This is a good example of a 'race condition' as described in the CVSS spec, where the Vulnerability only presents itself under specific circumstances.

In this case, a simple (although incomplete) solution may be to add some javascript to the exit page that cleans up the Application Server cookies as well, which may allow the Access Complexity to be moved from Low to Medium.


A simple example of a business process type Vulnerability may be the need for registered users to be able to change their contact details where those same contact details are also used as a means of confirming a users identity via a back channel.

The user will need to authenticate in order to get to the profile page, but if they don't need to enter their password again when changing their contact details then anyone walking past an unlocked computer could change their contact details without challenge. They could then potentially use it to change the victims password via the 'forgotten password' option, which will utilize the new email address just entered.

Adding a password confirmation to the screen that allows these details to be changed would allow the Authentication selection to be adjusted from single to multiple.

Up Next

As with all Countermeasures, the hard part is the assessment on the costs.


Personal tools