Category: Cyber Defence

Business and Threat Assessments

by Tolosa, posted in Cyber Defence, Cyber Security, Cyber Security Strategy, Evidence Based Enterprise Architecture, Threat, Threat Actor

To support a cyber security strategy it is necessary to conduct a business assessment and evaluation of the organisation’s current state. The breadth and depth of this assessment will again be in proportion to the proposed scope and vision of the strategy. The criteria for an assessment should again reflect the scope but in general the assessment should aim to cover:

  • Geography and locations
  • Business services and operations
  • Organisational structure
  • Legal or regulatory requirements per geography
  • Current business strategies per geography
  • Current risk and threats
  • Current security capabilities
  • Current architecture
  • Current service management and supplier management

The list above is not exhaustive and there may be other specific areas that are beneficial to the strategy but the list above should cover enough to gain a good understanding of the current or AsIs position. The assessment is basically the beginning of the necessary gap analysis required to qualify the strategy, transformation and determine its success. There are a number of different ways to conduct a business assessment and enable the gaps to be identified. These include diagrammatic means such as building block diagrams and use case models or through spreadsheet matrices.

Once the business assessment has been completed and sufficient information has been gathered to form a good understanding of the organisation and its scope of operations, an assessment of the likely threat to these finding can begin. Your security operations should have a security incident classification within the organisation incident management domain which can be used to define threats. This classification or taxonomy of threat types should be used to help produce an initial threat assessment based upon a breakdown of what a threat means and how it manifests. There are a number of useful threat classification model available including those from:

The type of information that is also required if it can be obtained is the following:

  • Security incident reports
  • Assets targeted
  • Geography
  • Impact on business/services
  • Root cause conclusions
  • Repeated incident types
  • Organisation vulnerabilities

A Threat Assessment is built up with the following activities and output:

  1. Define threat types facing organisation and order by severity
  2. Define threat profile for each threat type – including threat actor, motive, FOI or target asset
  3. Define threat scenarios to challenge the organisation and its vulnerabilities

Once you have completed the business and threat assessment and the have an understanding of the current state and operations within the organisation, its vulnerabilities and threats you can conduct a risk assessment. Your risk assessment should follow your organisation risk method or select FAIR or OCTAVE as a means to determine the risk “appetite” or tolerance towards the threat. This tolerance and assessment will influence further assessment types, gap analysis and areas for transformation.

Cyber Security Strategy Business Threat Assessment
Cyber Security Strategy Business & Threat Assessment

Applying evidence of risk to support architectural design and change

by Tolosa, posted in Cyber Defence, Cyber Defence Ontology, Cyber Security Strategy, Evidence Based Enterprise Architecture, RISK

There is an awful lot of material published on risk in general, risk analysis and management as well as the methods used to determine and classify risk.  Unlike vulnerability, which is more objective in evidence and assessment, risk is more subjective and therefore requires more effort in the gathering and development of the evidence used to support a decision. From an enterprise point of view decision makers will be subject to the risk vs cost vs benefit tradeoffs. When faced with these tradeoffs decision makers will have to choose from options that may cause harm or worse. Important factors in these choices include both the probability of a risk and whether its consequences would be negligible, moderate, or serious. So it is important that the criteria used in the evidence supporting the choices is sufficient for the right choice to be made as well as managing the consequences should the risk arise.

As always Wikipedia provides a suitable definition and further background to the topic:

In enterprise risk management, a risk is defined as a possible event or circumstance that can have negative influences on the enterprise in question. Its impact can be on the very existence, the resources (human and capital), the products and services, or the customers of the enterprise, as well as external impacts on society, markets, or the environment. [Wikipedia]

Certainly cyber threats pose events or circumstances that can have negative influences on the enterprise and security incidents and reports from security technology provide sufficient evidence that the risk of attack is constant. What is important is the requirement to ascertain what, within the enterprise, are the critical assets – services/systems and their availability, customer data, intellectual property etc., and conduct appropriate risk /threat assessment and evidence to show the risk can be mitigated or the threat determined.

If i refer back to the evidence model and the means to accumulate the required forms of evidence – for risk analysis and management – benefits from an evidence evaluation method and there are a number associated with risk:

  • FAIR (Factor Analysis of Information Risk) – Information Security
  • RiskIT – IT Risk
  • ISO 31000 – Risk Management General Principles and Guidelines
  • CRAMM – UK OGC General Risk Management Framework
  • ISO 27000 – ISO Series on Information Security Standards
  • NIST 800 – US standards for Computer Security
  • OCTAVE – CERT Strategic Information Risk Assessment

An evaluation method applies a level of control as well as quality to the output and also the reliability that the method has its own evidence of effectiveness.

I am going to use FAIR as the example method as the output gained can be applied to architectural decision making in respect to cyber security. In other words there is a risk to a critical system from an inside attack and in order to propose a change or security improvement plan evidence needs to show the vector and example evidence that the risk is highly probable.

FAIR Model Cyber Security Ontology
FAIR Model & Cyber Security Ontology

The model i have attached to this post shows the alignment between the recognition that the risk method is a valid evaluation method, the threat is determined as an Insider Threat and the vulnerable system being a Critical Business Application. The source of the security events associated with the threat are derived from Access Management log data analysed via anomaly analysis – unusual log in patterns by user for example – which also corresponds to an evidence source – metadata analysis. The purpose of the alignment of the evidence model to the risk method is to indicate that the method is a recognised and authoritative means to provide evidence and the source of the evidence is derived from a cyber defence capability. The data source for the Threat Event Frequency would be derived from the Log Analysis. Other criteria within the FAIR model would be derived form additional research or analysis. There are other factors to include that the data is stored and managed in a forensically ready manner, however the report output has justification nevertheless to support risk based decision making.

Cyber Security Ontology and Cyber Defence Ontology

by Tolosa, posted in Cyber Defence, Cyber Defence Ontology, Cyber Security Ontology, Enterprise Ontology

First I am going to reference some work i found on the internet which offers some interesting insights into the various different views and approaches to developing ontologies for security and cyber security.

The first is a project form 2007 which provides a Cyber Security Ontology developed in OWL – Reference: A. Herzog, N. Shahmehri, C. Duma, ‘An Ontology of Information Security’, International Journal of Information Security and Privacy, 1(4):1-23, 2007. The paper is available here.

The second is a Seventh Framework research programme called PoSecCo – Policy and Security Configuration Management – and is contributing in some part to the Digital Agenda for Europe. One thing in particular which caught my attention is the paper called Security Ontology Definition, which describes in detail the ontologies consider within the project. There are also some interesting videos of the project.

It is interesting reading through the material produced by these projects as it shows the variety of different approaches taken to define and apply the domain of cyber security. It also highlights just how varied this domain is and how much needs to be formalised. The PoSecCo projects also describes a Security Decision Support System (SDSS) which would suggest that the models and data  are being used to infer some outcome to support a decision criteria.

Whilst each of the projects above have covered different areas of  security it may well be that from an ontological perspective that some consolidation of ideas and classifications are required to standardise the domain.  So, and it is just my opinion, there may be two or three key ontology models required – two if cyber defence is considered a subset of cyber security. The first being the enterprise architecture ontology to provide the context for all the entities that comprise the enterprise. The second is the security ontology covering what constitutes security through policy, compliance, threat, risk and vulnerability. The third is the defence ontology which covers the technologies, methods and capabilities to protect the enterprise. Each works in conjunction to provide a range of views to understand the challenges and also to provide sufficient situational awareness to combat the increasing threat. For more information on Situational Awareness there is an excellent website called Military Ontology which whilst specific to military defence has some very thought provoking material and resources. Finally there is a paper on the subject of Situational Awareness Ontology which is well worth reading and i hope to come back to this topic in the future.

Cyber Defence Ontology
Cyber Security Data Architecture

 

Applying evidence of vulnerabilities to support architectural design and change

by Tolosa, posted in CERT, Cyber Defence, Enterprise Architecture Repository, Evidence, Evidence Based Enterprise Architecture, SABSA, Vulnerability Management

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

by Tolosa, posted in Cyber Defence, Evidence Ontology, Principles

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