Skip to content

Latest commit

 

History

History
105 lines (76 loc) · 5.77 KB

lab1_introduction.md

File metadata and controls

105 lines (76 loc) · 5.77 KB

/ main /

Lab1: Introduction to the ontology-driven threat modeling

Starting threat modeling...

The classic approach to threat modeling is based on Data Flow Diagrams (DFD). Also several other techniques exist.

You can use the OWASP Threat Dragon desktop application to manage threat models, apply mitigations, and create reports (there is its documentation). Threat Dragon has a built-in threat rule engine, supporting the STRIDE, CIA, LINDDUN techniques. However, we use here original ontology-driven approach, based on domain-specific threat models, and implemented by own OdTMServer application.

So, there is a simple computer system. It includes a web application (process) and background database (storage). Also, users of this system (external entities, or actors) should be taken into account. A user communicates with the application by the HTTPS protocol, and the application and database interact by the SQL protocol.

To examine security aspects of the system, a simple DFD has been created:

lab1_example1

After processing by OdTMServer, the threat model (Example1) is like (i.e. the 'db' item in the picture can be affected by the tampering, repudiation, denial of service, and information disclosure threats):

lab1_example2

Also, it can be found, that the 'app' component has double number of the STRIDE threats, because it has two flows (for example, denial of service of 'app' can be caused by the 'user' item with the 'https' flow, as well as by 'db' with 'sql'):

lab1_example3

Note, the ontology-driven threat modeling framework is focused on the network communications. Every data flow represents a network connection from a client (edge without arrow) to a server (edge with arrow). Such a connection is bidirectional, and you do not have to create a flow from the server to client (but this sort of traffic should be taken into account).

...and applying the cloud threats

Example1 (see above) shows how the ontological approach works. Our rule engine has 'taken' the STRIDE threats from the base threat model, which is an OWL (Web Ontology Language) ontology. Actually, that has been a result of automatic reasoning of the semantic interpretation of DFD (ontology too), e.g. ABox (Assertion Box), and the base threat model, e.g. TBox (Terminology Box). An introduction to Ontology Engineering can be found here (if you were really interested in).

The STRIDE approach gives a generic view to security threats. Analysis of particular cases requires domain-specific knowledge (for example, the threats that are specific to interaction between browser and web application or between web application and SQL database). The ontology-driven approach gives such an opportunity by domain-specific threat models. A domain-specific model contains typical components and threats, assigned to the flows between those components, for a particular kind of computer systems.

This guide depicts a cloud threat model, based on the Academic Cloud Computing Catalog Patterns (ACCTP) catalog. We have created an ontological domain-specific threat model from the ACCTP catalog.

With ACCTP it is possible to morph the common example of computer system to cloud specific. To do so, the 'app' and 'db' items have been labeled as 'class#CloudApplication' (see picture), and 'user' as 'class#RemoteUser'. These concepts ('CloudApplication', 'RemoteUser') are parts of ACCTP.

lab1_example4

After processing by OdTMServer, the items of the threat model (Example2) have got a bunch of new threats. The 'user' item has the least threats:

lab1_example5

Now you can work with cloud threats (apply mitigations, define severity or delete a threat) using Threat Dragon.

Note, our cloud threat metamodel has a minimum set of architectural components. In fact, you can model a structure of your application using the 'CloudApplication' concept and its derived entities only. External entities are represented by the 'RemoteUser' and 'ExternalService' concepts (see details in Lab2). To enable compliance-like threats the 'ComplianceManager' concept should be used (see Lab3), to apply the privacy threats use the 'PrivacyManager' concept (see Lab4).

Assignments

  • Using Threat Dragon, create a DFD for a case, that includes a web application (frontend interface and background database) and uses an HTTP balancer. Carefully define all the data flows. Save the diagram as a JSON file.

  • Using Threat Dragon, apply mitigations to the threats of the 'user' entity from Example2; save a report as a PDF file. To find mitigations use the ACCTP catalog and other cloud security sources.

Self-testing

  • What is threat modeling?
  • What approaches are used for the threat modeling?
  • Which items can a data flow diagram consist of?
  • What is STRIDE?
  • What benefits does STRIDE-per-element provide?
  • What is ontology engineering?
  • How can you describe a role of OWL in the ontology engineering?
  • How can you describe a role of automatic reasoning in the ontology engineering?
  • What is the base threat model (OdTM) in charge of?
  • What is function of domain-specific threat models (OdTM)?

/ main /