← All study guides
401
Security Solutions (401)
Part of F5 Certified Solution Expert, Security
Computer-based, multiple-choice; delivered at Pearson VUE test centers (English). Credential awarded: F5 Certified Solution Expert, Security (F5-CSE, Security). Prerequisites: F5-CA plus F5-CTS LTM, F5-CTS ASM, and F5-CTS APM.
Independent study aid built from the public exam blueprint. Not affiliated with, authorized by, or endorsed by F5. Objectives are transcribed and mapped by hand, so this page may contain mistakes or may have fallen behind the vendor's current material: exam objectives, versions, numbering and availability all change without notice. Treat F5's own certification portal as the source of truth and verify against it before you book anything.
Section 1: THREAT ANALYSIS
1.01 Analyze external threat research to determine the potential impact to an organization
What to know:- Threat research inputs: F5 Labs, CVE/NVD feeds, vendor advisories, ISAC bulletins, and the OWASP Top 10 as a recurring baseline.
- Translate a published threat into exposure: which applications use the affected component, which are internet-facing, and what the blast radius is.
- CVSS scores severity in the abstract; EPSS estimates exploitation likelihood. Neither substitutes for asking whether YOUR deployment is reachable and unpatched.
- Virtual patching with AWAF is the standard answer when the application itself cannot be fixed quickly.
- Deliverable of this objective is a prioritized impact statement, not a vulnerability list.
Tools: cvss-vector-decoder1.02 Analyze threat modeling data to determine risk profiles of the infrastructure and applications
What to know:- Threat modeling asks four questions: what are we building, what can go wrong, what will we do about it, and did we do a good job.
- STRIDE is the common taxonomy: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege.
- Risk profile combines asset value, exposure, and likelihood; a low-severity flaw on a crown-jewel app can outrank a high-severity one on an isolated system.
- Data classification drives control selection: PCI DSS cardholder data, PII under privacy law, and health data each carry different obligations.
- Map each identified risk to the F5 control that addresses it, so the design justifies itself objective by objective.
Tools: cvss-vector-decoder
Section 2: ARCHITECT SOLUTIONS
2.01 Determine the correct solution to mitigate a given threat
What to know:- Match the threat class to the module: AWAF for application-layer attacks, AFM for network-layer firewalling and DoS, APM for access and identity, DNS for DNS-layer protection.
- Layer 7 DoS and layer 3/4 DoS are different problems with different mitigations; do not answer one with the other.
- Bot Defense and Web Scraping protections address automation, which is a separate class from injection or exploitation.
- SSL Orchestrator addresses the visibility problem, not an attack directly: it lets other tools see decrypted traffic.
- The correct answer is usually the least-privileged control that fully addresses the threat, not the most powerful one.
On this site: L7 Behavioral DoS (BaDoS): How Advanced WAF Learns Normal and Mitigates the Rest, SYN Flood Protection on BIG-IP: Cookies, Thresholds, and Who Answers FirstTools: f5-dos-vector-explainer2.02 Determine the correct control to address a compliance or business requirement
What to know:- Compliance regimes name required controls: PCI DSS requirement 6.6 explicitly accepts a web application firewall as an alternative to code review.
- Business requirements often translate to availability and latency budgets, which constrain how aggressive a control can be.
- Blocking versus transparent mode is a business decision before it is a technical one; staging policy in transparent mode first is standard practice.
- Logging and reporting requirements are controls too: audit evidence is frequently the actual deliverable.
- Document which requirement each control satisfies, because compliance auditors ask for the mapping, not the configuration.
2.03 Determine the appropriate security framework for an application
What to know:- Common frameworks: OWASP Top 10 for application risk, NIST Cybersecurity Framework for programme structure, CIS Controls for prioritized hardening, ISO 27001 for management systems.
- Framework choice follows the organization's obligations and maturity, not the technology in front of you.
- MITRE ATT&CK is behavioral and post-compromise; it complements rather than replaces the design-time frameworks.
- F5 policy templates map to framework expectations, which is what makes them defensible in an audit.
- Expect to justify a framework choice in terms of coverage and reporting, not preference.
2.04 Explain the justification for a proposed solution
What to know:- A justification connects the threat, the control, the residual risk, and the cost, in that order.
- State what the solution does NOT cover: unaddressed residual risk stated openly is a sign of a sound design.
- Quantify where possible (requests blocked, latency added, incidents avoided) and be explicit where quantification is not possible.
- Operational cost matters: policy tuning effort, false-positive handling, and staffing are part of the proposal.
- Anticipate the alternatives and explain why they were not chosen.
2.05 Determine when BIG-IQ is required for centralized management and visibility
What to know:- BIG-IQ centralizes management, licensing, and visibility across multiple BIG-IP devices; a single device does not need it.
- Triggers for BIG-IQ: fleet-scale policy consistency, centralized AWAF policy management, aggregated reporting, and license management for virtual editions.
- BIG-IQ also provides role-based access and change staging for teams that must separate duties.
- It is a management plane, not a data plane: it never sits in the traffic path.
- The exam question is usually scale plus governance, so read for fleet size and audit requirements.
Section 3: OPERATION AND IMPLEMENTATION
3.01 Apply procedural concepts required to configure F5 technology to provide network layer DOS protection
What to know:- AFM provides network-layer DoS protection through device-level and virtual-server-level DoS profiles.
- Know the vector families: floods (SYN, UDP, ICMP), malformed packets, and protocol abuse, each with its own detection and rate thresholds.
- Detection threshold, mitigation threshold, and auto-threshold behavior are the three settings the exam expects you to distinguish.
- SYN cookies protect the connection table without holding state for unverified clients.
- Whitelist and blacklist behavior, plus escalation to hardware offload on supported platforms, complete the picture.
On this site: SYN Flood Protection on BIG-IP: Cookies, Thresholds, and Who Answers First, Connection Eviction Policies: What BIG-IP Throws Overboard, and WhenTools: f5-dos-vector-explainer3.02 Determine the appropriate protection against known bad actors
What to know:- IP Intelligence categorizes known bad sources (botnets, scanners, proxies, Tor exit nodes) via a subscription feed.
- The IPI policy decides per-category action; feed freshness is what makes it useful, so subscription state matters operationally.
- Shun lists and manual blacklisting handle actors the feed does not know about yet.
- Geolocation-based restriction is a blunt but common business control; know its limitations against proxies and VPNs.
- Reputation controls reduce noise so the deeper inspection layers work on a smaller, more suspicious population.
3.03 Determine the appropriate settings to mitigate web fraud
What to know:- Web fraud protection addresses client-side threats that a server-side WAF cannot see: credential stuffing, malware in the browser, and automated abuse.
- DataSafe provides application-layer encryption of form fields so a keylogger or man-in-the-browser sees ciphertext.
- Bot Defense distinguishes humans from automation; Credential Stuffing protection checks for known-compromised credentials.
- Anti-fraud is behavioral: the signal is how the client behaves, not just what it sends.
- These controls target the user's device as the compromised element, which is the distinction the exam draws.
3.04 Articulate architectural requirements for outbound SSL visibility
What to know:- Outbound SSL visibility exists because inspection tools cannot examine what they cannot decrypt.
- SSL Orchestrator provides decrypt-once, inspect-many via service chains, avoiding the cost of daisy-chained decryption.
- Topologies to know: transparent forward proxy, explicit forward proxy, and inbound reverse proxy, each with different placement and routing requirements.
- Certificate handling is the architectural crux: outbound inspection requires an internal CA trusted by the clients.
- Bypass policy matters legally and operationally: financial and health categories are commonly excluded from decryption.
3.05 Apply procedural concepts to configure network firewall protection
What to know:- AFM is a full network firewall on BIG-IP, with rules organized in a context hierarchy: global, route domain, virtual server, and self IP.
- Rule evaluation follows the context order, and the first match wins within a context; understand which context a packet hits first.
- Default-deny versus default-accept posture is a design decision that the rule set must state explicitly.
- Firewall rules can be staged for evaluation before enforcement, which is the safe path into production.
- Packet filters, AFM rules, and port lockdown on self IPs are distinct mechanisms that are easy to confuse.
3.06 Troubleshoot F5 technology to address functionality or performance issues
What to know:- Start from the traffic path: is the issue in connection establishment, TLS negotiation, policy enforcement, or the pool member.
- tcpdump with the p modifier follows a flow through both sides of the proxy; that is the single most useful capture technique on BIG-IP.
- Request logging and the AWAF event log tell you whether a request was seen, matched a signature, and was blocked or allowed.
- Performance issues: check CPU per TMM, connection table pressure, and whether a policy is doing full-body inspection on large payloads.
- Change one variable at a time and confirm against a known-good baseline; that discipline is what the objective is testing.
On this site: qkview and iHealth: the Support Snapshot Workflow3.07 Verify a configuration is functioning as intended to mitigate a vulnerability
What to know:- Verification means reproducing the attack safely and observing the block, not reading the configuration back.
- Use the policy's own logging to confirm the signature or violation fired, with the request ID as the anchor.
- Confirm the negative case too: legitimate traffic must still pass, which is why a false-positive check belongs in the verification plan.
- Staging and enforcement readiness periods exist so new signatures can be observed before they block.
- Document the test, the evidence, and the date; that record is what satisfies an auditor later.
Section 4: SECURITY RESPONSE
4.01 Analyze logs or other data sources for security incidents
What to know:- Sources: AWAF event logs, AFM logs, LTM request logging, and system logs, ideally aggregated in a SIEM.
- Correlate on request ID, source IP, and time window; a single event rarely tells the story.
- Look for patterns rather than single hits: distribution across sources, timing regularity, and user-agent uniformity all indicate automation.
- High-speed logging offloads log traffic from the control plane, which matters at incident volumes.
- The output of analysis is an assessment of what happened and whether it succeeded, not just a list of blocked requests.
On this site: The BIG-IP Log Files: a Map of /var/log4.02 Determine the appropriate proactive security response plan
What to know:- A proactive plan hardens before the incident: signature updates, policy staging cadence, IP Intelligence subscription currency, and tested backups.
- Define the escalation path and thresholds in advance, so the decision to block aggressively is pre-authorized.
- Regular review of blocked and allowed traffic keeps policies tuned as the application changes.
- Tabletop exercises validate that the plan works with the people who will run it.
- Proactive work is measured by reduced time to detect and time to mitigate, which is what the objective is asking for.
4.03 Determine the appropriate incident response plan given specific attack details
What to know:- Incident response phases: preparation, detection and analysis, containment, eradication, recovery, and lessons learned.
- Containment on BIG-IP can be immediate: an iRule, a blocking policy change, or an IP shun list applied at the edge.
- Match the response to the attack: a volumetric flood needs rate limiting and possibly upstream scrubbing, while an application exploit needs a virtual patch.
- Preserve evidence before you change configuration, because the capture and logs are unrecoverable afterwards.
- Post-incident, convert the fix into a permanent control and a detection rule so the same attack is caught earlier next time.
Public sources, used in good faith
These guides are independent study aids built from publicly available material: published exam blueprints, official product documentation, and vendor training catalogues. Product names, exam codes, and trademarks belong to their owners and are used only to identify the subject being taught. This site is not affiliated with or endorsed by any vendor named here. If you hold rights in material published on this page and believe it should be removed or corrected, please send the exact URL and a short note on the issue through the contact page; requests are reviewed promptly and in good faith. Read the full disclaimer →