Its multi-agent AI platform generates the telemetry an attack would produce to fix gaps in enterprise defenses.
The post Brava Security Emerges From Stealth With $15 Million in Funding appeared first on SecurityWeek.
One of the biggest questions I get whenever I’m teaching anything focused on core skills—whether it’s network security, SOC analysis, or ecurity essentials—is whether any of these classes are even necessary anymore because of AI.
The assumption seems to be that AI is going to eliminate the need for foundational knowledge. People believe that AI will simply handle the technical details for us, allowing security professionals to skip over the basics and move directly to the advanced work.
Unfortunately, that assumption creates a sense of hopelessness.
Junior analysts who are trying to enter the field start wondering whether it’s worth studying at all. Companies looking to hire are hesitant because they’re not sure what the workforce will look like in a few years. Everyone is waiting to see where things land.
When it comes to core information security skills, I believe we need to recognize something important:
The fundamentals matter more today than they ever have.
The reason is context.
The more context and understanding you have about a technical problem, the more effective AI becomes. Artificial intelligence is not a replacement for expertise. It amplifies expertise.
If you put AI in the hands of someone who doesn’t understand networking, operating systems, or security fundamentals, the impact is often limited. They may get answers faster, but they have no way to evaluate whether those answers are correct.
Put the same tools in the hands of someone who understands TCP/IP, operating systems, network architecture, authentication, and how systems actually work, and AI becomes an incredible force multiplier.
As we move into the future, it will become even more important for security professionals to understand the basics. Those foundational skills provide the context necessary to ask better questions, recognize bad answers, and effectively leverage increasingly powerful AI tools.
I also think we can look at chess as a preview of where our industry is heading.
Chess is more popular today than it has ever been. There are more strong chess players than at any other point in history. At the same time, AI engines can defeat even the world’s best players without breaking a sweat.
So why hasn’t AI killed chess?
Because the chess community embraced it.
Players use AI engines like Stockfish to analyze games, identify mistakes, study openings, improve endgame strategy, and accelerate learning. Tournament organizers use AI to help detect cheating. Coaches use AI to provide insights that would have been impossible to deliver at scale just a few decades ago.
The result isn’t fewer chess players. In fact, it is the opposite. The other result is better chess players.
I believe cybersecurity is heading down a very similar path.
AI will help us learn faster. It will help us identify patterns more quickly. It will help us automate repetitive work and explore technical problems at a scale that wasn’t previously possible.
But none of that eliminates the need for foundational knowledge.
In fact, it increases its importance.
The people who understand the fundamentals will be the ones who get the most value from AI. They’ll be able to guide it, challenge it, verify it, and use it to solve increasingly complex problems.
The future of cybersecurity isn’t humans versus AI.
It’s humans with strong fundamentals using AI to become dramatically more effective than ever before.
Check out John’s Antisyphon courses (including Pay-What-You-Can options!) here:
The cybersecurity battlefield evolves daily, with SOC analysts serving as front-line defenders. After years of training SOC teams, I’ve identified 11 core skills that separate effective defenders from the rest.
Here’s the problem: we’re training analysts to look for needles in haystacks when they don’t even know what hay looks like. Too many enter SOC positions without understanding the systems they’re trying to protect.
You can’t defend what you don’t understand. Period. Master both Windows and Linux. Not just surface stuff, but really get how they work under the hood. Learn through the incident response lens:”If this system were hacked, how would I find the bad guys?”
Understand TCP/IP and how traffic actually flows (the OSI model matters less than knowing what a SYN flood, DNS tunnel, or C2 beacon looks like on the wire). Know the difference between TCP and UDP, and establish baselines for what normal traffic looks like in your environment.
Memory forensics shows you malware that might be invisible on disk. Tools like Volatility let you examine processes, connections, and DLLs from a memory dump. This works even when attackers delete their tools or use fileless malware. It’s like catching someone with their hand in the cookie jar.
Logs are your investigative breadcrumbs. Know which ones to collect and how to make sense of them. Remember, no single log tells the whole story. You need to connect multiple data points, like a detective piecing together clues at a crime scene.
Master your EDR solutions. Understand how they work, what they can do, and where they fall short. No EDR catches everything. You need to tune these tools, like adjusting the sights on a rifle for better accuracy.
Don’t just sit back waiting for alerts. Get out there and hunt! Look for threats that slipped past your automated systems. Combine smart hypotheses with data analysis to find attackers living off the land, using legitimate tools for evil purposes.
Every SOC analyst should know basic static and dynamic analysis. Look at the file without running it, then observe its behavior in a safe sandbox. Learn to spot common techniques like obfuscation and persistence. Know thy enemy, right?
Understand different vulnerability types and how they’re exploited. Don’t just focus on CVSS scores. Consider actual exploitability in your environment and the potential impact. A “critical” vulnerability that can’t actually be exploited in your environment isn’t critical for you.
When stuff hits the fan, know what to do. Identify what happened, contain it, kick out the attackers, and recover your systems. Document everything. Not just for compliance, but so your team can learn and improve.
Automate the boring stuff with PowerShell, Python, or Bash. Create tools that do the repetitive work for you. This frees you up to focus on the complex problems that need human brainpower.
Technical skills alone won’t cut it. You need to explain complex technical stuff to different audiences. The most brilliant analysis in the world is useless if you can’t make the bosses understand why they should care.
Mastering these skills won’t happen overnight, but they’re the foundation of being an effective SOC analyst. What makes great analysts stand out isn’t just knowing individual skills but connecting dots across domains: seeing how network traffic ties to endpoint behavior, when log weirdness might point to memory-resident malware, and how vulnerabilities create openings for attackers
By building these core skills, you’ll be ready to protect your organization against even the nastiest threats out there..
Here’s a counterintuitive truth: the ultimate goal of threat hunting isn’t to find more security incidents—it’s to drive continuous improvement across your entire security program. We’re not hunting merely to find present bad; we’re hunting to decrease the probability of future bad.
Think of it like debugging. You don’t debug just to find bugs—you debug to build better software. Each bug you find teaches you something about your system, improves your testing, and makes future bugs less likely. Threat hunting works the same way.
Every threat hunting framework can be thought of as a cycle that improves with every revolution.
The biggest challenge in threat hunting? Answering this question: “Where do we even start?” You can’t just randomly poke around in logs hoping to find something interesting. You need a method to focus your efforts.
The good news is that there are several effective approaches, and you don’t have to pick just one. In fact, most mature programs blend approaches over time.
Hypothesis-driven hunting starts with an educated guess, perhaps informed by the latest threat intelligence. Maybe something like, “I bet adversaries are using scheduled tasks for persistence on our web servers.”
Baseline hunting flips the question entirely: instead of rooting around for specific threats, you map what “normal” looks like in your environment, then investigate anything that doesn’t fit the pattern.
Statistical analysis tools like RITA let you approach those patterns from yet another angle. They surface statistically weird behaviors and connections, giving you a prioritized list of anomalies to consider and maybe investigate.
Machine learning models can highlight specific events that deviate from learned baselines, essentially saying “start here” with confidence scores attached.
The real detective work happens here. Investigation is iterative and rarely linear. You start broad, progressively narrow your focus by filtering out known-good activity, and follow interesting patterns wherever they lead. One scheduled task leads to a user account, which leads to authentication logs, which leads to source IPs, which leads to ... you get it.
The “art” is knowing which threads to pull and which to drop. Something can be technically anomalous but contextually benign, like a DBA running weird queries at 2 AM because production is on fire.
Eventually you reach a conclusion. Maybe you found a threat. Awesome! Now hand it to incident response.
But maybe, or most likely in fact, you found nothing…
Here’s the critical mindset shift: finding nothing isn’t failure. It’s validation—discovery of a different kind, even. A thorough hunt might confirm that your defenses are working and that an attack isn’t happening (win!). Or it might reveal that a detection you thought existed doesn’t, or that it’s misconfigured and wouldn’t fire even if the attack happened (also a win because now you know what to fix).
Approached with this mindset, any outcome is a win, and every hunt ultimately makes you more secure.
This is where threat hunting transforms from investigation into force multiplication. Everything you’ve learned feeds back into your security program:
This phase is what makes hunting a continuous improvement engine. Each excursion expands detection coverage, deepens environmental knowledge, sharpens hunting skills, and strengthens overall security posture.
The real power of this hunting “loop” is its cumulative nature. Your first few hunts might feel slow and uncertain. But knowledge accumulates. Patterns become obvious. Investigation approaches become routine. Organizations committed to sustained hunting programs often hit critical mass around 12–18 months, where value accelerates dramatically.
Remember: You’re not just looking for today’s threats. You’re building tomorrow’s defenses. Every rotation improves your skills, the program, and the rotations themselves. That’s the threat hunting flywheel.
Security, Orchestration, Automation, and Response (SOAR) is still a foreign concept to some but has rapidly evolved into a necessity for high-performing SOCs. SOCs without a SOAR — or without meaningful automation — will struggle with manual repetition, duplicate alerts, and slow response times as they scale. With SOAR, many of these problems can be addressed or reduced.
While SOAR isn’t a “silver bullet” by any means, the operational impacts are real because of the power it gives a SOC to optimize workflows, centralize security alert management, and minimize threat response time (or mean time to resolution). According to the Ponemon Institute, organizations can receive on average upwards of 17,000 malware alerts per week. The BHIS Active SOC reduced overall ticket volume by roughly 60% through intelligent alert grouping — consolidating related signals into single cases instead of working them as individual alerts.
To understand how this is possible, we need to discuss what SOAR is and how it works. A SOAR is a platform specialized primarily around security use cases. This platform serves as a centralized hub for data enrichment, integrations, and response actions, all of which take place in the context of “playbooks.” Think of a playbook as a flowchart, where each step performs a specific operation.
At the top of the flowchart, data (let’s say an EDR alert) initially enters the playbook. As it continues, decision points control the directional flow, API requests gather additional data or perform actions, and finally, there is some sort of output. So, a SOAR is really a technology—a curated set of tools and processes that work together to automate what can be wisely automated so as to serve as a happy medium between total manual management and total automation to maximize a SOC team’s ability to respond quickly and appropriately despite the problems and time constraints that the team encounters due to sheer volume.
Consider a real-world example: Suppose that a device triggers a low-confidence EDR alert. Since it’s low-confidence, the EDR doesn’t take any action and sends it to the SOAR. The SOAR makes an API call out to VirusTotal (a service for detecting malware) with the indicators of compromise (IOCs) of the alert. If the IOCs return as malicious, the SOAR reaches back to the EDR, which in turn, isolates the host.
Now let’s say that this EDR alert fired 100 times, each on a different signature, all on the same host. Let’s also say that network detections for Command and Control also started firing related to that user. With a SOAR, all of those disparate signals could be condensed into one singular Case, rather than a number of individual alerts. Using logic within your SOAR playbooks, you could group all these events together based on numerous field values, going a layer deeper than you normally could with a SIEM, which usually just allows for the suppression of duplicates.
Now that you understand the potential power of a SOAR, you might be asking, “Hayden, why isn’t everyone using a SOAR then?” There are a few good reasons for that:
It may sound like I’m trying to convince you that a SOAR isn’t worth the effort, but that couldn’t be further from the truth. On the contrary, SOAR is becoming an expectation for any high-performing SOC, rather than a nice-to-have. As volume and complexity of alerts increase, a SOAR becomes essential to respond quickly and adequately to these alerts.
As AI becomes increasingly utilized throughout the security space, it's important to consider how it should be used most effectively. We've all seen companies adding AI into every offering and function they perform, often as much as possible.
In security operations, this creates a divide between two types of companies:
Both types address a clear problem: volume. Anyone who has worked in a SOC knows that alert volume results in burnout, limits the number of customers you can support, and takes time away from more important tasks. Using AI to accelerate triage of high-volume, lower-complexity alerts is a practical and effective strategy. It frees analysts to focus on the ambiguous cases that require human judgment. With the right context and data, AI can meaningfully assist in distinguishing malicious from benign activity — but "most of the time" isn't good enough when a miss means a breach. AI augments the analyst; it doesn't replace their judgment.
That said, keeping a human in the loop is critical for the fringe cases: AI hallucination, highly complex technical investigations, and even situations where attackers attempt to fool the models with injection or evasion techniques.
Let's talk about some ways you can be the second type of company: the one that enables operators rather than replaces them.
Utilizing AI for enhancement of the triage process is something all security operation centers should be doing right now. While AI may occasionally be wrong or may hallucinate, anyone not taking advantage of it to work across the huge amount of data that SOCs process will fall behind their competitors.
I'm not suggesting that an AI model should be constantly closing alerts. Instead, consider this: Could an AI elevate alerts that would otherwise not have been investigated?
All SOCs process swathes of low-fidelity or low-severity alerts that are usually suppressed, deduplicated, or closed out through automation. What if you could use an AI model to review these alerts that would've been closed anyway and elevate those requiring human response to higher priorities? The worst-case scenario—a false negative—isn't applicable here. These alerts wouldn't have received much attention anyway. In the ideal scenario, you could intelligently review alerts your analysts wouldn't have looked at otherwise, escalating truly concerning activity for a human to look at.
Another clear use case for AI in SOCs is quality assurance. Many QA checks on investigations are random, but what if you could curate a set of prompts that tasks AI with looking for common mistakes within your investigations and notifies a human to review them?
The AI could highlight the causes for concern, providing a starting point for the human analyst. It could even offer suggestions to both the reviewer and the analyst, making note of possible improvements. The higher quality the QA prompts, the better the feedback.
Similar to the first use case mentioned, AI could validate analyst investigations and look for logical gaps or potential blind spots. Effectively, it could be used to provide top cover for analysts, giving them more space to triage quicker without chasing down every lead, knowing that the model (ideally trained on past cases!) is fact-checking and logically validating their investigation, freeing them to confidently triage without second-guessing themselves.
While AI excels at handling repetitive high-volume tasks, human expertise remains essential for complex investigations, fringe cases, and maintaining accountability. Rather than viewing AI as a cost-cutting tool to reduce headcount (or to take on many more customers with the same headcount), think of it as an investment that multiplies the effectiveness of your existing team. By strategically deploying AI to handle or fact-check routine work, you free your analysts to focus on the sophisticated threats that truly require human judgment and critical thinking.
If you take one thing from this article, I want it to be this:
Using AI to augment your operators may not show the same immediate "return" as replacing them, but, over time, it will increase your service quality tenfold.
Working in the SOC can be a grind. Whether triaging alerts, escalating to clients, or just trying to understand why users download malicious files, we feel the need to get through tickets as fast as possible. But in that rush, we can actually hinder our progress and slow ourselves down.
What can we do to make tickets, notes, and escalations aid the SOC in the past, present, and future? Using structure, “building upon,” and clear and concise direction, we can set ourselves and the SOC up for success.
In one of Jason Blanchard’s “Job Hunt Like a Hacker” BHIS livestreams, he emphasized using bullet points when listing job experience rather than a big wall of text, as “people will get lost and stop reading.” I took this advice to heart in the way I structure the internal notes of my tickets.
I use structured, cascading bullet points to document each step taken and each piece of evidence discovered during triage. This format makes it easy for any teammate to pick up where I left off — or for a lead to QA my work without asking me to explain it.
Now that we know how to structure our notes, what should we actually document? While triaging the alert, begin with steps taken. This could be “- Ran query: {the query itself or link to SIEM platform of query used}”, “- Investigated User’s recent login history”, etc. From there, gather evidence (log data, artifacts, screenshots, etc.) pertaining to the events that occurred and add them to your notes as you discover them.
Just because you add something to your notes, doesn’t mean it’s set in silicon (excuse my play on words...). If an event or evidence is not actually linked to the alert, you can remove it. It’s better to capture too much and trim later than to miss something you’ll need to reconstruct hours or days from now. This is a key part of the “Report-As-You-Go” process.
We have our structure and our evidence... now what? It’s time to edit down and proofread what we have in the internal so that it only contains necessary information. Clear away any rabbit holes or evidence not pertinent to the alert in question. Your thought process should be apparent from the information you present. A final bullet point stating your verdict will enhance this clarity, such as “- Atypical behavior of user, will escalate and confirm expected.”
With the evidence well-documented and your verdict made, you are set to either update the client or close the ticket, setting everyone up for future success.
Just like regular muscles, you need to constantly work out your reporting-as-you-go muscles. The more you exercise these muscles, the stronger they become. It’s an ever-improving process: the first couple of internals you create are not going to be great, but you will see improvement the more you work at it. Another way to work this muscle is to start a blog and write walkthroughs on different cyber rooms, CTFs, or topics you’re studying. Get started today!
How To Write Practical Lab Notes with Obsidian and Notion with Daniel Lowrie and Antisyphon Training
The Formula for Great SOC Tickets by Hayden Covington
by Dan “Haircutfish” Rearden | haircutfish.com | Guest Author Working in the SOC can be a grind. Whether triaging alerts, escalating to clients, or just trying to understand why users […]
The post Report As You Go: Maintaining Good Documentation for SOC Analysts appeared first on Black Hills Information Security, Inc..
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..
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..
ANTISOC uses a mix of techniques from traditional penetration tests like red teams, cloud, web applications, externals, internals, and, of course, social engineering. We combine this mix of techniques with a wide-open scope, with the goal of going beyond what a typical pentest can discover.
The post Bad Habits: An ANTISOC Operation appeared first on Black Hills Information Security, Inc..
There is a certain kind of conversation that doesn’t get written up in a post-mortem, doesn’t generate a ticket, and never makes it into an end-of-quarter report. It happens on the margins—at a conference, in a hallway, or, in this case, at 30,000 feet above sea level. It’s the conversation where two people who are solving the same problem from opposite ends of the table finally sit down next to each other.
The post Same Problem, Different Angles: When Red Team and Blue Team Actually Talk to Each Other appeared first on Black Hills Information Security, Inc..
In the ever-evolving world of cybersecurity, staying ahead of the curve is not just a goal—it’s a necessity. As new vulnerabilities emerge, the race to identify and mitigate them begins. But how do we, the guardians of the digital realm, rapidly pinpoint these threats as they become public? Let’s dive into the fascinating world of vulnerability identification and see how the magic happens.
The post How to Identify and Exploit New Vulnerabilities appeared first on Black Hills Information Security, Inc..
Hear a tale about the time the BHIS SOC team conducted a 14-hour overnight incident response... from the Wild West Hackin' Fest conference in Deadwood, South Dakota.
The post When the SOC Goes to Deadwood: A Night to Remember appeared first on Black Hills Information Security, Inc..
By Troy Wojewoda During a recent Breach Assessment engagement, BHIS discovered a highly stealthy and persistent intrusion technique utilized by a threat actor to maintain Command-and-Control (C2) within the client’s […]
The post The Curious Case of the Comburglar 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..
This webcast was originally published on November 8, 2024. In this video, Hayden Covington discusses the detection engineering process and how to apply the scientific method to improve the quality […]
The post The Detection Engineering Process appeared first on Black Hills Information Security, Inc..
A lot of emphasis and focus is put on the investigative part of SOC work, with the documentation and less glamorous side of things brushed under the rug. One such […]
The post Clear, Concise, and Comprehensive: The Formula for Great SOC Tickets 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..
Login