Using UML Misuse Diagrams to Secure Systems From Threat Actors

Organizations have traditionally used attack trees and data flow diagrams to understand system risks and how to manage them. These have worked well, but they do not always show the points in a system where a threat actor can cause interruptions or steal data. UML misuse diagrams are often better tools for showing how a system is supposed to behave and how internal and external actors might compromise it.

What is a Use Case Diagram

Misuse case diagrams are an extension of use case diagrams.  Use case diagrams are based on the Unified Modeling Language, or UMLOpens a new window .  They depict a system’s operation and the associated actors.  The elements of a use case diagram include 

• Actors – Actors include human and non-human entities that interact with the system, including organizations and other systems.
• System – The system is depicted as a set of services that are either performed by actors or executed due to actor behavior.
• Relationship lines – Arrows with different line and arrow styles show how the system services and actors interact.

See More: Exploring the Use Cases and Costs of Facial Recognition Solutions

Purpose of Use Case Diagrams

Use case diagrams are helpful for more than just an entire system. They also help understand functional requirements for websites, software components, business processes, and applications. Teams can leverage use case diagrams whenever a clear picture is needed of any business activity.

One of the most common uses of use case diagrams is to define and verify functional requirements.  Let’s see how this works.

An example of an Use Case Diagram

Figure 1 is a simple example of a use case that  I created with one of many diagramming solutions that support UML modeling. 

Figure 1: Use Case Diagram

• • The yellow rectangle represents the system.  In this case, it is an accounts payable system. 
  • The ovals within the rectangle represent a set of functions within the system.  The functions in Figure 1 make up the tasks required to enter and pay a vendor invoice.
  • The stick figures represent the roles that interact with the system.  Note that they are roles, not named individuals.  Actors on the right might also include a bank stick figure if the system checks with the bank for balance information.

 The use case uses three types of lines and arrows.

• • The dashed lines between the actors and ovals represent actor interaction with the system.
  • The arrows with an “<<include>>” label extend from one function to a second function that is always executed when the first (base) function is executed.  For example, Verify ID is always executed when Login is executed.  Login is the base function in this relationship.
  • The arrows with an “<<extend>>” label sometimes executes, depending on process conditions.  The arrow extends from the extended function to a base function.  For example, Send Error is executed if Verify ID fails.  In this case, Verify ID is the base function.

It is usually a good idea to understand the use case before looking at ways the system can be misused.  This allows the definition of security requirements while determining functional requirements.

See More: How Multi-CDN Strategies Can Help Organizations to Mitigate the Impact of Outages

Misuse Case Diagrams

Misuse case diagrams expand use cases by adding malicious functions that might adversely affect the system.  Figure 2 is an example of one way to convert Figure 1 into a misuse case. 

Figure 2: A Misuse Case Diagram

One threat actor in this misuse case is a rogue employee. She is an AP clerk. The AP clerk can create invoices, enter new vendors, and make payments in this application design.  This enables a rogue clerk to enter a fake invoice for a phony vendor.  She can then create and send a payment to herself or a collaborator.

In this case, the security team would likely create a security requirement that forces the separation of duties. The AP system should not allow the same person to enter an invoice, create a new vendor, and pay an invoice.  Another clerk should be needed to perform one or more of these tasks.

The other example is an external threat actor, on the right, that either acquires the credentials of an AP clerk or has compromised a device used by an AP clerk.  It is possible to perform payment tasks or steal vendor bank data used to make payments in either case.

Separation of duties will also prevent an external threat actor from performing AP tasks.  In addition, multi factor authentication would keep a threat actor from successfully using stolen credentials.

These are just two simple examples of how to use a misuse case.  There are usually other attack paths to address, depending on the location of the system and the prevention, detection, and response controls that surround it.  Usability.gov provides a helpful guideOpens a new window for designing use cases. The same steps we use for actors with normal behavior can also be used for threat actors.

Final Thoughts

Misuse cases, like any diagram, help all stakeholders to understand functional and security requirements.  They make it much easier to engage a cross-functional team where everyone is “on the same page.”

Like attack trees, saving misuse case diagrams with the rest of the system documentation help enable revisiting probable attack paths during subsequent risk assessments.

Has your organization used a misuse case diagram to map its systems yet?  Let us know on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We’d love to hear from you!