While "digital forensics" and "incident response" often appear together (as in the acronym "DFIR"), they represent two distinct disciplines.

What's in a Name?

The American Heritage Dictionary defines forensics as "The use of science and technology to investigate and establish facts in criminal or civil courts of law."

Contrast this with IBM's definition of incident response: "Incident response [...] refers to an organization's processes and technologies for detecting and responding to cyberthreats, security breaches or cyberattacks." Note the absence of any reference to legal proceedings—it simply describes the process by which an organization detects, halts, and recovers from an incident.

Legal Considerations

Although most incidents never end up in court, all should be treated as if they might.

Taking the proper steps before, during, and after response ensures that any data collected can be admissible as evidence.

It's important to know the rules of evidence for relevant jurisdictions. Global corporations should consider each jurisdiction they have locations in when developing standard operating procedures (SOPs). Always include legal counsel when developing your organization's SOPs.

Data Preservation

A common rule for digital evidence is the retention of data in its "original state." This is accomplished by using validated hardware and software to create an exact bit-for-bit copy of a piece of digital media. Yet during incident response, it is rare that full forensic images are created—typically, only a small subset of data is collected from victim devices for analysis. Before any action is taken, consult legal advisors to decide whether to collect full forensic images.

A good practice is to create a folder for the original data, generate and document a hash of its contents, and then create a working copy in a separate folder. Only perform analysis on the working copies of your data to preserve the integrity of the original data.

Documentation

Documentation is critical when handling potential evidence. A chain of custody (CoC) records details about what the data is, where it came from, who collected it, whom it was transferred to, a brief description of what was done to it, and so forth.

The National Institute of Standards and Technology (NIST) provides a sample CoC here:

https://www.nist.gov/document/sample-chain-custody-formdocx

Each person working with the data must keep detailed notes: record dates, times, and any actions taken. Binary files often need to be parsed by special tools to make their data human-readable—include any tool names and versions. The same should be done with human-readable data, such as text-based log files. While you likely don't need to document the version of Excel used to read a log file, if you added a column to show UTC date/time stamps in local time, that is worth noting.

The gold standard for documentation is this: notes should be detailed enough that someone with a similar background can recreate your steps and produce the same results.

This is the scientific method part of digital forensics. Processes need to be repeatable and generate the same results.

Tool Validation Procedures

Before an incident occurs, verify that your hardware and software are working. Test write blockers to ensure they do not alter the evidentiary media. Validate that your forensic software functions correctly (it's not unheard of for new versions to report the wrong date/time stamps when parsing binary data).

While there is no set standard for validation processes, some guidelines exist to help you develop validation SOPs.

Validation SOPs guidelines:

NIST: https://www.dhs.gov/science-and-technology/nist-cftt-reports

SWGDE: http://cet4861.pbworks.com/w/file/fetch/120024474/4861.2014-09-05_SWGDE_Recommended_Guidelines_for_Validation_Testing_V2-0.pdf

Additional Considerations for Incident Handling

When managing incidents, also consider:

• What are the data retention policies of your Endpoint Detection and Response (EDR) tools?
• How is your cloud data preserved?
• Who has access to sensitive or personal data?

These factors often depend on your license agreement with providers. Make sure data can be maintained in a secure, long-term manner, as it can take years until an incident makes it into the courtroom. Implement processes to export incident data from systems and services while preserving integrity and meeting long-term storage requirements that protect its availability and confidentiality. Access to confidential information must always be managed carefully.

Remember: Involve your legal team, validate your tools, work from copies (never original data), document everything meticulously, and maintain chain of custody.

Many people ask: At what point do I bring in law enforcement during a cyber incident? When should I get outside help such as another consulting firm to support incident response? The honest answer is simple: before you ever need them. The best time to build reinforcements is not during a crisis. It is now.

It’s the same idea as that old proverb: “The best time to plant a tree was 20 years ago. The second best time is now.” Cybersecurity works the same way. Incident response is messy, emotional, and chaotic. You don’t want to be flipping through your contacts for a random phone number when your domain controller is encrypted and your CEO is standing behind you asking for updates. You want relationships, people who already know you and are ready to help.

Build Your Network Before You Need It

Start with your own community. Get involved with organizations such as InfraGard and HTCIA. Attend local cybersecurity meetups, conferences, and regional response groups. Shake hands. Collect business cards. Swap stories. These small moments build the trust you will rely on when your network goes sideways at 2 a.m. on a Saturday.

Identify who your law enforcement contacts are now, such as local FBI field office personnel, state cybercrime investigators, or specialized digital forensic units. Introduce yourself. Learn what they do and how they operate. Because during an incident is a terrible time to be making introductions.

When to Call Law Enforcement

Whenever you are handling an incident, reach out to law enforcement early. They might not jump into every ransomware attack or stolen laptop case, but it is still important to keep them informed. They have something you do not have: legal authority. If you need warrants, subpoenas, or data preserved from third-party providers, law enforcement has the tools to make that happen. If nothing else, contacting them shows you are acting responsibly, and that matters later.

Your next reinforcement is legal. You should already have a law firm on an incident response retainer before something goes wrong. But don’t just pick any law firm. Choose one with real experience handling cyber incidents.

Traditional attorneys often respond to breaches by locking everything down and preventing collaboration. That approach creates chaos. Experienced breach counsel understands that incident response requires teamwork, not isolation.

They know how to:

• Work with law enforcement
• Coordinate with security firms
• Maintain legal privilege where appropriate
• Guide sensitive communications
• Draft clear breach notifications
• Stay cool when everything burns

If they have been through this before, they will not fall apart when it is your turn.

Cyber Insurance Requires Work

If you are in an incident and asking whether your cyber insurance covers it, it is already too late. You either have coverage or you do not. And getting that coverage is becoming harder.

Insurance companies are nervous. Ransomware costs are rising and payouts have become massive. Even if you do get coverage, read the fine print. Most policies require due diligence—you must demonstrate that you were following reasonable security practices. If you have ignored vulnerability management, asset inventory, access control, logging, and backups, your insurer may deny your claim.

Cyber insurance is not a magic safety net. It is a contract that assumes you are taking security seriously.

Build Relationships, Not Just a Plan

If there is one theme here, it is this: In a crisis, you do not rise to the occasion. You fall back on the strength of your relationships. When an incident hits, you should not be scrambling to track down experts. You should already know who to call and they should already know you.

Start building your network today. Law enforcement contacts, legal counsel, insurance providers, and trusted incident response partners should already be in your corner. When the day comes, you will not be calling strangers. You will be calling reinforcements. Friends. Colleagues. People who already have your back.

Start now.

You've just confirmed it: that alert isn't a false positive. Your heart rate kicks up a notch—this is the real deal. Whether it's suspicious PowerShell execution, unusual network traffic, or signs of credential compromise, you've got a genuine security incident on your hands. Let's go.

What happens in the next 60 minutes can make or break your entire incident response. Miss a critical step, fail to preserve evidence, or escalate to the wrong people, and you could turn a manageable incident into a career-defining disaster. Tread carefully.

The First 15 Minutes: Immediate Actions

When you confirm a true positive, your brain wants to jump straight into investigation mode. Resist that urge. Instead, take the following actions right away to lay the foundation for everything that follows.

Preserve Evidence First

Before you click a button or run another query —

Document the current state:

• Screenshot the original alert with full context visible.
• Capture system timestamps (note any time zone differences).
• Record which detection rule or signature triggered.
• Note your analysis tools and queries used for confirmation.

Preserve volatile data:

• If dealing with endpoint alerts, consider memory capture before the system state changes.
• Document running processes, network connections, and logged-on users.
• Save original log entries before anyone accidentally overwrites any evidence while "investigating."

Establish Incident Tracking

Without delay, create your incident ticket with these critical fields:

• Incident ID: Use your organization's numbering scheme.
• Initial Classification: Malware, data breach, unauthorized access, etc.
• Affected Assets: Systems, IP addresses, user accounts.
• Discovery Time: When the alert fired vs. when you confirmed it was legitimate.
• Analyst: The person taking point on this incident.

Pro Tip: Many teams skip this step thinking they'll "create the ticket later." Don't. You need that incident number for all subsequent communications and actions

Quick Impact Assessment

Spend 5 minutes answering these questions to determine everything else, including your escalation path, response urgency, and resource allocation:

• Is this affecting critical business systems?
• Could this be active lateral movement?
• Is sensitive data potentially at risk?
• Are customers or operations impacted right now?

The Next 45 Minutes: Assessment and Documentation

Now you can dig deeper, but you need to do it systematically. Your goal is to build a complete picture while documenting everything for the team members who'll join your response.

Comprehensive Alert Analysis

Expand your investigation scope:

• Look for related alerts in the same time window (±2 hours).
• Check for indicators across multiple data sources (SIEM, EDR, network monitors).
• Identify the attack timeline: initial access → persistence → lateral movement → impact.

Document key findings:

• Initial Vector: How did this start (phishing, exploit, credential compromise)?
• Affected Systems: Complete inventory with hostnames, IPs, and roles.
• User Accounts: Any compromised or suspicious account activity.
• Network Activity: Unusual connections, data transfers, or command and control.
• Potential Impact: What could an attacker do with the current level of access?

Communication and Escalation: Who Needs Immediate Notifications?

(i.e., within the first 15 minutes)

Always notify the following:

• Direct supervisor/on-call manager.
• Other SOC analysts.
• Network operations (if needed).

Escalate to Security Leadership if:

• Multiple systems compromised.
• Critical business systems affected.
• Ongoing data exfiltration.
• Privileged account compromise.
• Indicators suggest APT.

Escalate to Executive Leadership if:

• Customer data confirmed compromised.
• Business operations significantly impacted.
• Potential regulatory violations.
• Media attention or disclosure is likely.

Involve Legal/Compliance if:

• PII/PHI compromised.
• Breach notification requirements.
• Law enforcement involvement.
• Regulatory reporting deadlines.

Execution and Ongoing Management

Investigation Coordination

Daily standup structure:

• Previous 24 hours: What was discovered or completed?
• Next 24 hours: What are the priority investigation activities?
• Blockers: What's preventing progress or needs leadership support?
• Key findings: Any new IOCs, affected systems, or impact discoveries?

Evidence management:

• Maintain chain of custody for all forensic evidence.
• Use standardized file naming conventions.
• Store evidence in secure, access-controlled locations.
• Document who accessed what evidence and when.

Recovery Planning in Parallel with Investigation

• System restoration: Clean rebuilds vs. remediation approaches.
• Access restoration: New credentials, certificates, and authentication tokens.
• Business process restoration: How to resume normal operations safely.
• Monitoring enhancement: Additional detection capabilities to prevent recurrence.

Leadership and Stakeholder Updates

• Security leadership: Daily — focusing on scope, impact, and containment effectiveness.
• Executive leadership: When status changes significantly or every 24–48 hours.
• Business units: When their operations or data might be affected.
• Legal/compliance: Regularly — on potential regulatory implications.

Leadership and Execution Resource Requirements

• Dedicated incident response platform: Don't rely on email chains and spreadsheets.
• Forensic tool access: Memory capture, disk imaging, and network analysis capabilities.
• Communication tools: Secure channels for sensitive incident coordination.
• Documentation templates: Standardized formats for consistent incident reporting.

Team Training Priorities

• Incident classification: How to quickly assess severity and impact.
• Evidence preservation: Proper forensic procedures that hold up under scrutiny.
• Communication protocols: Who to notify, when, and how.
• Tool proficiency: Regular hands-on training with investigation tools like DeepBlueCLI.

Final Thoughts

The moment you confirm a true positive, you're not just investigating an incident—you're protecting your organization's future. The actions you take in that critical first hour determine whether this becomes a contained incident or a business-threatening breach.

Key Principles to Remember

• Preserve first, investigate second: You can't go back and collect evidence you've overwritten.
• Communicate early and often: Stakeholders need information to make good decisions.
• Document everything: Your future self (and legal team) will thank you.
• Contain quickly, but thoughtfully: Rushed containment can destroy evidence or cause business disruption.
• Measure success by these four things: Time to containment, communication effectiveness, evidence quality, and learning integration.

Your organization is counting on you to get this right. With a reliable process, tools like DeepBlueCLI, and a systematic approach, you'll be ready when that next alert turns out to be the real deal.

Next Steps

1. Review your current true positive workflow: Do analysts know exactly what to do in the first 15 minutes?
2. Test your escalation procedures: When was the last time you exercised your communication plans?
3. Audit your investigation tools: Do you have the capability to investigate modern threats effectively?
4. Train on DeepBlueCLI: If you're not using this for Windows event analysis, start now.

Essential Reading for Report Writing

• NIST SP 800-61: Computer Security Incident Handling Guide (Section 3.4 on documentation).
• CERT Resilience Engineering Framework: Structured approaches to incident documentation.
• Your organization's legal requirements: Know what documentation standards apply to your industry.

Tool Resources

PowerShell for Security Professionals: Advanced techniques for incident response.

Windows Event Log Analysis: Understanding what logs contain the evidence you need.

Security Operations Centers (SOCs) serve as a critical line of defense against today's constantly evolving cybersecurity threats. At the heart of these teams are SOC analysts, who monitor, detect, and respond around the clock to potential attacks.

The post The Life of a SOC Analyst: Responsibilities, Challenges, and Strategies for Success appeared first on Black Hills Information Security, Inc..

Spend time performing forensic analysis on the Windows Operating System and you'll see a host of artifacts that can be used to identify adversary activity. From changes to the registry to the System Resource Utilization Monitor, Windows artifacts run deep. The challenge is locating, extracting, and parsing these artifacts in an efficient manner.

The post KAPE 101: A Kroll Artifact Parser and Extractor Cheatsheet appeared first on Black Hills Information Security, Inc..

We're all petrified about missing a critical event or misclassifying an alert, but when we're talking about incident response (IR), there are often hundreds if not thousands of alerts to parse through. It's easy to get caught up with one alert because it feels "too hot" or maybe not spend enough time looking into something that initially seems "too cold."

The post Finding the “Goldilocks” Zone: A Practical Approach to Alert Triage appeared first on Black Hills Information Security, Inc..

What happens when you ditch the tiered ticket queues and replace them with collaboration, agility, and real-time response? In this interview, Hayden Covington takes us behind the scenes of the BHIS Security Operations Center, which is where analysts don’t escalate tickets, they solve them.

The post Inside the BHIS SOC: A Conversation with Hayden Covington  appeared first on Black Hills Information Security, Inc..

But what if we need to wrangle Windows Event Logs for more than one system? In part 2, we’ll wrangle EVTX logs at scale by incorporating Hayabusa and SOF-ELK into my rapid endpoint investigation workflow (“REIW”)! 

The post Wrangling Windows Event Logs with Hayabusa & SOF-ELK (Part 2) appeared first on Black Hills Information Security, Inc..

In part 1 of this post, we’ll discuss how Hayabusa and “Security Operations and Forensics ELK” (SOF-ELK) can help us wrangle EVTX files (Windows Event Log files) for maximum effect during a Windows endpoint investigation!

The post Wrangling Windows Event Logs with Hayabusa & SOF-ELK (Part 1) appeared first on Black Hills Information Security, Inc..

Remember the good ‘ol days of Zip drives, Winamp, the advent of “Office 365,” and copy machines that didn’t understand email authentication? Okay, maybe they weren’t so good! For a […]

The post Stop Spoofing Yourself! Disabling M365 Direct Send appeared first on Black Hills Information Security, Inc..

In this video, John Strand discusses the complexities and challenges of penetration testing, emphasizing that it goes beyond just finding and exploiting vulnerabilities.

The post 5 Things We Are Going to Continue to Ignore in 2025 appeared first on Black Hills Information Security, Inc..

Changes to the msds-KeyCredentialLink attribute are not audited/logged with standard audit configurations. This required serious investigations and a partner firm in infosec provided us the answer: TrustedSec.  So, credit where […]

The post Enable Auditing of Changes to msDS-KeyCredentialLink  appeared first on Black Hills Information Security, Inc..

Recently in the SOC, we were notified by a partner that they had a potential business email compromise, or BEC. We commonly catch these by identifying suspicious email forwarding rules, […]

The post Monitoring High Risk Azure Logins  appeared first on Black Hills Information Security, Inc..

While social engineering attacks such as phishing are a great way to gain a foothold in a target environment, direct attacks against externally exploitable services are continuing to make headlines. […]

The post In Through the Front Door – Protecting Your Perimeter   appeared first on Black Hills Information Security, Inc..

Be sure to read PART 1! Metadata and a New-Fashioned Bank Robbery Let’s face it, some cases are just more interesting than others and, when you do incident response for […]

The post OSINT for Incident Response (Part 2) appeared first on Black Hills Information Security, Inc..

Being a digital forensics and incident response consultant is largely about unanswered questions. When we engage with a client, they know something bad happened or is happening, but they are […]

The post OSINT for Incident Response (Part 1) appeared first on Black Hills Information Security, Inc..

Patterson Cake // PART 1 PART 2 In part one of “Wrangling the M365 UAL,” we talked about acquiring, parsing, and querying UAL data using PowerShell and SOF-ELK. In part […]

The post Wrangling the M365 UAL with SOF-ELK and CSV Data (Part 3 of 3) appeared first on Black Hills Information Security, Inc..

Patterson Cake // When it comes to M365 audit and investigation, the “Unified Audit Log” (UAL) is your friend. It can be surly, obstinate, and wholly inadequate, but your friend […]

The post Wrangling the M365 UAL with PowerShell and SOF-ELK (Part 1 of 3) appeared first on Black Hills Information Security, Inc..

Troy Wojewoda // In honor of Shark Week1, I decided to write this blog to demonstrate various techniques I’ve found useful when analyzing network traffic with Wireshark, as well as […]

The post Welcome to Shark Week: A Guide for Getting Started with Wireshark and TShark appeared first on Black Hills Information Security, Inc..

Tom Smith // At Black Hills Information Security (BHIS), we deal with all manner of clients, public and private. Until a month or two ago, though, we’d never dealt with […]

The post Why Do Car Dealers Need Cybersecurity Services?  appeared first on Black Hills Information Security, Inc..