|
|
| Line 28: |
Line 28: |
| | |} | | |} |
| | </div></div> | | </div></div> |
| − | | + | {{Delete|reason=Expired Content}} |
| − | {{TOCright}} | |
| − | == Use Cases ==
| |
| − | | |
| − | As outlined by [http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/other_life_cycle_building_blocks_articles/spanning_operational_space.html 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:
| |
| − | | |
| − | #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.
| |
| − | #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.
| |
| − | #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|center|700px|thumb|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|center|608x608px|thumb|Use Case and Interaction Diagram]]
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == 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:
| |
| − | | |
| − | {| class="wikitable"
| |
| − | |-
| |
| − | | style="background: #000000; color: #ffffff | '''Content''' || style="background: #000000; color: #ffffff | '''Description'''
| |
| − | |-
| |
| − | | style="background: #727272; color: #ffffff | '''''Name'''''
| |
| − | |A meaningful and memorable way to refer to the pattern, typically a single word or short phrase.
| |
| − | |-
| |
| − | | style="background: #727272; color: #ffffff | '''''Abstract'''''
| |
| − | | style="background: #e5e5e5; color: #000000 | 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.
| |
| − | |-
| |
| − | | style="background: #727272; color: #ffffff | '''''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.
| |
| − | |-
| |
| − | | style="background: #727272; color: #ffffff | '''''Applicability'''''
| |
| − | | style="background: #e5e5e5; color: #000000 | A description of when the pattern applies and when it does not.
| |
| − | |-
| |
| − | | style="background: #727272; color: #ffffff | '''''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.
| |
| − | |-
| |
| − | | style="background: #727272; color: #ffffff | '''''Solution'''''
| |
| − | | style="background: #e5e5e5; color: #000000 | 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.
| |
| − | |-
| |
| − | | style="background: #727272; color: #ffffff | '''''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.
| |
| − | |-
| |
| − | | style="background: #727272; color: #ffffff | '''''Related Patterns'''''
| |
| − | | style="background: #e5e5e5; color: #000000 | 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.
| |
| − | |-
| |
| − | | style="background: #727272; color: #ffffff | '''''Mitigated Threats'''''
| |
| − | |Threats mitigated by the pattern and use cases.
| |
| − | |-
| |
| − | | style="background: #727272; color: #ffffff | '''''References'''''
| |
| − | | style="background: #e5e5e5; color: #000000 | Relevant references to support the pattern.
| |
| − | |}
| |
| − | | |
| − | [http://www.opensecurityarchitecture.org/cms/index.php 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 [[Media:GC ESA Framework.pdf|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|thumb|center|800px|An example EUD security Pattern (Authenticate Device to Network)from the ESADD Annex on End User Devices]]
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == ESA Pattern Diagram Repository ==
| |
| − | | |
| − | Each one of the [[Enterprise Security Focus Areas|ESADD Annexes]] provides a series of related pattern diagrams. For the ESA Pattern Diagrams, please see the [[ESA Pattern Diagrams|ESA Pattern Diagram Repository]].
| |
| − | | |
| − | <br>
| |
| − | | |
| − | == References ==
| |
| − | * [[Media:GC ESA Framework.pdf|GC ESA Framework]]
| |
| − | * [[ESA Pattern Diagrams|GC ESA Pattern Diagram Repository]]
| |
| − | * [[Enterprise Security Focus Areas|GC ESADD Annexes]]
| |
| − | * [http://www.opensecurityarchitecture.org/cms/index.php Open Security Architecture (OSA)]
| |
| − | * [http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/other_life_cycle_building_blocks_articles/spanning_operational_space.html MITRE]
| |
| − | [[Category:Enterprise Security Architecture]]
| |
| − | [[Category:Government of Canada Enterprise Security Architecture (ESA) Program]]
| |
