I’m Jeff Moore, a security practitioner, educator, and builder. Over the last 25+ years, I’ve worked across technology and security leadership roles, and today I write about security architecture, AI security, risk management, certification preparation, and the practical realities of defending modern systems.

People typically subscribe for one of three reasons:

Path 1: You’re Studying for CISSP

If you’re preparing for the CISSP exam, start here.

You’ll find content on:

• CISSP study strategies

• Domain-specific guidance

• Practice questions and exam preparation

• Security architecture fundamentals

• Common mistakes candidates make

Recommended reading:

• How difficult is the CISSP exam?

• Strategy Guide for Answering Difficult Questions

• AI Security for the CISSP: What’s Changed and How to Prepare

• CISSP CBK Explainer

• Security Control Frameworks Explained

Path 2: You’re Already a Security Professional

Many readers already hold certifications and work in security, engineering, architecture, governance, risk, compliance, or leadership roles.

Topics include:

• Security architecture and governance in the age of AI

• Cloud security

• Risk management

• Security leadership

• AppSec and development

• Security Credentials

Recommended reading:

• Strap In (with harness engineering)

• MITRE ATLAS: The AI Threat Framework Every Security Leader Needs to Know

• ISACA’s AAISM: The First AI Security Management Certification, Examined

• The CISSP Holder’s Guide to AI Security Credentials

• Inside the NIST AI Risk Management Framework

Path 3: You’re Exploring Security

AI is rapidly changing how organizations build, operate, and defend systems.

Here you’ll find content covering:

• Overviews of specific security topics, including governance and risk management

• Security & risk management frameworks

• Security implications of AI adoption (including AI-driven dev, supply chain, and model security)

Recommended reading:

• Guide to Security Governance

• NIST AI RMF or ISO 42001?

• Six Things Adversaries Are Doing With AI

• Inside the NIST AI Risk Management Framework

• Exploring Claude Code and AI-Driven Development

What I’m Building

In addition to writing, I’m currently building the Academy, an AI-powered learning platform for CISSP candidates and security professionals.

As founding members, participants receive access to my new CISSP book, available exclusively on the platform as an interactive learning experience.

You’ll also receive 30 days of Pro access and an opportunity to help shape the platform through direct feedback.

If that sounds interesting, learn more here.

Say Hello

One thing I enjoy most about this platform is meeting other people in the field.

Hit reply and tell me:

• What brought you here

• What you do

• What you’re working on

• What you’d like to learn next

I read every response.

For decades, information security worked on a simple assumption: software is deterministic. Input parameter A into system B, and you’ll get result C every time, bounded by the strict logic a programmer wrote. Security controls (whether static code analysis, input validation, or access control matrices) were built around that predictability.

Artificial intelligence breaks that assumption.

Generative AI and autonomous agent architectures move enterprise systems into probabilistic, non-deterministic, and increasingly autonomous territory. ISC2 acknowledged this on April 2, 2026 by publishing Exam Guidance for Artificial Intelligence, which maps AI security topics across the eight existing CISSP domains. (For more on that guidance, see AI Security for the CISSP: What’s Changed.)

This article, the first in a series, covers the Domain 1 material: foundational concepts, governance frameworks, and the administrative controls a CISSP candidate needs.

Concept Coverage

To evaluate AI risk on the exam (or in practice), you need the vocabulary. Questions may test whether you can place a specific risk at the right point in the system lifecycle.

What is Generative AI?

Generative AI or Gen AI is ubiquitous and you’ve probably been using many associated services for a couple of years. Gen AI refers to AI systems that create new content (text, images, code, audio) rather than just analyze existing data. Examples span many aspects of our digital lives: text (Claude, ChatGPT, Gemini), images (DALL-E, Stable Diffusion), video (Sora, Runway), music (Suno), voice synthesis (ElevenLabs), and code (Cursor). When a vendor says their platform is “powered by GenAI,” they mean it produces output, not just classifies or scores inputs.

What is an AI Model?

An AI model is a mathematical structure trained on a dataset to recognize patterns, make predictions, or generate outputs, without being explicitly programmed with step-by-step rules. After training, the model is the brain of the AI system. It holds everything the system “learned” as numbers (the weights and biases) that determine how it responds to any new input.

While traditional software uses code written by human developers to process inputs (Input → Rules → Output), an AI model uses statistical weights and biases derived from training data to produce its output (Input → Statistical Weights → Output).

What is a Large Language Model (LLM)?

A Large Language Model (LLM) is a specialized subset of generative AI built on a deep neural network architecture (specifically the Transformer architecture) that uses “self-attention” mechanisms to model relationships between words in a sequence.

LLMs are trained on internet-scale text to understand, summarize, translate, predict, and generate “human-like” language. The training data is measured in tokens: a token is what the model treats as a unit of text, usually a word or a piece of a word. Modern LLMs are trained on trillions of them.

What is a Prompt?

A prompt is everything you (or the system) hand to the AI on a single request. That includes the user’s question, any instructions the application has added behind the scenes, and any documents or chat history the model is pulling in. It’s also the only entry point an attacker has, which is the entire basis of prompt injection (see below).

Training vs. Inference: The AI Lifecycle

You need to distinguish the two operational phases of an AI model’s life:

• Training is how the model gets built. The system shows the algorithm a big dataset over and over, and each pass nudges the weights and biases until the model gives the “right” answer often enough to ship. The dataset used is the training data, and if it’s biased, missing important cases, or just bad, the model can never outperform what it was shown.

• Inference is what the model does once it’s running. Every time someone asks a chatbot a question or a fraud detector scores a transaction, that’s inference: one run of the trained model. Almost everything a CISSP encounters in the enterprise is inference. Training is a much heavier, much rarer event.

Each phase has a different attack surface and calls for different controls.

The Training Phase (Development Lifecycle):

• The Process: The algorithm is exposed to a training dataset and adjusts its internal parameters (weights and biases) until it can perform its target task.

• Secure SDLC Focus: A sensitive supply-chain and development phase. The priority is the integrity of the training dataset.

• Primary Threat: Data poisoning. If an attacker injects malicious or biased records into the training pool, they can permanently alter the model’s behavior or implant hidden backdoors.

The Inference Phase (Production Operations):

• The Process: The trained model runs in production (API endpoint, web application, autonomous agent) and processes live inputs.

• Operational Security Focus: The priority is validating inputs and sanitizing outputs.

• Primary Threat: Prompt injection and model hijacking, where attackers manipulate live runtime inputs to execute unauthorized commands or bypass safety boundaries. Simon Willison coined the term “prompt injection” in September 2022. The Samsung ChatGPT IP-leak incident in April 2023 was its first widely-reported corporate consequence.

Why It’s Hard to Secure

AI systems introduce three architectural properties that legacy security frameworks can’t fully manage:

Non-Determinism

Generative AI models don’t produce identical outputs for identical inputs. LLMs are the clearest example: each next token is picked from a probability distribution, so the same prompt can produce two slightly different answers on two different calls. Image, music, and video models work the same way. Traditional security testing depends on reproducibility: find a bug, baseline behavior, confirm a fix. Non-determinism breaks all three.

The Black-Box Problem

A trained neural network has millions or billions of internal parameters. Decisions emerge from those parameters all at once. There’s no sequence of if-then rules a human can follow. When a model denies a credit application or flags a transaction as fraud, no one can point to the specific reason. The model just produces an output.

In terms of the CISSP, that hits Traceability: the ability to verify, audit, and recreate why an action was taken. After an incident, reconstructing what the AI “saw” and “decided” requires specialized logging of the inputs that went in (prompts, retrieved documents, prior context) plus the outputs and confidence scores that came back. Without that logging, you can’t answer what every regulator, auditor, and exec will ask after an AI incident: “Why did it do that?”

Hallucinations

A hallucination is when a generative model confidently produces false information that looks plausible. The model generates output based on statistical patterns in its training data. There’s no internal step that checks whether that output is true. So it can invent names, citations, statistics, or quotes that don’t exist.

The CISSP implication is direct. AI outputs are unverified data. The professional who acts on them is the one who answers for it, in court and in the boardroom.

Frameworks and Regulation

Governments and standards bodies are still catching up to AI. Domain 1 expects you to know how the major frameworks fit into a compliance posture.

Standardized Security Frameworks

NIST AI Risk Management Framework (AI RMF 1.0) is the most cited voluntary framework for structuring an AI security program. It organizes work into four core functions:

• Govern: Establish a culture of risk management, policies, and organizational alignment.

• Map: Contextualize the AI system, identify boundaries, and map specific risks.

• Measure: Quantify, analyze, and track identified risks through empirical testing.

• Manage: Allocate resources to respond to mapped and measured risks dynamically.

These aren’t sequential steps. Govern sits across the whole framework as the policy and accountability layer, while Map, Measure, and Manage form a continuous feedback loop on top of it. In practice, Govern is also the function organizations may underinvest in the most.

The 40-page framework gives you the principles. The companion NIST AI RMF Playbook is where the operational guidance lives. If you’re implementing rather than briefing, you need both. NIST has also published a Generative AI Profile (NIST AI 600-1) that applies the four functions to GenAI-specific risks like hallucinations, data exposure, and misuse.

ISO/IEC 42001 (Artificial Intelligence Management System) is the certifiable counterpart to the NIST framework: a third-party-auditable management system that adds an outward-facing AI System Impact Assessment (consequences for external individuals and groups) on top of an ISO 27001-style structure. It also aligns with EU AI Act compliance expectations, which makes it the more useful choice for companies with European exposure. The most common pattern is to deploy NIST first to build taxonomy and lifecycle discipline, then layer ISO 42001 on top for external attestation. The common failure mode is starting both at once and finishing neither.

Global AI Regulation

CISSPs don’t need to be lawyers, but you do need to understand regulatory risk. The most prominent example is the EU AI Act, which classifies AI systems by risk tier:

• Unacceptable Risk: Systems that threaten human safety or rights (e.g., government social scoring) are banned outright.

• High Risk: Systems used in critical infrastructure, medical devices, or employment. These require pre-market assessments, logging, and human-in-the-loop oversight.

• Limited Risk (Specific Transparency): Chatbots, deepfakes. Users have to be told they’re interacting with AI.

• Minimal/No Risk: Spam filters, video games. No additional regulatory intervention required.

The Act reaches beyond the EU. Article 2 says it applies to anyone selling an AI system into the EU, anyone using one inside the EU, and any company anywhere whose AI outputs end up being used in the EU. If you have European customers, you’re in scope no matter where you’re headquartered.

Data, Bias, and Ethics

AI security still depends on the CIA triad, but integrity grows to include Data Quality and AI Ethics.

Data Quality (Garbage In, Garbage Out)

If the training dataset is poisoned, incomplete, or fundamentally skewed, the model’s outputs will be flawed, and the integrity of every downstream corporate decision goes with them. Security leaders need to vet data pipelines for accuracy, representativeness, and absence of tampering.

AI Ethics & Societal Adaptation

Ethics on the CISSP exam comes back to the ISC2 Code of Ethics (act honorably, protect society). In an AI context, that translates to:

• Fairness: Algorithmic decisions shouldn’t exhibit systemic bias against protected groups.

• Transparency: Stakeholders should be able to understand how a model reaches its conclusions.

• Human Oversight: Critical actions, especially those affecting livelihoods, physical safety, or financial assets, need human validation rather than fully automated execution.

The Disinformation Suite: Deepfakes and Automated Misinformation

Two non-technical AI threats sit squarely in Domain 1’s governance and societal-adaptation area. Deepfakes (AI-generated voice, image, or video impersonations) are now used in executive-targeting fraud and social engineering, blurring the line between identity verification and content verification. Automated misinformation campaigns use generative AI to produce false content at industrial scale and distribution speed, complicating brand defense, election integrity, and customer trust. Both call for governance responses (executive verification protocols, public-communications playbooks, third-party content-authenticity standards) rather than purely technical ones, which is why they belong in a Domain 1 risk conversation, not a firewall ruleset.

Building the Program

How do you turn the regulatory and architectural concepts into something operational? Start with administrative and organizational changes.

The Chief AI Officer (CAIO) or “AI Czar”

When organizations adopt AI at scale, a leadership gap often opens between the CISO (security) and the CDO/CIO (data and enablement). Enter the Chief AI Officer.

The CAIO aligns AI strategy with business goals, manages AI-specific compliance, and coordinates with the CISO on security architecture. If you don’t have a CAIO, a formal AI Governance Board (legal, compliance, engineering, security) fills the void.

The AI Acceptable Use Policy (AUP)

Before buying expensive security tools, set clear guidelines. An AI AUP should explicitly define:

• Approved Platforms: Distinguish approved enterprise-tier AI platforms (which guarantee data privacy) from public, consumer-grade tools (which may ingest user prompts for training).

• Classification Constraints: Restrict sensitive intellectual property, source code, and PII from being submitted to unauthorized external LLMs.

• Code Review Requirements: Any software written with AI coding tools goes through standard SAST/DAST security reviews before deployment.

Verify then Trust

For AI, every input (prompt) sent to a model needs sanitization to prevent prompt injection, and every output coming back gets treated as untrusted, hostile data. You can’t assume the model will always return benign, safe, or accurate content. The pattern echoes Zero Trust’s “never trust, always verify,” applied to LLM I/O. The OWASP LLM Top 10 (LLM01: Prompt Injection) is the canonical taxonomy.

Cost-Benefit Analysis

AI deployments have real resource overhead. Beyond software subscriptions, deep learning needs GPU compute and storage at scale. A formal cost-benefit analysis weighs efficiency gains against the costs of implementation, continuous monitoring, model retraining, and new compliance liabilities.

Adapting Your Existing Program

Your existing Domain 1 risk management processes also need to adapt to AI-related assets:

• Asset Inventory: Build a registry of AI models, training datasets, fine-tuning pipelines, and vector databases. Treat them as critical enterprise assets.

• Risk Register Integration: Document new threat profiles (prompt injection, training data poisoning, model inversion, and AI-augmented attacks like automated phishing and vulnerability discovery at scale) and assign risk owners.

• Third-Party Risk Management (TPRM): When evaluating SaaS vendors, audit AI usage. Do they use customer data to train their models? Are their LLM dependencies hosted in secure environments?

In the Next Article...

With governance and policy in place, the next article moves to Domain 2 (Asset Security): how to classify, protect, and dispose of the data pipelines, model weights, and compute assets that drive AI in the enterprise.

I’m building a CISSP prep platform centered on the idea that the exam tests your judgment and application of concepts, not rote memorization. It includes an adaptive CAT practice-exam engine, concept-coverage analytics, question-by-question scoring, exam-readiness tracking, mindset pattern analysis, weak-area drills, a custom study planner built around your schedule and requirements, my integrated book, and spaced repetition. It’s in limited beta. To request an invite (free extended Pro access in exchange for your feedback), join the waitlist at academy.balancedsec.com, and I’ll send invites on a rolling basis.

AI-native platforms have broken that math. Every prompt sent to a frontier model, every retrieval-augmented query, every personalized explanation routes through a metered inference call. The marginal cost per trial signup is no longer near zero. It’s measurable, often material, and almost always non-recoverable when the user doesn’t convert. The economics of free trials need a fresh look.

I’m working through this decision right now for a CISSP exam prep platform I’m building. The product combines a large proprietary practice-question bank, an adaptive CAT engine, an in-app full-text version of my book CISSP: A Balanced Approach, and AI features that lean heavily on premium models: a personalized in-context coach, mindset pattern analysis, and dynamic answer rationales that go beyond what I’ve written. Every one of those AI features costs real money per use. Free-trial design has become a three-way decision: marketing reach, security exposure, and unit economics.

Here is my reasoning through that decision and the security trade-offs each option carries.

Opt-In vs. Opt-Out

The first fork is whether to require a credit card before someone gets to use the product. Opt-in (no card required) is frictionless and historically draws a larger top-of-funnel. Opt-out (requiring a card upfront) reduces sign-up volume but serves as a self-qualification gate. ChartMogul’s January 2026 SaaS Conversion Report, based on 200 B2B software products, puts hard numbers on the trade-off. Per 1,000 website visitors, an opt-in trial typically produces about 45 signups and 3.6 paying customers. An opt-out trial produces about 35 signups and 10.5 paying customers. So opt-in pulls roughly 30% more signups, but opt-out produces nearly 3x the paying customers. Stated as trial-to-paid conversion, no-credit-card trials sit in the 4-6% range, and credit-card-required trials sit around 30%, more than 5x higher.

For a conventional SaaS product, that’s a marketing decision. For an AI-native product, it’s also a threat-model decision because each model targets a different adversary class.

The opt-in failure mode is automated trial farming. With no financial identity at the door, attackers can use headless browser scripts (Puppeteer, Playwright), temporary inbox generators, and residential proxy networks (Bright Data, Oxylabs) to bypass standard IP-based rate limits. Once inside, two attacks run in parallel: (1) walking your REST endpoints to dump proprietary content like a test bank or curated explanations, and (2) hammering the most expensive AI features to drain inference credits for personal use, resale, or training a copycat model. The cost falls on you as non-recoverable compute.

The opt-out failure mode is payment fraud. Putting a card form at the top of the funnel attracts a different adversary: carders running stolen-card dumps against your checkout endpoint to validate live numbers, and abusers feeding single-use virtual cards (privacy.com, Revolut) that pass a $0 authorization and then go dead before the first real charge. The cost includes processor review fees, chargeback exposure, and merchant-account standing.

For my platform, I’m landing on opt-out for three reasons:

1. The compute exposure on opt-in is asymmetric. A single determined adversary with a residential proxy pool can extract thousands of dollars in inference cost in a weekend. Recovering it is not realistic. Recovering payment-fraud losses, by contrast, is a workflow that processors already run for me.

2. Self-qualification matters more when seats are expensive to serve. A ~30% conversion rate on a smaller pool of higher-intent users is a better fit for a product where every active trial user is burning real money in tokens.

3. It lets me push off device fingerprinting. This is the part nobody talks about. If I went opt-in, I’d need a custom abuse stack from day one: device fingerprinting, behavioral signals, residential-ASN detection, link-graph clustering. With opt-out, the identity boundary moves to the financial system, which is the part of the internet where identity already costs something to fake.

How the Posture Slims: Shifting Identity to the Financial Layer

The core idea: in opt-in, you build a “proxy identity” yourself because emails are free and unlimited. In opt-out, you outsource identity to the card network, where supply is constrained, fraud is regulated, and the processors already operate a global tracking layer.

That outsourcing works regardless of which processor you pick. Stripe is what I’m using, but the same architectural pattern applies to Adyen, Braintree, Chargebee, Paddle, or any modern PSP with a managed checkout flow and a fraud product. What you get for free, in rough order of value:

1. Card fingerprinting across the processor’s network. Modern processors see the same card across many merchants. Stripe alone processed $1.9 trillion in transaction volume in 2025, and reports that 90% of the cards used on its network have been seen more than once across different merchants. Adyen and Braintree have comparable cross-merchant signals on a smaller scale. A card with a history of trial-abuse showing up at other merchants will get flagged before it ever creates an account on your platform.

2. Built-in trial-abuse models. Most processors now ship a free-trial-abuse product as a one-click feature rather than a custom build. Stripe Radar’s Free Trial Abuse Prevention, launched in 2025, claims 90% accuracy at flagging signups likely to violate trial terms. In its first two months across four high-growth AI businesses, Stripe blocked over 550,000 high-risk trials and reported $4.4M in prevented downstream compute losses. Other processors offer analogous features under different names. The point is that the processor’s centralized view of card and bank identification number (BIN) behavior is doing work that you’d otherwise have to build in-house.

3. Lightweight pre-checkout gating. A few cheap filters in front of checkout keep the customer database clean and stop low-effort scripts before they reach the payment layer:

• Disposable email blocks. Server-side validation against a maintained list of throwaway domains. Free or low-cost APIs (NinjaPear, DeBounce, AbstractAPI) handle this.

• Email alias and syntax checks. Block +alias spamming and obvious typos at the form level.

• A bot challenge at signup. Cloudflare Turnstile, hCaptcha, or Google reCAPTCHA. Low friction for humans, high friction for scripts.

With this combination, an abuser has to spend real capital on unique, valid credit cards to automate signups. The economics of attacking the platform invert. The custom device-fingerprinting stack you’d need for opt-in becomes unnecessary on day one.

The New Threat Landscape: Payment-Layer Vulnerabilities

The opt-out posture, however, is slimmer, but not threat-free. Three vectors carry over from the broader card payments ecosystem, regardless of which processor you choose. The mitigations are processor-agnostic in concept, and I’ll note how they look in Stripe specifically since that’s what I’m implementing.

1. Card Testing

A public card form is a target for card testing: criminals with stolen-card dumps fire $0.50 to $1.00 validation charges to find live numbers. Modern processors detect and block most of these, but two costs are still yours:

• Review fees on the paid fraud tier. Stripe’s Radar for Fraud Teams add-on costs 7¢ per screened transaction (reduced to $.02 if you’re on Stripe’s standard processing pricing). An overnight botnet of 15,000 attempts can saddle a Fraud Teams subscriber with anywhere from $300 to $1,050 in review fees, depending on tier, even though none of the charges went through. Adyen and Braintree’s enterprise risk products follow the same per-transaction pricing model.

• Auth-rate damage. A flood of declines hurts your acceptance-rate signal at the network.

Mitigation, in general: rate-limit your payment endpoints at the network layer (Cloudflare, your WAF, or your edge proxy), and put a bot challenge in front of checkout so high-velocity scripts can’t reach the processor’s backend at all. Stripe Checkout also ships its own managed CAPTCHA, which kicks in dynamically when Stripe’s models detect card-testing patterns.

2. Single-Use Virtual Card Drain

The more sophisticated abuser doesn’t use stolen cards. They use legitimate single-use virtual cards from services such as Privacy.com or Revolut.

• The loophole. A trial signup runs a $0 authorization, which the virtual card passes. The abuser then closes the card. When the first real charge fires at the end of the trial, it’s declined. The attacker has now extracted the full trial period of premium AI usage for free.

• The detection signal. Virtual and prepaid cards have identifiable BIN ranges. Most processors can flag them.

Mitigation, in general: if this pattern shows up in your data, write a rule against prepaid and known-virtual BINs. In Stripe, this is a custom rule in Radar for Fraud Teams. Other processors expose similar BIN targeting via their rule engines. The cost is that some legitimate users (people who genuinely prefer virtual cards for privacy) get blocked, so you can choose whether to enable this on day one, or only once the data shows it’s a real problem.

3. Friendly Fraud and Card-Network Monitoring

The leading cause of opt-out chargebacks is friendly fraud: a real user signs up, forgets to cancel, sees the charge on their statement, and disputes with their bank instead of asking you for a refund. The threshold of concern is the dispute rate.

• Industry standard threshold. Above 0.75% dispute rate, you’re under processor scrutiny. Above 1%, you risk being placed in Visa’s monitoring program. Stripe explicitly recommends staying below 0.75% to avoid being escalated.

• Card-network programs. Both card networks run monitoring programs that can ultimately terminate your processing relationship if dispute activity stays elevated. Visa’s Acquirer Monitoring Program (VAMP) replaced the older VDMP and VFMP programs, with enforcement live since October 1, 2025. Mastercard’s Scam Merchant Monitoring Program (SMMP) takes full effect on July 24, 2026, with confirmed scam activity resulting in immediate termination of Mastercard and Maestro processing.

Mitigation, in general: make the trial reminder and cancellation flow nearly impossible to misuse against you. An email 3 days before the charge clearly stating the upcoming amount, plus a one-click cancellation in the user dashboard, converts most would-be disputers into either renewals or clean cancellations. In Stripe specifically, the customer.subscription.trial_will_end webhook is the trigger point. Other processors expose equivalent events.

TL;DR

The marginal-cost economics of AI-native platforms make the free-trial decision a security- and unit-economics decision, not just a marketing one. Opt-in trials draw a larger top-of-funnel but expose you to compute exfiltration via automated farming. Opt-out trials draw a smaller, higher-intent funnel and shift your residual risk into the payment layer, where the processor’s global fraud signal does most of the work you’d otherwise build in-house.

For an AI-native product where each active trial user burns real tokens, the opt-out posture plus pre-checkout gating (disposable email blocks, a bot challenge, and a clean cancellation flow) is the architecture I’m going with. You don’t get an enterprise-grade anti-abuse stack out of it, but you get most of the way there for a fraction of the engineering cost, and you keep your focus on the product instead of fighting botnets.

As organizations rush to harness and deploy autonomous AI agents for software development, security professionals face a daunting challenge: how do we secure a system that relies on probabilistic reasoning rather than deterministic code?

We’re all looking for ways to bring some secure sanity to this new development paradigm. I started my AI-assisted development experimentation way back in the early days (last year) by spinning up Claude directly in a cloned repo on my development machine (please don’t do that). As we’ll see below, giving an agent that much unfettered access can lead to unfortunate outcomes. Put simply, an agent should never run directly on a developer’s bare-metal machine with full filesystem access, or even broad local access.

The best approach is isolation.

That’s why I wanted to write this article. For CISSP holders and cybersecurity leaders, securing AI dev tools means moving past “prompt engineering” (asking AI to be good) and instead thinking in terms of Harness Engineering.

This short guide provides an overview of what harness engineering is, why it represents an important security boundary for AI agents, and how you can lead an assessment to protect your organization.

What is “Harness Engineering”?

The term harness engineering, coined by Mitchell Hashimoto in early 2026, refers to “designing the environment, specifying intent clearly, and building the feedback loops that allow agents to autonomously build and maintain software.” You could generalize this as defining how modern autonomous systems must be structured:

• The Model is the “Brain”: An LLM (like Claude or GPT) provides the raw reasoning, language processing, and statistical inference. However, in isolation, a model can’t interact with the world.

• The Harness is the “Hands, Eyes, and Guardrails”: the deterministic software infrastructure that wraps around the model. It manages the memory modules, tool registries, database/API connectors, execution loops, and safety checkpoints.

For security professionals, harness engineering encompasses the discipline of designing the control systems that govern how an AI agent perceives its environment, selects actions, and validates its outputs.

Harness components generally fall into two classic control-theory categories:

1. Guides (Feedforward Controls): Active constraints that direct the agent before it acts. Examples include system prompts, constraint documents, and organizational boundaries (such as a CLAUDE.md or AGENTS.md file).

2. Sensors (Feedback Controls): Mechanisms that observe and validate the agent’s behavior after it acts. Examples include real-time validation loops, output parsers, and automated evaluation suites.

Why the Harness is a Better Security Boundary

Early implementations of AI assistants relied on “prompt guardrails” (e.g., “Do not delete files” or “Never disclose system keys”). However, prompts are mere suggestions to a probabilistic model. Under complex multi-step reasoning, context dilution, or adversarial inputs, these prompt-based walls reliably collapse.

And of course, you know this: You wouldn’t secure a database with just a comment like ‘please don’t drop tables.’ You’d write a permission system.

The harness is that permission system.

Without a secure harness, your organization is exposed to severe, agent-specific risks:

• Excessive Autonomy and Tool Abuse: An agent might exploit overly permissive tools to execute high-impact actions without human-in-the-loop validation.

• Indirect Prompt Injection: A malicious payload hidden in an external data source (like a customer PDF, a PR comment, or a web page) can hijack the agent’s reasoning loop. If the agent has a privileged toolset, this injection instantly escalates to remote code execution.

• Malicious Repository Configurations: In tools like Claude Code, repository configuration files (which historically were passive metadata) now control active execution paths. Disclosures such as CVE-2025-59536 and CVE-2026-21852 demonstrated that simply opening or cloning an untrusted project could enable a rogue configuration to execute arbitrary code or steal API credentials.

How to Conduct an AI Agent Harness Assessment

To help your engineering teams transition from risky “vibe coding” to a more hardened, compliant deployment, you can lead a security assessment of their AI agent harness.

This structured assessment methodology maps the bleeding-edge AI risks back to traditional CISSP domains.

Step 1: Map the Trust Boundaries (Asset Security & Architecture)

Before evaluating code, you need to map the data flows. Treat the AI agent as a highly privileged, non-human identity.

• Inventory Entry Points: Where does the agent ingest data? (e.g., User prompts, API responses, RAG databases, and/or external URLs).

• Define Trust Zones: Where does the trusted system end and untrusted data begin? Remember: any data retrieved by the agent (including tool outputs) must be treated as untrusted input.

• Identify Secrets: Ensure the agent’s harness doesn’t have direct access to raw SSH keys, cloud credentials, or long-lived API tokens. Instead, verify it uses scoped, short-lived tokens injected at runtime (typically implemented using OAuth 2.0).

Step 2: Threat Modeling

While the classical Microsoft STRIDE framework is great for static applications, autonomous agents break the idea that software has fixed, predictable roles. We previously explored several threat modeling frameworks, including MITRE ATLAS, and used MAESTRO alongside ATLAS.

Instead of fixed roles, Agents simultaneously behave as users, services, and data pipelines. For the purposes of this discussion, let’s conduct a threat modeling session using STRIDE+A, where “A” stands for AI Agent-Specific Attacks:

Step 3: Audit Tool Permissions & Sandboxing (Identity & Access Management)

Evaluate the physical boundaries of the agent’s execution environment.

• Isolate the Host: As I mentioned at the top, the agent should never run directly on a developer’s bare-metal machine with full filesystem access. It must run inside an ephemeral container (such as a DevContainer), a microVM, or a remote sandbox.

• Enforce Least Privilege: Does the agent have “wildcard” access (e.g., Bash(*))? Scrutinize and restrict allowed commands.

• Network Egress: Is network traffic wide open? Establish a strict network proxy with an allowlist limited to required endpoints (like the LLM provider and specific package registries) to prevent data exfiltration.

Step 4: Assess the Guides and Sensors (Security Assessment & Testing)

Review how the engineering team is instructing and observing the model.

• Feedforward Check: Review system instructions and constraint files (e.g., AGENTS.md or CLAUDE.md). Are they under version control? Are they concise (ideally under 150 lines) to avoid context bloat?

• Feedback Check: Does the harness use deterministic validation loops? If the agent edits code, does a PostToolUse hook automatically run tests and linters before committing?

• Human-in-the-Loop Gates: Ensure that destructive, financial, or externally visible actions (like pushing to production or deploying code) require explicit, independent human authorization.

Step 5: Implement Continuous Automated Scanning (Security Operations)

Unfortunately, we can’t treat this assessment as a one-time gate. The threat landscape of Model Context Protocol (MCP) servers and agent skills is evolving daily.

• Static Configuration Auditing: Integrate tools like AgentShield (ecc-agentshield) into your team’s local environments or CI/CD pipelines. These scanners continuously look for hardcoded secrets, overly permissive tool definitions, and risky MCP server configurations before code is committed.

• Behavioral Regression Testing: Introduce frameworks like the OWASP Agent Security Regression Harness. This allows security teams to run executable security regression scenarios against the agentic application, verifying that prompt or model updates do not introduce new security failures or allow goal hijacking.

What are you using to keep your development environment secure?

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