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.


The production of enterprise architecture documents should adopt a formal content authoring framework – principle 4

The common tool across most organisations for authoring documents is Microsoft Office – Word, Excel and Powerpoint – however this does limit the usefulness of the information contained within the document. Even though Microsoft has updated the file format to an XML based format this still does not allow the author to add intelligence to the document by way of tagging content with more than just headings and styles.

In order for enterprise content management systems and enterprise search engines to manage and deliver content to users they need to be formatted in a particular way with metadata and xml. Microsoft Word and Excel are able to do this but there are other tools that could be used to build a better content library for an enterprise architecture repository. At this point I am not talking about models produced with an appropriate enterprise architecture tool such as Troux or Aris but document based artefacts.

It is worth considering the potential benefits from authoring content within a XML authoring tool – at the moment i am looking at an open source tool from Syntex called Serna. This is a WYSIWYG XML authoring tool that offers DITA and Docbook formats and at some later date i will post some comments on the application.

The role of an enterprise architecture repository – principle 1

Enterprise Architecture Management System
Enterprise Architecture Management System

The Enterprise Architecture Repository is both a means to store all of the artefacts concerning the enterprise architecture and a federated information system linking with other sources of data and c0ntent. This federated environment produces a enterprise architecture management system to support architectural development. There is quite an interesting overview of this on the Aris Community blog.

Along side the standard features of the repository, to hold the information pertaining to the AsIs and ToBe models, is the need for the system to support research development and evidence management. The enterprise architecture is represented by a collection of facts and statements about the enterprise. They are collected in a set of artefacts and are used through the architecture development methodology to build future versions of the enterprise. It is the change from the current state of the enterprise to a new state that evidence is required and applied to support change decisions. The evidence that is used and cited within artefacts it should be stored within the architecture repository. This enables the evidence to analysed and tracked through the lifetime of the decision.

The evidence repository is a subset of the EA repository or federated knowledge base that has defined relationships that link the evidence to the artefact. This can be achieved through simple hyperlinks but a defined approach with specific artefact metadata and unique identifiers would offer a structured relationship. This should also encompass the evidence metadata to provide the attributes to support tracking such as the value, confidence and temporal attributes.

Whilst it is important to store evidence cited within artefacts within the EA repository it is also important to store research and information to act as future evidence. This form of evidence should be built with a formal process and should be collected in line with future views of the organisation. This type of evidence can include horizon scanning of new technologies, customer or user opinions and surveys, planned legislative changes or innovations.

I have made this principle 1 because i consider an enterprise architecture repository a fundamental part of enterprise architecture and building up and storing evidence is a vital part of evidence based enterprise architecture.