XSIAM Engineer flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

XSIAM Broker VM

A customer-deployed virtual appliance that collects syslog and file-based logs, proxies agent traffic, and caches content. It must reach the XSIAM cloud over TCP 443.

Data residency region

The cloud region chosen when a tenant is provisioned, which determines where customer data is stored. It cannot be changed later without re-provisioning the tenant.

Ingestion licensing model

XSIAM capacity is licensed by daily data volume and endpoint count. Exceeding contracted ingestion causes throttling or dropped data, not automatic overage billing.

Broker VM high availability

Cloud services are inherently redundant, but on-premises collection is not. Deploying multiple brokers in an HA cluster removes the single collection point of failure.

Deployment sequence

Provision tenant, deploy and register brokers, install agents, onboard log sources, validate parsing, then enable detections and automation in that order.

Normalization to data model

Raw events are mapped into standard fields such as actor, action, and source IP so detections and queries work consistently across different vendor products.

Custom parser purpose

Built-in parsers cover common products. Custom parsers handle unsupported or proprietary formats and must map fields into the data model for detections to see them.

Unmapped field consequence

If a parser fails to map a field to the data model, the raw event is still stored but is invisible to model-based detections and dashboards.

Syslog transport choice

Broker VM collection supports syslog over UDP, TCP, and TLS. TLS with certificate validation is recommended for any log crossing an untrusted network.

Duplicate collection paths

Collecting the same host through both agent and syslog inflates ingestion volume and can distort detections. Choose one authoritative path per data type.

Parsing validation test

Send a known sample, confirm the raw event appears, then confirm normalized fields populate correctly before enabling detections that depend on those fields.

Correlation rule anatomy

A detection combines a query over normalized data, a schedule or streaming trigger, and a severity. Rule output creates alerts that group into incidents.

ML baseline requirement

Behavioral and machine learning detections need sufficient baseline telemetry, typically days to weeks, before they produce meaningful results after onboarding.

Alert grouping tuning

Grouping rules decide how many alerts become one incident. Tuning grouping reduces analyst fatigue more effectively than deleting detections outright.

Narrow exclusions rule

False positive exclusions should be scoped by user, host, or specific field value and time-boxed where possible. Broad exclusions silently disable coverage.

Hunt to detection path

A threat hunting query in the XSIAM query language can be saved and converted into a scheduled detection, making hunts durable and repeatable.

ATTACK coverage analysis

Mapping detections to MITRE ATT&CK techniques reveals coverage gaps. Gaps are found by comparing technique coverage to the threat model, not by counting rules.

Playbook trigger types

Playbooks run on incident creation, alert creation, manual execution, or schedule. The trigger type decides whether the playbook runs per incident or per alert.

Sub-playbook reuse

Sub-playbooks hold reusable logic called by multiple parent playbooks. They are the standard mechanism for sharing automation across incident types.

Integration instances

An integration can have multiple configured instances, such as two EDR tenants. Playbook tasks must specify which instance to call.

Context path errors

Playbook tasks reference command output through context paths. Incorrect context paths are the most common cause of silent task failures.

Destructive action gating

Actions such as host isolation, user disablement, or hash blocking should sit behind approval tasks or conditional checks to prevent accidental disruption.

Command timeout and retry

Timeout and retry settings define behavior when a third-party API is slow or down. Without them, playbooks hang and incidents queue up.

Incident war room

The war room holds the collaboration record for an incident, including comments, playbook runs, and collected evidence used during investigation and closure.

Indicator TTL

Threat intelligence indicators carry time-to-live values. Expired indicators stop matching in detections unless the feed refreshes them.

Indicator confidence scoring

Confidence and scoring determine whether an indicator match raises incident severity. Low-confidence feed data should not escalate incidents without corroboration.

Attack surface findings

Attack surface management discovers external-facing assets and exposures, risk-scores them, and can convert findings into incidents or remediation tasks.

Incident closure disposition

Closing an incident requires documented resolution and root cause. Missing disposition data degrades reporting and breaks the detection tuning feedback loop.

Scoped RBAC roles

Roles define permissions such as view, investigate, respond, and administer, and can be restricted by resource scope like endpoint groups or datasets.

Ingestion troubleshooting order

Confirm the source sends, the broker receives, the parser matches vendor and product, then confirm normalized fields populate. This isolates the failing stage.

Detection data versus logic

Run the rule query manually over the same window. If it returns data, the problem is rule logic; if not, the problem is missing or unparsed data.

Administrative audit logs

Audit logs record logins, configuration changes, and administrative actions. They are the primary evidence source for insider or credential misuse investigations.