LogRhythm LRSA cheat sheet

Deployment tiers: Data Indexer, Data Processor, AI Engine (formerly Advanced Intelligence Engine), Platform Manager, and Client Console/Web Console; Data Processors collect and normalize, Indexers store, AI Engine runs correlation and analytics.

The Platform Manager hosts the Admin API, licensing, and configuration replication; Client Console connects over TCP 8501 to the PM by default, and Web Console uses HTTPS 443.

Data Indexer storage sizing rule: raw log retention is driven by licensed MPS (messages per second) times average event size times retention days; index storage is typically estimated at roughly 20-30% of raw volume depending on indexing policy.

Entity hierarchy: System Monitor -> Entity -> Log Source; alarms, cases, and RBAC permissions inherit through the entity tree, so placing a log source under the wrong entity misroutes alarms and reports.

User roles include Administrator, Analyst, and restricted custom roles; RBAC is enforced by entity-level read/write permissions and by client permission sets, not by log source alone.

Backup and HA: Platform Manager backup captures configuration and the SQL database; Data Indexers use replication for redundancy, and an Indexer failure triggers index rebuild or failover rather than data re-collection.

Upgrade order is Platform Manager first, then Data Processors, AI Engine, and Indexers; verify the compatibility matrix and take a configuration backup before any version change.

Health checks to run routinely: Data Processor/Indexer service status, license MPS utilization, disk and index capacity, and time-source accuracy via NTP on all appliances.

Log source onboarding sequence: configure the device to send logs, create the Log Source in the Client Console with the correct Log Source Type, assign an Entity, then validate parsing in the Log Source Monitor.

MPS (Messages Per Second) is the licensing metric; a single device bursting above its average rate can consume shared licensed MPS and cause throttling across the deployment.

Parsing uses a Log Source Type's MPE (Message Processing Engine) rules; unparsed or misparsed events appear in the Log Source Monitor with the raw message and the failing reason.

Collection methods include Syslog (UDP/TCP 514, TLS 6514), agent-based collection, SNMP traps, file/API collection, and Windows Event Forwarding; choose by device capability and reliability needs.

Log Source virtualization: one physical device sending multiple log types can be split into multiple virtual log sources by using different ports or source identifiers.

Date parsing is the most common onboarding failure; if the device omits the year or timezone, set the Log Source Type date parser explicitly rather than relying on receipt time.

Silence/absence detection is configured per log source with a threshold; it fires an alarm when no events arrive within the window, catching broken forwarding.

Log retention and archiving: raw data retention is set at the Indexer, while archival to external storage is a separate policy; confirm which tier satisfies your compliance requirement.

AI Engine analytics comprise correlation rules, advanced intelligence rules, and behavioral analytics; correlation rules evaluate normalized fields, while AI Engine rules can use stateful and multi-event logic.

Normalization maps raw fields to the Common Event Format fields (e.g., origin, subject, object, action, status, amount); analytics only work when the relevant CEF field is populated.

Rule building blocks: filter (which events), group-by (entity, log source, user, host), time window, threshold/count, and suppression; changing any one changes the detection outcome.

Risk-based prioritization uses Risk Score derived from classification, while alarm severity and priority are separate attributes; do not conflate risk with severity when tuning.

Baseline/behavioral analytics compare current activity to a learned baseline per entity or user; they need a stable learning period before thresholds are meaningful.

Trend and rate analytics require adequate data density; a rule with a 1-hour window and a count threshold of 5 will not fire if the log source sends fewer than 5 events per hour.

Test analytics with the rule's built-in test/simulate mode against historical data before enabling, and check the false-positive rate against representative traffic.

Alarm lifecycle: Open -> Assigned/In Progress -> Resolved, with optional escalation; a resolved alarm can be reopened, and case creation links alarms into an investigation record.

Alarm rules define notification targets, escalation timing, and whether the alarm auto-creates a case; they are distinct from the correlation rule that detects the event.

Suppression and throttling: suppression by entity/log source prevents duplicate alarms, while throttling limits alarm volume per time window; both must be tested to avoid masking real incidents.

Notification methods include email, SNMP trap, syslog forward, and webhook/API; verify the notification target is reachable from the Platform Manager, not just the Client Console.

Alarm priority is a computed value combining severity, entity risk, and other factors; changing severity alone may not change the displayed priority as expected.

Global vs. entity-specific alarm rules: entity-level rules override global defaults, so a silent alarm often traces to an inherited entity rule.

False-positive tuning loop: identify the offending rule, add a precise exclusion (not a broad filter), retest against historical data, then monitor the alarm rate for a full business cycle.

Case management workflow: create or auto-create a case, attach alarms and evidence, assign an owner, set priority, and record the resolution; the case is the audit trail for the incident.

Investigation tools include the alarm detail view, the Log Search/Investigation tab, entity and user drill-down, and timeline reconstruction across log sources.

Evidence preservation: export raw log events and case details before retention expires; exported evidence should include timestamps and source identifiers for chain-of-custody.

Containment actions available from the platform are primarily investigative and notification-based; endpoint isolation and blocking are performed in external tools, not the SIEM itself.

Escalation paths should be defined by severity and entity criticality, with named owners and response-time targets; escalation is often automated via alarm rules.

Post-incident review: confirm the detection rule fired correctly, document tuning changes, and update the case with lessons learned so the same gap is not repeated.

Correlation across entities: a single incident may span multiple log sources and entities; search by user, host, and IP rather than by a single log source to avoid missing scope.

Platform health monitoring covers Data Processor and Indexer service status, MPS utilization against license, disk capacity, and queue/backlog depth; a rising backlog precedes data loss.

Report types include scheduled reports, ad hoc reports, and dashboards; scheduled reports are delivered by email or stored, and require a valid report definition and data range.

Report accuracy depends on the entity scope and the time range; a report scoped to the wrong entity silently omits data rather than erroring.

Compliance reporting maps to frameworks (e.g., PCI DSS, HIPAA) via predefined report templates; verify the template covers the specific control you must evidence.

Dashboards are built from widgets bound to saved searches or report definitions; a slow dashboard usually indicates an expensive query, not a platform fault.

Audit and user activity reporting tracks administrative actions such as rule changes, log source edits, and user permission changes; these are essential for change control.

SLA metrics to track: mean time to detect (MTTD) and mean time to respond (MTTR), computed from alarm open time to case resolution time.