An essential component of an effective security program is defining security use cases and building solutions around them. A security use case is an attack scenario that a security control, policy, or guideline is intended to prevent or mitigate. Examples include phishing, credential dumping, and browser hijacking.
Many organizations use MITRE ATT&CK techniques for selecting use cases to solve. The challenge with creating solutions for security use cases is that each organization has a unique technology stack and requirements. Having a strategy for defining security use cases is essential for ensuring that requirements are met and the right solution is implemented.
When addressing security use cases, it’s essential to follow these seven steps.
Step 1: Select a Use Case
Gathering requirements should always be the first step for identifying which use cases your security solutions will solve. This involves meeting with stakeholders to identify which business processes and assets are most critical for the organization’s success.
Requirements evolve as technology changes and teams grow. This makes it important to meet with and gather requirements from stakeholders often. The way to prove requirements are being met is by selecting use cases that your team can measure. For example, if your stakeholders identify the requirement to “restrict non-developer users from executing system commands as root or administrator,” your team may want to consider defining a use case around privilege escalation. Risk, probability, and impact should be reviewed when prioritizing security use cases and determining how to measure success.
Step 2: Set a Goal
Setting a goal and documenting it is the next step. Without a specific goal, it won’t be clear if the use case was solved and if requirements are being met. If setting a goal is difficult, you can try creating S.M.A.R.T. goals. The acronym stands for specific, measurable, achievable, relevant, and time-bound.
Setting goals with these characteristics will enable your team to make informed decisions when creating, customizing, and implementing solutions for security use cases. If a team has identified privilege escalation as a security use case but has no prevention capabilities, then it may be helpful to first set a goal based on alerting.
It’s also common for goals to change as your security program matures.
Step 3: Define Precondition
A precondition is the state of a system or process before the attack scenario. It allows IT and security teams to have a better opportunity to understand how an attack is negatively affecting a resource.
For example, if it’s understood that a critical production database should only have four user accounts, it’ll be easier for teams to create solutions to identify anomalies and misconfigurations that may pose a security risk.
Step 4: Identify Trigger Events
Triggers are how a security control identifies the attack scenario is occurring or has occurred. In an ideal situation, a trigger will be an automated action that prevents a threat from occurring or notifies a team with security context around an event.
Identifying trigger events helps teams:
- Prioritize events that require immediate attention
- Simulate an attack scenario and measure the efficacy of security controls and response processes
Step 5: Review Existing and Missing Capabilities
Understanding what’s required to create a safeguard for your assets will help your team make a decision on which solutions to build and/or purchase. In some situations, technology is not able to prevent a threat or type of attack, which makes teams accept some risks.
Having insight into the capabilities of your security stack creates an opportunity for automating repetitive security tasks and ensures tools have the capabilities of offloading to technology. Having a close relationship with architects, engineers, and vendors will provide your team with confidence that the security use case is understood and information on events that require the most attention.
Step 6: Define Postcondition
After understanding the attack scenario, the goal, and the capabilities that can be leveraged to address the attack, your team can define a postcondition. The postcondition is the state of the system or process after the attack scenario is executed. If in the previous steps your team determined that a security solution can prevent an attack, then the postcondition will likely be similar to the precondition.
In other scenarios, incident response and team coordination may be required to restore the system or process to the desired state. Having a postcondition documented makes it easier for teams to determine when an investigation is required.
Step 7: Create Workflows
What happens if the attack associated with the use case is observed? What should happen if the attack wasn’t prevented? These questions are answered when creating a workflow for responding to security events and attacks. The workflow can be a manual or automated pathway to the postcondition. Organizations often use flowcharts or lists to document the workflow that should be followed after an attack is observed.
Having workflows associated with security use cases provides team members a guide for preventing, responding to, and remediating attacks.
Defining specific use cases is the path for security teams to meet requirements and build resilient solutions. Creating a repeatable strategy to assess and solve security use cases can empower teams to shift from reactive to proactive.
