FortiWeb Lesson 10: Machine Learning, Baselines and Model Quality

FORTIWEB CLASSROOM • LESSON 10

Level: Intermediate to advanced · Study and lab: 75 minutes
Instructor: Harpreet Singh Virdi, CISSP, CCSP

FortiWeb course guide · FortiWeb training block

---

A model learns from what it sees

Our bookshop has search, login, cart, and order workflows. If the learning traffic contains only homepage requests, it does not represent the application. If it includes uncontrolled hostile traffic, undesirable patterns may influence the model. Machine learning needs traffic quality and review.

Understand the purpose

FortiWeb's ML-based anomaly detection learns characteristics of application input and looks for deviations. It is different from a static signature match and different from manually defining an input contract. Other learning and profiling workflows may exist in your release; inspect which mechanism is actually enabled.

A trained model is not proof that every business function was covered or every learned value is safe. Learning milestones and sample counts describe model processing, not permission to skip application validation. Do not reduce thresholds simply to make a dashboard look ready.

Plan representative traffic

• Browsing, search, filters, and pagination.
• Success and failure paths for synthetic logins.
• Cart and order operations with valid boundary values.
• API, mobile, administrative, and batch clients where applicable.
• Localization, punctuation, and uncommon but valid inputs.

Guided observation lab

1. Read the ML-based anomaly detection workflow for your exact firmware.
2. Document the protected host, relevant server policy, current signature protection, and intended learning sources.
3. Create and associate the supported ML configuration using an observation-oriented lab plan.
4. Generate the planned valid user journeys with synthetic values.
5. Inspect model status by relevant URL/parameter rather than looking only at total traffic volume.
6. Introduce a legitimate edge case and review the resulting classification.
7. Use a documented lab anomaly case and compare it with the legitimate edge case.
8. Record the interpretation, response settings, and any model gaps before considering enforcement.

Expected result: you can explain what was represented in the model and what was not. A small lab may not collect enough representative samples to reach later model stages. Report that limitation honestly.

Manage change and noise

Application releases can add new endpoints or change valid input. Investigate whether a spike in anomalies reflects a release, a client bug, abuse, or a training problem. Review source restrictions and filtering so the model sees the intended population.

ML-based bot detection is a separate use case with its own policies and data. Do not assume that an application-parameter model automatically configures bot defense or vice versa.

Knowledge check

Why does a high traffic count fail to prove learning coverage?

Instructor answer

The requests may repeat only a narrow workflow or input pattern. Coverage requires representative endpoints, parameters, clients, and valid edge cases, not just volume.

---

Official reading

• Fortinet: ml based anomaly detection
• Fortinet: waf machine learning policy

Independent training, not affiliated with Fortinet. Examples use an authorized isolated lab with synthetic data. The lab steps and expected outcomes have not been executed on a FortiWeb appliance for this publication. Firmware, platform, operating mode, licensing, and subscriptions affect behavior; follow the documentation for your exact build. References use 8.0.x examples and do not constitute an upgrade recommendation.

← Previous FortiWeb lesson · FortiWeb course guide · Next FortiWeb lesson →