threat modelling

The Diamond Model of Intrusion Analysis

/ bugejajoseph / Leave a comment
Photo by Michael Morse on Pexels.com

In the world of cyber security, effectively processing data and turning it into actionable intelligence is crucial. While the Cyber Kill Chain® and the MITRE ATT&CK Framework are commonly used methodologies, there is perhaps a lesser-known alternative called the Diamond Model of Intrusion Analysis. Developed in 2013 by renowned cyber security professionals, Sergio Caltagirone, Andrew Pendergast, and Christopher Betz, this model is an indispensable resource for cyber security professionals. It offers a simple yet powerful way to analyze and document intrusion incidents.

The Diamond Model is composed of four features: adversary, infrastructure, capability, and victim. The adversary represents individuals, groups, or organizations that exploit vulnerabilities to achieve their goals. Capability encompasses the tools, techniques, and methods used by adversaries, while infrastructure refers to communication systems like IP addresses and domain names. Victims can be individuals, organizations, or specific assets such as target email addresses. In addition, it delineates supplementary meta-features that bolster higher-level constructs, while also incorporating measurement, testability, and repeatability to deliver a more encompassing scientific approach to analysis.

Despite its unassuming appearance, the Diamond Model possesses the ability to swiftly navigate intricate and multifaceted details. The dynamics of a threat actor exist in a perpetual state of flux, as attackers continuously modify their infrastructure and capabilities. Moreover, when integrated with the Cyber Kill Chain® and other frameworks, it contributes to the establishment of a comprehensive cyber security framework. This integration facilitates a deeper understanding of threats and strengthens incident response capabilities, empowering a more proactive defense posture.

An example of using the Diamond Model in practice is found here.

My talk in Japan

/ bugejajoseph / Leave a comment

On Monday 11th March, I attended IEEE PerCom in Kyoto, Japan.  PerCom is regarded as a top scholarly venue in the areas of pervasive computing and communications. It is my third year participating in this conference. This year, I presented a paper titled: “IoTSM: An End-to-end Security Model for IoT Ecosystems”, in PerLS’19 – Third International Workshop on Pervasive Smart Living Spaces.

My presentation, live demos, and paper awards at the International Conference Center in Kyoto (2019).

In my presentation, I talked about how most of the reviewed security frameworks and maturity models, tend to focus more on securing web applications and services, but have not evolved particularly to cater for the additional complexities and challenges that IoT technologies bring to the table. While most of the security practices remain similar, IoT requires additional checks and balances to implement effective security.  Some reasons for this, is that IoT applications by their nature tend to be Internet-connected, deal with highly personal data, and feature complex interdependencies involving multiple stakeholders and third-party systems.

Reviewing the existing scholarly literature and interviewing various IoT security experts based in Sweden, we especially observe the need for continuous processes rather periodical processes. For instance, when it comes to risk assessment in IoT it is especially preferred if it is “continuous” in order to deal with the highly dynamic nature of IoT systems. Unfortunately, there is a shortage of methodologies for that and most of the related research work is still in its early stages.  Moreover, we note the lack of security awareness common across the industry, e.g., with regards to “threat modelling”, but as well its applications to model data flows, in particular to deal with information privacy.  Finally, we recognise the diversity of IoT security requirements. While for a traditional application, one needs to ensure service, network, and physical security for IoT one might need as well other to consider other requirements, e.g., that of ensuring resilience, data security, cloud security. Likewise, IoT may require to cater for additional threat agent goals. Such goals may not necessarily be related to confidentiality, integrity, and availability.

Take a look at my presentation: IoTSM: An End-to-end Security Model for IoT Ecosystems

Using STRIDE to Uncover Threats in an Information System

/ bugejajoseph / Leave a comment

As part of my threat modelling lecture, on 4th February, I covered the basics of STRIDE. STRIDE is a mnemonic – Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Microsoft’s STRIDE is a well-known and mature technique used by security professionals to elicit information security threats of real-world systems.

STRIDE

STRIDE is a model for identifying computer security threats.

The properties of STRIDE are as follows:

  • Spoofing Identity: Spoofing threats allow an attacker to pose as some other process or somebody else. Example, a user can pretend to be Steve Jobs, or a server can pretend to be Amazon.com, or even code posing as msvcrt.dll. This is a threat to authentication.
  • Tampering: Tampering threats involve unauthorised modification of data or code. The resource being manipulated could be both in storage or being transmitted. This is a threat to integrity.
  • Repudiation: An attacker makes a repudiation threat by denying to have performed an action that other parties can neither confirm nor contradict. Example, a user may claim that he has not received the goods that he purchased while in fact he did receive them. Naturally, this violates the repudiation property of a system.
  • Information Disclosure: Information disclosure threats involve the exposure of information, typically of a sensitive or personal nature, to individuals who are not supposed to have access to it. Examples of this threat type include a user’s ability to read a file, e.g., payroll information sent to HR, that he was not granted read access to. This is a threat to confidentiality.
  • Denial of Service: Denial-of-service (DoS) attacks deny or degrade service to valid users. Typically, this makes a Web server or a device (e.g., battery-operated device) temporarily unavailable or unusable, but it can also be of a permanent nature (e.g., if attacking an ICS or SCADA system). This is a threat to availability.
  • Elevation of Privilege: Elevation-of-privilege (EoP) threats often occur when a user gains increased capability. For instance, a non-privileged user  taking advantage of a coding flaw to gain administrator or root capabilities. This threat type violates the authorisation goal of a system.

STRIDE provides a very effective way for identifying threats but before it can be used effectively one needs to be familiar with system modelling techniques. This is needed to provide a working model of the system being analysed. Here, Data Flow Diagrams (DFDs) come to the rescue. DFDs provide a visual notation of a system enabling an analyst to depict processes, storage, data flows, external entities, and as well trust boundaries. Once you get the system model right, it is relatively easy to identify threats with STRIDE.

Feel free to contact me for more insights on this or related topics.

Information Assets: An Essential Ingredient of Threat Modelling

/ bugejajoseph

Threat models are a way of looking at risks in order to identify the most likely threats to your organisation’s security. The first step in the threat modelling process is concerned with gaining an understanding of the application and how it interacts with external entities. This involves creating use-cases to understand how the application is used, identifying entry points to see where a potential attacker could interact with the application, identifying assets, and more. In this post, we focus on identifying information assets.

Assets are essentially threat targets, i.e. they are the reason threats will exist. Assets can be both physical assets and abstract assets. For example, an asset of an application might be a list of clients and their personal information; this is a physical asset. An abstract asset might be the reputation of an organisation. Hereunder, we identify some key informational assets that your organisation or information system might have or process:

  • Credit card data: yours, or (if you sell stuff) a customer’s.
  • Banking data: account numbers, routing numbers, e-banking usernames and passwords.
  • Personally identifying information: Social Security number, date of birth, income data, W-2s, passport numbers, drivers’ license or national ID numbers.
  • Intellectual property: like source code or software documentation.
  • Sensitive personal or business information and communications: e-mails and texts that could be used to embarrass, blackmail, or imprison you.
  • Politically sensitive information or activities that could get you in trouble with your employer, the government, law enforcement, or other interested parties.
  • Travel plans that could be used to target you or others for fraud or other forms of attack.
  • Other business or personal data that are financially or emotionally essential (family digital photos, for example).
  • Your identity itself, if you are trying to stay anonymous online for your protection.

When it comes to protecting the assets pieces of information that could be used to expose your assets are just as essential. Personal biographical and background data might be used for social engineering against you, your friends, or a service provider. Keys, passwords, and PIN codes should also be considered as valuable as the things that they provide access to.

Other operational information about your activities that could be exploited should also be considered, including the name of your bank or other financial services provider. For instance, a spear-phishing attack on the Pentagon used a fake e-mail from USAA, a bank and insurance company that serves many members of the military and their families.