Use Case Template
Each section of the use case template is below in a heading style with the instructions on populating that section between square brackets. General advice on implementing the use case is given in angle brackets. After this, build a document with these headings, populate it with information relevant to your organization, your system, your customer, and the use case you are defining.
name:
[Name of Use Case]
purpose:
[The purpose of this Use Case design document is to fully describe a security use case, document the requirements to implement the Use Case within the SIEM, and how the Security Operations Center will respond based on the Use Case definition. State the purpose of this particular use case.]
problem statement:
[Describe the business objective, process, and problem, that this use case will address here. The problems statement should clearly define and identify the issue, and provide direction to achieve a solution. Ideally, it expresses a solvable problem.]
<First, write out the issue without regard to getting it right. Make sure that the initial draft identifies the issue at hand and needs to be solved by the SOC Developer. Refine the problem statement and make sure that it sets sufficient direction to solve the problem, can be measure, will keep the implementer on track, and scan be validated at the other end. If you have difficulty, make sure you answer the “5 Ws”.>
requirements statement:
[Describe the action(s) that the SIEM system or SOC team is to take – alert, email, record, port to list, etc. These actions must be achievable and actionable, should not be in terms of the specific system, can be implemented in software, and have sufficient definition for the automation that a SIEM solution provides.]
<A proper and well-designed requirements statement will have one or more characteristics:
Correct or accurate, in user terms, and unambiguous
Can be implemented or feasible
Be necessary to support the use case. Keep requirements on point. Can be satisfied during implementation phases for the use case.
Measurable or verifiable in some way which will manifest through the source data and actions that the system will take.>
Design Specifications – discrete objectives:
[Define objectives, which must include actionable tasks that don’t imply specific resources. These resources are ordered by priority for the SOC team. An objective provides concrete support for a goal.]
<George T. Doran wrote an article for the 1981 issue of Management Review, titled “There’s a SMART way to write goals and objectives” that can be applied to SOC use cases. Ideally speaking, each discrete objective should satisfy one or more of the SMART criteria:
Specific: target a specific area for improvement
Measurable: quantify or at least suggest an indicator of progress
Assignable: specify who will do it
Realistic: state what results can be realistically achieved, given available resources
Time-related: specify when the results can be achieved>
security operations center notification:
[When building out a use case, describe the relevant and helpful information for the SOC team so that they can respond to an alert, monitor a dashboard, or review a report Include a sample of the notification as an appendix to the use case document. For Operator Console notifications, include a list of relevant and helpful fields for the SOC that the system needs to include.]
use case component name(s):
[This section identities the Use Case components as they will appear within the SIEM system, data feeds, plug in or device names, rules or directives, content components such as internal lists, dashboards, output repots, etc. Each maintained as the system is updated. This section is concretely answered in terms of the specific platform tool itself. It may be very useful to diagram how the components interact.]
use case data source description:
[List of data sources and the system types that support the use case. Indicate if the data source is currently available, or steps to make it available. Also, list the components and/or systems in the enterprise that can support the use case ordered by the Lockheed Martin Cyber Kill Chain in the section below. The data sources cited in this section will need to be monitored will need to be monitored top ensure that they are providing data.]
use case data stream analysis and field set:
[For each involved component of the data stream, there will be a Use Case Data Stream Analysis section. Each section needs to match the Use Case Component Name and Use Case Data Source Description sections above. This section describes how the data stream will be captured from the source system and delivered to the SIEM platform. Some SIMEM platforms permits analyzing input data and sending it to the logging function while not persisting that data in the analysis store. If so, indicate that condition in this section. Lastly, some data receivers or syslog servers can trim data it is not delivered to the SIME. If that function will be implemented, document what data is trimmed and the reasons why trimming the data is valid and does not represent a degradation of the security monitoring capability of the organization.]
<Discuss what are they characteristics of an event. Include screen shot and/or plain text as necessary or if they would be helpful. Always indicate how the data was produced – when, where, from whom.>
cyber kill chain analysis and support:
[Indicate how this Use Case supports the Lockheed Martin Cyber Kill Chain.]
CKC Phase Use Case Support
Reconnaissance
Weaponization
Delivery
Exploitation
Installation
Command and Control
Actions on Objectives
assumptions and limitations:
[In order to implement any use case there are often assumptions made about the data sources, delivery, and IT operations. This section is where you will document them. For example, if the use case relates to Active Directory monitoring, then implementing the use case assumes that new servers will be configured to report and that if a Domain Controller(s) fail to report for some period of time that condition can be detected and resolved.]
alternative solutions and discussion:
[If there are any alternatives to implementing the use case as described, list them here in this section. Many alternatives have strong and weak points. If those points are relevant to the final solution, make note of them. For example, a static report may seem to be sufficient on first review, but may prove out not to satisfy the desired level of monitoring since a real time alarm is needed.]
<This section should demonstrate that the analysis and design team actually thought about alternatives and as a result designed an optimal use case.>
deliverable profile:
[Many organizations have a standard block that describes their software and system specifications, which is the intention of this section. Use Cases should conform to organization standards, so make sure to modify this section as appropriate. The meanings of the profile statement are listed under “Description”. One item that should not be omitted is company policy/procedure that the use case supports.]
Profile Description
File Name Deliverable_Project_Title_DATE.doc
Process Owner Lists the single person within the organization who are responsible for the most relevant process that the use case addresses.
Original Author State who wrote the original use case
Policy/Procedure: Title or reference to company policy/procedure that the use case directly supports.
Industry Reference This line lists applicable standard references. For example, a reference to an item in NIST SO800-53, a critical control, or the ASD.
Effective Date: Date when the use case is considered in production. Further modification would be under some form of change control.
Document Last Modified: Records when the actual document was last edited (consider using a word auto update field).
Approval Record who and when the use case was approved.
Version History
Version Revision
1.0 This section provides history of use case changes, enhancements, and revisions.
chaseyates.com 