CSIS common mistakes
CSIS · Understand the traps and how to avoid them.
Answers risk scenarios by picking whichever treatment sounds safest - 'avoid' or 'transfer' - or by choosing 'accept' outright, without naming who holds acceptance authority and without separating inherent from residual risk.
Items are graded on the decision process, but candidates pattern-match on trigger words like 'insurance' or 'cannot be eliminated' instead of applying the treatment criteria to the stated facts.
What to do instead
For every risk item write down asset, threat, vulnerability, likelihood and impact before looking at the options. Apply the rule: avoid only if the activity can be discontinued; transfer only if a third party can bear the financial consequence; mitigate if a control changes likelihood or impact; accept only with documented management sign-off. Where figures are given, compute ALE = SLE x ARO and state which input changed.
Selecting the most restrictive-sounding access control model - almost always MAC - for scenarios that describe job functions or delegation of access decisions to a resource owner.
Candidates rank models by perceived strength instead of asking which party makes the access decision in the scenario, and MAC sounds like the 'most secure' answer.
What to do instead
Before choosing, answer one question: who decides access? Owner discretion = DAC; labels and clearances = MAC; job role = RBAC; multiple attributes or context = ABAC. Then pick the option consistent with that decision-maker rather than the option that sounds strongest.
Mixing cryptographic primitives - using a hash to try to provide confidentiality, or applying RSA to encrypt a large data set directly.
Exam stems describe a goal ('protect the file', 'prove who sent it') without naming the primitive, and all cryptographic functions get filed under one mental category.
What to do instead
Keep a one-line map and answer from the stated goal, not the algorithm name: confidentiality = encryption (symmetric for bulk data, asymmetric for small payloads and key transport); integrity = hash or MAC; non-repudiation = digital signature made with the sender's private key. If an option offers a hash for confidentiality, eliminate it immediately.
Placing a control at the wrong layer or treating a segmentation feature as a security boundary - for example expecting a WAF to stop ARP spoofing, or treating a VLAN as a trust boundary between tenants.
Controls are memorized as a flat list of product names rather than as functions operating at a specific point on the packet path.
What to do instead
Before answering, sketch the path from source to protected asset and mark where each candidate control sits. Match the control to the layer it actually operates at, and assume any Layer 2 segmentation can be crossed unless an Layer 3/Layer 4 policy enforces it.
Confusing the classic security models - applying Bell-LaPadula's no-read-up rule to integrity, or Biba's rules to confidentiality - when the stem names a model or a property.
The rules are learned as slogans without being anchored to the property the model exists to protect, so they get swapped under time pressure.
What to do instead
Anchor each model to its property and re-derive the rule from it: Bell-LaPadula protects confidentiality (no read up, no write down); Biba protects integrity (no read down, no write up); Clark-Wilson protects integrity through well-formed transactions and separation of duty. Ask 'what leaks, or what gets corrupted?' before selecting.
Treating a certification or compliance attestation as evidence that a system is secure, and mislabeling governance documents - calling a standard a policy, or a procedure a guideline.
Compliance terminology dominates the study material and the document hierarchy is rarely practiced, so the four tiers blur into one another.
What to do instead
Rank documents explicitly: policy (management intent, mandatory, high level) then standard (mandatory specifics) then procedure (step-by-step) then guideline (recommended). On compliance items, state what the requirement compels, then state the residual risk it leaves unaddressed - the correct option usually distinguishes the two.
Jumping from detection straight to eradication, or reimaging an affected host before evidence and chain of custody are captured; also swapping RTO and RPO.
Incident response feels intuitive as 'fix it fast', and the two recovery metrics are both stated in time units and sound interchangeable.
What to do instead
Justify each phase in order and say why it must precede the next: preparation, detection and analysis, containment, eradication, recovery, lessons learned. Containment precedes eradication, and evidence capture precedes reimage. Define the metrics precisely: RTO is tolerable downtime to restore service; RPO is tolerable data loss measured backwards from the event.
Choosing generic 'input validation' or 'sanitize output' as the fix for SQL injection, or confusing SAST with DAST when asked which testing technique to use.
Input validation appears in nearly every control list, so it feels like the universal correct answer even when a more specific root-cause fix exists.
What to do instead
Match the remediation to the root cause: SQL injection = parameterized queries or prepared statements; cross-site scripting = context-aware output encoding plus a content security policy; broken access control = server-side authorization checks on every request. SAST examines source code without executing it; DAST exercises the running application from outside.
Assigning accountability for security to the CISO or the security team, or placing awareness training above policy in the governance hierarchy, when asked who owns risk or which document governs.
Study material emphasizes the security function, so candidates assume the function also owns the risk, when accountability sits with senior management.
What to do instead
State the chain explicitly: senior management owns risk, sets policy and accepts residual risk; the security function advises, implements and reports; data and process owners are accountable for their own assets. Order governance top-down: business objectives, policy, standards, procedures, controls. On 'who is responsible' items choose the accountable business owner unless the stem explicitly assigns the process to security.
Treating biometrics as automatically the strongest authenticator, and overlooking that push-notification or SMS-based second factors can be relayed or phished in real time.
Factor categories are memorized as three buckets with an implicit strength ranking, and that ranking is never tested against a specific attack described in the stem.
What to do instead
Compare factors by the attack they defeat, not by category. Biometrics are a local convenience factor and are non-revocable if compromised; phishing resistance requires origin-bound credentials such as FIDO2 or passkeys. Identify the threat stated in the stem - phishing, replay, insider, lost device - and select the factor that specifically defeats it.