Certified: The CompTIA SecOT+ Audio Course

When people first hear the phrase threat intelligence, it can sound like a secret club that only big government agencies or massive companies can join, because the word intelligence carries a kind of movie-like vibe. In reality, threat intelligence is simply the disciplined habit of turning messy information about adversaries and attacks into understanding that helps you make better decisions. For Operational Technology (O T), that matters even more because mistakes can lead to real-world consequences like equipment damage, unsafe conditions, or a shutdown that affects the public. The hardest part for beginners is that threat information often arrives as scattered facts: a suspicious file name, a strange network connection, a headline about an incident, or a rumor about a new tactic. Frameworks help you organize those facts so you can reason clearly, communicate consistently, and avoid overreacting to the wrong detail. In this lesson we’ll build that mental structure by using three well-known frameworks that behave like different lenses: the Diamond Model, the MITRE ATT&CK for ICS knowledge base, and the Cyber Kill Chain.

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.

A useful starting point is to separate raw data from intelligence, because new learners often treat them as the same thing and then get frustrated when “intel” doesn’t immediately tell them what to do. Data is a fact you can point to, like an I P address, a process name, a time stamp, or a vendor advisory. Information is data with basic context, like knowing that the I P address is associated with a hosting provider or that the process name is unusual for a controller engineering workstation. Intelligence is information that has been interpreted for a specific decision, such as whether to block a remote connection, whether to adjust monitoring, or whether to change how remote support is handled. Frameworks support that interpretation step by providing categories and relationships that keep you from chasing random indicators. In O T, you also have to recognize that “actionable” does not always mean “block it right now,” because availability and safety are top priorities and a blunt response can be worse than the threat. The goal is a calm, repeatable method for understanding who might be attacking, how they do it, and what stage they are in, so your response can be proportionate and safe.

The Diamond Model is a great first lens because it forces you to think in relationships instead of isolated events, and that is exactly what beginners need when they are tempted to anchor on a single artifact. The model describes an intrusion event using four core features: adversary, infrastructure, capability, and victim. The idea is that if you know something about one corner, you can reason about the others and ask better questions. For example, if you learn about a capability like a specific type of malware or a technique for remote control, you can ask what infrastructure it tends to use, what kinds of victims it targets, and what adversaries historically used it. In O T settings, this matters because the environment is often stable and predictable, so changes stand out, but you still need a way to explain why a change might be malicious rather than a normal maintenance action. The Diamond Model becomes a structured storytelling tool: it turns scattered observations into a coherent narrative that other people can follow, including operators, engineers, and leaders.

To make the Diamond Model concrete, imagine you notice a remote connection into an engineering workstation at an unusual time. If you only focus on the infrastructure corner, you might say, “This I P address is suspicious,” and stop there, which is not very helpful. The Diamond Model pushes you to ask what capability is being exercised, such as remote administration, credential use, or file transfer, and whether that capability matches normal vendor support patterns. It also nudges you to consider the adversary corner, not as a named group at first, but as a profile: is this likely opportunistic, financially motivated, or focused on disruption? Finally, the victim corner helps you define what is actually being targeted: the workstation itself, the controller programming environment, the process network, or the safety system interface. In O T, that distinction changes everything, because a connection to a historian server has different implications than a connection to a safety controller engineering station. Even when you cannot identify the adversary, the Diamond Model still helps because it clarifies what you know, what you assume, and what you need to verify before taking action.

Another beginner-friendly advantage of the Diamond Model is that it encourages pivoting, which means using one known fact to discover related facts without getting lost. If you have infrastructure, you can pivot to see if the same infrastructure has contacted other assets or appeared in prior events. If you have a capability, you can pivot by looking for the same behavior patterns elsewhere, such as the same remote access tool or the same technique of moving files. If you have a victim, you can pivot to identify similar victims, like other sites with the same vendor equipment, similar network architecture, or similar remote access arrangements. In O T, pivoting is often more about patterns than volume, because you might not have huge data lakes, and some systems produce limited logs. That is okay, because the model is about disciplined thinking, not big-data magic. The biggest mindset shift is learning to treat each observation as a doorway to structured questions rather than a final conclusion. When you do that, you stop being “the person who saw a weird log” and become “the person who can explain what it might mean and what to check next.”

Where the Diamond Model gives you a relationship map, MITRE ATT&CK for ICS provides a shared vocabulary for adversary behavior in industrial environments, and that helps you talk about attacks in a way that is consistent and testable. The MITRE ATT&CK framework (A T T and C K) is essentially a catalog of tactics and techniques that attackers use, and the ICS-focused portion emphasizes behaviors relevant to control systems. A tactic is the attacker’s goal at a stage, like initial access, execution, persistence, or impact, while a technique is a specific way of achieving that goal. The reason this is helpful for beginners is that it breaks the foggy idea of “they hacked us” into a chain of behaviors you can observe and defend against. It also prevents the common mistake of assuming every incident is malware, because many real intrusions are mostly about credentials, remote access, and living off the land. In O T, the ICS flavor adds nuance about engineering workstations, controllers, process manipulation, and the difference between disrupting visibility versus disrupting physical process.

ATT&CK for ICS is especially useful because it connects defensive thinking to what you can actually monitor, and that matters in environments where you cannot deploy every shiny security tool. If you map what you can see to techniques, you can identify blind spots without panicking. For example, if remote services are a common path for initial access, then you want to know how remote sessions are authenticated, logged, and approved, even if you cannot run aggressive endpoint detection agents. If attackers often attempt to impair process control or inhibit response functions, you want visibility into changes to controller logic, changes to setpoints, or changes to alarm configurations, even if that visibility comes from engineering process records rather than security logs. The framework also helps you write clearer requirements, such as needing the ability to detect unauthorized program downloads or detect unusual use of engineering software outside change windows. Beginners often struggle to translate “be more secure” into concrete needs, and ATT&CK for ICS gives you a menu of behaviors that can be turned into monitoring and control priorities.

It is also important to understand what ATT&CK for ICS is not, because misconceptions create wasted effort. It is not a list of guaranteed steps that every attacker will follow, and it is not a magic checklist that, once completed, makes you safe. It is a knowledge base of observed behaviors, and its value comes from how you apply it to your environment. Two plants can have the same technique in theory, like remote access, but different risk in practice depending on segmentation, authentication, and operational discipline. In O T, the same technique may also have very different safety implications depending on what part of the process is affected. Another misconception is that mapping to ATT&CK is only for incident response after something bad happens. In reality, it is most powerful before incidents because it helps you prioritize what to harden and what to watch. When used well, it makes your security conversations more specific, less emotional, and easier to validate with evidence.

Now let’s bring in the Cyber Kill Chain, which is another framework lens, but it focuses more on the stages of an attack and the opportunities to stop it earlier. The idea is simple: attackers usually have to do multiple things in sequence to reach their goal, and defenders want to interrupt that sequence as early as possible. The classic stages include things like reconnaissance, weaponization, delivery, exploitation, installation, command and control, and actions on objectives. For a beginner, the key value is that it provides a timeline, so you can ask, “Where are we in the story right now?” That question matters because the right response depends on the stage. If you are seeing early reconnaissance, you might strengthen monitoring and reduce exposed services, while if you are seeing command and control traffic, you might need containment and a careful plan to avoid disrupting operations. In O T, the kill chain also reminds you that an incident may begin in I T and only later threaten O T, so the “delivery” phase might be a business email compromise, and the “actions on objectives” phase might be an attempt to change process settings.

A helpful way to understand how these frameworks complement each other is to imagine them as three ways to describe the same event, each emphasizing different details. The Kill Chain tells you when and how the attacker is progressing, which is great for planning defensive choke points and response timing. ATT&CK for ICS tells you what behaviors the attacker is using at each point, which is great for detection engineering and clear communication. The Diamond Model tells you who and what is connected to the event, which is great for investigation, pivoting, and building a coherent narrative. None of them replaces the others, and you do not have to choose a single “best” framework. In practice, teams often use the Kill Chain for the big story arc, ATT&CK for the behavioral detail, and the Diamond Model to connect the people, infrastructure, and victim context. For a new learner, the goal is to become comfortable switching lenses, because real incidents rarely fit neatly into one diagram. When you can do that, you can explain an incident in a way that makes sense to both technical and non-technical stakeholders.

Let’s apply the combined approach to a simple O T-flavored scenario without getting into tools or commands. Suppose a facility uses a remote access portal for vendor support, and someone logs in outside normal hours, then accesses an engineering workstation, and later there is an unexpected process change. The Kill Chain view might say the attacker first performed reconnaissance by learning the facility’s remote access methods, then gained initial access through the portal, then established control by using remote sessions, and finally attempted actions on objectives by changing something that affects the process. ATT&CK for ICS would let you describe those steps with techniques such as external remote services, valid accounts, remote services, and potentially techniques related to modifying control logic or manipulating process variables, depending on what happened. The Diamond Model would help you track the adversary profile, the infrastructure used for remote access, the capability represented by the session behavior, and the specific victim systems involved, including which segment and which role each system plays. Even if you do not know the attacker’s name, you can still communicate a clear, defensible explanation of what you observed and why it matters.

Because O T environments care deeply about safety and reliability, using frameworks also supports better decision-making under pressure, which is when mistakes happen. A common failure mode is to treat every suspicious event as an emergency that demands immediate shutdown. Another failure mode is the opposite: to assume it is just a glitch or normal maintenance because “nothing bad has happened yet.” Frameworks help you avoid both extremes by giving you a way to assign meaning without guessing wildly. If the Kill Chain suggests you are early in an intrusion, you can focus on tightening exposure and increasing observation while coordinating with operations. If ATT&CK mapping suggests techniques that commonly lead to impact, you can elevate urgency while still choosing controls that are safe for the process. If the Diamond Model shows the same infrastructure touching multiple victims, you can treat it as a campaign rather than a one-off anomaly. The point is not to become dramatic, but to be precise, because precision is what keeps response actions aligned with operational priorities.

Finally, it helps to internalize what a “good” outcome looks like when you operationalize these frameworks as a beginner. A good outcome is not memorizing every technique name or drawing perfect diagrams from memory. A good outcome is being able to take a confusing incident description and translate it into a structured explanation that supports action. You want to be able to say, with confidence, what is known, what is suspected, and what evidence would reduce uncertainty. You want to be able to communicate clearly across the I T and O T boundary, where vocabulary and priorities differ, without losing the thread of what is happening. You also want to identify where to improve visibility over time, because many O T environments start with limited telemetry and must add observability carefully. When you use frameworks consistently, your organization builds institutional memory, meaning today’s lessons become tomorrow’s faster detection and calmer response. That is the real power of threat intelligence frameworks: they turn scattered events into learning that compounds.