Elastic Certified SIEM Analyst common mistakes
Elastic Certified SIEM Analyst · Understand the traps and how to avoid them.
Creates a Kibana space per customer/team and tells the customer their data is now isolated by space, then builds roles around space membership alone.
Spaces are visible in the UI and feel like tenants, so candidates conflate the saved-object boundary with the data boundary; they never verify whether a user in Space A can still query Space B's indices with the assigned role.
What to do instead
Treat spaces as a UI/saved-object boundary only. Enforce data isolation with roles that carry index privileges (and document-level security or field-level security where needed), then test by logging in as the restricted user and confirming Discover returns no documents from the other indices.
Assumes every prebuilt detection rule and rule type will run on the deployed cluster, enabling ML-based prebuilt rules or a large prebuilt rule set on a single node with a Basic license and no Fleet Server, then marks the deployment 'complete'.
Prebuilt rules can be installed broadly, so candidates equate 'rule visible in the UI' with 'rule operational'; the license tier, cluster capacity, ML node availability, and Fleet Server host/output configuration that certain rules and integrations depend on are never checked.
What to do instead
Before relying on a rule set, verify the license tier and enabled features (ML jobs and advanced rule types require higher tiers), confirm Fleet Server is running and its host URL/service token are configured, check each rule's execution status for gaps/failures, and remove or disable rules whose required integrations or ML jobs are absent.
Adds an integration to a policy and immediately writes custom detection rules against ECS fields such as process.executable or event.category, without confirming the enrolled agent is Healthy on that policy or that incoming documents actually carry those field names.
The integration appears in the policy UI, which looks like success; candidates skip Fleet agent status, the integration's index/dataset naming, and a Discover field check, so ingest pipelines, namespace or ECS-compatibility issues surface later as rules that never fire.
What to do instead
After onboarding, verify in Fleet that the agent is Healthy and assigned to the policy containing the integration, confirm documents render in Discover with the expected data view and timestamp, inspect the field list (and data quality/mapping views) to confirm ECS fields are populated, and only then author rules using those exact field names.
Writes a multi-event correlation ('sequence by ... with maxspan ...') inside a Custom query rule and either gets a rule error or assumes the rule is correlating events when it is behaving as a flat filter.
Both rule types accept a query box, so candidates paste EQL syntax into the default query rule without checking the rule type selector or running validation.
What to do instead
Choose the EQL rule type for sequences/joins, keep Custom query for single-event KQL/Lucene filters, validate the syntax in the rule editor before saving, and check the rule's execution status/logs after enabling to confirm it is producing (or correctly not producing) alerts.
Sets a rule interval and lookback with no additional look-back time and leaves max_signals at its default, then concludes the detection logic is broken when events 'disappear'.
Candidates reason about event time rather than ingestion delay and rule scheduling, and rarely scroll to the rule's execution status panel, so delayed indexing plus a zero look-back produces silent gaps and a legitimate rule looks unreliable.
What to do instead
Set additional look-back time equal to or greater than observed ingestion lag, size the interval against data volume, raise max_signals for high-volume rules, and review the rule details execution status and gaps to distinguish 'no matching events' from 'rule truncated or failed'.
Creates an exception from an alert and assumes it applies to every rule, or edits a shared exception list without attaching it to the rule; in other cases the exception entry silently fails to match because the field is multi-valued or the value uses path/wildcard semantics the candidate didn't account for.
'Add exception' from an alert feels global, and the relationship between rule-default exceptions and shared exception lists is easy to overlook; value and field matching semantics (matching a single array element, case sensitivity, wildcards) are not tested before declaring the exception working.
What to do instead
Open the rule and confirm the exception appears under its rule exceptions (or that the shared list is linked), scope the exception to the intended fields with the correct operator, test it against recent events with the preview, and remember exceptions only affect future evaluations, not existing alerts.
Types a Lucene-style query while KQL is the active language (or vice versa) and uses leading wildcards or unquoted multi-word values, then reads an empty Discover result set as proof that no suspicious activity occurred.
The language selector is a small toggle, both syntaxes look similar for simple field:value pairs, and candidates trust an empty result rather than validating query semantics.
What to do instead
Check the active query language before typing, quote exact multi-word values, avoid leading wildcards, verify the field exists in the current data view using the field browser, and sanity-check by querying a known-present event before concluding there is no activity.
Investigates in Timeline without setting the Timeline data view and time range to cover the relevant indices, and pivots on fields like host.name or process.parent.name that aren't populated the way the candidate assumes.
Timeline inherits defaults that may exclude the index holding the evidence, and pivot assumptions come from the ECS ideal rather than the field list of the actual documents, so a correct pivot returns nothing and the hunt is abandoned.
What to do instead
Explicitly set Timeline's data view and time window to the indices under investigation, confirm pivot fields are populated in the source documents before grouping, and use the Correlation tab to group and count across entities rather than eyeballing individual events.
Attaches alerts to a case and expects the alerts to be acknowledged or closed, and wires a rule's automated response (case creation, isolation, host action) without confirming the required connector or endpoint capability exists.
Case creation feels like the end of triage, and rule actions look like one-click automation; the distinction between a reference link and alert status, and the connector/agent prerequisites for response actions, is never verified.
What to do instead
Manage alert status explicitly (per-alert or bulk acknowledge/close) and treat the case link as a reference only; before relying on automated response, confirm the connector is configured and healthy and that the target host has a healthy agent with the required endpoint capability, then test the action on a low-impact host.
Expects network connection events and host containment to behave out of the box: builds detections on event.category: network without enabling network event collection in the Elastic Defend policy, and assumes 'isolate host' is permanent or blocks all traffic including the agent's connection to Fleet.
Process events flow by default so candidates generalize that all event classes are captured, and isolation is imagined as a hard network cut, so they never check the policy's event collection settings or the release/isolation semantics.
What to do instead
Enable the required event collection options in the Elastic Defend integration policy and push the policy to the host, confirm the expected event.category values arrive in Discover, and document that isolation restricts traffic while preserving management connectivity and must be explicitly released to restore the host.