Applying evidence of threat to support architecture design and change


As with the evidence of risk, threat evidence is also subjective and therefore requires a similar development through methods, analysis and qualification. So what do we mean by threat and how does threat manifest itself. I like the definition of threat by NIST Federal Information and Information Systems:

Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, or individuals through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service. Also, the potential for a threat-source to successfully exploit a particular information system vulnerability.

So evidence is required to understand what is the potential of the threat or threats to an organisation and to understand the business impact. It will be evident from investigations and understanding the root cause of incidents as well as any reports form logs, rule or signature based security technology that attacks are happening but understanding who and why is a lot harder to determine.

There are a long list of threat actors who pose a threat, some more sophisticated and more capable than others but they are all a risk. Each threat actor will have a particular motive and target, whether that is financial, espionage or sabotage and use different methods and approaches to reach their goal.  The table below covers the common threat actors and background to their activities.

 

Hobbyist Predominantly lower skilled individuals motivated by curiosity, fun or peer groups.
Corporate Espionage Some organisations may use hacking methods or employ others to attempt to steal Intellectual Property or information to gain competitive market advantage
Investigative Journalist Journalists with a remit to investigate will use less scrupulous means to obtain privileged information.
Malware authors Malware authors may provide malware to other threat actors or attempt to release malware into an organisation to steal information or disrupt a service for other gains.
Privileged Users – Internal, Suppliers (e.g. developers, service provider) Individuals with the privilege of being an authorised user may exploit this position to commit fraud, steal Intellectual Property or cause damage.
BlackHat (hacker) / Criminal Gangs Lone or small groups of experienced hackers may seek to gain illicit access for self gain or to forward stolen information to others. They are seen to possess higher levels of both skills and motivation than hobbyists.

There are two key types of threat; a general threat where any compromise and exploitation of an asset will be of value to a threat actor to either maintain a backdoor for use a a future stage or to sell the access to another threat actor; the second and most important is the specific threat where a threat actor has a particular motivation.

Apart from a privileged user, it is difficult to identify the specific threat actor and their motivations, that can only be speculated at as the evidence and information is built up. So it is easier to align threat actors types to particular critical assets within the organisation as a means to develop threat evidence. For example, personal credit card data or research into a new drug may be of interest to different threat actors and as such will have different patterns of evidence that there is or is not a threat to these assets.

If we refer back to the Evidence model the focus begins with Evidence Development and the Hypothesis. The Evidence Development will help determine the right approach to go about gathering the information and data to form the evidence to support any hypothesis. Evidence of a threat my be suspicious activity, failed attempts to compromise a network or the discovery of malware. These events may be unrelated however they may begin to support the arguments and assertions that a threat is real and an attack likely. It may require many months of gathering the right information and evidence to result in the recommendations to make changes to architecture. The threats will remain as long as the assets are of interest to threat actors and they will change their methods and approaches as well as remain persistent.

b2

 

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.

b2

Building an Evidence Ontology


I have already highlighted in several earlier posts the aspects and importance of evidence but i am going to revisit particular key messages to explain the benefits from formalising the structure of evidence in order for it to support and improve EA knowledge.

  • The evidence ontology needs to be able to bring together a variety of research to strengthen hypotheses and recommendations in the artefacts and methods used in the architecture development method.
  • The evidence ontology needs to be able to support the internal EA content behind new views and scenarios as well as incorporate evidence from external sources.
  • Finally the evidence ontology needs to be able to support the formation of an evidence knowledge base that is flexible to help the engineering of future organisation models.
  • The evidence ontology needs to be able to enable the cross referencing required to demonstrate the importance of pattern and knowledge rules

You may be asking what is the point of building up a model of evidence to such a degree as an ontology. The main reason is that it is a relatively simple model and by doing so you are able to decide upon what constitutes evidence, how you characterise it and how you build and approve it. Otherwise any supporting evidence looses it importance if it does not have foundation. The reason i choose to use Cyber Defence evidence as an example it that the lessons and knowledge gained from understanding threats, risk and vulnerabilities in your organisation is vital to your architectural development now and in the future. That is not to say that evidence in Marketing, Sales or Product / Service development is less important, it is not, as any evidence used to support decision making is vital to develop and sustain a business.

So back to the Evidence Ontology and a proposed high level structure. at the top level the Evidence Ontology looks as follows:

  • Evidence research
  • Evidence development
  • Evidence synthesis
  • Evidence evaluation
  • Hypothesis
  • Evidence monograph
  • Evidence attributes

Each of these classes is further defined by sub classes as demonstrated in the attached image file. I have collected these classes from various sources of information and they represent my view of the necessary requirements to cover the process, classification, evaluation and provision of evidence material to support any decision based activity such as planning, strategy and enterprise architecture. I will continue in the next post with a look at the properties and relationships to the decision based activities through examples.

Evidence Ontology
Evidence Ontology

An evidence based enterprise


Is the enterprise of the future an evidence based enterprise? It is an interesting question and as the number of business functions exploring an evidence based approach grows, then perhaps there will be a tipping point towards its acceptance.

Every organisation has a different view of how technology can influence how they do business. Perhaps this is best explained using the old term from the late 90s when enterprises were either Bricks and Mortar or Dot Coms. Whilst this does not mean that one is more or less likely to adopt evidence based practice a smaller more agile organisation should have the advantage because their thinking may be more progressive.

I think the adoption will depend upon the type of organisation and the culture it instills. Technology has the ability now to communicate with every single person in an enterprise, no matter how large it is, via email or the internet. Thus, it has the ability to deliver information to every person so that they can use it to perform the activities they do. Therefore technology is able to put evidence in the hands of everyone that makes a decision. So a culture that exists with the belief that evidence is important combined with a pioneering view of using technology in the workplace, like the dot coms, should be better placed to leverage information and technology to make better decisions.

What the evidence ontology should support.


In a nutshell an enterprise architecture is a collection of facts about the organisation’s current architecture, a development methodology supported by a collection of artefacts and a model of the organisation’s future architecture. On top of that there are the capabilities of the people, processes and technologies that make up the organisation that defines what it is and what it does. An evidence based approach to enterprise architecture requires evidence in a variety of types and to varying degrees of detail to support all of the above.

The current architecture is primarily a collection of facts that have been built up, depending upon how recently the organisation has adopted enterprise architecture, under varying amounts of decision making and control. Information can and should exist about how the current architecture is operating and performing and to what level of satisfaction and success. This information can be formulated to represent existing evidence and therefore provide support for future decisions about change.

The future model of the organisation is a set of concepts that offers a new view of the organisation depending upon the scenarios it envisages. The model and concepts will evolve and impact on that evolution. The degree of possible change will depend upon how far in the future the model is set, the maturity of the strategies and organisational decisions. there will also be unexpected impacts on the organisation and on the strategic direction. This future model is dependent upon an architectural development method to deliver the new version of the organisation as well as the capabilities and tools to support it. So it is important that the evidence ontology is able to support the following principles:

  • The evidence ontology needs to be able to support the internal content behind new views and scenarios as well as incorporate evidence from external sources.
  • The evidence ontology needs to be able to bring together a variety of research to strengthen hypotheses and recommendations in the artefacts and methods used in the architecture development method.
  • Finally the evidence ontology needs to be able to support the formation of an evidence knowledge base that is flexible to help the engineering of future organisation models.

Evidence ontology – a high level overview of a model to support evidence based enterprise architecture


Evidence Ontology Concepts

The model attached to this post is a strawman collection of concepts i am evolving to represent an evidence ontology. The concepts I am exploring are:

  • Evidence research
  • Evidence development
  • Evidence synthesis
  • Evidence evaluation
  • Hypothesis
  • Evidence monograph
  • Evidence attributes