CCNP Security common mistakes
CCNP Security · Understand the traps and how to avoid them.
Treats the Firepower Threat Defense access control policy as one flat, top-to-bottom ACL and assumes prefilter rules are evaluated after access control rules.
The FMC GUI presents prefilter, SSL, and access control policies as separate tabs that look like ordered lists, so candidates memorise screen layouts instead of building a packet-evaluation model.
What to do instead
Draw the evaluation pipeline from memory (SSL policy, prefilter, access control policy, platform settings) and rehearse where a given flow exits the pipeline before reaching the ACP.
Recites IKEv2 configuration fields but cannot state which security associations are created in which exchange and what traffic each SA protects.
Study material often shows the crypto map/proposal screens without connecting them to the IKE_SA_INIT, IKE_AUTH, and CREATE_CHILD_SA exchanges.
What to do instead
Build a two-column table: IKE SA versus child SA, with initiator/responder, messages, and the traffic each protects; then map every configuration field to one of those SAs.
Configures IPsec crypto ACLs that are not exact mirrors on both peers, or ignores NAT-T encapsulation when explaining phase 2 failures.
Candidates treat the crypto ACL like a security ACL and permit broad subnets, then cannot explain why the tunnel stays down.
What to do instead
Practise writing mirrored crypto ACLs for specific host/subnet pairs and tracing a packet through NAT discovery (UDP 4500) before ESP is accepted.
Applies one blanket statement ('the cloud provider secures the cloud') across IaaS, PaaS, and SaaS scenarios.
The shared responsibility model is learned as a slogan rather than as a per-service-layer matrix.
What to do instead
Memorise a matrix of customer versus provider responsibility for compute, OS, runtime, application, identity, and data, and answer each scenario by naming the service model first.
Mixes CASB API mode with forward-proxy and reverse-proxy modes, then selects API mode for a requirement to block a file upload in real time.
All three are described as 'CASB' features, so the deployment placement (out-of-band versus inline) is not tied to the control capability.
What to do instead
For each CASB mode, write where it sits in the traffic path and which controls it can enforce (visibility, API-based retro-scan, inline block), then match requirements to placement.
Conflates the roles of the email security appliance, the web security appliance, and Umbrella, such as expecting the email gateway to enforce outbound web category policy.
The products share reputation and intelligence features, so candidates assume overlapping enforcement points.
What to do instead
Create a one-line scope statement for each product (mail flow, web proxy, DNS-layer resolution) and a table of which traffic each one can see and block.
Treats file reputation and file analysis as the same verdict source, assuming a file with a clean reputation has been detonated and cleared.
Both feed the same console and verdicts, so the distinction between hash lookups and sandboxed dynamic analysis is lost.
What to do instead
State for each verdict where it came from (local cache, cloud reputation lookup, sandbox analysis) and what happens when reputation is unknown versus malicious.
Selects an EDR product when the scenario asks for blocking known malware at first execution, and selects an EPP product when the scenario asks for hunting and retrospective response.
Vendors market EPP and EDR under one suite name, so candidates answer with the brand rather than the capability.
What to do instead
Write a two-column comparison of EPP (prevention at the endpoint, signature and behavioural blocking) versus EDR (telemetry, detection, investigation, response) and classify each scenario requirement before choosing.
Assumes exploit prevention signatures are the same as malware signatures and cannot separate behavioural protection from file-hash matching.
Both appear as 'signatures' in the console, so the difference between detecting an exploitation technique and matching a known file is not examined.
What to do instead
For each protection type, state what it inspects (process behaviour versus file identity) and give one attack that only one of them would stop.
Configures 802.1X but cannot sequence the EAP exchange or explain when MAB is used, and applies MAB to managed domain machines.
The supplicant, authenticator, and authentication server roles are memorised as definitions without a message-by-message flow.
What to do instead
Draw the supplicant-authenticator-server exchange including EAPOL start, identity, challenge, and success, and list the exact conditions (no supplicant, devices such as printers) that justify MAB.