Leedy and Ormrod’s Practical Research: Planning and Design serves as an ideal framework for the practice of blue team detection development, thus helping meet the guidelines prescribed in NIST’s Cybersecurity Framework, particularly as part of detection and response.
I’m now a doctoral student at Capella’s School of Business and Technology in the Information Assurance and Cybersecurity Specialization.
Suffice it to say, my perspective, and the resources at my disposal regarding the practice of research, have expanded significantly of late.
Figure 1: Leedy & Ormrod’s Research Cycle
The Research Cycle, from Leedy and Ormrod’s Practical Research: Planning and Design, is an important reference.
-
Step 1: The researcher begins with a problem-an unanswered question.
-
Step 2: The researcher clearly and specifically articulates the goal of the research endeavor.
-
Step 3: The researcher often divides the principal problem into more manageable subproblems.
-
Step 4: The researcher identifies hypotheses and assumptions that underlie the research effort.
-
Step 5: The researcher develops a specific plan for addressing the problem and its subproblems.
-
Step 6: The researcher collects, organizes, and analyzes data related to the problem and its subproblems.
-
Step 7: The researcher interprets the meaning of the data as they relate to the problem and its subproblems (Leedy & Ormrod, 2014, p. 2-6).
Blue teams are often challenged with issues of scale, specifically high signal-to-noise ratio of actionable alerts arising from detection, as well as sheer data volumes.
A common blue team mantra might be this simple:
How do we answer questions in the data?
This aligns nicely with Step 1 of the Research Cycle.
The blue team’s goal as network defenders is to identify and eliminate adversaries.
Many related questions arise, but the answers can be difficult to develop.
As part of activity often referred to as ‘hunting’, hunters (researchers) focus on very specific goals (Step 2) for a two-week period.
Consider following the sprint model as part of agile project management, where sprints are two weeks (Step 3).
The sprint will often be defined by concepts and assumptions driven by customer (to whom the detection applies) demand and need for specific detection or behavioral analysis (Step 4).
The related detections and behaviors can be divided into a family of rules, signatures, or models that are then vetted to determine if the effectively answer ‘questions in the data’ (Step 5).
All the resulting detections are parsed, analyzed and validated for accuracy with the customer to ensure readiness for production implementation (Step 6).
As new detections are implemented and finalized, the final result is one where the security operations center can utilize the alert as a singleton (atomic, less than ideal) or as a component of a larger scored, contextualized, correlated analysis (ideal) before escalation to the customer (Step 7).
Note that some steps could be compressed, teams don’t have to arbitrarily extend the process where not necessary. As an example, Steps 3 through 5 could arguably collapse in to one.
You can snap this approach in to your efforts to follow parts of the NIST Cybersecurity Framework (CSF) lifecycle, particularly protect, detect, and respond.
Detection development following the Research Cycle exhibits direct alignment with the CSF’s Five Functions, specifically as it pertains to detection and response.
Figure 2: The Five Functions - Detect & Respond
While this may feel somewhat over simplified and obvious, this level of program and process around detection development has absolute benefit to you as part of successful blue team efforts.