Risk Assessment Method: Step 4

<h2>Risk Assessment Method: Step 4</h2>

<p><span style="font-family: 'Constantia',serif; color: black;">Vulnerability Assessment</span></p>

<p style="box-sizing: inherit; font-variant-ligatures: normal; font-variant-caps: normal; orphans: 2; text-align: start; widows: 2; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial; word-spacing: 0px;"><span style="font-family: 'Constantia',serif; color: black;">Now comes the assessment of the strengths&nbsp;and weaknesses of your system, processes and culture. (See on page 207 columns 8 and 9 of the Table 9-8).</span></p>

<p><span style="font-family: 'Constantia',serif; color: black;">There trick here is to try to ignore any additional controls that you have already put in place but to assess the vulnerability as if noting special had ben done. This is called the green field vulnerability assessment. This is often difficult because people always want to explain how they have already done enough to prevent the threat from materializing, but it does help in the development of the security architecture to assess the contribution of all the planned controls over and above the green field situation before any security is build.</span></p>

<p>The aim of this exercise here is to state some control objectives at the conceptual security architecture level and to use these to drive through the detailed design of controls at the logical, physical, component and operational security architecture levels. This architectural development has different objectives from a security reviews of an existing system. This same&nbsp;risk assessment method can be applied to conducting such a security review of an existing system. This same risk assessment method can be applied to conducting such a security review, but there are differences in how you do it. These are described in part 4 of the book under the operational security architecture (See chapter 15), since&nbsp;conducting a security review is an operational activity, not an architectural development activity. Hence the subtly different approach.</p>

<p>Once again, a simple qualitative scale of measurement is used:</p>

<p style="padding-left: 30px;">H &ndash; High vulnerability: easily exploited by the threat</p>

<p style="padding-left: 30px;">M &ndash; Medium vulnerability: possible for the threat to exploit</p>

<p style="padding-left: 30px;">L - Low vulnerability: very difficult to exploit by the treat</p>