LogRhythm LRSA flashcards
LogRhythm LRSA · Build recall with a focused review session.
32 cards. Read the term and the definition here. The deck at the top of this page is optional.
- Platform Manager role
- Central component hosting the Admin API, licensing, and configuration replication for the deployment. Client Console and Web Console connect to it to administer entities, users, and system settings.
- Data Indexer function
- Stores normalized and raw log data and serves searches. Indexer sizing depends on licensed messages per second, average event size, and retention days, with index overhead added on top of raw volume.
- Data Processor function
- Receives raw logs, parses and normalizes them into common event fields, and forwards to Indexers and the AI Engine. A backlog here means events are delayed before correlation runs.
- Entity hierarchy inheritance
- System Monitor contains Entities, which contain Log Sources. Alarms, cases, and role-based permissions inherit down this tree, so a misplaced log source misroutes alarms and reports.
- Licensed MPS meaning
- Messages per second is the licensing metric for event throughput. Sustained bursts above the licensed rate cause throttling or dropped events across all log sources sharing the license.
- Platform upgrade order
- Platform Manager upgrades first, then Data Processors, AI Engine, and Indexers. A configuration backup and compatibility matrix check are required before starting any version change.
- Log source onboarding sequence
- Configure device forwarding, create the log source with correct type and entity, then validate parsing in Log Source Monitor. Skipping validation leaves silent misparsing that corrupts later analytics.
- Log Source Type and MPE
- The Log Source Type selects the message processing engine rules that parse raw messages into normalized fields. Wrong type selection is the most common cause of unparsed events.
- Virtual log source split
- A single physical device sending multiple log formats can be represented as multiple virtual log sources, separated by port or source identifier, so each format parses correctly.
- Date parsing failure
- When a device omits year or timezone, the parser may assign receipt time instead of event time. Set the date parser explicitly, or event ordering and correlation windows break.
- Silence detection threshold
- A per-log-source setting that raises an alarm when no events arrive within a defined window. It detects broken forwarding that would otherwise leave a silent monitoring gap.
- Common Event Format fields
- Normalized fields such as origin, subject, object, action, status, and amount. Correlation rules evaluate these fields, so analytics fail when the relevant field is never populated.
- Correlation rule components
- A rule combines a filter selecting events, group-by keys, a time window, and a count threshold. Changing any component changes which activity the rule detects.
- Risk score versus severity
- Risk score derives from classification and contributes to prioritization, while severity is an assigned attribute. Tuning one does not automatically change the other or the computed alarm priority.
- Behavioral baseline analytics
- Rules that compare current activity against a learned baseline per entity or user. They need a stable learning period before thresholds produce meaningful results without excessive false positives.
- Rule simulation testing
- Built-in test mode runs a rule against historical data before enabling it. It reveals false-positive rate and confirms the rule fires on representative traffic.
- Data density rule constraint
- A threshold rule cannot fire if the log source sends fewer events than the threshold within the window. Low-volume sources need longer windows or lower counts.
- Alarm lifecycle states
- Alarms move from Open through Assigned or In Progress to Resolved, and can be reopened. Cases group related alarms into a single investigation record with an audit trail.
- Alarm rule versus correlation rule
- The correlation rule detects activity and generates an alarm. The alarm rule separately defines notification targets, escalation timing, and automatic case creation.
- Suppression versus throttling
- Suppression blocks duplicate alarms for the same entity or log source. Throttling caps alarm volume per time window. Both can mask real incidents if configured too broadly.
- Alarm notification targets
- Email, SNMP trap, syslog forward, and webhook or API. The target must be reachable from the Platform Manager, since notification originates there rather than from the console.
- Entity alarm rule override
- Entity-level alarm rules take precedence over global defaults. A silent or missing notification often traces to an inherited entity rule rather than a broken global configuration.
- False positive tuning loop
- Identify the offending rule, add a narrow exclusion rather than a broad filter, retest against historical data, then monitor alarm rate across a full business cycle.
- Case as incident record
- A case attaches alarms and evidence, records an owner and priority, and captures resolution. It serves as the auditable record of the incident from detection through closure.
- Evidence export requirements
- Export raw events and case details before retention expires. Include timestamps and source identifiers so the exported evidence supports chain-of-custody and later review.
- Cross-entity incident scope
- One incident may span multiple log sources and entities. Search by user, host, and IP rather than a single log source to avoid missing part of the scope.
- SIEM containment limits
- The platform investigates, correlates, and notifies. Endpoint isolation and network blocking occur in external tools, so containment steps must be documented outside the SIEM workflow.
- Post-incident rule review
- After resolution, confirm the detection rule fired correctly, document tuning changes, and record lessons learned in the case so the same gap is not repeated.
- Backlog as health signal
- Rising queue depth on Data Processors or Indexers precedes event loss. Monitor backlog alongside service status, license utilization, and disk capacity for early warning.
- Report scope accuracy
- Reports depend on entity scope and time range. A report scoped to the wrong entity silently omits data instead of returning an error, so verify scope before distribution.
- Dashboard widget binding
- Dashboard widgets bind to saved searches or report definitions. A slow dashboard usually reflects an expensive underlying query rather than a platform performance fault.
- MTTD and MTTR metrics
- Mean time to detect runs from event occurrence to alarm creation; mean time to respond runs from alarm open to case resolution. Both derive from alarm and case timestamps.