F5 WAF Skills Employers Want: Building, Tuning and Troubleshooting BIG-IP ASM Security Policies
The F5 web application firewall skills employers pay for come down to four jobs: building a BIG-IP ASM security policy that fits the application, tuning it until it blocks attacks without blocking customers, reading violation logs to decide what is an attack and what is a false positive, and fixing the performance and enforcement problems that follow. This guide walks through each job as it is done in production, then explains how the F5 BIG-IP ASM Specialist practice exam can help you check that you are ready.
It is written for people who already touch F5 hardware or virtual editions: a load-balancing engineer who has been handed the WAF module, a security analyst who keeps receiving tickets that say the firewall blocked a payment page, or an engineer at an F5 partner who has to deploy protection for a customer's portal. You do not need an F5 credential to follow it. The one set of exam figures quoted here, including the fee, was taken from F5's published exam page in November 2026; F5 can revise them, so treat them as a snapshot.
What does a BIG-IP ASM engineer actually do?
Application Security Manager, sold today as part of BIG-IP Advanced WAF, sits in front of web applications and inspects every HTTP request and response against a security policy. The engineer who owns it is rarely writing rules from scratch. Most of the week goes on four recurring tasks: deciding how a new application should be protected and creating its policy, refining that policy as the application changes, investigating the requests the policy flagged or blocked, and solving the problems that appear when protection and real traffic meet.
The work sits between two teams that often disagree. Security wants every OWASP Top Ten category blocked on day one. The application owner wants nothing to break. A good ASM engineer translates between them: they turn a requirement such as protect the login page from credential stuffing into concrete settings, explain the trade-off between strict enforcement and false positives, and keep enough evidence in the logs to justify each change. That translation skill is what separates someone who can click through the deployment wizard from someone a bank or retailer will trust with its customer-facing applications.
The same four tasks are exactly how F5 organises the specialist exam for this module. Its outline is split into architecture, design and policy creation; policy maintenance and optimisation; reviewing event logs and mitigating attacks; and troubleshooting. Learning the job and preparing for the credential are therefore the same activity, which is why this guide teaches the job first.
How do you choose the right way to deploy a new security policy?
Every protected application starts with a deployment decision, and the wrong one costs weeks of tuning later. The policy is attached to the virtual server that publishes the application, and the engineer chooses how it will be built and how strictly it will enforce at the start.
Transparent first, blocking later
A policy in transparent mode records violations but lets every request through. In blocking mode, a request that triggers a violation set to block receives a blocking response page with a support ID instead of reaching the application. Almost every production rollout begins in transparent mode so that the engineer can see what normal traffic looks like before anything is refused. Switching to blocking is a deliberate decision made once the false positives have been dealt with, not a default to accept on day one.
Templates, the policy builder and scanner output
ASM offers several ways to create a policy. A rapid deployment template gives broad protection quickly, with attack signatures and basic checks, and suits a team that needs coverage this week. Automatic learning lets the policy builder watch real traffic and suggest or add the URLs, parameters, file types and cookies the application actually uses, which produces a tighter positive security model over time. A policy can also be built from the output of a supported vulnerability scanner, so that the weaknesses a scan found are covered first, and from web service descriptions for XML or JSON applications.
Choosing between them is a requirements question. A legacy application that no one fully documents is a good candidate for automatic learning on real traffic. A modern API with a published schema can start from that schema. An urgent exposure found by a penetration test calls for the scanner route. The engineer's job is to match the method to the application and explain why.
Mapping traffic to the right policy
Large deployments protect many applications behind shared virtual servers. Traffic is then routed to the right security policy with an LTM policy or, less often, an iRule that matches the host name or path. Being able to read that logic matters: a request that lands on the wrong policy produces violations that make no sense for the application, and the cause is in the traffic mapping rather than the WAF settings.
Which protections go into a well-built policy?
A policy is a collection of entities and checks, and knowing what each one does is the core of the skill. The aim is the right granularity: strict where the application is sensitive, broader where it is not, and never so detailed that nobody can maintain it.
- URLs and file types: which paths and extensions the application serves. Allowing .php and .html but refusing .bak or .config stops a whole class of information leaks.
- Parameters: the names, value types and lengths of form fields and query strings. A numeric account ID that suddenly carries SQL text is easy to catch once the parameter is defined.
- Headers, cookies and content profiles: rules for request headers, which cookies the application sets and whether they may be modified, and parsing profiles for JSON and XML bodies.
- Attack signatures: F5-maintained patterns for SQL injection, cross-site scripting, command execution and many other attack types, grouped into signature sets that match the application's technology.
- Sessions and logins: login pages defined so the policy can enforce that protected URLs are only reached after authentication, and so brute-force protection knows what a failed login looks like.
- CSRF protection: tokens injected into forms to stop cross-site request forgery.
- DataGuard: response inspection that masks credit card numbers, national identity numbers or custom patterns before they leave the application.
- Anomaly detection: brute-force and web-scraping detection, Layer 7 denial-of-service protection and proactive bot defence, each configured for how the application is really used.
Two habits make these protections manageable. The first is using wildcard entities deliberately. A wildcard such as /images/* keeps the policy small and fast, while explicit entities for the login and payment paths keep the sensitive areas strict. The second is writing down why each setting exists, because the next engineer will otherwise relax a check that was protecting something important.
Why the attack signature lifecycle decides how fast you can block
Attack signatures are where many new ASM administrators get into trouble. F5 updates its signatures regularly, and a new signature that blocks immediately can break an application that happens to send matching text for a legitimate reason. ASM therefore puts new and updated signatures into staging. A staged signature reports matches but does not block them.
Staging is tied to the enforcement readiness period, which is seven days by default. During that window the engineer watches what each staged signature matches. If a signature fires only on genuine attack traffic, or not at all, it is ready to enforce. If it fires on normal requests, the engineer adds an exception for the specific parameter or URL, or disables the signature for that entity, and only then enforces it. Policies with automatic learning can enforce ready signatures themselves; manual policies wait for the engineer.
The same thinking applies to the learning, alarm and blocking flags on each violation. Learn means the violation produces suggestions, alarm means it is logged and reported, and block means it is refused when the policy is in blocking mode. A violation set to alarm but not block will never stop an attack, even in a policy that is switched to blocking. Many puzzling cases in which an attack got through come down to exactly this combination, so the three flags are worth learning thoroughly.
How to read ASM logs and remove false positives without opening a hole
Once a policy is live, the event logs become the engineer's main tool. Every flagged request is stored with its violations, a violation rating that estimates how likely it is to be a real attack, the matched signatures and the full request. When a user reports a blocked page, they normally quote the support ID shown on the blocking page, and the engineer searches the log for it to see exactly what was refused and why.
A practical triage routine
- Find the request by support ID, client address or time, and read the violation details rather than the summary line.
- Decide whether the request is legitimate. A product search that contains an apostrophe is not SQL injection; a parameter value containing a full UNION SELECT statement probably is.
- If it is a false positive, change the narrowest thing that fixes it: one signature on one parameter, one allowed meta-character, one length limit. Avoid disabling a check across the whole policy.
- If it is an attack that was let through, find out why: a signature still in staging, a violation set to alarm only, a wildcard entity that is too permissive, or traffic routed to the wrong policy.
- Apply the change, note the reason in the policy history, and watch the next day's traffic to confirm the result.
The policy builder's suggestions help with step three, but they are suggestions, not decisions. Accepting every suggestion during a period when the application was under attack teaches the policy that the attack is normal. Reviewing suggestions against the logs, and trusting only traffic from known good sources, is part of the skill.
Reports that answer management's questions
ASM's reporting shows trends: top violations, attacked URLs, source countries, anomaly statistics and, for card data environments, a PCI compliance view. Security managers use these to judge whether protection is working. An engineer who can turn the reports into a short monthly summary, for example that cross-site scripting attempts on the checkout form were all blocked and false positive tickets fell after tuning, makes the WAF's value visible to people who never log in to it.
Keeping a policy healthy as the application changes
Applications change every sprint, and a WAF policy that does not change with them either starts blocking new features or is quietly put back into transparent mode. Policy maintenance is therefore a standing duty, not a one-off project.
- Policy history and revert: every saved change is kept, so a change that broke something can be compared with the previous version and rolled back quickly.
- Import, export and merge: policies are exported for backup and moved between test and production devices. Merging lets a team bring the entities learned in a test environment into production without overwriting production's tuning.
- Scanner updates: when the security team runs a new vulnerability scan, its output can be imported again so that newly found weaknesses are covered.
- Change review: before a release, the engineer checks which URLs and parameters the release adds, so the policy can be updated before users start triggering violations.
- Roles and permissions: ASM has its own user roles, such as web application security administrator and editor, so that application teams can view or tune policies without receiving full control of the BIG-IP system.
Teams that do this well usually agree a simple rule with developers: any release that adds a new form, API endpoint or file upload tells the WAF owner first. It costs one message and saves an outage.
What troubleshooting looks like when protection and performance collide
The hardest tickets are not blocked requests but slow ones, or requests that should have been blocked and were not. Both need a methodical approach.
When traffic is not being inspected
The first check is whether the policy is actually seeing the traffic. A security policy that is attached to the wrong virtual server, a logging profile that is missing, or an application that sends a content type the policy does not parse will all produce an empty log that looks like perfect health. Confirming that the application works and that the policy is parsing its requests comes before any tuning. The logging profile assigned to the virtual server also decides which events are recorded at all, so an expected violation that never appears may simply not be logged.
When the WAF slows things down
Performance problems usually trace back to a recent change. ASM's performance graphs and the policy history show whether latency rose after a policy update, a new set of signatures, a large increase in explicit entities or a new iRule. Remote logging options matter too: guaranteed logging makes the system wait until an event is recorded, which protects the audit trail but can slow traffic when the remote logger is overloaded. Traffic spikes, whether a sale or an attack, are handled with denial-of-service protection and by keeping the policy efficient with sensible wildcards rather than thousands of explicit entities.
An engineer who can correlate the graphs with the policy history, name the likely cause and propose a measured fix is the person who gets called during an incident, and that experience is what the troubleshooting part of F5's exam is designed to measure.
Where the F5 BIG-IP ASM Specialist credential fits
F5's specialist credential for this module confirms that you can do the work described above. Passing the exam earns the F5 Certified Technology Specialist, BIG-IP ASM title, and F5 states on its exam page for the BIG-IP ASM Specialist that this certification is a prerequisite for its Security Solutions Expert track. As of November 2026, F5 lists the exam as follows:
| Item | Detail |
|---|---|
| Credential earned | F5 Certified Technology Specialist, BIG-IP ASM |
| Level | Technology Specialist |
| Fee | US$180 |
| Time limit | 90 minutes |
| Passing score | 245 |
| Delivery | Proctored at Pearson VUE test centres, in English |
The exam's objectives follow the four areas above, from explaining how common web attacks affect applications and summarising the OWASP Top Ten, through policy structure and the signature lifecycle, to log analysis, performance and ASM user roles. The full list of objectives is on the BIG-IP ASM Specialist syllabus page. F5 recommends hands-on experience together with its Configuring F5 Advanced WAF course, which is offered self-directed and instructor-led.
How to prepare without wasting weeks
- Build a lab. A BIG-IP virtual edition with a deliberately vulnerable test application lets you create policies, launch attacks and read the logs safely.
- Create the same application's policy three ways: from a rapid deployment template, with automatic learning and from scanner output. Compare what each produces.
- Practise the signature lifecycle: stage signatures, generate matching traffic, add a narrow exception and enforce.
- Work through real false positives: break a form on purpose with a strict setting, then fix it with the narrowest change.
- Use timed practice questions late in your preparation to find weak objectives and to get used to reading scenario questions under time pressure.
Timed practice is a diagnostic, not a substitute for the lab. F5 sells its own short practice test, and CertFun's practice exam is an independent rehearsal written to F5's published objectives; neither is a replacement for having built and tuned a policy yourself.
Which jobs use F5 WAF skills, and how do you prove them in a job search?
The same skills appear under several job titles. Application security engineers own WAF policies for a whole portfolio of web applications. Network and load-balancing engineers often inherit the WAF module because it runs on the BIG-IP platform they already manage. Security operations analysts investigate WAF alerts and work with the engineer on mitigations. Engineers at F5 partners design and deploy protection for customers, and partner programmes reward certified staff.
Banks, insurers, retailers, government services and online platforms are typical employers, because they run customer-facing applications that attract constant automated attacks and must meet standards such as PCI DSS. In those environments the WAF is in the path of revenue, so the engineer's judgement on false positives matters as much as their knowledge of attacks.
Hiring managers respond to results rather than product names. Rather than writing ASM in a skills list, state that you moved an application from transparent to blocking mode without a customer-facing incident, cut false positive tickets by tuning signatures per parameter, or stopped a credential stuffing campaign with brute-force and bot protection. In interviews, be ready to walk through one false positive you fixed and one attack you confirmed from the logs, including the evidence you used.
Start with whichever of the four jobs you do least today, whether that is building a policy, tuning it, reading logs or troubleshooting, and rehearse it on a test system over the next few days. Once all four feel routine, the credential simply records a level you have already reached.
Frequently Asked Questions
What is the difference between BIG-IP ASM and BIG-IP Advanced WAF?
Application Security Manager is F5's web application firewall module. F5 now sells that protection as BIG-IP Advanced WAF, which includes the ASM policy engine with additional protections such as bot and credential defence. The policy skills are the same, and F5's own training for the ASM specialist exam is the Configuring F5 Advanced WAF course.
Should a new ASM security policy start in transparent or blocking mode?
Start in transparent mode in almost every case. The policy records violations without refusing requests, so you can see normal traffic and fix false positives first. Switch to blocking once the staged signatures have been reviewed and the remaining violations are genuine attacks.
What is the enforcement readiness period in BIG-IP ASM?
It is the time new or updated attack signatures and learned entities stay in staging before they are considered ready to enforce, seven days by default. During staging a signature reports matches but does not block them, which gives the engineer time to spot false positives first.
What does the F5 BIG-IP ASM Specialist exam cost, and what is the pass mark?
In November 2026 F5 listed the exam at US$180 with a 90-minute time limit and a passing score of 245. It is taken in English at Pearson VUE test centres, and passing it earns the F5 Certified Technology Specialist, BIG-IP ASM credential.
How do I find out why ASM blocked a user's request?
Ask the user for the support ID shown on the blocking page and search the application security event log for it. The entry shows every violation, the matched signatures, the violation rating and the full request, which tells you whether to tune the policy or treat the request as an attack.
Does CertFun's ASM practice exam come from F5?
No. CertFun is independent of F5 and none of its products are F5 material. The practice exam is an independent, timed rehearsal written to F5's published objectives, useful for finding weak areas. Hands-on lab work and F5's own training remain the main preparation.
