CAS-005 Security engineering

Security engineering Detailed Explanation

Security engineering questions in CAS-005 usually test whether you can diagnose how security controls behave under failure. The domain blends IAM, endpoint protection, network protocols, specialized systems, automation, and cryptographic implementation. The correct answer normally follows the evidence object that owns the behavior: token claim, secret version, route decision, certificate chain, TPM attestation, HSM custody, SOAR approval, or signed artifact.

Enterprise IAM Troubleshooting and Secrets Control

Exam Radar

Official Objective Mapping: Security engineering; related CAS-005 objective areas: identity and access management implementation, federation, authorization, PAM, secrets management, certificates, tokens, MFA, Kerberos, cloud trust policy, and workload identity.

Plain-English Understanding: This topic tests whether you can troubleshoot IAM by separating who authenticated, what claims or scopes were issued, what resource was requested, and which policy denied or allowed the action. Successful login does not prove authorization.

Key Concepts: SAML assertion; OIDC ID token; OAuth access token; Kerberos ticket; MFA claim; PAM session; secret rotation; workload identity.

Exam Focus: authentication versus authorization, token audience, scopes, claims, PAM state, secret version, and workload identity binding.

• Core Priority: Identify the IAM layer that matches the symptom before changing permissions.
• High Frequency: CAS-005 asks about users or services that can authenticate but cannot perform the intended action.
• Confusion Alert: Password resets rarely fix claim mapping, token audience, scope, or resource-policy problems.
• Scenario Logic: Inspect issuer, audience, subject, scopes, role claims, resource policy, PAM approval, and secret version in that order.
• Version Delta: SecurityX expects cloud workload identity, federated claims, PAM, and secret-vault behavior in the same troubleshooting space.
• Failure Trigger: Broadening access before reading token or vault evidence can hide the cause and create new exposure.
• Operational Dependency: The resource must trust the issuer and audience, receive the needed claim or scope, and enforce the correct policy.
• How the Exam Asks It: The stem often says login succeeds, an API returns 403, or a rotated secret is not consumed.
• How Distractors Are Designed: Wrong answers reset unrelated credentials, bypass PAM, or rotate everything without identifying the active binding.
• Why the Correct Answer Works: It inspects the exact identity artifact that the resource uses to authorize the request.

Practice Question: An API returns 403 for a service account after migration to OIDC. Authentication logs show a valid token. What should be inspected first?

A. Token audience, scopes, subject, issuer, and resource API policy B. User desktop wallpaper policy C. The number of failed antivirus updates D. A new VLAN name

Correct Answer: A

Explanation: A is correct because a valid token with a 403 response points to authorization. Audience, scope, subject, issuer, and resource policy explain whether the API should accept the request. Desktop policy, antivirus updates, and VLAN names do not explain a token-based authorization failure.

Practice Question: A database password was rotated in the vault, but the application still uses the old credential. Which evidence best identifies the problem?

A. A list of all domain users B. Secret version, application binding, workload identity permission, and last successful retrieval log C. Firewall rules for a different subnet D. The public key of the code-signing certificate

Correct Answer: B

Explanation: B is correct because secret rotation only works when the application is bound to the current secret version and can retrieve it with the right identity. Domain user lists, unrelated firewall rules, and signing certificates do not show which secret the workload actually consumed.

Exam Takeaway: For IAM failures, the best first check is the artifact the resource evaluates: assertion, token audience, scope, claim, PAM approval, policy condition, or secret version.

Atomic Deconstruction - Operational Level

What this topic really tests: can you identify the IAM layer where the failure occurs? Authentication validates identity. Authorization evaluates claims, scopes, roles, groups, policies, and resource conditions. PAM controls temporary privileged access. Secrets systems control credential versions and retrieval permissions. The best answer inspects the layer that matches the symptom instead of applying a broad access change.

Beginner-friendly grounding: For IAM questions, do not treat successful login as successful access. Check the token, claim, scope, policy, PAM state, or secret version that the resource actually uses.

Exam transformation: wrong options usually appear as resetting passwords for a claim-mapping failure; broadening permissions before checking token audience; using standing privilege instead of PAM; rotating every secret before identifying the active version. These options can sound professional, but they solve the wrong layer or skip the state that must be proven. The correct option matches the security property, operational phase, and evidence requirement described by the stem.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
SAML assertion	Issuer, audience, subject, attributes	Signed, encrypted, expired, invalid audience	Provider default claims	IdP and SP metadata	Authentication succeeds but authorization fails because claims do not match application policy
OAuth token	Scope and audience	Least-privilege scope to broad delegated access	Excessive or stale grant	Authorization server and resource API	API rejects access or allows unintended actions
PAM session	Privileged elevation state	Approved, active, expired, recorded	Standing privilege	PAM policy and approval workflow	Privileged action lacks accountability or remains active after task completion
Secret object	Rotation and deletion state	Current, expiring, revoked, orphaned	Long-lived credential	Secrets vault and workload identity	Application outage or compromise occurs due to stale key or exposed password

Step-by-Step Execution Path

1. Separate authentication failure from authorization failure by reading identity provider sign-in logs and application access logs. This prevents resetting credentials when the issue is claim or scope related.
2. Validate federation metadata, signing certificate, issuer, audience, clock skew, and claim transformation. These fields determine whether the application trusts the assertion or token.
3. Inspect effective permissions for the subject: user, process, device, or service. IAM failures often involve the wrong principal type.
4. Review PAM elevation, approval, recording, and session expiration for privileged tasks. Standing privilege should not be treated as a troubleshooting shortcut.
5. Check secret age, rotation history, vault access policy, and workload binding. Expected evidence shows valid secret version and least-privilege access path.

Command and evidence confidence: Use vendor-supported consoles, management APIs, SIEM/EDR views, GRC workflow evidence, repository settings, cloud audit views, or version-aware CLI verification for the deployed platform. Treat generic shell snippets, sample queries, and tabletop rehearsals as lab rehearsal unless they are validated against the organization's active tool version.

Technical Chain

The chain starts with a principal such as user, service account, workload identity, or device. The identity provider authenticates it, issues a token or assertion, and the target resource evaluates audience, issuer, claims, scopes, roles, and policy conditions. For secrets, the workload must authenticate to the vault, request the correct version, and satisfy access policy. A failure at any step produces a different symptom, so the correct response follows the evidence path.

A strong exam answer follows this chain without skipping layers. First identify the event or requirement, then the object that controls it, then the dependency that must be valid, then the evidence source that proves the state. If the option jumps straight to remediation while the controlling dependency is unknown, it is usually a distractor.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Inspect federated sign-in result	Identity provider logs: user sign-in > token details > conditional access and claims	Authentication status, issuer, audience, and group or role claims match application requirements
Validate API token scope	Authorization server introspection endpoint or admin portal token view	Token is active, unexpired, intended for the resource API, and limited to required scopes
Review privileged session	PAM console: request > approval > session recording > expiration	Privileged access is approved, time-bound, recorded, and revoked after completion
Check secret rotation state	Secrets vault: secret > versions > last rotation > access policy	Only current secret version is active and workload identity has least-privilege read access

Endpoint, Server, and Network Security Failure Analysis

Exam Radar

Official Objective Mapping: Security engineering; related CAS-005 objective areas: endpoint, server, and network security controls, EDR, application control, host firewall, SELinux/AppArmor, DNSSEC, DKIM/SPF/DMARC, TLS, PKI, IPS, ACLs, routing, and secure protocol validation.

Plain-English Understanding: This topic tests whether you can correlate host behavior, network path, name resolution, email authentication, and cryptographic trust. The first answer should collect the signal that separates endpoint compromise from route, policy, DNS, mail, or TLS failure.

Key Concepts: EDR process tree; application allow list; host firewall profile; SELinux/AppArmor enforcement; DNSSEC; SPF/DKIM/DMARC; TLS certificate chain; ACL and route path.

Exam Focus: correlate endpoint behavior with route, ACL, DNS, mail-authentication, TLS, and PKI evidence instead of fixing one layer blindly.

• Core Priority: Build a timeline across host, network, identity, DNS, email, and TLS evidence.
• High Frequency: Questions combine endpoint alerts with routing or protocol symptoms to see whether you overfocus on one tool.
• Confusion Alert: Opening all traffic, disabling DMARC, or rebuilding servers before evidence collection usually makes the situation worse.
• Scenario Logic: Ask which layer first diverges from expected behavior: process, local policy, route, ACL, name validation, sender alignment, or certificate trust.
• Version Delta: CAS-005 engineering items expect cross-layer troubleshooting rather than isolated endpoint or network definitions.
• Failure Trigger: Evidence becomes misleading when endpoint, network, and protocol timestamps are not correlated.
• Operational Dependency: EDR mode, host firewall profile, route table, DNS record, email-authentication result, and TLS chain must agree with the scenario path.
• How the Exam Asks It: The stem may mention intermittent access, suspicious execution, email alignment failure, or external-only TLS errors.
• How Distractors Are Designed: Wrong answers apply a broad fix that suppresses evidence or widens exposure.
• Why the Correct Answer Works: It identifies the failing layer before containment, route changes, or policy relaxation.

Practice Question: A TLS-enabled service fails only for external clients. Internal clients work. What should be validated first?

A. Whether all users completed annual training B. External certificate chain, SAN, SNI listener, firewall path, and negotiated cipher/protocol C. Whether source code comments are formatted D. Whether an unrelated EDR policy exists on laptops

Correct Answer: B

Explanation: B is correct because the failure appears only on the external access path. Certificate chain, SAN, SNI, firewall path, and cipher negotiation are the evidence points external clients depend on. Training, comments, and unrelated EDR policy do not explain the path-specific TLS symptom.

Practice Question: Outbound email is delivered but fails DMARC alignment for a new marketing platform. What evidence matters most?

A. A screenshot of endpoint disk usage B. The number of VLANs in the data center C. SPF include chain, DKIM selector signature, From-domain alignment, and DMARC report disposition D. Kerberos ticket lifetime for database admins

Correct Answer: C

Explanation: C is correct because DMARC depends on SPF or DKIM alignment with the visible From domain. The marketing platform must be authorized and signing correctly. Disk usage, VLAN count, and Kerberos settings are unrelated to sender authentication.

Exam Takeaway: When symptoms span host, network, DNS, email, or TLS, choose correlation evidence before broad changes that disable controls or widen access.

Atomic Deconstruction - Operational Level

What this topic really tests: can you avoid single-layer thinking? Endpoint alerts explain process behavior, but not necessarily routing. ACL counters show path decisions, but not application identity. DNSSEC and email authentication prove name and sender integrity. TLS validates identity and cryptographic negotiation. The exam often combines symptoms so that the correct answer is correlation, not a single dramatic fix.

Beginner-friendly grounding: Endpoint and network failures are usually layered. A process tree, route table, DNS result, mail-authentication record, and TLS chain may each explain a different part of the same symptom.

Exam transformation: wrong options usually appear as opening all firewall traffic to fix diagnosis; turning off DMARC for convenience; rebuilding systems before collecting evidence; using one telemetry source for a multi-layer failure. These options can sound professional, but they solve the wrong layer or skip the state that must be proven. The correct option matches the security property, operational phase, and evidence requirement described by the stem.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
EDR alert	Process and behavior context	Blocked, detected, isolated, allowed	Passive detection only	Telemetry and response policy	Lateral movement or credential dumping continues because response mode is not enforced
Host firewall rule	Local ingress/egress decision	Allow, deny, profile-based	Broad allow	Endpoint profile and service dependency	A service is exposed or blocked contrary to workload requirements
DNSSEC chain	Validation status	Secure, insecure, bogus	Not validated	Resolver and zone signing	Users are exposed to poisoning or name resolution fails for signed zones
TLS certificate	Subject, SAN, validity, chain, cipher	Valid, expired, mismatched, weak	PKI trust store and server config	Clients fail validation or negotiate weak cryptography

Step-by-Step Execution Path

1. Build a timeline from change records, route updates, endpoint alerts, and user reports. Complex failures require sequencing before remediation.
2. Validate endpoint controls: EDR mode, application allow list, host firewall profile, SELinux or equivalent enforcement state, and process lineage. The first endpoint signal should identify behavior, not only malware name.
3. Inspect network security path: route table, ACL, VPN tunnel state, IPS rule hits, and sensor placement. Misplaced sensors can hide the real traffic.
4. Check DNS and email authentication with resolver validation, SPF include chains, DKIM selector records, and DMARC alignment reports. Email security failures are evidence-driven.
5. Verify TLS and PKI state: certificate chain, SAN, expiration, OCSP or revocation behavior, and cipher policy. Expected state is a valid trust chain and approved protocol negotiation.

Command and evidence confidence: Use vendor-supported consoles, management APIs, SIEM/EDR views, GRC workflow evidence, repository settings, cloud audit views, or version-aware CLI verification for the deployed platform. Treat generic shell snippets, sample queries, and tabletop rehearsals as lab rehearsal unless they are validated against the organization's active tool version.

Technical Chain

The chain starts with a user action, process execution, packet flow, DNS lookup, email send, or TLS handshake. Each layer emits different evidence: EDR timeline, host firewall profile, route table, ACL hit counter, DNS validation result, DKIM signature, DMARC disposition, certificate chain, and cipher negotiation. Correct troubleshooting orders these signals to isolate where trust, route, authentication, or enforcement fails.

A strong exam answer follows this chain without skipping layers. First identify the event or requirement, then the object that controls it, then the dependency that must be valid, then the evidence source that proves the state. If the option jumps straight to remediation while the controlling dependency is unknown, it is usually a distractor.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Review endpoint execution evidence	EDR console: device timeline > process tree > response action	Suspicious process lineage, user context, and block or isolation action are visible
Inspect route and ACL path	Network management console: route table > ACL hit counters > VPN tunnel status	Traffic follows expected route and denied flows match intended policy
Validate email authentication	DNS lookup tools or email security portal: SPF, DKIM selector, DMARC aggregate report	SPF passes or aligns, DKIM signature validates, and DMARC disposition matches policy
Check TLS trust state	Version-aware TLS verification: inspect certificate chain, SAN, expiration, and negotiated cipher	Certificate chain is trusted and negotiated cipher/protocol meets policy

Hardware, Specialized Systems, Automation, and Cryptographic Use Cases

Exam Radar

Official Objective Mapping: Security engineering; related CAS-005 objective areas: hardware and specialized systems, OT/IoT/embedded constraints, automation and orchestration, cryptographic implementation, HSM, TPM/vTPM, secure boot, code signing, tokenization, envelope encryption, and post-quantum planning.

Plain-English Understanding: This topic tests whether you can match a control to the environment and data state. OT safety, HSM key custody, TPM attestation, SOAR automation, code signing, tokenization, AEAD, and envelope encryption are not interchangeable.

Key Concepts: TPM/vTPM; HSM; secure boot; OT segmentation; passive monitoring; SOAR playbook; SCAP; AEAD; envelope encryption; tokenization; code signing; PQC readiness.

Exam Focus: choose the control that matches the security property: platform integrity, key custody, release provenance, safe OT monitoring, automation safety, or data-state protection.

• Core Priority: Match control choice to asset type, safety constraint, and security property.
• High Frequency: Questions contrast enterprise IT assumptions with OT, embedded, hardware-trust, automation, or cryptographic requirements.
• Confusion Alert: Encryption, signatures, tokenization, and HSM custody protect different things.
• Scenario Logic: Identify whether the stem asks for confidentiality, integrity, provenance, attestation, recoverability, or non-disruptive monitoring.
• Version Delta: CAS-005 expands coverage of specialized systems, automation, cryptographic design, and future-facing PQC planning.
• Failure Trigger: Using an aggressive or generic control in fragile systems can create availability and safety risk.
• Operational Dependency: Hardware trust requires attestation; signing requires protected private keys; SOAR requires safe triggers, approvals, and audit records.
• How the Exam Asks It: The stem may ask how to monitor OT safely, prove release integrity, protect keys, or automate response without destroying evidence.
• How Distractors Are Designed: Wrong answers confuse confidentiality with provenance or trade safety for convenience.
• Why the Correct Answer Works: It satisfies the precise security property while respecting the environment's operating constraints.

Practice Question: A build system must prove that release binaries were not altered after approval. Which control is most direct?

A. Tokenizing developer comments B. Turning on passive DNS logging only C. Code signing with protected private key custody and hash verification D. Increasing password length for help-desk users

Correct Answer: C

Explanation: C is correct because release integrity and provenance require a verifiable signature tied to protected key custody and artifact hash validation. Tokenization, passive DNS, and password policy may be useful elsewhere, but they do not prove that the binary matches the approved release.

Practice Question: A plant network contains fragile PLCs that cannot tolerate aggressive scans. Which approach best fits the environment?

A. Continuous unauthenticated scanning of every PLC B. Removing segmentation to simplify operations C. Giving controllers direct internet access for patch downloads D. Passive monitoring, segmentation, allow-listed communications, and vendor-approved maintenance testing

Correct Answer: D

Explanation: D is correct because OT security must preserve safety and availability. Passive monitoring and segmentation reduce risk without disrupting controllers, while maintenance testing respects vendor constraints. Aggressive scans, removed segmentation, and direct internet access create operational danger.

Exam Takeaway: Choose the mechanism that matches the property being tested: attestation, key custody, provenance, safe OT visibility, automation control, or data-state protection.

Atomic Deconstruction - Operational Level

What this topic really tests: can you choose controls by operational constraint and security property? TPM and secure boot support platform integrity; HSMs protect keys; code signing proves artifact provenance; tokenization reduces sensitive-data exposure; envelope encryption scales key hierarchy; SOAR automates response only when evidence, approval, and rollback are designed. Specialized systems require safety-aware control selection.

Beginner-friendly grounding: Match the control to the security property. TPM proves platform state, HSM protects key custody, code signing proves artifact integrity, tokenization reduces data exposure, and OT monitoring must avoid unsafe disruption.

Exam transformation: wrong options usually appear as actively scanning safety-critical OT without approval; storing signing keys on a build server filesystem; using encryption when integrity/provenance is required; automating containment without evidence or approval controls. These options can sound professional, but they solve the wrong layer or skip the state that must be proven. The correct option matches the security property, operational phase, and evidence requirement described by the stem.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
TPM or vTPM	Measured boot and key protection	Enabled, disabled, attested	Disabled or unmeasured	Firmware and platform trust	Disk or workload keys can be used without platform integrity proof
HSM key	Centralized key protection	Generated, imported, rotated, disabled	Software-stored key	Crypto service and access policy	Private keys are exportable or lack separation of duties
SOAR playbook	Automated response logic	Manual approval, auto-containment, evidence collection	Ad hoc script	SIEM alert and response integration	Automation acts on false positives or misses required evidence
Cryptographic control	Use-case fit	AEAD, envelope encryption, tokenization, digital signature, PQC candidate	Generic encryption	Data state and regulatory need	Wrong technique protects the wrong state or breaks performance constraints

Step-by-Step Execution Path

1. Classify the environment: enterprise endpoint, server, cloud workload, OT, IoT, embedded, or legacy. Control selection depends on operational constraints and safety impact.
2. For hardware trust, verify secure boot, measured boot, TPM or vTPM attestation, HSM-backed key status, and firmware update path. These controls anchor integrity before software controls run.
3. For specialized systems, prioritize passive monitoring, segmentation, allow-listed communications, vendor-supported maintenance windows, and regulatory or safety requirements. Aggressive scans can create outage risk.
4. For automation, inspect trigger source, enrichment step, approval requirement, containment action, rollback path, and audit record. SOAR should preserve evidence before action when attribution matters.
5. For cryptography, match technique to use case: AEAD for confidentiality plus integrity, signatures for non-repudiation and provenance, tokenization for reducing sensitive data exposure, and envelope encryption for scalable key hierarchy.

Command and evidence confidence: Use vendor-supported consoles, management APIs, SIEM/EDR views, GRC workflow evidence, repository settings, cloud audit views, or version-aware CLI verification for the deployed platform. Treat generic shell snippets, sample queries, and tabletop rehearsals as lab rehearsal unless they are validated against the organization's active tool version.

Technical Chain

The chain starts with the asset type and required security property. A boot process needs measured integrity, so TPM and secure boot matter. A signing process needs non-exportable private keys, so HSM or managed signing custody matters. OT monitoring needs visibility without unsafe traffic, so passive sensors and segmentation matter. Automation needs trustworthy triggers and audit records. Cryptography must match data state and objective: confidentiality, integrity, provenance, or exposure reduction.

A strong exam answer follows this chain without skipping layers. First identify the event or requirement, then the object that controls it, then the dependency that must be valid, then the evidence source that proves the state. If the option jumps straight to remediation while the controlling dependency is unknown, it is usually a distractor.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Validate platform trust	Firmware or endpoint security console: secure boot > measured boot > TPM attestation	Boot state is measured and attested before secrets or workloads are trusted
Inspect HSM-backed key status	Key management console: key material origin > exportability > rotation history	Private key is non-exportable or policy-restricted and has current rotation evidence
Review SOAR playbook safety	SOAR console: playbook > trigger > approval gate > audit log	Automated action has evidence collection, approval where required, and reversible containment
Check code-signing provenance	Build/release system: artifact signature > certificate chain > hash verification	Artifact signature validates and hash matches released binary or container image