Sometimes we treat cybersecurity as an art form—relying on “gut feelings” about anomalous network traffic or the intuition of a seasoned penetration tester. While intuition is valuable, it isn’t scalable, and it isn’t measurable. To build mature security programs, we should incorporate the scientific method to help remove bias and replace guesswork with empirical evidence.
Defining the Scientific Method #
At its core, the scientific method is a rigorous, systematic approach to problem-solving designed to minimize cognitive bias and replace guesswork with empirical evidence. While it originated in the physical sciences to investigate natural phenomena, its principles are universal and perfectly suited for investigating complex IT systems or correcting previous security assumptions. The framework relies on a repeatable, eight-step loop:
- Define a Question: Identifying a specific security concern or a potential gap in defenses.
- Gather information and resources (Observation): Identifying a specific anomaly, understanding an environment, or establishing a baseline control group.
- Formulate a Hypothesis: Formulating a specific, testable, and falsifiable prediction.
- Experimentation: Designing and executing a controlled, isolated test to prove or disprove the hypothesis.
- Analysis: Reviewing the resulting empirical data to draw a definitive, evidence-based conclusion.
- Interpret Data and Draw Conclusions: Documenting your findings to serve as a starting point for your next hypothesis.
- Share your Results: Communicating findings to stakeholders, leadership, or the broader security community to improve collective defense.
- Retest: Validating that remediation efforts were successful and ensuring the environment remains resilient over time.
The Hypothesis-Driven Threat Hunt #
In science, you do not run experiements randomly. This can cost time and money and likely leads to wasted effort. While gut feels and anecdotal evidence may certainly play a part at times in the direction you may take, you start with a hypothesis and defined plan. The same must apply to how we defend our networks.
In the SANS whitepaper, Applying the Scientific Method to Threat Hunting by Jeremy Kerwin, the author drives that point home. Without a repeatable framework, threat hunting is an exhausting, time-consuming challenge. Staring at SIEM logs waiting for an alert is reactive. A mature threat hunt is proactive, and it begins with a falsifiable question.
Instead of saying, “Let’s look for bad stuff on the network,” a scientific approach requires a specific hypothesis: “Because of recent geopolitical events, I hypothesize that an adversary is attempting to exfiltrate data via DNS tunneling on our legacy servers.” This gives your team a focused, measurable objective.
Mapping the Eight Stages to Security Science #
If we map the complete scientific method to our daily operations, the alignment provides a comprehensive playbook:
1. Define a Question (The Objective) Everything starts with a specific security concern. Instead of vague goals, ask direct questions: “Is our new segmentation policy actually blocking lateral movement from the guest Wi-Fi?”
2. Gather Information (Reconnaissance & Baselining) You establish your baseline measurements and understand your environment. You cannot identify an anomaly if you don’t know what “normal” looks like. Whether you are a red teamer mapping out an attack surface or a blue teamer tuning a WAF, observation is the foundational step.
3. Formulate a Hypothesis (Threat Modeling & Attack Scenarios) Based on your observations, you formulate a theory. For a red team, the hypothesis might be: “The current endpoint detection and response (EDR) configuration will not detect process hollowing in this specific segment.”
4. Experimentation (Execution & Validation) This is where the test happens. The red team executes the exploit. The threat hunter queries the data lake for the specific indicators of compromise (IoCs). The key here is isolation and controlled variables so you know exactly what triggered (or failed to trigger) an alert.
5. Analysis (Reviewing the Telemetry) Once the experiment is run, you analyze the empirical data. Did the logs capture the payload? Did the SIEM aggregate the data correctly? This is the raw technical review of the experiment’s outcome.
6. Interpret Data and Draw Conclusions (Metrics & Remediation) Did the experiment prove or disprove the hypothesis? In Josiah Dykstra’s book, Essential Cybersecurity Science, he emphasizes that the scientific method is the only reliable way to generate meaningful security metrics. If the red team bypassed the EDR, the conclusion is a verifiable data point about a control failure that can be used to allocate resources.
7. Share Your Results (Reporting & Threat Intel) A successful hunt or penetration test is useless in a vacuum. Sharing results means distributing a detailed report to leadership, updating internal knowledge bases, or even contributing sanitized IoCs back to the broader cybersecurity community.
8. Retest (Continuous Validation) Security is not static. Once a vulnerability is remediated or a new detection rule is implemented based on your conclusions, you must retest the environment to validate that the fix actually works. This loops you right back to the beginning.
Bringing Rigor to Security Operations #
A core challenge in cybersecurity is proving your security posture to the business. You cannot report “gut feelings” to leadership or a board of directors—you report data.
By training our teams to adopt the scientific method, we move away from alert fatigue and reactive firefighting. We create structured, repeatable, and evidence-based strategies. Whether you are dissecting malware in a sandbox, hunting for persistent threats, or simulating an adversary, a little scientific rigor goes a long way.
