Certified: The GIAC GSOM Audio Course

In this episode, we’re going to build a reliable way to prioritize what your S O C collects, how it enriches that data, and where it still has blind spots, using industry frameworks as a guide rather than as a pile of jargon. Beginners often hear the word framework and picture something overwhelming, like a huge reference document that only experienced professionals can use. The more useful way to think about a framework is as a shared map of common attacker behaviors and defensive goals, which helps you avoid guessing about what matters most. A framework does not replace understanding your organization, but it gives you a structured way to compare your current visibility against known patterns of how incidents unfold. When you combine business priorities with a framework view, you can explain why certain data sources are foundational, why some enrichment is urgent, and why specific gaps are more dangerous than others. By the end, you should be able to use framework thinking to make prioritization faster, clearer, and easier to defend.

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.

The first concept to cement is what frameworks actually do for telemetry decisions, because they are not checklists that magically make a monitoring program complete. Frameworks organize security thinking into categories, such as how attackers gain initial access, how they establish persistence, how they escalate privileges, and how they move laterally across systems. That organization is helpful because it gives you a repeatable set of questions to ask about visibility, like whether you can see authentication abuse, whether you can detect suspicious process execution, and whether you can observe unusual network connections. Without a framework, teams often prioritize based on what is easiest to collect or what a tool makes visible by default, which can create impressive dashboards but weak protection. A framework also provides a common language, which helps different teams agree on priorities even when they do not share the same technical background. For a beginner, the key is not to memorize every category, but to understand that frameworks help you think in behaviors and outcomes rather than in vendor-specific features. That mindset is what makes frameworks practical for collection planning.

One widely used behavioral framework is MITRE ATT&CK (A T T A C K), and you do not need to be an expert in it to benefit from its structure. The high-level idea is that attackers tend to follow recognizable patterns, such as gaining access, running code, stealing credentials, escalating privileges, discovering the environment, moving to other systems, and then reaching their goals like theft or disruption. Each of those patterns implies certain observables, which are the traces those behaviors leave in logs and telemetry. For example, credential abuse implies authentication events and identity-related signals, while execution implies endpoint and application activity that shows what processes or scripts ran. Lateral movement implies network and authentication signals that show unusual connections and remote access paths between systems. Exfiltration implies signals about data access and outbound transfers that are unusual in destination or volume. Using A T T A C K at a high level helps you ask whether your collection can see these behaviors, and if it cannot, you have a framework-defined blind spot.

Another common framework family is the NIST Cybersecurity Framework (C S F), which is organized around functions like Identify, Protect, Detect, Respond, and Recover. This is useful for prioritization because it reminds you that telemetry is part of a broader system, where data collection supports detection, but enrichment and workflow support response and learning. If your collection is strong but your response evidence is weak, you might detect events but struggle to act confidently, which is a mismatch between Detect and Respond. If you lack asset and identity context, your Identify function is weak, which makes your Detect function less reliable because you cannot judge importance. For beginners, the main use of C S F is to keep you from tunnel vision, where you only invest in detection logic while ignoring the context and processes needed to make detection meaningful. When you prioritize collection and enrichment, it helps to remember that data must support both noticing and deciding, not just noticing. That is the operational bridge between framework language and real S O C performance.

Frameworks also help you distinguish between collection, enrichment, and coverage, which sound similar but represent different problems. Collection is getting raw events from systems, such as authentication logs, endpoint events, and application audit records. Enrichment is adding context that makes those events interpretable, such as mapping user identifiers to roles, mapping hosts to business owners, or tagging assets by criticality. Coverage is the combined result of both, meaning how completely you can observe important behaviors across the systems that matter. A team can collect a lot of data but still have poor coverage if it lacks enrichment that ties events to business context. A team can enrich beautifully but still have poor coverage if it collects only a narrow slice of systems. Frameworks help because they define behavior categories that you can use as a yardstick, and then you can ask whether your collection and enrichment jointly provide visibility into each category. This is a clearer approach than counting log sources, because it measures the ability to observe meaningful behaviors rather than the volume of telemetry.

When you use a framework to prioritize collection, you are essentially ranking which behavior categories you most need to see first, based on likely threats and business impact. A common pattern is to start with visibility into identity and access, because credential abuse and account misuse show up in many attack paths. That implies collecting authentication successes and failures, privilege changes, and administrative actions on identity systems and key platforms. Next, you often prioritize endpoint behavior, because many attacks involve executing malicious code, changing persistence settings, or using legitimate tools in suspicious ways. That implies collecting process execution signals, service and scheduled task changes, and security control changes, at a level of detail that supports correlation. Network behavior often follows because lateral movement and command-and-control patterns involve connections that deviate from normal service communication. That implies collecting connection metadata and key gateway telemetry that shows external reach and internal movement. Framework thinking does not force a single order, but it provides a rational basis for choosing an order that matches how attacks commonly unfold.

Frameworks are also powerful for prioritizing enrichment, because many gaps in detection are not caused by missing events, they are caused by missing context. A framework might tell you that you need to detect suspicious remote access, but you cannot do that well unless you can distinguish approved remote administration from unusual remote access for a given role. That distinction often requires enrichment from identity roles, device inventories, and network segment definitions. A framework might push you to detect privilege escalation behavior, but you cannot judge that without knowing which privileges are expected for the account and which system is being affected. That requires enrichment like role-to-privilege mapping and asset criticality tagging. A framework might encourage detection of data access anomalies, but without data classification context and business ownership, you cannot prioritize which accesses are truly risky. This is why enrichment can be as high priority as collection, because it turns raw events into meaning. When you evaluate enrichment needs through a framework lens, you can focus on the context that unlocks multiple detections rather than context that only helps one narrow alert.

Coverage gaps become much easier to reason about when you define them in terms of framework behaviors you cannot observe, rather than in terms of specific tools you do not have. A gap might be that you cannot see process execution on a class of endpoints, which weakens your visibility into execution and persistence behaviors. Another gap might be that you cannot see administrative changes in a key cloud environment, which weakens your visibility into privilege and defense evasion behaviors. Another gap might be that you have network telemetry for external connections but not for internal east-west movement, which weakens your visibility into lateral movement and internal discovery. A framework-based gap description is useful because it stays stable even if systems change, and it communicates risk clearly to non-specialists. It also helps prioritize, because some gaps block your ability to observe many behaviors, while others are narrower. When you prioritize gaps, you want to close the ones that remove entire categories of visibility, especially around identity, privilege, and execution.

A practical spaced-review habit is to use framework coverage as a layered view, where you aim for baseline visibility in many areas before you chase deep detail in a single area. Baseline visibility means you can at least observe the key steps in common attack paths, even if you cannot capture every detail. For example, you might be able to see that an account logged in unusually, that an endpoint executed something suspicious, and that the endpoint then communicated externally in an odd way, even if you do not have full command-line details or full network content. That baseline is valuable because it supports early detection and broad triage, and it helps you decide where to deepen collection next based on what you actually see. Depth comes later when you add richer fields, longer retention, and more detailed telemetry for the systems that prove most important. Frameworks support this approach because they encourage broad behavioral coverage rather than narrow technical perfection. For beginners, this is a healthy way to build monitoring maturity without getting overwhelmed.

Frameworks can also help you avoid a common beginner trap, which is collecting only what triggers alerts and ignoring what supports investigation. A framework might push you to detect suspicious credential activity, but without good identity and asset context, the alert might be noisy and hard to confirm. Similarly, a framework might push you to detect unusual network connections, but without knowing which systems normally talk and which do not, you might drown in false positives. Investigation support requires that you can pivot from an alert to related evidence, such as recent privilege changes for the account, recent configuration changes on the system, and recent peer connections from the same host. That pivoting depends on consistent identifiers and normalized fields across sources, which is a collection and enrichment design problem. Framework thinking helps because it encourages you to see the full behavior chain, not just the first signal. When you prioritize, make sure you invest in the linking tissue, like identity resolution and asset mapping, because that is what makes framework-based detections usable.

Another valuable use of frameworks is to create a simple scoring mindset for collection and enrichment decisions, even if you never compute a number. You can ask whether a data source enables visibility into multiple framework behaviors, whether it supports correlation across systems, and whether it improves both detection and investigation. You can also ask how critical the systems are that the data source covers, because collecting excellent telemetry from low-impact systems does not meaningfully reduce risk. Enrichment sources can be scored similarly, such as whether they improve triage speed across many alerts and whether they reduce false positives by explaining normal behavior. This scoring mindset is not meant to be rigid, but it keeps you from being swayed by flashy details that only help one corner case. It also keeps you honest about tradeoffs, because some telemetry may be high value but too expensive at full detail, so you might collect a lighter version first. Frameworks provide the categories, and your scoring provides the prioritization logic.

Framework-driven prioritization should also include the idea of validation, because a coverage plan is only real if you can confirm that the data arrives, is complete, and is usable. It is common for teams to assume they have coverage because a connector is enabled, only to find later that key event types are missing or fields are inconsistent. Validation means checking that the telemetry represents the behaviors you care about and that it can be searched and correlated reliably. It also means monitoring the pipelines, so you know when sources go silent, when delays grow, or when field mappings change after updates. Frameworks help here because they give you concrete expectations, like what evidence should exist when certain behaviors occur, and you can test whether your system sees it. This makes coverage a measurable reality rather than a belief. For spaced review, remember that framework coverage is not just a design diagram, it is something you must continuously confirm.

As we conclude, keep the main idea simple: industry frameworks give you a shared map of attacker behaviors and defensive functions, and that map helps you prioritize collection, enrichment, and coverage gaps in a rational way. They push you to think in behaviors like credential abuse, execution, privilege change, movement, and data access, rather than thinking only in terms of what a tool can ingest. They also remind you that raw collection is not enough, because enrichment like identity context and asset criticality is what turns events into decisions, and decisions are what reduce risk. When you describe gaps in framework terms, you communicate risk clearly and you can focus on closing the gaps that remove entire categories of visibility. Finally, frameworks support a mature building approach where you aim for broad baseline coverage first, validate it, and then deepen visibility where it provides the most leverage. If you can use frameworks as a prioritization compass rather than as a memorization burden, you will be able to justify your telemetry program choices quickly and confidently.