Section 1 Quiz

--- shuffle_answers: true shuffle_questions: false --- ## An organization has budget to implement AI security in only ONE DevSecOps stage this quarter. Their AI chatbot is already in production with no security controls. Which stage should they prioritize FIRST to get the broadest risk reduction? > Hint: Consider which stage addresses the most attack surface for the lowest effort when an AI system is already deployed, and think about dependency relationships between stages. - [ ] Plan -- threat modeling is the foundation everything else rests on, so it should always come first > Threat modeling is valuable but produces documentation, not runtime protection. For an already-deployed system with zero controls, a planning exercise doesn't reduce active risk. The system is live and exposed now -- you need controls that intercept attacks in real time. - [ ] Train -- securing the training pipeline prevents data poisoning from reaching the model > Training pipeline security prevents future poisoning, but the model is already trained and deployed. Securing the training stage protects the next training cycle, not the currently running system. The immediate risk is at the runtime boundary. - [ ] Validate -- red-team testing will identify the vulnerabilities that need fixing first > Validation testing reveals vulnerabilities but doesn't stop attacks against the live system. Testing informs what to fix, but without runtime controls, every vulnerability found remains exploitable. Testing is most valuable after you have controls to validate. - [x] Monitor -- runtime filtering and anomaly detection defend the live system now, and feed every other stage > Correct! Monitor is prioritized because it provides the broadest immediate risk reduction for an already-deployed system. Runtime prompt/response filtering and anomaly detection actively intercept attacks happening right now -- unlike Plan (produces documents), Train (protects future cycles), or Validate (identifies but doesn't block). The judgment framework: (1) coverage breadth -- Monitor addresses injection, data leakage, cost abuse, and anomalous behavior simultaneously; (2) cost-effectiveness -- a single AI Guard deployment covers the entire live attack surface; (3) dependency value -- Monitor generates threat intelligence (blocked attacks, usage patterns) that makes future Plan, Train, and Validate stages more targeted and effective. ## A security architect is performing a threat model for an LLM deployment using STRIDE adapted for AI. Which of the following correctly maps a STRIDE category to an AI-specific threat? > Hint: Review how traditional STRIDE categories translate to AI-specific attack surfaces. - [ ] Spoofing: an attacker poisons the training corpus to introduce systematically biased outputs > Training data poisoning is Tampering (modifying data), not Spoofing. Spoofing in AI contexts involves impersonation -- agent identity spoofing, deepfake credentials, or impersonating legitimate MCP servers. - [x] Elevation of Privilege: injection escalating from text generation to tool execution > Correct! In AI-adapted STRIDE, Elevation of Privilege includes prompt injection that escalates to tool use, agent privilege abuse, and excessive agency exploitation. When an attacker uses injection to make a chatbot execute tools it shouldn't, that's a privilege escalation from the text domain to the action domain. - [ ] Information Disclosure: an agent is manipulated into performing actions it is not authorized to take > Unauthorized actions map to Elevation of Privilege or Tampering, not Information Disclosure. AI-specific Information Disclosure covers system prompt leaking, training data extraction, and PII in model responses. - [ ] Denial of Service: an attacker extracts the confidential system prompt from a deployed model > System prompt extraction is Information Disclosure, not Denial of Service. AI-specific Denial of Service covers unbounded consumption, context window stuffing, and GPU exhaustion. ## In the shared responsibility model for AI security, which responsibility falls primarily on the enterprise security team rather than the AI provider? > Hint: Consider what AI providers typically handle versus what enterprises must secure themselves. - [ ] Base model safety training, alignment tuning and content policy enforcement > Base model safety training is the AI provider's responsibility. Providers like OpenAI and Anthropic handle alignment, safety training, and content policies for their base models. - [ ] API endpoint availability, uptime guarantees and volumetric DDoS protection > API infrastructure security is primarily the provider's responsibility. They maintain uptime, handle DDoS protection, and ensure API availability. - [x] Tool and agent security -- allowlisting, permission scoping, execution monitoring > Correct! Tool and agent security falls entirely on the enterprise. AI providers typically don't provide tool security because they don't control how organizations configure agentic capabilities. Tool allowlists, permission scoping, execution monitoring, and agent guardrails are all enterprise responsibilities -- and this is one of the most critical gaps in the shared responsibility model. - [ ] Encryption of data in transit on every call to the hosted API endpoint > Encryption in transit for hosted APIs is the provider's responsibility. Providers implement TLS on their API endpoints. ## A security team wants to map Chapter 2's attack domains to the Blueprint defense layers. Which mapping correctly connects an attack domain to its primary defense approach? > Hint: Think about which Blueprint layers address which types of threats. - [ ] Prompt-level attacks (Section 2) are primarily addressed by Layer 1 (Data), through data classification and labelling > Layer 1 protects data assets. Prompt-level attacks (injection, jailbreaking) are primarily addressed by Layer 5 (Access) through input/output filtering and Layer 6 (Zero-Day) through behavioral detection. - [x] Agentic attack vectors (Section 5) are addressed by Layers 3 and 5, through tool controls, execution monitoring and ZTSA > Correct! Agentic attacks -- tool misuse, privilege escalation, agent hijacking -- require infrastructure-level controls (AI-SPM posture management, orchestration security) from Layer 3 and access-level controls (ZTSA, rate limiting) from Layer 5. These two layers together constrain what agents can do and how they interact with services. - [ ] Model and infrastructure attacks (Section 4) are primarily addressed by Layer 4 (Users), through security awareness training > Model and infrastructure attacks target technical components, not users. They're addressed by Layer 2 (Models -- container security) and Layer 3 (Infrastructure -- posture management). - [ ] Output and trust exploitation (Section 6) is primarily addressed by Layer 6 (Zero-Day), through virtual patching > Output exploitation is primarily addressed by Layer 4 (Users -- protecting humans from misleading outputs) and Layer 5 (Access -- response filtering). Layer 6 handles unknown/novel threats, not established output exploitation patterns. ## When an organization moves from a cloud-hosted AI model to a self-hosted deployment, how does the shared responsibility model change? > Hint: Consider what the cloud provider was handling that now falls on the organization. - [ ] The responsibility split stays exactly the same, because self-hosting does not change who secures what > Self-hosting dramatically shifts the responsibility boundary. Functions previously handled by the AI provider now fall on the organization. - [ ] The AI provider becomes responsible for more, since it must support the self-hosted deployment > Self-hosting reduces the provider's involvement, not increases it. The organization takes on infrastructure security that the provider previously handled. - [x] The enterprise takes on nearly all of them -- infrastructure, weight protection, safety validation > Correct! Self-hosting shifts the responsibility boundary dramatically. The enterprise must now secure the model serving infrastructure, protect model weights from extraction, validate base model safety for their use case, manage API infrastructure, and handle all the responsibilities that a cloud provider previously covered. This is directly relevant to the infrastructure attacks from Chapter 2 Section 4. - [ ] Most security responsibilities are eliminated, because the data now stays on-premises > Data staying on-premises doesn't eliminate security responsibilities. It actually increases them because the organization must now secure infrastructure that was previously managed by the cloud provider. ## A development team is deploying a model that classifies customer support tickets. During threat modeling, they identify that an attacker could submit crafted tickets that cause the model to misclassify urgent issues as low-priority. Which STRIDE category best describes this threat? > Hint: Think about what the attacker is changing and what effect it has on the system's outputs. - [ ] Spoofing -- the attacker is pretending to be a legitimate paying customer of the service > The attacker may be a legitimate customer. The threat isn't about identity -- it's about manipulating the data the system processes to corrupt its output. - [x] Tampering -- the attacker modifies input data to corrupt the classification output > Correct! Tampering in AI-adapted STRIDE covers modifying data that the AI system processes. By crafting tickets with specific characteristics that exploit classification boundaries, the attacker tampers with the model's input to produce incorrect outputs. This maps to both training-time tampering (data poisoning) and inference-time tampering (adversarial inputs). - [ ] Denial of Service -- the misclassification prevents the system from functioning > Misclassification degrades output quality but doesn't prevent the system from functioning. Denial of Service in AI contexts involves resource exhaustion, context window stuffing, or GPU monopolization. - [ ] Repudiation -- the attacker later denies having submitted the crafted tickets > While the attacker might deny their actions, the core threat is the manipulation of classification outputs, not the inability to attribute actions. Repudiation in AI covers audit gaps and missing tool call logs. ## An architect maps SLM threats from Chapter 2 Section 7 onto the Blueprint and lands on Layer 4 (Users), reasoning that SLMs run on endpoints. What is the mapping missing? > Hint: Endpoint governance addresses the deployment. What addresses the artifact that was deployed? - [ ] Nothing is missing -- SLMs run on endpoints, so Layer 4 is a complete answer for them > Layer 4 is a correct part of the answer and the right instinct. It is not the whole one, because it governs the endpoint rather than the model that was put on it. - [x] Layers 2 and 3 -- model provenance and edge posture are separate problems from the endpoint > Correct! Layer 4 covers endpoint security and shadow AI governance, which matter because SLMs run where users are. But two of the section's biggest findings sit elsewhere: provenance is a Layer 2 problem, since distillation, fine-tuning and quantization each change safety without changing benchmarks, and patch staleness and the absent rate-limit are Layer 3 posture problems. A mapping that stops at Layer 4 governs the laptop and never asks what was installed on it. - [ ] Layer 6, because zero-day defense is what catches novel attacks against small models > Layer 6 handles novel and unknown threats. The dominant SLM risks are neither -- weak alignment and unreviewed provenance are known, measurable and testable before deployment. - [ ] Layer 1, because the training data behind the small model is the actual root cause > Training data does drive SLM safety, but it is the vendor's data and outside Layer 1's scope, which covers data you hold. What you control is which artifact you accept. ## An organization runs a fleet of agents that call tools and hand work to each other. A consultant proposes threat-modelling it with STRIDE. What is the strongest objection? > Hint: STRIDE analyses entities and the flows between them. What does an agent do to that assumption? - [ ] STRIDE is outdated and has been formally superseded for every type of system > STRIDE has not been superseded and remains the right tool for an LLM behind an API with static trust boundaries. The objection is about fit, not currency. - [ ] STRIDE has no category that covers prompt injection, so the attack would be missed > Prompt injection does map -- to Elevation of Privilege when it reaches tool use, and Tampering at the input. Category coverage is not where STRIDE struggles here. - [x] An agent is caller, callee and data store at once, and its boundaries move at runtime > Correct! STRIDE assumes entities with fixed roles and trust boundaries drawn at design time. An agent violates both: its output becomes its own next input, it is simultaneously a client, a service and a memory store, and installing a tool redraws the boundary at runtime. Multi-agent interaction is outside the model entirely. This is the gap CSA's MAESTRO was published to fill, with seven layers to reason across rather than six threat categories per entity. Use MAESTRO for the system and STRIDE inside a layer where the boundaries do hold still. - [ ] STRIDE requires a data flow diagram, and agentic systems cannot be diagrammed at all > Agentic systems can be diagrammed. The problem is that the diagram is only valid until the agent's tool set changes, not that it cannot be drawn. ## A vendor states that its foundation model has undergone extensive safety alignment. Your team downloads a community 4-bit quantized fine-tune of that model and self-hosts it. How much of the vendor's safety assurance transfers? > Hint: Which artifact did the vendor actually test? - [ ] All of it, because safety alignment is a property of the model architecture and weights > Alignment is a property of a particular set of weights, and the fine-tune and quantization both changed them. Architecture is unchanged; the behaviour is not. - [ ] Most of it, since fine-tuning adjusts capability while leaving safety behaviour intact > Capability and safety are separable, which is exactly the problem. Fine-tuning degrades alignment even on benign data, and benchmark parity says nothing about refusals. - [x] None of it -- the claim covered the artifact the vendor shipped, and two steps have changed it > Correct! A safety assurance is a statement about a specific build. Chapter 2 Section 7 showed each transformation can change safety without changing capability: fine-tuning degrades alignment even on benign data, and quantization changes behaviour in a direction the evidence still disputes. Because your artifact is two steps removed from the tested one, the claim does not transfer -- and neither does the responsibility. Self-hosting also moves weight protection, infrastructure security and rate limiting onto you, none of which the vendor's assurance ever covered. - [ ] It transfers only when the fine-tune was published by the same vendor as the base model > Provenance helps, but the same-vendor case still involves an untested artifact. What restores the assurance is evaluating the build you ship, not the identity of who produced it.