FortiSIEM threat hunting works best when a query is treated as a question about behavior rather than a request to dump logs. A strong hunt starts with a hypothesis, chooses the right time model, filters on normalized attributes, and then reshapes the result until a suspicious pattern becomes visible. The same search engine also supports rapid incident triage, so the practical skill is knowing when to use a narrow real-time view, when to search historical data, and when to aggregate or enrich the result.

The current NSE 7 Security Operations 7.6 Architect objectives explicitly include building FortiSIEM queries to search event logs. That makes query construction an operational competency: analysts must move from a symptom or detection to evidence quickly, without turning every investigation into an unbounded search across the entire event store.

Choose real-time or historical search based on the question

FortiSIEM distinguishes real-time and historical search. Real-time search evaluates matching events as they are ingested, which is useful when you are reproducing an issue, observing a live attack path, validating a parser, or watching a control change take effect. Historical search works against events already stored in the event database and is the normal choice for retrospective hunting, timeline reconstruction, and comparison across a defined period.

The distinction affects what you can do. Real-time search is designed for streaming visibility and does not provide the same aggregation behavior as historical analysis. If your question is “does this firewall now send the expected deny event?”, real-time is efficient. If the question is “which hosts contacted more than fifty distinct external destinations during the last six hours?”, historical search is the appropriate model because the answer depends on accumulation and grouping.

Pick the shortest time range that can answer the question. A one-week search when the suspicious activity occurred in a fifteen-minute window increases cost, noise, and analyst effort. Expand the range only when the evidence suggests the behavior started earlier or recurred.

Begin with a hunt hypothesis and observable evidence

Threat hunting is not random browsing. Write a hypothesis that can be tested with available telemetry. “An attacker may be using one workstation to probe many internal servers after compromising a user account” suggests several observables: one source, many destinations, unusual ports, authentication events, and perhaps a change in device behavior. Those observables become query fields and pivots.

Map the hypothesis to the logs FortiSIEM actually receives. A hunt for endpoint process behavior cannot succeed if the required endpoint telemetry is absent. A network hunt may need firewall sessions, DNS, proxy, VPN, identity, or NetFlow data. Before refining syntax, confirm that the source devices are reporting and that the fields you intend to filter are populated consistently.

This is why threat hunting belongs inside a larger SIEM discipline. Search quality depends on collection, parsing, normalization, retention, and context. Query skill cannot compensate for telemetry that never arrives.

Filter narrowly, then widen with purpose

Start with high-confidence attributes: a known source IP from an incident, a user, a destination, an event type, a device, or a short time window. Confirm that the expected events exist, then widen one dimension at a time. This approach preserves causal context and prevents the analyst from being overwhelmed by unrelated activity.

For example, an alert may name one suspicious account. Search the account across authentication events. Pivot to the source IPs used by that account. Then search those source IPs across network events. If one host contacted unexpected services, pivot again to destinations and applications. Each query should be motivated by evidence from the previous result.

Negative evidence is useful as well. If a host is suspected of using a specific protocol but the expected network telemetry shows no such connections, that finding changes the hypothesis. Hunting is not about forcing the data to confirm an assumption; it is about reducing uncertainty.

Use normalized attributes instead of vendor-specific text where possible

FortiSIEM’s value comes partly from presenting heterogeneous telemetry through normalized attributes. A hunt that depends only on raw message text may break when devices format the same concept differently. When reliable normalized fields exist, use them for source, destination, user, event type, port, protocol, device, and other common entities.

Raw-event review still matters. Normalization can hide detail, and parsing errors can populate a field incorrectly. When a result looks surprising, inspect the original event to verify what the device actually reported. This is especially important when a hunt crosses multiple vendor sources or when a parser update may have changed field extraction.

Think of normalized search as the wide lens and raw events as the verification lens. Use the first to correlate behavior across systems and the second to validate exact evidence before making a high-impact conclusion.

Aggregation exposes patterns that individual events hide

Historical search becomes more powerful when you group by stable entities and calculate counts or distinct values. A list of thousands of firewall connections may be unreadable, but grouping by source and counting distinct destinations can reveal scanners. Grouping authentication failures by account can expose targeted attacks. Grouping DNS queries by source and counting rare domains can surface unusual behavior.

Choose groupings that correspond to the hypothesis. If you are hunting for one host touching many accounts, group by source and count distinct users. If you are looking for one account moving across hosts, group by user and count distinct destinations. The same event population can tell different stories depending on the entity held constant.

Do not over-aggregate. A summary can hide sequence, exact timestamps, and individual evidence. Once an aggregate reveals an outlier, drill back into the matching events to reconstruct the timeline.

Combine event, CMDB, and lookup context

FortiSIEM can search more than event rows. Its search framework supports event data, CMDB information, lookup tables, and combinations of those sources. That enables hunts based on context instead of raw volume. A connection to one destination may be ordinary unless the destination is a critical server. An authentication failure may be more important when the account is privileged. A quiet host may matter when the CMDB says it is an internet-facing system.

Use context to prioritize and constrain. Device groups, business services, locations, asset roles, watch lists, and lookup data can reduce false positives and make results easier to interpret. The goal is not to add every enrichment field; it is to include the context that changes the security meaning of an event.

When a hunt depends on a lookup or CMDB property, verify that the reference data is current. Stale asset ownership or classification can misdirect an investigation just as surely as a bad log parser.

Build pivots that support investigation, not just dashboards

A useful hunt query should suggest the next question. If the result shows an unusual source, make sure source IP, host identity, user, and timestamp are available for pivoting. If the result shows a suspicious destination, expose domain, destination IP, application, and related source systems. If the hunt concerns lateral movement, keep both the authenticating identity and target host visible.

Save queries that repeatedly prove useful, but do not let saved searches become unquestioned truth. Document what each query assumes, the telemetry it requires, and the behavior it is meant to surface. A saved query is a starting point for analysis, not a substitute for reasoning.

Incident-response planning makes threat hunting more actionable because the organization already knows who owns investigation, escalation, containment, and evidence preservation when a hunt finds something real.

Use incident context to seed a hunt

FortiSIEM incidents provide a natural starting point because a correlation rule has already narrowed a large event population into a suspicious pattern. Take the source, target, user, timing, and triggered attributes from the incident and search outward. The purpose is to discover what happened before and after the detection, whether related assets were involved, and whether the incident represents a single event chain or a broader campaign.

Search backward for initial access indicators, configuration changes, new authentication paths, or unusual process/network behavior. Search forward for lateral movement, privilege changes, persistence, outbound communications, or repeated attempts. Compare the affected entity with peers to determine whether the behavior is rare or normal for that role.

This transition from alert to hunt is where a SOC gains leverage. Instead of closing a single incident after confirming one event, the analyst uses that incident as evidence for a wider question.

Record the time range, filters, groupings, and key pivots that produced an investigative conclusion. Another analyst should be able to rerun the search and reach the same evidence. Reproducibility matters for handoffs, post-incident review, tuning, and audit work.

When a hunt produces a durable detection idea, move it into the rule-engineering process instead of relying on analysts to repeat the query manually forever. Conversely, when a rule generates a weak incident, use hunting queries to understand the surrounding behavior before tuning the rule. Search and detection should reinforce each other.

Across Fortinet certification SOC objectives, these skills form one workflow: real-time search validates live behavior, historical search reconstructs and compares, and rule logic turns recurring high-confidence patterns into repeatable detection.

Use baselines and rarity without turning them into truth

Many hunts become more useful when the analyst compares an entity with its own history or with peers. A workstation contacting one hundred destinations may be suspicious in a finance office but normal for a vulnerability scanner. A user logging in from two countries may look unusual until the organization confirms that the account belongs to a travel team or a cloud automation service. Baselines provide context, not a verdict.

Start with a population that makes sense. Compare servers with similar roles, users with similar job functions, or devices in the same site instead of calculating one average across the entire enterprise. Large heterogeneous baselines often label ordinary specialist behavior as anomalous while hiding small deviations in sensitive groups.

Rarity can help prioritize. A domain contacted by one host, an application seen on only one server, or a new administrative tool appearing for the first time deserves attention when it conflicts with expected behavior. But rare does not mean malicious. Use the rare observation to generate the next query: who introduced it, when did it first appear, what process or account was involved, and did the same entity show other unusual behavior?

Preserve the difference between baseline evidence and business context. The SIEM can show that a behavior is unusual; the asset owner may explain that a migration, maintenance activity, or new application made it legitimate. Good hunting combines both forms of evidence before escalating.