ESA Framework Description of Use Case Patterns

ESA Program Overview	ESA Foundation	ESA Artifacts	ESA Initiatives	ESA Tools and Templates	ESA Reference Materials	Glossary

ESA Backgrounder	ESA Program Charter	ESA Program Implementation Framework	ESA Framework

Actors	Components	Use Cases and Patterns	ESA Artifacts	ESA Requirements Matrices

Use Cases

As outlined by MITRE, a use case is a description of a system's behavior as it responds to a request that originates from outside of that system. It describes "who" can do "what" with the system in question and allows a system's behavioral requirements to be captured as scenarios that trace back to requirements. Scenarios are depicted using sequence diagrams. Use cases are ideally generated from the System Concept of Operations. Use cases are decomposed into one or more detailed scenarios that assist in the identification or creation of an applicable pattern.

The following describes the process used to identify use cases and patterns:

1. The first step is identifying common use cases that apply to the system. A use case is simply a function that is offered by the system to one or more types of actor, where an actor may be a human user or an external system with which the target system interacts.
2. Each case is expanded into a scenario, a diagram that shows a time-based sequence of actions that are performed to achieve its corresponding use case. A scenario must always show the interactions between the actor (or actors) and the system, and may also show interactions among well-defined components that comprise the system. A scenario is documented as a Unified Modeling Language (UML) Sequence Diagram.
3. Patterns are developed based on the use cases. It is expected that a single pattern will trace to multiple use cases.

The following is an example of a use case which identifies pre-conditions and post-conditions:

File:ESA Use Case with Pre and Post Condition Example - Framework.png

Use Case (Discover Unauthorized Device)

The following figure provides an example of an interaction diagram which includes components, dependencies, processes, and people:

File:ESA Framework Use Caseand Interaction Diagram.png

Use Case and Interaction Diagram

Patterns

An ESA pattern is simply a description of a reusable solution to a problem. Patterns must include a description of the context and problem addressed by the pattern. The following table provides an overview of the general contents of a pattern:

Content	Description
Name	A meaningful and memorable way to refer to the pattern, typically a single word or short phrase.
Abstract	Provide an overview of the pattern, including indicating the types of problems it addresses. It may also identify the target audience and what assumptions are made of the reader.
Problem	A description of the problem indicating the intent in applying the pattern - the intended goals and objectives to be reached within the context and forces described below. It includes identification of potential threats.
Applicability	A description of when the pattern applies and when it does not.
Trade-offs and Constraints	A description of the relevant forces and constraints, and how they interact/conflict with each other and with the intended goals and objectives. The description should clarify the intricacies of the problem and make explicit the kinds of trade-offs that must be considered. The notion of "forces" equates in many ways to the "qualities" that architects seek to optimize and the concerns they seek to address in designing architectures. For example: Security, robustness, reliability, fault-tolerance Manageability Efficiency, performance, throughput, bandwidth requirements, space utilization Scalability Extensibility, evolvability, maintainability Modularity, independence, re-usability, openness, composability, portability Completeness and correctness Ease-of-construction Ease-of-use Etc.
Solution	A description, using text and/or graphics, of how to achieve the intended goals and objectives. The description should identify both the solution's static structure and its dynamic behavior - the people and computing actors, and their collaborations. The description may include guidelines for implementing the solution. Variants or specializations of the solution may also be described. Preconditions under which the pattern is applicable will describe the initial state before the pattern is applied. The solution is offered by the pattern, comprising both its structure and behavior. The structure depicts the different actors that play a role in the pattern, and the relationships among them. The intended behavior of the actors defines the collaborations among the different actors. The post-conditions after the pattern has been applied. Implementing the solution normally requires trade-offs among competing forces.
Examples	One or more sample applications of the pattern which illustrate each of the other elements: a specific problem, context, and set of forces; how the pattern is applied; and the resulting context. An example of the pattern in an easily understood software setting. This example makes the pattern concrete and tangible. It also helps to clarify the pattern’s intent, its use, and its consequences to the user.
Related Patterns	The relationships between this pattern and others. These may be predecessor patterns, whose resulting contexts correspond to the initial context of this one; or successor patterns, whose initial contexts correspond to the resulting context of this one; or alternative patterns, which describe a different solution to the same problem, but under different forces; or co-dependent patterns, which may/must be applied along with this pattern.
Mitigated Threats	Threats mitigated by the pattern and use cases.
References	Relevant references to support the pattern.

Open Security Architecture (OSA) identifies a technique to facilitate the integration of security requirements in target architectures by visually allocating security controls to the various components within a target architecture. Visual patterns bring together security requirements for a use case and provide the basic building blocks to make a particular solution secure. The allocation of controls depends on the context of the environment or solution and will lead to the development of context-based patterns. These diagrams are annotated with references to the security controls. The patterns include actors who have a set of responsibilities that can be assigned to a prototypical role in a given setup. For more information about patterns, please read the GC ESA Framework.

The following figure is an example of a pattern for the authentication of an client endpoint device (END) to the network:

File:Example EUD Security Pattern (Authenticate Device to Network).png

An example EUD security Pattern (Authenticate Device to Network)from the ESADD Annex on End User Devices

ESA Pattern Diagram Repository

Each one of the ESADD Annexes provides a series of related pattern diagrams. For the ESA Pattern Diagrams, please see the ESA Pattern Diagram Repository.

References

• GC ESA Framework
• GC ESA Pattern Diagram Repository
• GC ESADD Annexes
• Open Security Architecture (OSA)
• MITRE