Applying evidence of vulnerabilities to support architectural design and change

To support this post i am going to assume that a vulnerability or weakness is due to a failing of the architectural design and development process to identify or mitigate the chance of exploitation. That failing may be due to lack of experience, legacy practice or an oversight in the evaluation and appraisal of the solution before it is deployed.

Depending upon the size and complexity of your architecture, determining how vulnerable your organisation is without the support of vulnerability scanning technology is difficult. That said, it is not difficult to introduce at various points of the architectural cycle the necessary evidence of known external  or internally discovered vulnerabilities to support new projects or change existing deployed architecture. Using TOGAF as an example, evidence should be included in stages B, C, D and E as well as stage H. All evidence collected should be included in the architectural repository. [From a wider security perspective it is also useful to consider more general application of security to architecture through the benefits of SABSA (Sherwood Applied Business Security Architecture) and TOGAF together.] More information on SABSA.

If we begin with the external evidence research there are numerous good sources of vulnerability information available on the internet. If starting this exercise for the first time i would recommend the Verizon Data Breach Investigation reports. These reports provide some excellent insights into the exploitation of vulnerabilities and attack types. To quote an insight from the Verizon report:

  • Opportunistic attacks: The victim isn’t specifically chosen as a target; they were identified and attacked because they exhibited a weakness the attacker knew how to exploit.
  • Targeted attacks: The victim is specifically chosen as a target; the attacker(s) then determines what weaknesses exist within the target that can be exploited. [Source Verizon]

The latest Verizon report provides more detail on the statistics and background to weaknesses or vulnerabilities exploited by attackers and it also shows that Hackers still very much rely on vulnerabilities as a means to gain access to an organisation’s environment.

A second area of research should focus on the more detailed reporting of vulnerabilities so that the research begins to align to the context or your organisational architecture. I would recommend CERT Division of the Software Engineering Institute (SEI) and Common Vulnerabilities and Exposures (CVE®).

Internally, the common ways to research necessary evidence for architectural change comes from the following operational capabilities:

  • Vulnerability Management
  • Patch Management
  • Intrusion Detection
  • Security Incident Management

What you determine internally will be dependent upon how mature these capabilities are in your organisation and what data or reports you are able to collect.  That is where the rest of the evidence model is able to help with the assessment and development of the material collected and produced. The application of the evidence model is there to help decide what is required to create a report or monograph to support architectural decision making and underpin the strength of the arguments stated in the evidence.

I am going to continue this thread by looking at Risk and Threat information as evidence as the three areas of risk, threat and vulnerability compliment each other. The combination of the three areas should mature the architectural thinking especially around the evaluations  and overall hypotheses made.