Rework vulnerabilities to better match the CVSS model

[andrewbwm]

Major rework of the Vulnerability asset to better reflect the CVSS framework.

The Exploit asset was merged into the Vulnerability asset.

SoftwareVulnerability was created to represent Vulnerabilities that impact Applications/SoftwareProducts.

Note: the intermediate attack steps should be hidden once the design is agreed upon.

[andrewbwm]

For the SoftwareProduct assets proxy intermediate steps needed to be created on the Application side to trigger the vulnerability conditionally for each of the Applications impacted by the SoftwareVulnerability tied to the SoftwareProduct.

[andrewbwm]

No SoftwareVulnerabilities, except for UnknownSoftwareVulnerability, lead to FullAccess on the Application asset anymore. We should discuss solutions to remedy this.

Possible solution: we could create a new asset called CriticalSoftwareVulnerability that on impact it allows for FullAccess.

@skatsikeas and @mathiasekstedt suggestion: Have the Modify attack step on the Application trigger FullAccess.

Implemented in 198434ee7e79bdbe5bb14f3321294bdfcf535005.

[andrewbwm]

Some of the defences. specifically the ones dealing with the Impact Metrics(confidentiality, integrity, availability) on the SoftwareVulnerability do not necessarily perfectly reflect the CVSS documentation. They are qualitative in nature in the CVSS specification and quantitative in our current implementation. This may be an acceptable compromise.

[andrewbwm]

One of the IAMIntegrationTests needs to be reworked to properly function with the new vulnerability model.

[andrewbwm]

I would like to remove the Object - Vulnerability association as I think that most vulnerabilities should be somewhat asset specific.

Implemented in 1b110b356578aef101ec442c12b26b2e9515fcb7.

[andrewbwm]

The current defences all involve a flat percentage of succeeding. Do we want to have a more temporally minded design approach where as time progresses the attacker is more likely to achieve their goal?

Implemented in df0b1e9.

[andrewbwm]

The scope change aspect of the CVSS specification is not currently implemented. We could implement this by triggering the impacts on host Applications/Systems.

We have concluded that it is best to represent scope change through modelling, perhaps by disaggregating vulnerabilities which scope change, rather than introduce a new defence to address it explicitly. This choice seems reasonable given that propagating the impact from the vulnerable component to the impacted one would be exceedingly cumbersome.

[andrewbwm]

At Pontus's advice via @skatsikeas we have removed the exploit maturity defence and have reworked the exploit complexity to reflect the fact that the attacker is expected to expend additional effort when operating with a high complexity exploit. This was done to better mirror the somewhat confusing CVSS specification.

Implemented in 5e163e5.