Certified: The GIAC GISF Audio Course

In this episode, we’re going to build a simple mental skill that separates random guessing from real security thinking, and that skill is learning to anticipate what an attacker is likely to do next. New learners often imagine cyberattacks as one dramatic moment, like a burglar kicking in a door, but most real attacks are a sequence of small steps that build on each other. When you can recognize the step you are currently seeing, you can predict the next few steps and respond faster and smarter. Two beginner-friendly frameworks help you do that: the Cyber Kill Chain and the Diamond Model. You do not need to memorize fancy definitions to get value from them. You just need to learn how each framework organizes a story, how it forces you to look for missing pieces, and how it turns scattered clues into a clear expectation of what comes next.

Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.

To anticipate next moves, it helps to start with a simple idea: attackers have goals, constraints, and habits, and those factors shape their behavior. A goal might be stealing money, collecting personal data, spying, or just causing disruption, but the goal is rarely achieved in one step. Constraints include time, skills, access, and the need to avoid being noticed, and those constraints often force attackers to reuse known techniques because they work reliably. Habits show up as patterns, like trying the same password spray approach across multiple services, or using the same style of phishing lures. A framework is basically a way to label those patterns so you can say, this clue suggests we are in this part of the story, so the attacker probably needs to do this next. Without a framework, beginners tend to focus on the loudest clue, like an alarming email, and miss the quieter clues that tell you where the attacker is in the sequence. With a framework, you can connect the clues and choose actions that break the attacker’s chain of progress.

The Cyber Kill Chain is a model that describes an attack as a series of stages, where each stage sets up the next one. You can think of it like a roadmap that runs from preparation to execution to staying in control. The exact names of the stages can vary depending on how it is taught, but the core idea is stable: attackers typically prepare, deliver something, gain a foothold, expand their control, achieve their objective, and try to avoid being removed. The value for a beginner is that it changes your question from what happened to what stage are we observing. When you can place an observed event into a stage, you can ask what resources the attacker needs next. For example, if you suspect a foothold has been established, you can expect attempts to move from one system to another, or attempts to collect credentials, because that is how attackers turn a single entry point into broader access.

A common misconception is that the Cyber Kill Chain is only useful after an incident is confirmed, like a forensic timeline you build when everything is already over. It is much more useful as a way to reason during uncertainty, when you only have hints. Most of the time, defenders do not get a clean, complete story. They get fragments: a suspicious link, a strange login, an unexpected new process, or a connection to an unusual destination. The kill chain helps you treat those fragments like partial puzzle pieces. If you see something that looks like delivery, you look for evidence that someone actually executed it and gained a foothold. If you see evidence of a foothold, you look for evidence of the next steps, like credential access or internal discovery. That approach makes you faster, because you are not waiting for certainty. You are making a reasoned prediction and then checking whether the world confirms or contradicts it.

It also helps to understand what the kill chain does not do, because beginners sometimes try to use it like a universal map for every possible attack. Real attackers do not always follow a neat linear path, and they can repeat stages, skip stages, or loop back when something fails. An attacker might deliver multiple lures before one works, or they might gain a foothold and then spend time quietly learning the environment before doing anything obvious. The point is not to force reality into a perfect sequence. The point is to keep your thinking organized so you can avoid tunnel vision. The kill chain is especially good for helping you ask, what comes next if the attacker succeeds, and what evidence would prove or disprove that. When you use it this way, it becomes less like a checklist and more like a decision-making compass that keeps you oriented in the middle of noisy information.

Now let’s add the Diamond Model, which is a framework designed to analyze intrusions by focusing on relationships between four core elements: the adversary, the victim, the infrastructure, and the capability. Instead of focusing primarily on stages, it focuses on who is doing the action, who it is happening to, what they are using, and what they can do. That may sound abstract at first, but it is extremely practical for anticipation. If you learn even one piece of the diamond, you can often infer something about the other pieces. If you know the infrastructure, like a set of domains or servers being used, you can look for other victims or related activity. If you know the capability, like a phishing style or malware family, you can predict what the attacker is likely to attempt next based on what that capability is designed to do. If you know the victim details, like a particular department being targeted, you can predict which accounts or data stores will be attractive next.

One of the biggest beginner breakthroughs is realizing that these two frameworks answer different questions, and that makes them powerful together. The Cyber Kill Chain helps you answer, where are we in the attack story, and what is the next stage of progress. The Diamond Model helps you answer, what kind of actor is this, what tools and infrastructure are they using, and what does that suggest about their options. If the kill chain is the timeline lens, the diamond is the relationship lens. Using only one can leave gaps. With only the kill chain, you may understand the sequence but not the identity clues that help you anticipate style and persistence. With only the diamond, you may understand the actor and resources but not the stage you are currently observing. Combined, they help you say something like, we are likely seeing initial access right now, and the infrastructure and capability suggest this actor tends to follow up with credential theft and internal discovery, so we should look for those moves before they succeed.

To make this feel real, imagine a simple story without getting lost in technical detail. A new learner might notice that someone received a message that looked slightly off, and later there was an unexpected login prompt, and later still a user reports their account acted strangely. Without a framework, those events might feel unrelated, like random problems. With a kill chain mindset, the message might be part of delivery, the prompt might suggest an attempt to capture credentials, and the strange account behavior might indicate a foothold using stolen access. That naturally leads to an anticipation step: if the attacker has credentials, the next move might be logging into more systems, searching for valuable data, or setting up a way to come back later. With a diamond mindset, you would also ask what infrastructure was used, like the domain hosting the lure, and what capability pattern it resembles, because that can connect your incident to other known activity and suggest what the attacker is likely to do once inside.

Anticipation becomes even more important when you remember that defenders rarely see the attacker directly. Defenders see traces and side effects, not intentions. That is why language matters. When you say, this login is suspicious, you are describing a feeling. When you say, this login could be part of credential use after an initial access attempt, you are describing a hypothesis grounded in a model. That difference changes your next action. Instead of staring at the one event, you start checking for supporting evidence that the hypothesis is correct. If it is correct, you act quickly to block the next stage. If it is not, you avoid overreacting. This is one of the healthiest habits you can build early: treat frameworks as tools for forming and testing hypotheses, not as labels you apply after you already know the answer. The goal is to reduce guesswork by making your reasoning visible and checkable.

Another useful way to apply these frameworks is to focus on what an attacker needs, not just what an attacker did. Needs are predictable because they come from basic constraints. If an attacker wants persistent access, they need a way to re-enter even if the victim changes a password or reboots a machine. If an attacker wants to reach sensitive information, they often need broader permissions, which pushes them toward privilege escalation, credential theft, or abusing trust relationships. If an attacker wants to avoid detection, they may limit noisy actions and use normal-looking channels for communication, which is where Command and Control (C 2) can blend into regular network activity. When you frame your thinking around needs, the kill chain provides the order in which those needs often arise, and the diamond model provides clues about how this particular attacker might satisfy them. That is anticipation in its most practical form: predicting needs leads to predicting moves.

Beginners sometimes worry that using frameworks will make them rigid, like they will miss creative attacks because they are stuck in a diagram. The opposite usually happens when you use frameworks correctly. Frameworks make you more flexible because they give you multiple ways to explain the same evidence, and they encourage you to look for missing links. If you see evidence of internal discovery but you never saw how the attacker got in, the kill chain reminds you there must have been some initial access or credential pathway, even if you missed it. If you see a capability, like a certain style of phishing lure, the diamond model reminds you there is an adversary behind it, and that adversary often has patterns you can research and anticipate. Frameworks also help teams communicate clearly. Instead of vague statements like it looks bad, you can say we have signs of execution and a foothold, and we suspect the next likely action is credential access, so we are focusing our attention there. Clear communication reduces wasted time and prevents confusion.

You can also use these frameworks to avoid a very common trap: confusing indicators with outcomes. An indicator, like a strange domain name, is a clue, not the goal. A capability, like a malicious attachment, is a method, not the objective. A stage, like initial access, is progress, not victory. When people panic, they sometimes treat the first sign as the full attack, and they either overreact or underreact. The kill chain helps you keep the mental distinction between a stage and the overall campaign, and the diamond model helps you keep the distinction between what is being used and who is using it. That means you can respond proportionally. You might treat one suspicious email as a delivery attempt that did not succeed, but if you see evidence that it led to a foothold and then internal activity, you treat it as an active intrusion. That shift happens because you are tracking progress through a story, not just collecting scary artifacts.

As you get comfortable, you can start practicing a simple routine that takes less than a minute in your head. First, name what you are seeing in terms of the kill chain stage you suspect, even if you are not sure. Second, name one likely next move the attacker would need to make if they are trying to succeed. Third, use the diamond model to ask what you know about adversary, victim, infrastructure, and capability, and then use that to refine your prediction. Fourth, decide what evidence you would look for to confirm or deny the prediction. This routine does not require deep tool knowledge. It requires structured curiosity and calm reasoning. Over time, you will start to recognize that many attacks share similar shapes even when the details differ. That recognition is what gives you speed. When something new happens, your brain already has a set of likely next steps ready, and you are not starting from zero every time.

The most important outcome of learning these frameworks is not memorization. It is building a habit of thinking in connected sequences and relationships, instead of isolated events. When you hear about an intrusion, try to map it to a stage progression and ask what the attacker needed at each point. Then try to describe the four diamond elements using whatever information you have, even if some are unknown. Unknowns are not failures; they are prompts for smarter questions. If you can say, we do not know the adversary yet, but we know the infrastructure and capability, you can still anticipate certain moves and protect likely targets. If you can say, we do not know exactly how they got in, but we see behavior that fits later stages, you can still act to prevent the objective from being achieved. These frameworks help you stay useful even when the picture is incomplete, which is most of the time.

By the end of this lesson, the big shift to carry forward is that anticipating next moves is not a magical intuition, it is a disciplined way of telling a better story with limited information. The Cyber Kill Chain gives you a progression that helps you predict what comes after the stage you think you are seeing, and it keeps you focused on preventing the attacker from moving forward. The Diamond Model gives you a relationship map that helps you connect evidence to the actor, the victim context, the infrastructure being used, and the capabilities involved, which often reveals patterns and likely follow-up actions. When you combine them, you stop chasing single clues and start shaping your attention around what the attacker must do next to succeed. The simplest decision rule to remember is this: whenever you see a suspicious event, place it into a likely stage, predict the next need-driven move, and then use the diamond elements to decide what evidence to check first before you commit to a response.