The structural signatures that gave GTIG confidence in the assessment are telling: the exploit script contained a hallucinated CVSS score in its docstrings (the in-code comments left by the developer), a textbook Python format characteristic of AI-generated code, down to extra code that prints the terminal output in color. These are small stylistic tells that a human exploit developer wouldn’t bother with.

That’s the headline finding from GTIG’s Q2 2026 AI Threat Tracker, published May 11. The TLDR version: adversaries have moved beyond basic experimentation to industrial-scale use of generative AI, and they’re doing several different things with it. Google is calling out specific groups by name, including state-sponsored clusters from China and North Korea, financially motivated cybercrime crews like TeamPCP, and Russia-linked operators targeting Ukraine. Each one uses AI at a specific phase of the attack lifecycle.

Below, I walk through what they’re doing and where it lands, mapping each use to the part of the kill chain a CISSP holder already operates against.

Here’s a quick tour.

Researching their targets

Before the attack comes the homework. Adversaries are using large language models to map out their victims. They generate detailed organizational hierarchies for departments such as finance and HR, identify which third-party vendors a target enterprise relies on, and even fingerprint the specific make and model of the computer a high-value executive uses. In one documented case, a threat actor asked an AI model to identify a target’s laptop from photographs.

Two China-linked actors stand out. The cluster GTIG tracks as UNC2814 prompts Google’s Gemini to act as a “senior security auditor” or “C/C++ binary security expert” before asking it to analyze the firmware of embedded devices like TP-Link routers. A separate China-linked group used a public agentic framework called Hexstrike, combined with a knowledge-graph memory system, to maintain persistent state on a target’s attack surface and pivot autonomously between reconnaissance tools.

The shared pattern: AI as a research force multiplier. Tasks that used to take a human analyst hours of OSINT can now happen at machine speed.

Developing new exploits

The identified zero-day matters for what it reveals about how AI changes vulnerability research. The 2FA bypass came from a hardcoded trust assumption in the developer’s authentication logic. It’s a high-level semantic flaw that fuzzers and static analyzers routinely miss. AI models, reading the developer’s intent across the codebase, increasingly find them.

Writing stealthier malware

AI also appears inside the malware itself. Sometimes it’s used to hide the malicious code. Sometimes it’s used to operate it in real time.

Two Russia-linked malware families, CANFAIL and LONGSTREAM, target Ukrainian organizations and contain LLM-generated decoy code. LONGSTREAM checks the system’s daylight saving status 32 times in a row, for no operational reason except to make the malicious file look like routine administrative work.

And then there is PROMPTSPY. The Android backdoor sends the device’s current screen layout to Google’s Gemini API and asks the model where to tap next. The model returns coordinates. The malware taps. ESET first identified the malware. GTIG extended the analysis to describe what they call the first widely-reported example of an AI service driving real-time malware behavior in the wild.

Industrializing account abuse

AI providers cap usage. Attackers don’t want to be capped. So they industrialized account abuse.

Two China-linked clusters, UNC6201 and UNC5673, run automated registration pipelines that bypass CAPTCHA and SMS verification to create premium accounts at scale. Middleware aggregators such as Claude-Relay-Service and CLIProxyAPI allow attackers to pool API keys from Gemini, Claude, and OpenAI accounts via a single OpenAI-compatible interface. Anti-detect browsers mask the fingerprints. The whole ecosystem looks professionalized. GTIG documents five tool categories with named examples for each.

Manufacturing scale

The same scaling impulse shows up in influence operations. The pro-Russia campaign Operation Overload used suspected AI voice cloning to make real journalists appear to say things they never said, splicing the synthetic audio into manipulated video to lend credibility to false narratives. Russia, Iran, China, and Saudi Arabia are all using AI to produce political content at volume, though most of the breakthrough capability claims for these campaigns have not yet appeared in observed operations.

Going after the AI supply chain

The frontier models themselves are well-defended. So attackers are going after the connecting layers: the libraries, the package managers, the skill marketplaces, and the API gateways that AI systems depend on.

A cybercrime cluster known as TeamPCP (also tracked as UNC6780) compromised the GitHub repositories of LiteLLM, BerriAI, Trivy, and Checkmarx in late March 2026. They embedded a credential stealer called SANDCLOCK that extracted AWS keys and GitHub tokens from affected build environments. The stolen credentials were sold to ransomware and data-theft-extortion groups, turning a single supply chain compromise into multiple downstream payloads.

A parallel pattern hit the OpenClaw skill marketplace. Researchers found malicious packages distributed as legitimate skills, containing hidden routines that abused OpenClaw’s elevated system access to run unauthorized code. Both incidents are supply chain attacks specifically targeting the AI dependency layer.

How does MITRE ATLAS help?

All six behaviors above need names. Once a threat has a technique ID, you can record it in a risk register, assign an owner, select a control, and audit the result. MITRE ATLAS is the canonical vocabulary for AI-specific adversary tactics, the AI extension of MITRE ATT&CK. I previously wrote a longer piece on ATLAS for readers who want the deeper context.

A question worth asking follows: how well does ATLAS cover what GTIG just documented?

The answer is partial. Some of GTIG’s findings map cleanly to pre-existing ATLAS techniques. Several map to techniques MITRE added or updated in their early May (v5.6.0) release. A handful have no direct ATLAS coverage, but the framework is responsive, and it’s still catching up.

Already in the catalog

Four of GTIG’s findings map to ATLAS techniques that predate the May update:

• PROMPTSPY’s autonomous orchestration is fully covered. AML.T0040 (AI Model Inference API Access), AML.T0103 (Deploy AI Agent), AML.T0102 (Generate Malicious Commands), and AML.T0053 (AI Agent Tool Invocation) describe the architecture pattern PROMPTSPY uses.

• LLM account abuse and middleware proxies map to AML.T0008.005 (AI Service Proxies), AML.T0021 (Establish Accounts), and AML.T0016.002 (Obtain Capabilities: Generative AI). These were added in earlier ATLAS releases.

• TeamPCP’s AI supply chain compromise maps to AML.T0010.001 (AI Supply Chain Compromise: AI Software).

• Operation Overload’s voice-cloning campaign maps to AML.T0088 (Generate Deepfakes), the technique GTIG used in their own appendix to attribute this finding. T0088 covers the synthesis of high-fidelity audio and video to impersonate authoritative figures.

These map straight into a register today without waiting for anything new.

Just added

ATLAS Data v5.6.0 (atlas.mitre.org, view the diff) added or updated four entries relevant to the behaviors above:

• Deepfake-assisted phishing (AML.T0052.001, new) is a phishing-specific subtechnique that extends the pre-existing T0088 Generate Deepfakes. GTIG didn’t document a deepfake-phishing-specific incident in this report, but ATLAS's addition of this subtechnique signals the framework’s anticipation of voice cloning moving from influence operations into phishing pretexts (CEO fraud, executive impersonation).

• Code repository reconnaissance (AML.T0095.000, new subtechnique under the new parent AML.T0095 Search Open Websites/Domains) covers the GTIG-documented use of public code repos for AI-related secrets and configuration discovery.

• LLM Jailbreak (AML.T0054, updated) now reflects persona-driven prompting patterns, including acting as a “senior security researcher” jailbreak that GTIG attributed to UNC2814.

• OpenClaw command-and-control case study (AML.CS0051, updated) formalizes the OpenClaw skill marketplace compromise pattern.

The release timing: MITRE published v5.6.0 on May 4. GTIG published their threat report on May 11. The framework was updated in close parallel with the threat intelligence cycle.

Not yet in the catalog

Three GTIG findings have no dedicated ATLAS technique:

• AI-developed zero-day exploits. The lead finding from the GTIG report, the criminal-actor 2FA bypass developed with AI assistance, doesn’t have a specific ATLAS technique. The closest is AML.T0017 (Develop Capabilities), which is generic. There’s no “adversary uses AI to discover vulnerabilities in target systems” entry.

• AI-generated polymorphic malware code. The LLM-generated decoy code in CANFAIL and LONGSTREAM, including LONGSTREAM’s 32 daylight-saving checks, has no dedicated technique. ATLAS covers prompt-side obfuscation under AML.T0068, but adversary use of AI to generate malware code with camouflage logic isn’t named.

• Agentic frameworks as offensive tools. The PRC-nexus actor using Hexstrike with the Graphiti memory system for autonomous reconnaissance has no matching ATLAS entry. The framework covers adversaries' use of AI inference APIs and includes AML.T0103 for deploying defender- or victim-owned agents, but offensive use of full agentic frameworks against victims remains a gap.

The gap is ATLAS-specific. GTIG’s own appendix maps these findings to conventional MITRE ATT&CK techniques: T1587.001 (Develop Capabilities: Malware) for CANFAIL and LONGSTREAM, T1587.004 (Develop Capabilities: Exploits) for the AI-developed zero-day, T1027.014 (Polymorphic Code) for PROMPTFLUX, and T1027.016 (Junk Code Insertion) for the decoy code patterns. Traditional ATT&CK covers the underlying behaviors. ATLAS hasn’t yet named them in AI-specific form.

The gap is informative. The biggest single GTIG finding (AI used to develop a real zero-day exploit) sits in the no-direct-mapping bucket. Frameworks update on incident-disclosure timelines, and it makes sense that the threat intelligence is ahead of the vocabulary.

How to harness ATLAS

Four things a CISSP-led security program can do this quarter with what’s in front of us:

1. Map ATLAS technique IDs into your existing risk register. The directly-mapped findings are the easy lift. Risk: AI dependency supply chain compromise. Threat: AML.T0010.001. Mitigation: AML.M0023 AI Bill of Materials and AML.M0014 Verify AI Artifacts. Owner: AppSec team. Same structural pattern your ATT&CK-anchored entries already use, with ATLAS-formal mitigation IDs rather than generic supply chain practices.

2. Add the v5.6.0 techniques where they apply. Deepfake-assisted phishing belongs in your security awareness training program now, not next year. The technique has a corresponding mitigation (AML.M0034 Deepfake Detection), and your tabletop exercises can use it as a scenario starter. Code repository reconnaissance fits into your secrets management and source control hygiene program.

3. Document the gaps as monitoring needs. This is the part most risk registers will miss. For each GTIG finding that doesn’t have an ATLAS technique (AI-developed zero-days, AI-generated polymorphic malware, offensive agentic frameworks), the register entry should explicitly say “no standard taxonomy entry; monitor framework releases for coverage.” A risk register that names where the framework has gaps is stronger than one that pretends the gaps don’t exist.

4. Track ATLAS releases. The framework moved from “no v5.6.0” to “four directly-relevant new entries” in less than a month after the underlying incidents became publicly known. Release tags live at github.com/mitre-atlas/atlas-data/releases. The canonical user-facing technique pages are at atlas.mitre.org. Subscribing to release notifications is a one-time setup with ongoing value.

Six attacker behaviors, named groups behind each, and a framework that’s partially there. Your risk register needs both the techniques the framework has named and the gaps it hasn’t.

Are you seeing any of these six behaviors already in your environment? Reply or drop it in the comments.

AI governance has moved from voluntary guidance to enforceable obligation in less than two years. The EU AI Act came into force on 1 August 2024. NIST released its AI Risk Management Framework (AI 100-1) in January 2023. ISO/IEC 42001, the first ISO standard for an AI management system, was published in December 2023.

For CISSP holders, the practical questions are how they fit together and what existing ISO 27001 work actually transfers. In this article, we dive into a comparison of NIST AI RMF and ISO/IEC 42001: how they differ, where they overlap, and which fits which use case.

The two frameworks at a glance

NIST AI RMF (AI 100-1). Published January 2023 by the U.S. National Institute of Standards and Technology (NIST). Four core functions: Govern, Map, Measure, and Manage. Seven trustworthiness characteristics. Four implementation Tiers. The Playbook companion document elaborates on 72 subcategories with suggested actions. NIST AI 600-1 (July 2024) introduces a Generative AI Profile that includes 12 GAI-specific risks. Voluntary, non-certifiable, free to download.

ISO/IEC 42001:2023. The AI version of ISO 27001. Published December 2023, it follows the same management system pattern that any 27001-certified organization already operates: leadership commitment, risk assessment, controls, internal audit, management review, and continual improvement. Clauses 4 through 10 are identical in structure to those in ISO 27001 and use the standard ISO management system template (i.e., “Annex SL-conformant”) as do other ISO management system standards. What’s new is the AI-specific control catalog in Annex A: 38 reference controls covering AI policy, roles, resources, system impact assessment, lifecycle management, data, transparency, intended use, and third-party relationships. As with 27001, you produce a Statement of Applicability (SoA) that lists every control and provides a written justification for its inclusion or exclusion. Unlike NIST AI RMF, you can earn a certificate through an accredited third-party audit. Note that reading the standard requires purchasing a license from ISO.

The two were designed to be readable together. ISO 42001 clause 4.1 NOTE 1 explicitly cross-references NIST AI RMF for AI role types and lifecycle stages.

What transfers from existing ISO 27001 work

If you have experience with ISO 27001, that muscle memory does most of the work. The ISO Survey 2024, published by ISO/IAF CASCO in September 2025, reports 96,709 ISO 27001 certificates and 179,877 sites globally. ISO 27001 ranks fourth among all ISO management system standards by certificate volume, behind only ISO 9001, ISO 14001, and ISO 45001. At a 179,877-to-96,709 ratio of sites to certificates, the average certified organization runs 1.86 sites under one certificate scope.

What that engagement gives you:

1. The audit cadence is identical. Stage 1 documentation review, Stage 2 on-site assessment, annual surveillance audits in years one and two, full recertification in year three. ISO 27001 audit capability (internal audits per clause 9.2, certification body relationships, surveillance preparation) transfers the management-system half of ISO 42001. The AI-specific half (model risk, AI System Impact Assessment, and the new control catalog) is a separate competency that typically requires AI domain expertise, which can be sourced internally or from specialists.

2. The Statement of Applicability is the document that gets audited. Both standards require it in the same form: a list of every Annex A control, justification for inclusion or exclusion, and management sign-off. ISO 42001 trades 27001’s 93 information security controls for 38 AI-specific ones. The document discipline transfers.

3. CISSP Domain 1 already covers both. ISC2’s Exam Guidance for AI (April 2026) cites NIST AI RMF and ISO 42001 as required compliance-tracking frameworks for AI governance professionals.

4. Top management commitment, internal audit, management review, and corrective action. Same wording in 27001, 42001, and other ISO management system standards. If you’ve run any of them, you already know these clauses.

5. A crosswalk already exists. NIST’s AI Resource Center hosts a community-submitted 72-row crosswalk pairing every NIST AI RMF subcategory with the relevant parts of ISO 42001. GOVERN maps to leadership and policy areas. MAP to context-setting and impact-assessment processes. MEASURE maps to monitoring and verification. MANAGE to management review and continual improvement. NIST hosts the crosswalk but doesn’t endorse it (the crosswalk’s page notes that inclusion doesn’t imply NIST endorsement of either framework’s coverage). Use it as a starting reference for your own verification work.

That covers maybe 60% of the work. Here’s where the muscle memory breaks.

What doesn’t transfer

NIST AI RMF asks for use-case-specific Profiles. An organization deploying both a recommendation engine and a clinical decision support system needs two different Profiles, not one. ISO 27001’s Statement of Applicability operates at the organizational level rather than on a per-use-case basis, so this is new ground for practitioners coming from ISO 27001.

ISO 42001 has an outward-facing AI System Impact Assessment (clause 6.1.4) with no clean 27001 analog. Internal risk assessment looks at consequences for the organization. Impact assessment looks at consequences for individuals, groups, and societies external to it. The closest 27001 analog is supplier risk, but it isn’t the same shape.

Annex A is leaner than 27001’s. 38 controls across 9 categories versus 27001’s 93. Lean by design, but it places more weight on the auditor's and implementer's judgment in the SoA. Two 42001-conformant organizations with identical risk profiles can end up with materially different control sets.

A climate change clause. ISO 42001 clause 4.1 requires the organization to determine whether climate change is a relevant issue. Inherited from a harmonized update that flowed through 27001, 9001, and other ISO management system standards in 2023 and 2024. The energy footprint of large-model training and inference makes this a real audit-interpretation question, not a paper one.

NIST has a dedicated Generative AI Profile (AI 600-1). ISO 42001 is a general-purpose standard. If your AI estate is mostly GenAI, AI 600-1’s 12 GAI-specific risks give you a more specific risk taxonomy than Annex A does.

Which to lead with

Lead with NIST AI RMF when your audience is the engineering organization, your regulatory exposure is U.S.-centric, or you want internal risk discipline before external proof. NIST is free, easy to adopt as a taxonomy, and doesn’t require a relationship with an audit body.

Lead with ISO 42001 when your audience includes procurement, customers, or regulators seeking third-party assurance. When your exposure is EU AI Act-adjacent. When you already have ISO 27001, 9001, or 14001 certified, the harmonized structure makes 42001 a meaningfully smaller delta than going greenfield. ISO 42001 is the path to a certificate. NIST AI RMF is the path to a self-attestation document.

The pattern teams might settle into is to implement NIST first to establish the taxonomy and lifecycle discipline, then layer ISO 42001 certification on top once the documentation work is complete. According to a Modulos vendor blog (April 2026), teams that go in this order find 42001 certification work substantially easier to land. Caveat worth flagging: Modulos sells an AI governance platform that supports both frameworks, so the framing is shaped by their product, but the structural claim still holds.

What doesn’t map cleanly?

NIST AI RMF cannot be audited. Self-attestation only. If a customer asks for proof, you have your documentation, not a certificate, and of course, ISO 42001 is the path to that certificate.

Both frameworks predate widespread agentic AI deployment, but their structure was built to flex. NIST AI 100-1 is January 2023. ISO 42001 is December 2023. Neither directly names the agent stack (multi-agent systems, persistent memory, tool-using agents). In practice, organizations map agentic behaviors onto existing requirements rather than waiting for explicit agent text. ISO 42001’s risk assessment (clause 6.1.2) and AI system impact assessment (clause 6.1.4) evaluate the degree of autonomy and identify agent-specific risks like prompt injection. Annex A.9 (Use of AI systems) covers responsible-use processes, including human-oversight controls for high-risk agentic workflows. A.6.2.8 (AI system recording of event logs) becomes the audit trail for agent reasoning. A.6.2.6 (AI system operation and monitoring) becomes the drift-detection discipline. Extension frameworks like CSA MAESTRO and the OWASP Agentic Top 10 add technical depth on agent-specific threats, but the management system architecture for governing them is already in 42001.

The decommissioning gap is the clearest difference. NIST AI RMF treats the safe retirement of AI systems as a separate step. ISO 42001 doesn’t have a dedicated decommissioning control. End-of-life gets folded into broader operation and monitoring work. If you run AI systems where retirement has real consequences (regulated industries, customer-facing deployments, and expensive trained models), you’ll need to build your own decommissioning process beyond what Annex A asks for.

BS ISO/IEC 42006:2025 is the AI audit qualification standard. Published by BSI in July 2025. When selecting a certification body for ISO 42001, ask whether their auditors are qualified under 42006. For CISSPs considering an AI audit as a career path, this is the named qualification track.

Monday morning

If you have an existing ISO 27001 SoA template, pull it. Sit down with the ISO 42001 Annex A controls list. For each of the 38 controls, note “we do this already / we partially do this / we don’t do this.” That 30-minute paper exercise becomes the foundation for an eventual real SoA.

If you don’t have a 27001 SoA in your toolkit, start with NIST AI RMF. Read the four functions. Run a one-page self-assessment of where your organization sits on the four Tiers. Two hours of work that helps create a defensible baseline.

A common implementation failure is starting both frameworks at once and finishing neither. Pick one to lead with, document the decision, and revisit in six months.

Your CISSP doesn’t make you an AI governance expert. It makes you the person whose existing risk discipline transfers fastest to the new problem. The frameworks are different. The job is the same.

Sources

Primary standards and frameworks

• ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system. ISO/IEC JTC 1 / SC 42, December 2023. https://www.iso.org/standard/42001

• ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection, Information security management systems, Requirements. ISO/IEC JTC 1 / SC 27, October 2022. https://www.iso.org/standard/27001

• ISO/IEC 27006:2015 (and revisions), Requirements for bodies providing audit and certification of information security management systems. ISO/IEC JTC 1 / SC 27. https://www.iso.org/standard/27006

• ISO/IEC 42006:2025, Information technology, Artificial intelligence, Requirements for bodies providing audit and certification of artificial intelligence management systems. ISO/IEC JTC 1 / SC 42, published September 4, 2025. https://www.iso.org/standard/42006. National adoption available as BS ISO/IEC 42006:2025 via BSI: https://knowledge.bsigroup.com/products/information-technology-artificial-intelligence-requirements-for-bodies-providing-audit-and-certification-of-artificial-intelligence-management-systems

• NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0). National Institute of Standards and Technology, January 26, 2023. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf

• NIST AI RMF Playbook (companion to AI 100-1, 72 subcategories with suggested actions). https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook

• NIST AI 600-1, Generative AI Profile. NIST, July 2024. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

• EU AI Act, Regulation (EU) 2024/1689. Entered into force 1 August 2024.

https://artificialintelligenceact.eu/

Survey and reference data

• ISO/IAF CASCO, The ISO Survey of Management System Standard Certifications, 2024, Explanatory Note. September 2025. https://iafcertsearch.org/services/iso-survey

• ISC2 Cybersecurity Workforce Study (2025) and Exam Guidance for AI (April 2, 2026), via ISC2 Insights. https://www.isc2.org/research

Secondary commentary (with vendor caveats)

• Modulos, NIST AI Risk Management Framework: the engineering spec for AI risk. Vendor blog, April 17, 2026. (Modulos sells an AI governance platform supporting both frameworks, and the framing reflects that.)

• NIST AI RMF to ISO/IEC FDIS 42001 AI Management system Crosswalk. Community-submitted, hosted on NIST AI Resource Center. PDF: https://airc.nist.gov/docs/NIST_AI_RMF_to_ISO_IEC_42001_Crosswalk.pdf. Listed on the AIRC crosswalks page: https://airc.nist.gov/airmf-resources/crosswalks/. NIST hosts but does not endorse the crosswalk. FDIS-stage clause references predate the December 2023 ISO/IEC 42001:2023 publication.

The framework is voluntary and non-certifiable. Nobody can audit you against it, and you can self-claim alignment, which is where ISO 42001 comes in as the certifiable counterpart. What RMF gives you is a shared vocabulary.

NIST also publishes a companion document called the AI RMF Playbook. The framework itself is about 40 pages of principles. The Playbook runs over 140 pages of suggested actions, transparency questions, and reference resources for each piece of the framework. If you only read the framework, you get the abstractions, while most of the operational guidance is in the Playbook.

This article walks through the four functions at the heart of the framework, using Playbook content to sharpen what each function actually requires.

The four functions at a glance

NIST AI RMF organizes everything around four functions: GOVERN, MAP, MEASURE, and MANAGE. They aren’t sequential steps. They’re roles in a system that runs continuously.

GOVERN sits across the whole framework. It’s the organizational substrate: policies, accountability, culture, and oversight that make the other three functions possible. MAP, MEASURE, and MANAGE, then run in a loop. MAP establishes the context for understanding a specific AI system. MEASURE tests it against the trustworthiness characteristics NIST defines. MANAGE turns those measurements into prioritization decisions, kill-switch procedures, and disclosures to affected parties. The outputs of all three feed back into GOVERN, which uses them to update policies, roles, and culture over time. The framework is iterative, not linear.

GOVERN

GOVERN is where the framework starts and where most organizations underinvest. It’s the function that establishes who’s responsible for what, what risks the organization is willing to take, how AI work fits into existing accountability structures, and how culture supports raising concerns rather than burying them.

Read more

The CISSP exam outline, which has been in effect since April 15, 2024, already includes some AI-specific references in several domain objectives. ISC2 didn’t bolt on a new “AI Security” domain. Instead, they distributed AI concepts throughout the existing structure, as they’ve always handled emerging technology. The difference this time is scale because AI touches every domain, and the Exam Guidance makes that explicit.

Here’s my take on what changed, and what you need to know.

The Dual Pattern

Across all eight CISSP domains, AI shows up in two ways:

1. AI as a system that needs to be secured. Protecting models, training data, and AI infrastructure from attack: think data poisoning, prompt injection, adversarial inputs, and model theft.

2. AI as a tool you use for defense. SIEM/SOAR automation, behavioral analytics, anomaly detection, and AI-powered vulnerability scanning.

Understanding which one is being asked will help you reason through unfamiliar scenarios on the exam.

What’s New in Each Domain

Here are some AI-related concepts from each domain that I think are the most likely to feel new or foreign to CISSP candidates.

Domain 1: Security and Risk Management

The new concept: AI supply chain risk.

You already know third-party risk management. The AI version asks the same governance questions, but about different things. Where does the training data come from? What model is your vendor using, and who trained it? What happens when the model is updated and its behavior changes? CISSPs are now expected to assess AI service providers with the same rigor applied to any critical vendor. The questions are different (data provenance, bias documentation, model transparency), but the framework is the one you already know from Domain 1.

Domain 2: Asset Security

The new concept: AI-specific asset classification.

Training datasets, pre-trained models, and model weights are now assets that need to be classified and protected. A pre-trained model is intellectual property. A training dataset may contain PII that triggers privacy mandates. Model weights are a theft target. If your organization’s data classification scheme doesn’t account for these asset types, it has a gap.

Domain 3: Security Architecture and Engineering

The new concept: Prompt injection as an architectural concern.

This is the domain where the technical specifics of AI attacks intersect with traditional security architecture. Prompt injection is the AI equivalent of SQL injection: untrusted input that manipulates the system’s behavior. But the defense isn’t just input validation. It includes architectural decisions about model isolation, output verification, and Explainable AI (XAI), which is the ability to audit why a model produced a specific output. ISC2 frames XAI as a security architecture requirement, not just a nice-to-have.

Domain 4: Communication and Network Security

The new concept: Network segmentation for AI workloads.

AI training clusters generate traffic patterns distinct from those of standard enterprise applications and pose unique lateral movement risks. The exam outline now expects CISSPs to understand micro-segmentation and Zero Trust Architecture as applied to AI environments. The goal is the same as always (prevent lateral movement from a compromised interface), but the specific architecture for isolating AI training environments from production networks is new territory.

Domain 5: Identity and Access Management

The new concept: Non-Human Identity (NHI) governance.

This one is significant. The CISSP now covers managing identities for AI agents and automated service accounts. That means understanding how to apply the Principle of Least Privilege to a system that might try to escalate its own permissions during learning or execution. It also means understanding the dual problem: you’re securing the AI’s identity (what credentials it has, who owns them, and whether it can escalate) while also using AI to make IAM more resilient (behavioral biometrics, adaptive authentication, anomaly detection in login patterns).

But credential controls alone don’t solve the problem. As Chris Hughes points out, agents don’t just exist as identities. They use identities to take action. An agent manipulated at runtime through prompt injection or a poisoned tool response will request access through valid paths, receive a properly scoped token, and act exactly as policy allows. Every identity control passes. The breach still happens. The threat model has shifted from “who holds the key” to “who is influencing the decision,” and static permission models weren’t designed to answer the latter.

For context on why this matters: a 2025 CSA survey of 383 security professionals found that only 8% were highly confident their legacy IAM tools could handle AI and NHI risks. Only 22% had formal policies for creating or removing AI identities. Making this more than a hypothetical gap.

Domain 6: Security Assessment and Testing

The new concept: Red teaming for AI systems.

Traditional penetration testing looks for software bugs and misconfigurations. AI red teaming tests different things: model robustness against evasion attacks, susceptibility to training data extraction, and “logic flaws” in the model’s output that an adversary could exploit. The Exam Guidance makes clear that CISSPs should understand these as distinct assessment methodologies, not just variations of traditional pen testing.

Domain 7: Security Operations

The new concept: Model drift as a security operations concern.

Model drift is what happens when an AI model’s performance degrades over time. Data scientists have always cared about this. What’s new is ISC2 framing it as a security operations problem. A model that’s drifting might be degrading naturally or under adversarial influence. SOC teams need to monitor AI systems as production assets, watching for drift as a potential indicator of compromise rather than just a performance issue.

Domain 8: Software Development Security

The new concept: AI-generated code risks.

As organizations adopt AI-generated code to an ever-larger degree, the CISSP is emphasizing the role of security in understanding specific risks. Hallucinated dependencies, where AI references packages that don’t exist (and an attacker creates a malicious package with that name). Insecure defaults in generated code. Leaked training data in code suggestions. And the AI/ML supply chain: the security of the ML libraries and frameworks your software depends on.

How to Prepare

If you’re studying for the CISSP right now, here’s some practical advice.

Don’t panic about depth. The CISSP is a management-level certification. You don’t need to know how to build a prompt injection defense, but you need to understand that prompt injection exists, that it’s an architectural concern, and that the defense involves input validation, model isolation, and output verification. As with other topics, you need to know what and why, not how to implement.

Distinguish the guidance from the outline. The Exam Guidance doesn’t always separate “the exam outline says this” from “here’s how to think about this in an AI context.” When it claims the outline integrates AI into shared responsibility models for cloud-based AI services, it’s most likely reading an AI lens onto an existing objective that already covers shared responsibility generally. The exam outline is the authoritative source for what’s explicitly tested. Read the Exam Guidance as an interpretive layer. It shows you how existing CISSP concepts apply to AI scenarios, rather than a guarantee that every domain now has standalone AI questions. To know what’s on the exam, check the outline. To understand how to think about it, read the guidance.

Learn the vocabulary. Several AI concepts show up across multiple domains. If you understand these terms, you can reason through scenarios even if the specific question is unfamiliar:

• Data poisoning: Corrupting training data to manipulate model behavior

• Model drift: Degradation of model performance over time (natural or adversarial)

• Prompt injection: Untrusted input that changes an AI system’s intended behavior

• Adversarial attacks: Inputs specifically crafted to cause model misclassification

• Non-Human Identity (NHI): Credentials used by AI agents and automated systems

• Explainable AI (XAI): The ability to understand and audit AI decision-making

• Shadow AI: Unauthorized use of public AI tools by employees

Map AI to frameworks you already know. The ISC2 Exam Guidance references several frameworks that connect AI security to traditional CISSP material:

• NIST AI RMF (AI 100-1): The voluntary US framework for AI risk management. Four functions: Govern, Map, Measure, and Manage. This maps directly to Domain 1’s risk management concepts. If you understand NIST RMF, the structure is familiar.

• ISO/IEC 42001: The certifiable AI management system standard. Think of it as ISO 27001 for AI. If you understand the ISO 27001 PDCA cycle, you understand the structure of 42001.

• OWASP Top 10 for LLMs: The authoritative vulnerability taxonomy for LLM applications. Prompt injection is #1. If you know the traditional OWASP Top 10, this is the AI equivalent.

Use the dual pattern as a study filter. When you encounter an AI topic, ask yourself: Is this about securing an AI system or about using AI for defense? That distinction will help you orient quickly to exam questions.

Read the Exam Guidance itself. It’s 25 pages, free, and directly from ISC2. The CISSP section is pages 8 through 10. It won’t tell you exactly what the exam will ask, but it tells you what ISC2 considers testable. That’s as close to a study guide as you’ll get from the source.

The Bigger Picture

ISC2 folded AI into every existing credential because that’s how AI works in practice. It isn’t a separate discipline. It changes how you manage risk, classify assets, design architecture, manage identities, test systems, run a SOC, and secure software.

The CISSP has always been about breadth. Knowing enough about every domain to make good security decisions. AI extends that expectation.

If you’re a current CISSP holder, this is CPE territory. Pick a framework (NIST AI RMF is a good starting point), learn the vocabulary, and start mapping AI risks to the domains you already understand. While the assets and threats may be different, the governance structure you’ve learned still applies.

ISC2 has built out a dedicated learning track for CISSP holders who want to go deeper. The ISC2 AI Security Certificate is a standalone credential covering AI attack recognition and mitigation, AI security framework comparisons, and strategies for balancing AI tools with human decision-making (essentially the layer above what the base CISSP AI integration requires). For something more targeted, the AI Security Express Courses cover specific topics like Generative AI, Secure Development, and AI Integration and Monitoring in a shorter format. If you have five or more years of experience and want to work through the strategic picture with peers, ISC2 also runs in-person and virtual Securing AI Workshops designed for mid- and senior-level practitioners. The data support doing something: according to ISC2’s 2025 Cybersecurity Workforce Study, 70% of CISSPs are already pursuing additional AI qualifications. The professionals who close this gap now will be the ones asked to lead the governance conversations in their organizations.

If you’re a candidate, the governance frameworks you’re studying are the foundation for AI security. The risk management processes, classification schemes, access control principles, and assessment methodologies all apply. What’s new is the threat surface inside each one: the poisoning vectors, the non-deterministic outputs, the identity challenges that come with autonomous agents. The Exam Guidance information gives you a map of what to learn.

The structure you’ve studied is the starting point.

CISSP relevance: All 8 domains. Domain 1 (AI governance, supply chain risk), Domain 2 (AI asset classification), Domain 3 (prompt injection, XAI), Domain 4 (AI network segmentation), Domain 5 (NHI governance), Domain 6 (AI red teaming), Domain 7 (model drift monitoring), Domain 8 (AI-generated code risks).

There are two specific guides that help answer that question more directly. The first is the OWASP Securing Agentic Applications Guide (80 pages, July 2025), an engineering manual from the same team behind the Agentic Top 10. The second is Casaba Security’s Agentic AI Security Guide (v1.2, April 2026), written by a penetration testing firm based on findings from actual engagements.

Between the two, you get both the framework and the field report. Here’s what I think matters, organized around the risks that show up in practice and the architectural decisions that address them.

A useful starting point

Before getting into specifics, one concept from the OWASP guide is worth mentioning first. The guide decomposes “an agent” into six Key Components (KC1 through KC6): the language model (KC1), orchestration and control flow (KC2), reasoning and planning (KC3), memory (KC4), tool integration (KC5), and the operational environment (KC6). Each has its own attack surface, and the risks below target specific components. This matters because you can’t secure a system you haven’t decomposed. I’m betting that teams mapping their agent to these six components will find gaps in KC4 (memory) and KC6 (operational environment), the components that existing threat models don’t cover well.

Untrusted Data Reaching the Control Plane

The risk that underlies almost everything else in agentic security is indirect prompt injection, what the research community calls XPIA. Most people think of prompt injection as a user typing something malicious into a chat box. The indirect version is harder to spot. The injection comes from the data the agent processes, not from the user: documents in RAG indices, tool outputs, emails, web pages, API responses, CRM records. Anywhere the agent reads untrusted data, an attacker can plant instructions.

Casaba breaks XPIA into four attack surfaces. Perception-layer injection hides instructions in content the agent ingests, but humans can’t see (e.g., CSS display: none, HTML comments, aria-label attributes). Research shows these alter agent outputs in 15-29% of tested cases. Instead of injecting explicit commands, the attacker fills the source content with confident, authoritative language that leans in a particular direction. The agent isn’t being told what to say. But when most of what it reads carries the same framing, its synthesis reflects that framing. There’s no payload to detect because the attack is in the aggregate rather than in any single document.

Memory and learning attacks corrupt stored context, so the compromise persists across sessions. Action-layer attacks embed explicit instruction sequences in external resources that, when ingested, override safety alignment.

The architectural response: separate the data plane from the control plane. This is the single most important design decision. The OWASP guide highlights Google’s CaMeL as the cleanest conceptual model. A privileged LLM receives only trusted inputs and generates control flow (which tools to call, in what order). A quarantined LLM processes untrusted data (web content, email bodies, retrieved documents) and has no access to tools. Prompt injection in a retrieved document hits the quarantined LLM, which can’t invoke tools. The injection has nowhere to go. CaMeL also isolates memory: the quarantined LLM’s context doesn’t leak into the privileged LLM’s memory, which prevents poisoned data from influencing future control flow decisions.

CaMeL remains a research architecture. A follow-up paper (May 2025) adds prompt screening, tiered-risk access, and output auditing, but no production deployments have been published. What is shipping in production is the underlying principle: external enforcement layers that sit between the agent and its tools. Check Points, Zenity’s runtime agent monitor, Lasso Security’s MCP Gateway, and Airia’s model-agnostic control plane all enforce the same boundary: untrusted content can’t directly trigger tool invocations. They do it through runtime policy engines and gateways rather than a second LLM, but the design principle is identical.

What to watch for: Any workflow where an agent retrieves or processes content from sources outside your direct control. Email summarizers, web research agents, document analyzers, RAG-based assistants. All are at high risk for XPIA.

Read more

Because here’s what ATLAS doesn’t cover: it can’t tell you how an attack might unfold in a system you’re building or defending right now, especially if that system involves autonomous agents with persistent memory, tool access, and the ability to spawn sub-agents. For a traditional web application, a retrospective TTP catalog is usually enough. The architecture is stable, and past patterns predict future ones with reasonable accuracy. Agentic AI doesn’t behave that way. An autonomous agent that can browse the web, call external APIs, write files, and delegate tasks to other agents creates an attack surface that’s still generating its first wave of documented incidents. The ATLAS case study record hasn’t caught up with what’s already in production.

That’s where MAESTRO comes in.

What MAESTRO Is and What Problem It’s Actually Solving

MAESTRO (Multi-Agent Environment, Security, Threat, Risk, and Outcome) was published in February 2025 by Ken Huang, co-chair of the CSA AI Safety Working Group. The framework’s central premise is that traditional threat modeling approaches weren’t designed for systems that make autonomous decisions, adapt behavior over time, and coordinate with other agents across trust boundaries.

That’s not a provocative claim. STRIDE models systems as static data flows between defined components (relying on Data Flow Diagrams to visualize a system at a specific point in time). PASTA’s attack simulation model assumes the system being analyzed has deterministic, bounded behavior, with no mechanism to represent a system that autonomously modifies its own goals or behavior at runtime.

Neither has a mechanism to address threats arising from goal misalignment, autonomous decision-making, or multi-agent collusion. A peer-reviewed 2025 study (Zambare, Thanikella, and Liu at Texas Tech University) reviewed existing frameworks and directly confirmed the gap, noting that STRIDE “does not model emergent behavior, cognitive reasoning of AI agents very well.” The OWASP Agentic Security Initiative reached the same conclusion, ultimately endorsing MAESTRO as a comprehensive extension of STRIDE for handling Agentic AI.

MAESTRO’s answer is a seven-layer reference architecture, each with its own mapped threat categories: Foundation Models (L1), Data Operations (L2), Agent Frameworks (L3), Deployment and Infrastructure (L4), Evaluation and Observability (L5), Security and Compliance as a vertical layer that cuts across all others (L6), and Agent Ecosystem (L7).

What that structure forces, and what classical frameworks don’t, is cross-layer analysis. Take a LangChain-based agent with RAG access. STRIDE treats it as a system with data flows. MAESTRO requires you to analyze it at L2 (the vector database is a poisoning surface), L3 (the framework itself is a supply chain risk), and L7 (the agent faces tool manipulation and identity attacks in the ecosystem it operates in). In other words, STRIDE asks, “Can someone tamper with the data moving through this system?” MAESTRO asks, “Can someone corrupt what the AI knows, compromise the tools it was built with, and manipulate who it trusts in the world it operates in,” and treats each of those as a separate, distinct problem requiring separate analysis.

Each layer carries its own threat categories, and a compromise in one doesn’t stay contained. Researchers at Texas Tech confirmed this empirically: poisoning a single memory file in L2 caused measurable performance degradation in L4 and L5 without altering any system logic. In essence, someone edited a JSON file, inserting fake high-severity attack entries that the agent reads. The agent didn’t break, but it degraded silently. The attack entered at L2 (data operations — the memory file). It affected L3 (the tuning module changed its behavior). That caused resource exhaustion at L4 (infrastructure) and degraded observability at L5 (the monitoring system itself became less responsive). One layer’s compromise propagated through three others without directly touching any of them. STRIDE would model the JSON file as a data integrity issue at one point in the system. It wouldn’t predict that corrupting the file would degrade the monitoring infrastructure two layers away.

The striking fact is that a single JSON file with no code access caused an autonomous security agent to silently misjudge its environment and waste resources defending against nonexistent threats, while potentially missing those that did exist.

That’s the kind of threat STRIDE doesn’t surface. MAESTRO does.

Where the Real Threats Live

Not all seven layers carry equal risk. Three of them deserve immediate attention.

L2 (Data Operations) is where the most operationally mature threat activity currently resides. ATLAS’s Resource Development tactic shows 9 of 13 rated techniques are “Realized”, meaning adversaries have already industrialized data poisoning against retrieval systems. Any organization running a production RAG pipeline should treat L2 threat modeling as urgent, and the Texas Tech cascade described above began here, with a single poisoned file.

L7 (Agent Ecosystem) is where agentic AI diverges most sharply from everything that came before. Agent impersonation, tool squatting, rug pull attacks against MCP integrations, and compromised discovery registries, none of which have classical equivalents. SesameOp (ATLAS case study AML.CS0042) confirmed adversaries are already using legitimate AI service APIs as covert C2 channels. That’s a fully “Realized” L7 attack chain. What makes L7 defense especially difficult is the governance baseline organizations are actually starting from. A 2025 CSA survey of 383 IT and security professionals found that 51% have no clear ownership of AI identities, and over 16% don’t track when new AI credentials are created. MAESTRO’s L7 threat categories assume someone is watching the identity layer. Most organizations aren’t.

L1 (Foundation Models) receives less operational attention, but two threat classes are particularly relevant for compliance-sensitive environments. Backdoor attacks embed hidden triggers in fine-tuned models that remain dormant until a specific input activates them. Membership inference attacks let an adversary determine whether specific records were used in training. That’s a direct HIPAA or GDPR exposure for any organization fine-tuning on sensitive data.

Using ATLAS and MAESTRO Together

The two frameworks solve different parts of the same problem. MAESTRO generates a systematic threat list from the architecture up. ATLAS tells you which items on that list adversaries have confirmed in the wild.

The workflow that combines them is straightforward. Take each layer of your system and ask: what could go wrong here? That’s the MAESTRO step. Then check ATLAS for each threat you’ve identified: has anyone actually done this? If a technique is tagged “Realized,” it moves to the top of your risk register. If it’s “Demonstrated” or “Feasible,” it still matters, but it’s not yet confirmed in the wild. The CSA Agentic Red Teaming Guide then provides concrete test procedures you can run against each layer to validate whether your system is actually exposed.

The Texas Tech study is the clearest argument for why you need both. The L2-to-L4/L5 cascade, the researchers confirmed, had no corresponding “Realized” ATLAS technique at the time of publication. MAESTRO predicted the attack class. ATLAS didn’t have the incident. That’s exactly where the combined methodology earns its keep.

One honest caveat: 46 of ATLAS’s 167 native techniques are unrated (as of this writing), and most are newer agentic additions. The “Realized” filter works well for L2 and L4 threats. For L7, it’s less discriminating. Treat more L7 items as “Demonstrated” rather than “Realized” until the incident record catches up.

What This Pairing Doesn’t Solve

MAESTRO doesn’t yet have a formal specification. No versioning, no conformance testing, no defined scoring methodology that I could find. The AgentRFC framework from Dartmouth and Palo Alto Networks produced companion security principles with formal conformance language. MAESTRO doesn’t operate at that level of rigor, and practitioners building repeatable assessment processes will hit that ceiling.

Both frameworks share a documented scope gap. ATLAS explicitly excludes malicious use of AI against non-AI targets, and MAESTRO follows the same boundary. AI-enhanced phishing, AI-automated vulnerability discovery, and deepfake-assisted social engineering aren’t covered. If your threat model needs to include those vectors, you’re working outside both frameworks.

There’s also no native scoring engine. OWASP’s Agentic Vulnerability Scoring System needs to be applied separately for quantitative prioritization.

And the constraint that no framework resolves: the CSA NHI survey found only 8% of organizations are highly confident their legacy IAM can handle AI and NHI risks, and 24% take more than 24 hours to revoke a compromised credential after an exposure event. A rigorous threat model is only as useful as the organization’s ability to act on it. Closing that operational gap is a separate, harder problem.

Where to Start

The combined methodology reduces to three questions applied to any AI system your organization operates.

1. What does your AI system actually touch? Map your system against MAESTRO’s seven layers. In practice, this means listing: which foundation model you use (L1), what data sources feed it and where they’re stored (L2), which framework or platform it’s built on (L3), where it runs and who manages that infrastructure (L4), how you monitor its behavior and measure its performance (L5), and what external tools, APIs, or other agents it can access (L7). Many teams will discover layers they haven’t thought about as attack surfaces, particularly L2 (the data the AI trusts) and L7 (the tools and services it connects to).

2. Which of those layers have confirmed attacks in the wild? Cross-reference your layer map against ATLAS. Start with L2: nine of thirteen techniques in ATLAS’s Resource Development tactic are “Realized,” meaning adversaries have demonstrated them in real incidents. If your AI system ingests external data — retrieval-augmented generation, fine-tuning on user data, or any pipeline that feeds information to the model — that’s your most evidence-backed risk. Any layer where ATLAS shows “Realized” techniques goes to the top of your risk register.

3. Can you actually detect and respond if something goes wrong? This is where most organizations hit the real gap. MAESTRO’s L5 (Evaluation and Observability) asks whether your monitoring can detect a compromised AI agent, not just whether the system is up, but whether it’s making trustworthy decisions. And the governance question is unavoidable: the CSA NHI survey found 51% of organizations have no clear ownership of AI identities. If no one owns the AI identity layer, your threat model describes a problem that nobody is accountable for fixing.

For CISSP holders, questions 1 and 2 fall under Domain 1 (Security and Risk Management). Question 3 spans Domain 8 (Software Development Security) for the monitoring and testing controls, and Domain 1 again for the governance structure. The CSA Agentic Red Teaming Guide provides executable test procedures for each MAESTRO layer once you’ve completed the mapping.

Assign ownership first. Then model the threats.

The attack wasn’t sophisticated in any traditional sense. No CVE was exploited. No credentials were stolen. No network was breached. It was simply provided inputs through the interface the system was designed to accept, and the model’s own learning mechanism turned those inputs into a weapon against itself. If you tried to map that attack to MITRE ATT&CK at the time, you’d come up empty. The attack surface wasn’t an endpoint or a network. It was the model’s relationship with its training data.

That gap, the space between what ATT&CK covers and what AI systems actually expose, is exactly what MITRE ATLAS was built to fill.

ATLAS stands for Adversarial Threat Landscape for Artificial-Intelligence Systems. It’s a structured knowledge base of adversary tactics, techniques, and real-world case studies specifically targeting AI and machine learning systems. Think of it as ATT&CK’s purpose-built extension into territory that traditional threat frameworks never modeled: data pipelines, model architectures, inference APIs, and training processes. As of today, ATLAS documents 16 tactics and 167 techniques across 57 case studies, with 35 mapped mitigations, and the framework is actively growing.

Read more

By The Cyber Leader | balancedsec.com

In August 2025, ISACA did something long overdue. They launched a certification built specifically for security managers who need to deal with AI. Not data scientists. Not ML engineers. Security managers.

The timing wasn’t subtle. Organizations were already deploying AI systems across their operations, and most had no one formally responsible for securing those deployments. ISC2’s 2025 AI Adoption Survey found that over one-third of surveyed cybersecurity professionals cited AI as the biggest skills shortfall on their teams, and 42% said they’re actively exploring or testing AI-focused security tools. ISACA’s response was the Advanced in AI Security Management (AAISM): a credential designed to sit atop existing security management expertise and extend it into AI governance, risk, and technical controls.

I believe it’s the first certification that treats AI security as a management and leadership discipline rather than as a demonstration of technical knowledge. For CISSP or CISM holders, it’s the most directly relevant option on the market right now. But “first” doesn’t automatically mean “complete,” and the certification has limitations worth understanding before you charge the card.

Read more

And for good reason — we’re all feeling it. In the face of an increasing rate of change and a plethora of new tools, securing what is already in adoption can feel overwhelming. ISC2’s 2025 AI Adoption Survey found that over one-third of surveyed cybersecurity professionals cited AI as the biggest skills shortfall on their teams, and 42% said they’re actively exploring or testing AI-focused security tools. But the good news is that you don’t need to start from scratch. Your CISSP already covers substantial ground in organizational security, risk management, and governance, which is exactly the foundation you need to develop real expertise in securing AI. The work is to figure out which gaps your next credential should fill and avoid paying for knowledge you already have.

Read more

So I just went down the rabbit hole of ISC2’s documentation to figure out what I’m up against. The CPE maintenance system is more flexible, more forgiving, and more useful than I expected. It just takes a little effort up front to understand. This is the guide I wish I’d had the day after the exam.

When ISC2 activates your certification, a three-year clock starts. On it: 120 CPE credits, a $135 annual maintenance fee, and enough administrative detail to trip up people who aren’t paying attention.

The Numbers (And the One Everyone Gets Wrong)

The CISSP requires 120 CPE credits over a three-year cycle, split between two groups:

• Group A credits: 90 over three years (domain-related activities)

• Group A or B credits: 30 over three years (can be either type)

You’ll see “40 credits per year” repeated everywhere. Here’s what most guides don’t tell you: that number is suggested, not mandatory. ISC2’s Certification Maintenance Handbook is explicit. There is no annual minimum for CISSP holders. Associates have a hard annual requirement, but full CISSP holders could technically earn 0 in year one, 0 in year two, and 120 in year three. I wouldn’t recommend it (this is a “don’t do as I do” statement), but the flexibility exists.

One more mechanic that flies under the radar: rollover credits. If you overshoot during the final six months of your cycle, up to 40 Group A credits automatically carry into your next cycle. Only Group A, only from the last six months. But it’s a free head start that most people leave on the table because they don’t know it exists.

The Annual Maintenance Fee is $135, due on the anniversary of your certification date (not January 1, which catches some people who set calendar reminders on the wrong date). If you hold multiple ISC2 certifications, one AMF covers all of them.

Group A, Group B, and the Category Nobody Mentions

Group A includes activities related to the eight CISSP CBK domains, such as conferences, courses, webinars, writing articles, teaching security topics, attending ISC2 chapter meetings, participating in standards development, and volunteering in security-related roles. One firm rule: normal paid job duties don’t count, no matter how security-focused. CPEs capture learning beyond the day job.

Group B covers professional development outside security domains, such as leadership training, project management, and non-security conferences. The cap is 30 credits, and it arrives faster than you’d expect. A PMP course plus a leadership program plus a couple of conferences, and you’re at the ceiling. Group B doesn’t apply to Associates or CC-only holders.

Then there’s Unique Work Experience, a Group A subcategory that barely gets discussed. It covers one-time projects during working hours that fall outside your normal responsibilities. A network admin leading a tabletop exercise for executives, or a security analyst pulled into a special zero-trust evaluation. Each entry caps at 10 credits and requires a 250-word description if audited. The test: Is this genuinely different from what you do every day?

Activity Caps: The Reference Table You’ll Want to Bookmark

Not all credits are created equal. These caps matter because it’s easy to assume that five blog posts earn as much as five journal articles. They don’t.

Authoring & Content Creation

Tip: writing five blog posts doesn’t earn the same as five journal articles. Check the caps before planning your strategy.

Self-Study (Reading)

Note: A 500-page textbook earns the same 5 CPE credits as a 200-page book. Self-study is valuable, but it’s not the most efficient way to reach 120 credits.

Education & Teaching

Note: Education has a no-category cap. You could technically earn all 120 credits through courses alone (although you’d need at least 3 separate entries, with a 40-max per entry).

The Free Credit Strategy (Start Here)

A significant chunk of your requirement can be earned free through ISC2’s own programs, and many auto-submit to your account with audit-exempt status.

ISC2 webinars on BrightTALK are free, auto-submitted, and pre-cleared for audits. But auto-submission only works if your ISC2 member ID was entered when you first registered for the BrightTALK channel. If you signed up before you were a member, or skipped that field, credits won’t post. Fix this now. Discovering the problem at the end of year two is unpleasant. Either delete your BrightTALK account and recreate it with your member ID, or download viewing certificates and submit them manually.

Beyond webinars, ISC2 offers several other ways to earn credits, including Skill-Builders and Express Courses (free), Insights quizzes (2 CPEs each), Security Congress (28+ CPEs from a single event), and credit for participating in JTA surveys or exam development workshops. Using these programs strategically can build a strong CPE foundation without spending beyond your AMF.

The Traps Worth Knowing About Early

These catch smart, busy professionals who don’t know the nuance.

Backloading is legal but risky. The flexibility to skip years one and two is real, but the endpoint is fixed, and the 90-day grace period isn’t designed for people who haven’t started.

The Group B ceiling sneaks up. A single project management certification and a couple of leadership workshops can eat most of it.

Regular job duties don’t count. Even after a year deep into security operations, it doesn’t generate CPE credits.

Upload documentation at submission time. Two minutes now versus a headache 18 months later when an audit notification arrives.

Know your AMF anniversary date. It’s the anniversary of your certification, not the calendar year. A lapsed AMF suspension is treated the same as a CPE shortfall.

When Things Go Wrong (And the Rungs on the Way Down)

The system has more built-in recovery than most people realize. When a cycle ends without 120 credits, there’s a 90-day grace period to earn and submit. Three months is enough to close most gaps.

Miss that, and suspension kicks in. You can’t claim the designation, your badge is disabled, and your name disappears from ISC2’s Member Verification tool. That last one stings professionally. Clients and employers check it.

The suspension lasts up to two years, and after that, the certification is terminated. Reinstatement requires 5 CPE credits in each of the eight domains, plus 40 in your primary domain, for a total of 120 credits within 12 months. Or you retake the exam. Associates only get the exam option.

The point isn’t to scare you. The system has rungs on the way down, and each one provides a chance to climb back.

Making It Actually Worth Your Time

Here’s the honest framing. The CPE system is self-reported and honor-based. A motivated person can game it. But a motivated person can use it as well.

Start by reviewing your certification anniversary date in the ISC2 member dashboard. This date determines your renewal timeline, including when CPE submissions and AMF payments are due. Pay the $135 annual fee on your certification anniversary. Even if you hold multiple ISC2 certifications, you only pay it once per year. Keeping a steady rhythm with CPE credits makes renewal much easier (something I’m reminding myself of as well).

Cybersecurity moves fast, and the CPE structure helps keep you current in ways many professionals might otherwise overlook. ISC2’s chapter network can be genuinely useful as a peer community. The free webinars often feature current topics from practitioners rather than vendor pitches. The Skill-Builders also give you a reason to dig into topics many of us might otherwise skip.

Whether CPEs become real professional development or administrative overhead depends on the person holding the certification. The structure is there, and it’s more forgiving than it looks from the outside. Use it well.

This is where security control frameworks can help. They can provide a more formal, structured way to implement a security strategy that governs and protects organizational assets. They help align goals, guide decisions, and provide the basis for communication with internal stakeholders and external regulators.

So what is a security control framework? At a high level, they provide a roadmap for creating policies, procedures, and technical safeguards organized by categories. They can include things like access control, incident response, encryption, asset management, and security awareness training.

Some frameworks define exactly what must be implemented, such as PCI DSS, while others, like NIST CSF, guide organizations to design controls based on risk. Highly regulated industries often require the certainty of prescriptive standards, whereas risk-based models provide flexibility to adapt and evolve securely.

Despite their differences in scope, audience, and cost, nearly all security control frameworks share the same structural DNA. Once you learn these building blocks, you’ll recognize them in most frameworks you encounter.

A typical framework includes components such as:

1. Controls: Specific measures used to mitigate risk. Many frameworks organize safeguards into several domains: administrative, technial and physical controls. Administrative controls provide general guidance for policies, procedures, and security awareness training. Technical controls are the tools and configurations, such as firewalls, encryption, MFA, logging, and endpoint detection. Physical controls cover the tangible stuff, such as door locks, security cameras, access badges, and environmental protections. Any given framework may slice these categories differently, but the underlying logic is the same.

2. Maturity models and assessment tiers: Models and tiers help organizations figure out where they stand and where they need to go. CIS Controls, for instance, uses Implementation Groups. NIST CSF v2.0 uses Tiers: Partial (ad hoc, reactive), Risk Informed (some awareness but inconsistent), Repeatable (formally approved processes), and Adaptive (continuously improving based on lessons learned). COBIT applies a six-level capability model (0 through 5) to each of its 40 governance and management objectives.

3. Governance structure: Governance serves as the strategic backbone that aligns security activities with an organization’s mission and risk appetite. It ensures security measures support specific business goals (e.g., growth or innovation) and provide adaptability for a business’s unique needs. It also helps answer important ownership questions, such as who owns cybersecurity risk at the board level? Who has the authority to approve exceptions to controls? And who is responsible for verifying that controls actually work?

4. Continuous monitoring mechanisms: We’re not done after implementation. Continuous monitoring provides a feedback loop to adapt to evolving threats. None of these frameworks is meant to be implemented and left on a shelf. Continuous monitoring helps to create a cycle that updates and implements new controls, tests them, finds gaps, fixes them, and repeats.

Let’s take a look at the major frameworks you should understand for the exam

Let’s look in more detail at the frameworks most likely to show up on the CISSP exam.

Read more

You Already Threat Model. You Just Don’t Call It That.

You own a retail store. Before opening day, you think about potential merchandise loss from shoplifting. You think about which products are expensive enough to warrant security tags. You think about whether the cheap lock on the back door is good enough, or whether something heavier is warranted. You don’t have a spreadsheet. But you’re doing something real: systematically thinking about what can go wrong, how badly, and what it’s worth spending to prevent it.

That’s threat modeling. Every formal framework we’re about to cover does this same thinking with more structure, more rigor, and a shared vocabulary. A vocabulary that lets teams see the same problems the same way.

As a CISSP exam candidate, you should be familiar with these threat models. And while you don’t need to be an expert in each, it helps to understand when they’re used and why.

Remember that the goal of threat modeling is simple: to reduce or eliminate threats.

Software-Centric Models: STRIDE and DREAD

Read more

You’ve looked at custom software before, but the estimates are always high, and your gut says the total cost is ultimately exponentially more. So you keep nursing the spreadsheets, duct-taping formulas, and hoping Bob in engineering never leaves.

This has been the reality for millions of small businesses and independent professionals for decades. Software development is expensive because it’s hard, and it’s hard because computers are fundamentally stupid. They do exactly what you tell them, nothing more, nothing less. The problem is that “telling them” requires speaking their language. Whether that’s Python, JavaScript, SQL, or a dozen others, each has its own grammar, quirks, and ways of punishing you for a misplaced comma.

AI-assisted development looks to help fix this problem. The question is can AI toolsets be trusted in production?

Claude Code, released by Anthropic in early 2025, is a different kind of tool. It’s AI lives in the command line (the text-based interface developers use to talk to their computers). It reads and understands entire software projects, and can plan, write, test, and fix code autonomously. You describe what you want in plain language. It builds it.

Now, if you’re not a developer, you might be tempted to tune out right here. Command line? Codebases? I need to go back to my spreadsheets. Fair enough.

But here’s why you should keep reading. Claude Code is a product built for developers. But the pattern it represents is coming for many professions. Understanding what it can do today tells you something important about what your job, your industry, and your competitive position will look like in two or three years.

This is not really a product review. Not a tutorial. I’m exploring Claude Code because once I started using it, I started to see more of the possibilities. And I’d like to share some of these thoughts.

Ok, so what is Claude Code?

The basics. Claude Code is a tool made by Anthropic, a San Francisco-based AI company that developed the Claude chatbot. If you’ve used AI chat (e.g., ChatGPT, Claude, Gemini, etc.) to answer questions or help with writing, you’ve met the polite, conversational version. Claude Code is its more capable sibling.

You install it on your computer, point it at a folder full of code (or an empty folder, if you’re starting from scratch), and give it instructions using natural language.

The critical difference between a chatbot and Claude Code is that it can act. It is an agent (it can do things on your behalf). It reads your files and writes new ones. It runs commands. It tests whether things work. When something breaks, it reads the error message, figures out what went wrong, and tries a fix. This loop of plan-execute-test-fix can be repeated dozens of times without your intervention.

As I started working with it, I asked for help to do something pretty simple. I pointed Claude Code at my CISSP Study Resources GitHub project, and asked it to identify errors and inconsistencies and automatically fix them. This obviously wasn’t an actual development assignment. I simply wanted to see how it worked in reviewing files, identifying problems, and providing automated solutions. I was pleasantly surprised to find that it identified several types of issues (a few wrong terms and better groupings for certain concepts), created updates, and successfully installed patches.

Agent vs. assistant. Earlier AI coding tools, like GitHub Copilot, work more like aggressive autocomplete. You’re writing code, and the AI suggests the next few lines. Helpful, sure. But you’re still all the driving.

Claude Code is closer to handing the keys over entirely. It doesn’t just suggest. It can plan a sequence of steps, execute them, evaluate the results, and adjust course when things go sideways. If Copilot is a GPS that helps you find faster routes while you drive, then Claude Code is more like the potential Robotaxi service (assuming Robotaxi actually works at some point).

So, why should you care?

Let’s say you’re convinced Claude Code is impressive. You still don’t write code, and you don’t plan to start. So why should you care?

Because the idea underneath Claude Code is leaking into many professions, and the speed of that leak is accelerating.

Last year, Andrej Karpathy (a well-known AI researcher and former head of AI at Tesla) used the term “vibe coding” to describe a different approach to software development. The idea is that you describe what you want in natural language, the AI writes all the code, and you mostly just steer and test the results. You don’t need to understand the code itself. You just need to know what you want and whether the output meets your needs.

This sounds gimmicky until you look at what people are actually building this way. Non-programmers have used tools like Claude to build powerful projects, including browser extensions, personal finance trackers, client scheduling tools, and even full-blown SaaS applications. Projects that would have cost thousands of dollars in freelance developer fees a year and a half ago.

If building custom software becomes as easy as creating a slide deck (we’re not there yet, but trending in that direction), the market dynamics in many industries will change in ways that weren't obvious not long ago.

Consider a marketing analyst at a mid-size company. In the past, if he needed a custom dashboard that pulls data from multiple sources with a specific visualization scheme, he submitted a request to the IT or marketing department. Maybe that request sat in a queue for a while. With tools built on the Claude Code model, he could describe what he needed and have a working prototype the same afternoon. He’s still not a programmer, and he doesn’t need to be. He just needs to articulate the problem clearly and evaluate whether the output solves it.

This means that the person who understands what to build and why starts to matter as much as the person who knows how to build it. That’s a significant reordering of professional value.

A growing number of tech leaders have been arguing that the ability to direct AI agents is becoming a baseline professional skill. Comparable perhaps to spreadsheet literacy in the 1990s. There’s something to this, and the gap between “technical” and “non-technical” roles is genuinely narrowing. Tools like Claude Code are a primary reason.

But we’re not there yet, and we need to separate out the marketing hype from the potential. That’s one of the reasons why I’ve been spending more time with these tools. I started my career as a developer, and I’ve been involved in IT, leadership, and security for a long time. My bias is skepticism for replacing human intelligence with Large Language Model (LLM) prediction-based tools. And I am concerned about the security implications of relying entirely on these tools.

But if you take a step back, tools like Claude Code seem to be improving on a curve measured in months. If you still think of AI based on your last frustrating experience with ChatGPT, it’s time for an update.

The trust problem

So far, the story sounds pretty good. Were’ talking about an AI toolset that can build software from plain language instructions. Non-programmers creating functional tools. Retail and manufacturing companies are designing custom solutions for a fraction of the cost.

I think this is true to a point. But every powerful tool comes with potential problems, and Claude Code’s are worth understanding clearly because many articles don’t spend much time on them.

The fundamental tension is that the thing that makes Claude Code useful is also what makes it risky. It can read your files, write new ones, run commands, and modify your system. That’s not a chatbot generating text in a sandbox. That’s AI with real access to real things on your real computer.

The risk isn’t necessarily that Claude Code will “go rogue” in some sci-fi sense (although there are examples of it making some catastrophic mistakes). The risk is more mundane and, honestly, more likely.

Consider prompt injection, a class of attack that security researchers have been talking about for several years. The basic idea is that an attacker hides malicious instructions inside content that the AI tool will process. If a developer points Claude Code at files that contain a cleverly hidden instruction (say, buried in a comment or a README file), it might follow that instruction without realizing it came from an adversary rather than the user.

Another problem is AI's tendency to hallucinate. In a chatbot conversation, a hallucination is when the model confidently states something that is false, such as a made-up citation, a nonexistent historical event, or a plausible-sounding but wrong answer. It’s annoying, but usually catchable.

In code, hallucination takes a different and more difficult form. Say Claude generates code that looks correct, follows proper syntax, uses the right function names, and seems logically sound. But it contains a subtle bug. Maybe it handles edge cases incorrectly. Maybe it introduces a security vulnerability by failing to validate user input. Maybe it uses an API function that was deprecated two versions ago and will fail silently under specific conditions.

And there is the supply-chain problem. When Claude Code writes your software, you’re not just trusting the code it produces. You’re trusting the entire chain behind it, largely based on open-source software. When you use a package someone else wrote, you’re trusting that person’s competence, security awareness, and good intentions. The catastrophic Log4j vulnerability in late 2021 showed what happens when a widely used library contains a critical flaw. Note that software developers have been dealing with supply chain risk in open-source libraries for a long time. But left on its own, without supervision, Claude Code could amplify this risk.

For enterprises and organizations handling sensitive data, these issues create a governance challenge that existing software auditing practices may not have been designed to address. How do you audit code whose “author” is a statistical model? How do you assign responsibility when something goes wrong? These questions don’t have easy answers yet, although with a bit of irony, AI tools may also be part of the solution.

At present, tools like Claude Code act like a confident junior developer. They are exceptionally fast and knowledgeable about syntax, but they lack the professional judgment, strategic foresight, and security intuition of a senior architect. Agents can struggle with large-scale architectural changes across multiple services, often creating "spaghetti code" or technical debt if not guided by a human who understands the entire system's long-term roadmap.

And while Claude can run automated security reviews, it often misses nuanced flaws like broken business logic, authorization escapes, or zero-day vulnerabilities that don't match its training patterns. Humans still serve as a critical failsafe, intercepting risky commands or unintended actions before they reach production.

Claude Code is improving at reviewing software to identify and fix security issues. I’ll have more to say about that in future articles as I continue to explore.

So, where does that leave us?

I’m just scratching the surface of AI tools and toolsets that can help accelerate development work. Claude Code is a tool that dramatically accelerates software development while introducing a new category of risks that the industry is still learning to manage. I don’t think it’s a scam. It works, often impressively. But “it works” and “you can trust it blindly” are very different statements.

The fact that it’s possible at all for a person without years of programming training to describe a problem in plain language and get functional software back represents a genuine shift in who gets to build things with computers. Not a complete shift. Not a frictionless one. But a real one.

And I think there is a real, positive impact for retailers and manufacturers who want software and functionality tailored to their unique needs at a reduced cost.

Ultimately, however, there is a greater need for enterprise-level software security governance. And these tools still benefit from architect-level software engineering oversight, people who understand the business’s needs and can guide the development process.

The question remains, can your AI toolset be trusted in production?

CISSP Domain 8 focuses on securing software throughout the development lifecycle, from design and coding to testing, deployment, and maintenance. In Part 1, we covered how to develop software securely from the very beginning of a project, using secure design principles, development practices, and testing methods to reduce risk in enterprise applications.

In Part 2, we’ll look at software security effectiveness, including auditing and logging, risk analysis and mitigation, identifying and addressing security weaknesses, and improving API security and coding practices.

Let’s jump into the domain and cover the material by following the ISC2 exam outline.

8.3 - Assess the effectiveness of software security

Assessing software security through auditing, logging, risk analysis, and mitigation is important for shifting from a reactive to a proactive defense strategy. Together, these practices provide the visibility and actionable insights needed to safeguard critical assets.

Auditing and logging of changes

Assessing the effectiveness of software security relies on robust auditing and logging. Applications should be configured to log details of errors and other security events to a centralized log repository. Some security use cases include identifying security incidents, monitoring for policy violations, creating audit trails (e.g., data additions, modifications, deletions), compliance monitoring, risk analysis and mitigation, and attack detection.

Logs provide a definitive record of "who did what, when, and from where," preventing denial of actions after a security incident. In the wake of a breach, audit trails act as a primary source of truth, allowing teams to reconstruct timelines, identify initial entry points, and determine the full scope of compromised data. Real-time log monitoring can reveal suspicious patterns, such as access to sensitive files outside of normal business hours or a high volume of failed login attempts.

Key Considerations for Auditing Changes

Read more

CISSP Domain 8 focuses on securing software throughout the development lifecycle, from design and coding to testing, deployment, and maintenance. In Part 1, we’ll cover how to develop software securely from the very beginning of a project, using secure design principles, development practices, and testing methods to reduce risk in enterprise applications.

Here is a breakdown of the topics in this domain:

• Security in the software development life cycle (SDLC): Integrating security tasks into various methodologies such as Agile, Waterfall, Spiral, and DevSecOps, and understanding how maturity models and change management fit in.

• Security controls in development ecosystems: Identifying and applying controls for programming languages, libraries, toolsets, and CI/CD pipelines. Utilizing various assessment methods to verify security, including SAST, DAST, and SCA.

• Software Security Effectiveness: Using auditing, logging, risk analysis, and mitigation.

• Acquired Software Security: Assessing the security impact of Commercial Off-the-Shelf (COTS), open-source, third-party, and cloud-based software before integration into the organization.

• Secure Coding Guidelines: Identifying and addressing security weaknesses, applying standards to improve areas such as secure coding practices and API security.

Let’s dive into the domain and cover the material by following the ISC2 exam outline.

8.1 - Understand and integrate security in the Software Development Life Cycle (SDLC)

The software development life cycle (SDLC) is the process of designing, creating, testing, and deploying software. From a security perspective, application development has become more complicated over the last few years, even as the introduction of AI-assisted coding has increased developer output. Incorporating guardrails and boundaries, staying on top of the latest changes, and ensuring the security of the application environment in production continue to be challenging.

From the CISSP perspective, SDLC terminology varies across models and publications, but what is most important is understanding the fundamental principles of how the process works.

One of the most important aspects of the SDLC is that security must be incorporated at every phase. While terminology may differ by methodology (such as Waterfall or Agile), the core phases and their associated security activities generally include:

1. Initiation/Planning: Define security objectives and perform initial risk assessments.

2. Requirements Definition: During this phase, security requirements are captured alongside functional requirements, and risk analysis is refined.

3. System Design: Threat modeling is used to identify architectural risks early in the design phase, before coding begins.

4. Development/Coding: Apply secure coding standards, conduct manual code reviews, and use static application security testing (SAST) to identify issues early.

5. Testing/Evaluation: Perform dynamic application security testing (DAST), fuzz testing, and additional SAST to validate security before release.

6. Deployment/Release: Ensure secure configuration, complete final certification and authorization activities to confirm the system is approved for production use.

7. Maintenance/Operations: Continuously monitor for emerging threats, apply patches and updates, and perform regular security audits.

Read more

Security Operations is the practical application of security concepts to identify, investigate, and mitigate risks across an organization's daily activities and operational lifecycle.

Part 1 covered important concepts, including investigations, evidence collection, logging and monitoring, threat intelligence, and configuration management.

We continued exploring areas such as resource protection, incident response, and detection and preventive technologies in Part 2.

In Part 3, we looked at vulnerability and patch management, change management, and disaster recovery plans, processes, and testing.

In the last article, we’ll discuss business continuity planning and physical and personnel safety.

Let’s dive into the domain and cover the material by following the ISC2 exam outline.

7.13 - Participate in Business Continuity (BC) planning and exercises

Business Continuity Management (BCM) is the holistic process that identifies potential threats and risks to operational continuity and provides a framework for building resilience. It ensures an organization can continue to deliver products or services at acceptable, predefined levels during and after a disruption.

The BCM process drives disaster planning and preparation by conducting the Business Impact Analysis (BIA). The BIA helps define metrics (e.g., RPO, RTO, WRT, and MTD) that, in turn, drive the creation of Business Continuity Plans (BCPs) and Disaster Recovery Plans (DRPs). BCM primarily aims to ensure an organization's survival during a disaster by maintaining its most critical processes.

Metrics that you should be familiar with:

Read more

Security Operations is the practical application of security concepts to identify, investigate, and mitigate risks throughout a business’s daily activities and operational lifecycle.

Part 1 covered application of important concepts, including investigations, evidence collection, logging and monitoring, threat intelligence, and configuration management.

In Part 2, we continued exploring areas such as resource protection, incident response, and detection and preventive technologies.

In Part 3, we’ll look at vulnerability and patch management, change management, and disaster recovery plans, processes, and testing.

Let’s dive into the domain and cover the material by following the ISC2 exam outline.

7.8 - Implement and support patch and vulnerability management

Patch management and vulnerability management are distinct but interconnected cybersecurity processes. While vulnerability management identifies the “cracks” in a system, patch management provides the “repair.” Patch and vulnerability management processes work together to help protect against emerging threats. Patch management ensures that fixes are applied to systems, and vulnerability management helps verify that systems are not vulnerable.

• Vulnerability Management: A broad, continuous, and strategic lifecycle used to identify, assess, and prioritize security weaknesses, including software flaws, misconfigurations, and weak authentication, across an organization’s entire IT footprint. Like other areas of cybersecurity, this lifecycle increasingly leverages AI to filter through the thousands of newly published vulnerabilities every year.

• Patch Management: A tactical, operational process focused specifically on identifying, testing, and deploying software updates or patches provided by vendors to fix known bugs and security holes. Change and configuration management are often used to make the patch management process work effectively.

Patch management is often viewed as a subset of the broader change and configuration management disciplines. While they overlap, each serves a distinct role in ensuring that security updates are applied safely and predictably.

Configuration management provides the foundation for patching by maintaining a known, secure baseline of all systems, while change management acts as governance for patching, ensuring that updates don't cause operational outages.

You should be familiar with the patch management process as follows:

Read more

Security Operations is the practical application of security concepts to identify, investigate, and mitigate risks throughout a business's daily activities and operational lifecycle.

In Part 1, we covered the basics, including the different types of investigations, evidence collection, logging and monitoring, threat intelligence, configuration management, and a few core security operations concepts.

In Part 2, we continue exploring the application of resource protections, incident response, and detection and preventive technologies. Let’s dive into the domain and cover the material by following the ISC2 exam outline.

7.5 - Apply resource protection

Organizations need to protect sensitive data and systems at every stage of their lifecycle, from secure provisioning and storage to proper disposal when assets are no longer needed.

Media management

Media management includes the security controls and techniques needed to protect media and stored data. Organizations use a wide variety of storage media, requiring appropriate policies and security controls to maintain confidentiality, integrity, and availability.

Organizations use a variety of media types that require protection to prevent data breaches, tampering, and loss. Security frameworks and best practices emphasize a mix of physical and digital controls to effectively manage these risks.

Read more

Security operations is the practical application of security concepts to identify, investigate, and mitigate risks throughout a business's daily activities and operational lifecycle. Comprising 13% of the exam, the domain covers areas like investigation and digital forensics, incident management, resource protection, and configuration and patch management.

The goal is to minimize the impact of threats while ensuring the organization meets its confidentiality, integrity, and availability objectives during normal, emergency, and recovery operations.

In Part 1, we’ll cover objectives 7.1 through 7.4. Let’s dive into the domain and cover the material by continuing to follow the ISC2 exam outline.

An investigation is simply the way we dig into what happened during a security incident to figure out how it started.

Security incidents can be anything from minor issues that don’t need follow-up to serious situations that require a formal investigation. A more serious incident investigation might involve law enforcement. Important investigations should follow a more formal process to avoid issues that might weaken or derail a case.

The following are some general high-level components of a formal investigation:

• Identify and secure the scene

• Protect evidence to preserve its integrity and the chain of custody

• Identify and examine the evidence

• Do an analysis of the most compelling evidence

• Provide a final report of findings

Note that we covered different types of investigations in Domain 1, but to briefly review:

• Administrative: cover operational issues or violations of an organization’s policies.

• Criminal: is centered around court admissibility and is conducted by law enforcement.

• Civil: conducted by lawyers or private investigators to gather evidence, establish liability, and determine damage or liability amounts.

• Regulator: conducted by a regulatory body against an organization suspected of an infraction.

Computer crime is a law or regulation violation that involves a computing device and can be grouped into six categories:

• Military and Intelligence Attack: Often carried out by foreign intelligence agents, state-sponsored actors, or traitors looking for classified military or law enforcement information. The goal is often cyber espionage (stealing proprietary data for political or strategic advantage) or cyber sabotage to disrupt an adversary’s critical infrastructure or military readiness.

• Business Attack: Targets a company to gather intelligence (stealing trade secrets or intellectual property) and DOS attacks intended to disrupt a competitor’s operations or damage their reputation.

• Financial Attack: Attacks targeting financial institutions, e-commerce sites, etc., to steal or embezzle funds. Tactics include stealing credit card numbers, committing identity theft, or using phishing to gain unauthorized access to online financial accounts.

• Terrorist Attack: Ideologically motivated attacks designed to incite fear or cause violence against civilian targets. Used to recruit members, spread fear, and cause disruption. Terrorists may target critical infrastructure, such as power grids or communication systems, to cause widespread social or economic disruption.

• Grudge Attack: These are personal attacks motivated by revenge, typically carried out by a disgruntled employee or former affiliate. The attacker seeks to damage the organization by deleting critical data, planting logic bombs, or leaking sensitive data.

• Thrill Attack: Often categorized as amusement or curiosity attacks, by thrill-seekers or "script kiddies" for the excitement of successfully breaching a system. While the attackers may not intend to cause severe harm, their unauthorized access remains illegal and can inadvertently lead to system instability.

Electronic discovery (e-discovery) is the legal process of identifying, collecting, and producing electronically stored information (ESI) as evidence in a lawsuit or investigation. While traditional discovery involves exchanging physical paper or digital documents, e-discovery focuses exclusively on digital data.

Most legal professionals follow the Electronic Discovery Reference Model (EDRM) to manage the process in a “defensible” manner that stands up in court:

1. Information Governance: Managing data from its creation to its destruction to reduce risks before a legal matter even begins.

2. Identification: Pinpointing which digital files are relevant to the case and identifying the “custodians” or people who own or control them.

3. Preservation: Issuing a legal hold to ensure data is not deleted, altered, or overwritten.

4. Collection: Gathering the data from sources like email servers, cloud drives, and mobile devices while keeping their original “digital fingerprint” (metadata) intact.

5. Processing: Converting files into a searchable format and removing duplicates (de-duplication).

6. Review: Examining the data to decide what is relevant to the case and what should be kept private (attorney-client privileged).

7. Analysis: Looking for patterns, key topics, and timelines to help build a legal strategy.

8. Production: Formally delivering the relevant data to the opposing side in a readable format, such as a PDF or native file.

9. Presentation: Displaying the final evidence to stakeholders (e.g., a judge or jury during a trial or deposition).

7.1 - Understand and comply with investigations

Evidence collection and handling

Proper evidence collection and handling are important for any investigation and are considered the “lifeline of credibility,” especially as digital data now appears in a high percentage of criminal cases.

Because digital evidence is fragile and easily altered, strict collection and handling protocols serve several critical functions:

• The primary goal of evidence handling is to ensure that it maintains the Chain of Custody. Maintaining a chronological record of who handled the evidence, when, and why is an absolute requirement for the court. Any “break” or missing link in this chain can lead to a ruling of inadmissible evidence, potentially resulting in the dismissal of an entire case. Chain of custody includes:

  • Description of the evidence and the circumstances around its collection.

  • Time and date it was collected.

  • Exact location of where the evidence was collected.

  • Name of people collecting the evidence, and logging of who handled it, or transferred it, and why.

  • Proving that it has not been altered.

• Proper handling allows investigators to prove that the evidence presented in court is exactly the same as what was originally collected and has not been tampered with.

• Digital evidence is “volatile,” meaning it can be changed accidentally just by turning on a device or copying a file, so maintaining evidence integrity is the primary concern.

  • Forensic Imaging: creating a "bit-for-bit" duplicate (forensic image) of the original data.

  • Cryptographic Hashing: Every piece of digital evidence is assigned a "digital fingerprint" or hash value. If even one bit of the data is changed, the hash value changes, alerting investigators to tampering.

Evidence admissibility requirements include the following:

• Admissible: It must meet legal rules before it can be introduced in court.

• Relevant and Complete: The evidence must be relevant to determining a fact in the case.

• Authentic and Related: Evidence must be material or related to the case.

• Reliable: Evidence must be competently or legally obtained.

• Believable and Convincing: It must be readily believable and understandable by a court.

The International Organization on Computer Evidence (IOCE) established five core principles to ensure that digital evidence is handled reliably and legally admissible:

• Integrity (No Alteration): When seizing digital evidence, no actions should be taken that change the original evidence.

• Forensic Competence: If it is necessary for someone to access the original digital evidence, that person must be specifically trained and forensically competent to do so.

• Full Documentation: Every activity related to the seizure, access, storage, or transfer of digital evidence must be fully documented and preserved so it is available for review by other parties.

• Individual Responsibility: Any individual who has digital evidence in their possession is personally responsible for all actions taken with that evidence during that time.

• Agency Compliance: Any agency responsible for seizing, accessing, storing, or transferring digital evidence is responsible for ensuring all these principles are followed by its staff.

The Order of Volatility (OoV) determines the sequence for collecting evidence, prioritizing data that is most likely to change or disappear quickly. Based on RFC 3227 guidelines, the standard order from most to least volatile is:

1. CPU/Cache/Registers: These contain the most transient data, potentially existing only for nanoseconds. They change constantly with every processor cycle.

2. Memory, Kernel/Routing/ARP Cache/Process Tables: Includes machine RAM and dynamic system data like active network routing tables and kernel statistics that change as the system operates.

3. Temporary File Systems/Swap Space: Temporary files and swap/page files reside on disk but are frequently modified or overwritten by the operating system during a live session.

4. Disk (Fixed Storage): Data on physical disks is non-volatile and persists after power-off, though it still risks being overwritten by continued use.

5. Remote Data: This includes live connections, logs, and monitoring data stored on external servers or cloud services, which may be overwritten by the logging system over time.

6. Physical Configuration/Network Topology: Physical machine configuration and topology of the network.

7. Stored Data on Backup Media: Archival media or offline backups are the least volatile, as the data remains unchanged unless the physical media is damaged or intentionally modified.

In legal proceedings, evidence is generally categorized into four primary types based on its nature and how it is presented to the court:

• Real Evidence (Physical Evidence): This refers to tangible objects that were directly involved in the event being investigated. Because these items are physical, they can be inspected by the judge or jury.

• Documentary Evidence: This consists of information recorded in a format that can be preserved and read, used to prove or challenge facts. Some examples include contracts, emails, business records, and system logs.

• Testimonial Evidence: This is oral or written evidence provided by a witness under oath. It involves the witness narrating what they saw, heard, or experienced firsthand.

• Demonstrative Evidence: This category includes items created specifically for the trial to illustrate or explain other evidence and testimony. Unlike real evidence, it was not part of the original event but helps the jury understand complex facts.

In legal and forensic contexts, evidence is further classified by source, reliability, and relationship to the facts of the case:

• Best Evidence (Primary): The most reliable form of evidence, typically the original document or file rather than a copy or printout.

• Secondary Evidence: Evidence that is reproduced from an original source, such as document copies or a witness’s oral description of a document’s contents. This form of evidence is used when best or primary evidence can’t be obtained.

• Direct Evidence: Evidence that proves a fact directly without needing any inference or interpretation, such as eyewitness testimony or a video recording of an event or act.

• Conclusive Evidence: Evidence so strong that it cannot be contradicted by other evidence. It obliges the judge or jury to reach a specific conclusion.

• Circumstantial (Indirect) Evidence: Evidence that suggests a fact by proving other related facts. It requires the judge or jury to make a logical inference to connect the evidence to the conclusion.

• Corroborative Evidence: Additional evidence of a different character that strengthens, supports, or confirms already existing evidence.

• Opinion Evidence: Testimony provided by a witness regarding what they believe or infer about a fact, rather than what they personally saw or heard. Typically, this type of evidence is limited to expert witnesses with specialized knowledge in a relevant field.

• Hearsay Evidence: “Second-hand” evidence consisting of a statement made outside of court by someone other than the person testifying, offered to prove the truth of what was said. It is generally inadmissible unless it meets specific legal exceptions.

Methods of evidence collection are governed by legal frameworks to ensure that evidence is gathered legally and remains admissible in court.

Methods for collecting evidence include:

• Voluntary Surrender (Consent): A person with authority over the property or data voluntarily agrees to provide it to investigators. For this to be valid, consent must be given freely, without coercion, and the person can typically limit the scope of what is searched.

• Subpoena: A legal demand for an individual or entity (like a business or witness) to produce specific documents, records, or digital data at a later date. Unlike a warrant, a subpoena does not require a showing of probable cause, and the recipient can challenge it in court before complying.

• Search Warrant: A court order signed by a judge that authorizes law enforcement to immediately enter a location and search for specific items or data based on probable cause. Warrants for digital devices must often include specific “search protocols” to prevent overly broad or intrusive exploration of private data.

• Seizure of Visible Evidence (Plain View Doctrine): This allows officers to seize evidence without a warrant if they are lawfully present (e.g., executing a different warrant or during a traffic stop), the item is in plain sight, and its incriminating nature is immediately apparent. However, while this may allow the seizure of a computer or phone, it generally does not grant the authority to search the digital contents without an additional warrant.

• Exigent Circumstances: Emergency situations that allow for immediate warrantless search or seizure to prevent the imminent destruction of evidence, protect lives from immediate danger, or during the “hot pursuit” of a suspect. Once the immediate emergency is over, a warrant is typically required to conduct further detailed searches.

Remember the Locard exchange principle: whenever a crime is committed, something is taken, and something is left behind. In short, contact leaves traces, whether it happens in the physical world or between digital objects.

Reporting and documentation

Reporting and documentation are prioritized as the primary defense against legal challenges and the key to organizational recovery. Effective investigation management centers on these core concepts:

1. Meticulous Step-by-Step: Documentation should serve as a detailed diary of the investigation to ensure it is thorough and fair.

2. Structured Report Creation: A professional investigative report summarizes findings objectively and prompts necessary action.

3. Secure Storage Systems: Integrity is non-negotiable, and investigators rely on secure, centralized systems to protect sensitive data.

4. Stakeholder Updates: Communication must balance transparency with the need to protect the investigation’s integrity.

Investigative techniques

Whether in response to a crime or incident, an organizational policy breach, or troubleshooting a system or network issue, digital forensic methodologies can assist in finding answers, solving problems, and, in some cases, help successfully prosecute crimes.

The forensic investigation process should include the following:

• Identification and securing of a crime scene.

• Proper collection of evidence that preserves its integrity and the chain of custody.

• Examination of all evidence.

• Further analysis of the most compelling evidence.

• Final reporting.

Sources of information and evidence include:

• Interviews, oral/written statements: Statements from witnesses, investigators, or testimony in court by people who witness a crime or who may have pertinent information.

• Data collection: Documentation such as business contracts, system logs, network traffic, and other collected system data. This can include photographs, video, recordings, and surveillance footage from security cameras.

Several investigative techniques can be used when conducting analysis:

• Forensic analysis: analysis of systems and components that are in scope for the incident or investigation.

• Software analysis: focuses on applications and malware, determining how it works and what it’s trying to do, with a goal of attribution.

• Third-party collaboration: assistance and collaboration with external organizations and authorities, such as law enforcement or insurance-related external investigators.

Digital forensics tools, tactics, and procedures

Digital forensics leverages highly specialized tools and standardized procedures to address the explosive growth of volatile, distributed data. Key areas of focus for investigators include:

1. Evidence Preservation (The Foundation)

Preserving data integrity is the most critical first step to ensure evidence is legally admissible.

• Tactics & Procedures:

  • Write Blockers: Using hardware write blockers when connecting to storage media prevents inadvertent modification of original data.

  • Forensic Imaging: Creating “bit-for-bit” duplicate copies of the original media. Analysis is performed only on these working copies, never the original.

  • Chain of Custody: Maintaining a meticulous, timestamped log of every person who handled the evidence.

  • Physical Protection: Protecting physical devices from access or damage. Examples include using a Faraday bag to block signals and prevent remote wiping of mobile devices.

2. In-Memory (RAM) Analysis

Memory forensics is essential for detecting “fileless” malware, active network connections, and encryption keys that do not exist on a storage drive.

• Key Tools: Memory forensic tools focus on acquiring volatile RAM snapshots and analyzing them for threats. The Volatility Framework (an open-source tool written in Python) is an example.

• Tactics: Prioritize RAM capture over hard drive imaging during initial triage because memory is the most volatile evidence and much faster to acquire.

3. Media Analysis (Fixed & Removable Storage)

Media analysis involves deep-level inspection of file systems, registry artifacts, and deleted content.

• Key Tools: Media analysis forensic tools provide acquisition, analysis, and reporting capabilities across cloud, desktop, and mobile devices.

• Tactics:

  • File Carving: Recovering fragments of deleted files by searching for specific file signatures in unallocated space.

  • Artifact Analysis: A specialized digital forensic process of identifying, extracting, and interpreting "digital footprints” or records of activity left behind on a device.

4. Network Forensics

Network analysis captures and reconstructs data flowing through a network to identify attack vectors and data exfiltration.

• Key Tools: Examples include Wireshark (packet sniffing), tcpdump, Snort (IDS logs), and Nagios.

• Tactics:

  • Packet Analysis: Deep inspection of individual data packets to identify malicious payloads.

  • Log Examination: Correlating traffic patterns with system and application logs to build a timeline of the incident.

5. Emerging Trends

• Cloud Forensics: Investigators can use specialized tools to extract evidence from remote cloud services and synchronized mobile apps.

• AI-Driven Analysis: AI tools are used to automatically flag relevant patterns and anomalies in massive datasets that would take human examiners months to review manually.

• Anti-Forensics Countermeasures: Investigators can use techniques like Metadata Analysis to detect when cybercriminals have attempted to wipe or manipulate evidence.

Artifacts (e.g., data, computer, network, mobile device)

Digital artifacts or digital evidence that provide information on a security incident are classified by their source and state (e.g., volatile vs. non-volatile). These "remnants" allow investigators to reconstruct who performed an action, what occurred, and when it happened.

Examples of artifacts include:

• Computer & OS: artifacts that track user activity, program execution, and system configuration, such as Windows registry elements, execution remnants (proof a program was run), or event logs.

• Network: Traffic telemetry and connection logs that track data movement and external communications.

• Mobile device: Smartphones function as "digital journals" with unique location and communication data that might include SMS, GPS location data, or browser history.

7.2 - Conduct logging and monitoring activities

Logging and monitoring are the primary mechanisms for security assurance, shifting security from a reactive "snapshot" approach to an ongoing "operational cadence". They help prevent incidents and provide critical validation that security controls, such as access management, firewalls, and encryption, are functioning as designed and effectively protecting assets.

Logging simply means recording information about events, such as changes, messages, and activities. The goal is to keep a record of what, when, where, and even how an event occurred. Logging and monitoring act as an "electronic sentry," providing immediate visibility when a control is bypassed or incorrectly implemented.

Security professionals need to understand and master tools such as IDPS, SIEM, SOAR, Threat Intelligence, and UEBA because modern cyberattacks, now frequently accelerated by AI, unfold faster than manual monitoring can keep pace. These technologies work together to transform massive volumes of raw data into actionable security insights and rapid responses.

Sampling is a technique for managing the explosive volume of telemetry data generated by distributed systems and AI-driven infrastructures. By capturing and analyzing a representative subset of data rather than every event, organizations can maintain visibility while controlling costs.

Clipping levels are a form of non-statistical (or discretionary) sampling in which only events that exceed a predefined threshold (the clipping level) are selected, and these types of events are ignored until they reach this threshold. Clipping is widely used to set a baseline for user activity or routine events.

Intrusion detection and prevention (IDPS)

IDPS provides early warning signals by monitoring network traffic for known threats or policy violations in real time. The technology helps provide visibility into malicious activity across networks with both real-time alerting (IDS) and automated response (IPS).

The two primary detection methodologies differ in their approach to identifying threats:

1. Signature-Based

Signature-based (AKA pattern-based or knowledge-based) IDPS works like antivirus software, matching incoming traffic against a database of known attack patterns or “signatures.”

• Effectiveness: Highly accurate at detecting known threats.

• Key Advantage: It produces a very low false-positive rate, meaning it rarely flags legitimate traffic as a threat.

• Limitation: It is entirely ineffective against zero-day exploits or novel attacks that do not yet have a recorded signature.

2. Anomaly-Based

Instead of looking for specific threats, this method establishes a normalized baseline of typical network behavior and flags any significant deviations as suspicious.

• Effectiveness: It excels at detecting unknown or emerging threats, including zero-day attacks, sophisticated insider threats, and polymorphic malware.

• Key Advantage: It is highly adaptable and can identify unusual patterns (e.g., massive data transfers at 3 AM) that signature-based systems would miss.

• Limitation: It is prone to a higher false-positive rate because legitimate but unusual business changes can trigger alerts. It also requires substantial computational resources for real-time behavioral analysis.

Security Information and Event Management (SIEM)

A SIEM collects, aggregates, and analyzes log and event data from various sources across an IT environment, such as network hardware, applications, and endpoints.

SIEMs have evolved from simple log collectors into “central nervous systems” for Security Operations Centers (SOCs), prioritizing threat detection, investigation, and response over basic compliance.

Common SIEM features include:

• Data aggregation and normalization: Collects logs from diverse sources (firewalls, cloud apps, servers) and converts them into a uniform, searchable format.

• Real-time event correlation: Uses predefined rules and advanced analytics to link seemingly unrelated log events (e.g., a failed login followed by a successful one from an unusual location) to identify a single multi-stage threat.

• AI and machine learning: Employs advanced algorithms to detect anomalies and “fileless” attacks that traditional signature-based rules might miss.

• User and Entity Behavior Analytics (UEBA): Establishes behavioral baselines for users and devices to flag suspicious deviations, such as an employee accessing sensitive files at odd hours.

• Incident response automation integration: Modern platforms increasingly integrate Security Orchestration, Automation, and Response (SOAR) to trigger automated workflows, such as isolating a compromised host or blocking a malicious IP within seconds.

• Compliance Management and Reporting: Automates the creation of audit-ready reports for regulatory frameworks like GDPR, HIPAA, and PCI DSS.

• Centralized dashboards: Provide “single-pane-of-glass” visibility with visual metrics and real-time alerts for security analysts.

• Forensic and historical analysis: Enables teams to search vast amounts of historical data to reconstruct the timeline of an attack and find its root cause.

• Threat intelligence integration: Enriches internal log data with external feeds of global indicators of compromise (IoCs) for more accurate detection.

Security Orchestration, Automation, and Response (SOAR) is a technology stack that enables organizations to collect data from various security sources, such as firewalls and endpoint protection systems, and automate responses to security events through a centralized platform.

SOAR is critical for reducing "alert fatigue" by automating low-level, repetitive tasks, allowing security analysts to focus on complex threat hunting and investigation.

Playbooks vs runbooks: note that there isn’t a universal definition for these terms. However, in incident response, playbooks are broad documents, checklists, or digital workflows that outline the high-level plan for responding to specific incident types. They help coordinate security tools and personnel to ensure a consistent, organization-wide response. Playbooks are the documented processes that should be followed.

Runbooks, on the other hand, implement the playbook’s actions. In a SOAR context, runbooks take playbook steps and translate them into automated actions and workflows. Runbooks are the implementation of the playbook’s documented processes.

Continuous monitoring and tuning

Monitoring and tuning are continuous processes of assessing events and adjusting security controls to match an organization’s requirements and operating environment. Systems like IDPS require tuning to reduce false positives while ensuring that potential intrusions are not missed.

In order to maximize the value of monitoring and tuning, considerations include:

• Establish metrics and KPIs: As we’ve previously noted, metrics are important for establishing baselines and showing progress, especially in the context of event and control monitoring. Boards will continue to require quantified, data-driven insights that metrics help provide.

• It’s also important to continuously improve security operations via processes such as root cause analysis, maintaining updated policies, and continuous training, evaluation, and tuning.

Egress monitoring

Egress monitoring involves tracking and analyzing data as it leaves a private network for external destinations. While many organizations traditionally focus on "ingress" (incoming) traffic to block external attacks, egress monitoring focuses on the internal-to-external flow to prevent data loss and detect compromised systems already inside the network.

The goal of egress monitoring is to prevent the exfiltration of sensitive data, disrupt malware, detect early compromise, and monitor the sharing of personal or financial information.

Egress monitoring tools and considerations include:

• Developing policies and rules to detect and deter exfiltration and communication with known malicious sites and services.

• Using egress filtering and monitoring controls such as firewalls and data loss prevention (DLP) to detect and block sensitive data transmissions and provide alerting.

• Using modern firewalls that can inspect the content of encrypted outbound traffic to ensure sensitive files are not hidden within authorized protocols like HTTPS.

• Monitoring egress traffic from internal services to third-party APIs to prevent the leakage of PII or the abuse of API keys.

• Integrating egress monitoring with other tools such as SIEM and SOAR.

Log management

Log management captures, stores, and protects the logs generated across an organization’s infrastructure. Robust log management is a requirement to support security monitoring, incident response, and compliance.

Log management involves creating the systems and infrastructure to capture and store log data from an organization’s diverse and relevant sources. To avoid losing data, organizations capture logs from the full stack, including ephemeral sources such as serverless functions and containers.

Log data should be stored for relevant periods, and retention and archival policies should define:

• The availability of log data for required record retention and regulatory compliance.

• The integrity of log data, for instance, by storing logs in a centralized location and ensuring that logs have not been altered or deleted.

• Ensuring the confidentiality of log data, which often contains sensitive information, such as IP addresses, usernames, and sometimes inadvertently captured passwords or PII.

Threat intelligence (e.g., threat feeds, threat hunting)

Threat intelligence is the collection, analysis, and interpretation of information about potential or current attacks targeting an organization. It can be classified into three functional levels:

• Strategic Intelligence: High-level information for executives and board members regarding long-term trends, geopolitical risks, and financial impacts.

• Operational Intelligence: Detailed insights into specific incoming campaigns, including the “who” (threat actors) and “why” (motivations) behind an attack.

• Tactical Intelligence: Real-time, technical indicators of compromise (IoCs) like malicious sites, IP addresses, file hashes, and specific Tactics, Techniques, and Procedures (TTPs) used by attackers.

A threat intelligence feed is an automated, continuous stream of real-time data that provides actionable information on emerging and active cyber threats. These feeds are the "breaking news ticker" for cybersecurity teams, delivering the technical details needed to identify and block attacks before they impact an organization.

STIX and TAXII are the global open standards that enable organizations to share cyber threat intelligence in a machine-readable format, reducing the need for manual data processing.

STIX (Structured Threat Information eXpression) is a standardized language and serialization format, typically in JSON, for describing cyber threat information.

TAXII (Trusted Automated eXchange of Intelligence Information) is the transport protocol used to securely exchange STIX-formatted data over HTTPS.

Automated Indicator Sharing (AIS) is a no-cost, voluntary service that enables the real-time exchange of machine-readable cyber threat indicators and defensive measures between the federal government and the private sector. AIS is managed by the Cybersecurity and Infrastructure Security Agency (CISA).

Threat hunting is a proactive search across an organization’s network and endpoints to identify malicious activity that has evaded traditional automated security tools. Unlike reactive monitoring, which waits for a system alert to trigger an investigation, threat hunting assumes an attacker may already be present in the environment.

The Cyber Kill Chain is a foundational cybersecurity framework that describes the sequential stages an adversary must complete to conduct a successful attack. Developed by Lockheed Martin, it adapts military strategy to help defenders identify, disrupt, and prevent intrusions across the attack lifecycle.

While some modern models expand this to eight stages by adding monetization (how attackers profit), the classic Lockheed Martin model consists of seven phases:

1. Reconnaissance: Gathering intelligence on the target, such as identifying open ports, searching employee details on social media, or scanning for network vulnerabilities.

2. Weaponization: Coupling an exploit (targeting a specific vulnerability) with a malicious payload that includes a backdoor for delivery to the target.

3. Delivery: Transmitting the weaponized payload to the target via phishing emails, malicious links, compromised websites, or physical media like USB drives.

4. Exploitation: Executing the malicious code on the target system by taking advantage of a software or hardware vulnerability.

5. Installation: Establishing a persistent foothold on the victim’s network, often by installing backdoors or Trojans that survive system reboots.

6. Command and Control (C2): Establishing a remote communication channel between the compromised system and the attacker’s infrastructure to receive instructions or move laterally.

7. Actions on Objectives: The final phase, where the attacker fulfills their primary goal, such as exfiltrating data, destroying systems, or encrypting files for ransom.

By understanding these phases, defenders can aim to "break the chain" as early as possible. Disrupting even a single stage can prevent the entire attack from succeeding. Security teams use the kill chain to map specific controls to each phase (e.g., email security for Delivery, EDR for Exploitation, and network monitoring for C2).

While traditionally linear, it is increasingly used alongside more detailed frameworks like MITRE ATT&CK to handle non-linear, AI-accelerated attacks that may compress multiple stages into hours rather than weeks.

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is the global industry-standard knowledge base for documenting and categorizing real-world cyber adversary behaviors. It provides a standardized language that allows security professionals to describe "how" and "why" attackers operate.

The framework or core is structured into tactics, techniques, sub-techniques, and procedures (TTPs):

• Tactics (The “Why”): The high-level technical goals an adversary wants to achieve, such as initial access, persistence, or exfiltration.

• Techniques (The “How”): Specific methods used to achieve a tactic. For example, spearphishing attachment is a technique used to achieve the Initial Access tactic.

• Sub-techniques (The “How” in Detail): More granular descriptions of a technique. Under phishing for instance, sub-techniques might include spearphishing link or “Spearphishing via Service.”

• Procedures: Real-world implementations and specific tools used by threat actors in observed incidents.

User and Entity Behavior Analytics (UEBA)

UEBA is an advanced cybersecurity solution that often uses AI and ML to establish "normal" behavioral baselines for users and entities. By monitoring for deviations from these baselines, UEBA identifies subtle, risky activities that traditional rule-based security tools often miss.

• Behavioral Baselining: The UEBA system observes activity over a period of time to learn patterns using data collected from sources such as system, application, and endpoint logs. The baseline covers things like standard login times, frequent file access, and average data transfer volumes.

• Anomaly Detection: Once a baseline is established, it continuously compares real-time activity to these norms. For example, a user who typically downloads 20MB of data suddenly downloading 4GB might be flagged as an anomaly.

• Dynamic Risk Scoring: UEBA assigns a risk score to each anomaly based on its severity and context. Multiple minor anomalies (e.g., a login from a new location plus access to sensitive files) can aggregate into a high-risk score that triggers an alert.

UEBA use cases include areas such as:

• Insider Threat Detection: Identifies unusual behavior that might indicate policy violations or malicious intent to harm the organization.

• Compromised Account Identification: Detects when a legitimate user’s credentials have been stolen by highlighting behavioral changes, even if the login appears authorized. It also helps monitor highly privileged user accounts for IoCs.

• Zero-Day and APT Detection: Uncovers sophisticated “low and slow” attacks and previously unknown exploits that lack traditional signatures.

• Data Exfiltration Prevention: Monitors for unusual data movement, such as large transfers to external cloud services or USB drives.

7.3 - Perform Configuration Management (CM) (e.g., provisioning, baselining, automation)

Configuration Management (CM) is the process of identifying, controlling, and verifying the configuration of organizational systems and settings. The focus is on establishing and maintaining the integrity of IT products and systems by controlling their initialization and changes, and by monitoring configuration throughout their lifecycle.

When something changes in systems under configuration management, for instance, patching software or a configuration update, the change is recorded. This allows the configuration management system to track changes, helping prevent mistakes and reduce security risks.

Some of the core functions of configuration management include:

• Developing a configuration management plan that outlines roles, responsibilities, standards, and the tools to be used for a project.

• Selecting and documenting configuration items (any IT asset worth tracking) and establishing a baseline configuration snapshot.

• Implementing configuration change control, a structured process managed by a configuration control board to review, approve, and track system changes to prevent unauthorized or risky modifications.

• Record-keeping that documents details (location, version, status) and tracks the history of changes (who, what, when, and why).

• Formal reviews to ensure that a system actually matches its design documentation and satisfies established performance and security requirements.

Provisioning means taking a specific config baseline, creating additional or modified copies, and deploying those copies into the environment. For instance, installing and configuring the operating system and required applications on new systems.

System hardening refers to the process of applying security configurations and locking down hardware, communication systems, and software. System hardening is normally based on industry guidelines and benchmarks.

A baseline in the context of configuration management is the starting point or starting config for a system.

7.4 - Apply foundational security operations concepts

Need-to-know/least privilege

Need-to-Know is a fundamental security principle that restricts access to sensitive data to only those individuals who require it to perform their specific, authorized job duties. It ensures that a user must have a legitimate business or mission requirement to access specific information, and even if an individual has the appropriate security clearance or high-level organizational role, they are still denied access to data that is not essential for their current task.

Granular data-centric access controls are often applied to specific information or data sets, which can be challenging to enforce in hybrid environments.

As we discussed in Domain 3, least privilege means that subjects are granted only the privileges necessary to perform assigned work tasks and no more. The concept should be applied to data, software, and system design to reduce the surface, scope, and impact of any attack.

Separation of Duties (SoD) and responsibilities

Separation of Duties (SoD) (AKA Segregation of Duties) helps prevent any single person from having enough unchecked authority to commit and conceal fraud or errors by dividing tasks among different individuals or organizations. It’s an effective "system of checks and balances," and a primary defense against insider threats.

Collusion is an agreement or cooperation between two or more individuals to deceive, bypass security controls, or commit fraud. By splitting responsibilities, SoD reduces the likelihood of fraud because it requires collusion — multiple people working together to commit the crime.

Privileged account management

Privileged Account Management (PAM) is the specialized security around controlling, monitoring, and auditing accounts with elevated permissions. These accounts have the authority to perform critical tasks like changing configurations, installing software, or accessing sensitive data.

PAM combines people, processes, and technology to tightly control who can access privileged accounts and how they’re used, helping protect an organization’s most critical systems and data. PAM enforces least privilege by granting only the minimum access needed for a role. It can also provide Just-in-Time (JIT) access, granting elevated privileges temporarily for a specific task and automatically revoking them once the task is complete, eliminating "standing privileges."

PAM is often required to qualify for cyber insurance and to meet stringent regulatory requirements.

Job rotation

Job rotation is an administrative security control where employees are systematically moved through different positions or tasks within an organization at regular intervals.

While it is often used for cross-training and employee development, its primary purpose in security is to act as a detective and deterrent control against fraud and insider threats.

As a real-world example, rotating the administrators responsible for managing the PAM system ensures that no single “super-admin” has unchecked control over the organization’s most sensitive credentials for too long.

Service-level agreements (SLA)

A service-level agreement (SLA) is a legally binding contract between a service provider and a customer that defines the expected service standard, the metrics used to measure it, and the remedies available if those standards are not met.

Effective SLAs often include several essential elements to prevent ambiguity:

• Service Description: A detailed overview of exactly what services are provided, their scope, and any dependencies.

• Performance Metrics: Quantifiable criteria (KPIs) such as uptime percentages, response times, and resolution rates.

• Roles and Responsibilities: Clear definitions of what is expected from both the provider and the customer (e.g., the customer’s duty to report issues promptly).

• Penalties and Rewards: Financial consequences like service credits for missed targets, or occasionally, incentives for exceeding performance standards.

• Exclusions: Explicitly stated services or circumstances (like natural disasters or “force majeure”) that are not covered by the agreement.

• Security and Compliance: Protocols for data protection, confidentiality, and meeting industry-specific regulatory standards (e.g., HIPAA for healthcare).

In part two, we’ll continue through Domain 7 and objectives 7.5 forward. If you’re on the CISSP learning journey, keep studying and connecting the dots, and let me know if you have any questions about this domain.

In Part 1, we covered the CISSP Domain 6 topics related to designing and validating assessment & audit strategies and conducting control testing. We defined core concepts, including what a security test and an audit are, which types of testing fall under an organization’s control, and what a vulnerability management program is designed to accomplish.

In Part 2, we continue exploring data collection, analyzing test results, reporting, and conducting various types of security audits. Let’s dive into the domain and cover the material by continuing to follow the ISC2 exam outline.

Read more