Business and Threat Assessments


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

A cyber security strategy, use case by use case.


Before i can start to define a cyber security strategy there are a number of prerequisites that need to be covered in order to ensure the right levels of formality and control of the design process. They include the use of different standards and design methods to enable the strategy to have consistency, accuracy and transparency in the requirements of inputs and production of output.

To begin i am going to use as a reference to use case development a great resource called http://www.uml-diagrams.org/ – it provides a comprehensive guide to UML. I am also going to highlight a quote from the UML-Diagrams website referring to Business Use Cases:

While support for business modeling was declared as one of the goals of the UML, UML specification provides no notation specific to business needs.

It is a shame that business modelling was included as a goal but has not yet been further expanded upon in the specification. That, however, does not stop use cases being used in business design and i have found that by complementing both UML and Archimate together this more than covers the requirements to model both behaviour and structure in conceptual diagrams.

The second item that i will highlight is the need for the support of metamodeling to provide the necessary modeling guidance – wikipedia provides a good overview at https://en.wikipedia.org/wiki/Metamodeling. A cyber security strategy will include a number of different domains each of which should be governed by a metamodel. There already exist a number of principle metamodels including:

  • TOGAF for enterprise architecture
  • IEEE for enterprise architecture
  • UML for system and behaviour modeling
  • SABSA for security architecture
  • Open Security Architecture (OSA) for security architecture
  • COBIT for governance
  • ITIL for service management

Otherwise you can define and declare your own metamodel or hybrid metamodel of domain concepts and relationships supported by taxonomy and controlled vocabularies. Thus ensuring you have in place some controls to support model development. Additionally you can also consider the ISO specification ISO/IEC 24744. A google image search for security metamodels will bring up a lot of examples.

The diagram below is a simple representation of the metamodel i use to identify the right concepts required for a cyber security strategy. It is just an example as selecting the right standards or controls will depend upon the type of strategy being defined. I will reference this diagram on many occasions as i cover each stage of developing a cyber security strategy, use case by use case.

Cyber Security Metamodel Example
Cyber Security Metamodel Example

The naked business…


I am going to begin with the theme of technology and organisation vulnerability and the importance of knowing how vulnerable you are and the many types of vulnerabilities and weaknesses there are. The root cause of any vulnerability can be traced back, directly or indirectly, to human error or misunderstanding.

My interest in this arose after reading several articles on the RISKS Digest, and in particular articles by its moderator Peter G Neumann who in in 1977 coined the term Peopleware. For its meaning i quote wikipedia:

Peopleware is a term used to refer to one of the three core aspects of computer technology, the other two being hardware and software. Peopleware can refer to anything that has to do with the role of people in the development or use of computer software and hardware systems, including such issues as developer productivity, teamwork, group dynamics, the psychology of programming, project management, organizational factors, human interface design, and human-machine-interaction.

Computer technology is now fundamental to organisational existence so to me it makes sense to consider vulnerability through the concepts of peopleware, hardware and software. Vulnerabilities manifest through either one, two or all of the three combined and so in contrast i will explore what these vulnerabilities entail and the required changes to enable greater resilience and resistance. Organisations unable to address their vulnerabilities face greater longterm nakedness and exposure to compromise.

b1

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 risk to support architectural design and change


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.

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