LogRhythm University

Administration Fundamentals
LogRhythm v7
Administration
Fundamentals
LogRhythm v7
LogRhythm University

v3.3
© LogRhythm, Inc. All rights reserved.
This document contains proprietary and confidential information of LogRhythm, Inc., which is protected
by copyright and possible non-disclosure agreements. The Software described in this Guide is furnished
under the End User License Agreement or the applicable Terms and Conditions (“Agreement”) which
governs the use of the Software. This Software may be used or copied only in accordance with the
Agreement. No part of this Guide may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying and recording for any purpose other than what is
permitted in the Agreement.

Disclaimer
The information contained in this document is subject to change without notice. LogRhythm, Inc.
makes no warranty of any kind with respect to this information. LogRhythm, Inc. specifically disclaims
the implied warranty of merchantability and fitness for a particular purpose. LogRhythm, Inc. shall not
be liable for any direct, indirect, incidental, consequential, or other damages alleged in connection with
the furnishing or use of this information.

Trademark
LogRhythm is a registered trademark of LogRhythm, Inc. All other company or product names
mentioned may be trademarks, registered trademarks, or service marks of their respective holders.

LogRhythm Inc.
4780 Pearl East Circle
Boulder, CO 80301
(303) 413-8745
www.logrhythm.com

LogRhythm Customer Support

[email protected]
CONTENTS
Chapter 1: Introduction 1
Administration Fundamentals: Introduction 2

What is a SIEM? 3

A Unified Platform 4

Log Data 5

Log Providers 6

Log Messages Made Easy-to-Use 7

Uniform Data Classification 9

Classifications and Common Events 10

Types of Metadata 12

Event Qualification 13

Alarming and Reporting 15

Log Storage 16

Profile Types 17

Next Steps 18

Exercises 19

Exercise 1: Review Questions 20

Chapter 2: Platform Overview 21

LogRhythm Components 22

Life of a Log in LogRhythm 23

System Monitors 26

Administration Fundamentals │ Contents iii

 Data Processors 27

Message Processing 28

Advanced Intelligence Engine 29

Platform Manager 30

Platform Manager Services 32

Data Indexer 34

Client Console 35

Web Console 36

Platform Review 37

Exercises 39

Exercise 1: Access the LogRhythm Training Environment 40

Exercise 2: Explore the LogRhythm Deployment Manager 42

Chapter 3: Object Management with Entities and Lists 43

Entities 44

Organizing Entities 45

Adding Entities from a CSV File 47

Entity Contents: Network and Host Records 49

Network Records 51

Direction 51

Assigning Risk and Threat 52

Add Network Records from a CSV File 54

Host Records 57

Log Sources and Host Records 58

Adding Host Records 59

Add a Host Record Manually 59

Adding Host Records via Batch Imports 61

iv Administration Fundamentals │ Contents

 Entities Reorganization Wizard 62

Lists 63

Using Lists 64

List Permissions 65

Managing Lists 67

Using Wildcards in Lists 69

Retiring and Activating Lists 70

Expiring Items 71

Exercises 73

Exercise 1: Exploring the Entity Structure 74

Exercise 2: Modifying an Entity Structure 77

Exercise 3: Create a List 84

Exercise 4: Modify a List 87

Chapter 4: System Monitors 89

System Monitor Overview 91

Supported Platforms for System Monitor Deployment 92

System Monitor Installation 94

System Monitor Permissions 95

System Monitor Acceptance 96

System Monitor Licensing 97

Data Processor Settings 99

Remote Collection Configuration: Syslog and Flow 100

Remote Collection Configuration: SNMP Trap Receiver 102

Endpoint Monitoring 103

User Activity Monitoring 104

File Integrity Monitor 105

File Integrity Monitor Policies 107

Administration Fundamentals │ Contents v

 Registry Integrity Monitoring 108

Data Loss Defender 109

Process and Network Connection Monitors 110

System Monitor Configuration Policy Manager 112

System Monitor Package Manager 113

System Monitor Updates 116

Initiate SmartResponses from a System Monitor 117

Exercises 119

Exercise 1: Create a New File Integrity Monitor Policy 120

Exercise 2: Create a New Data Loss Defender Policy 125

Exercise 3: Enable Endpoint Monitors 126

Chapter 5: LogRhythm Log Sources 129

Log Sources Overview 130

Log Sources and Host Records 131

Adding Host Records 132

Adding Log Sources 133

Adding Log Sources from a File 134

Adding Log Sources from the System Monitor 137

Log Source Basic Configuration Tab 139

Log Source Additional Settings Tab 141

Flat File Settings Tab 143

UDLA Settings Tab 145

Syslog, Flow, and SNMP Log Sources 146

Automatic Log Source Acceptance 148

Windows Host Wizard 150

Exercises 151

Exercise 1: Adding Log Sources via a System Monitor 152

vi Administration Fundamentals │ Contents

 Exercise 2: Adding Log Sources Via the Windows Host Wizard 159

Exercise 3: Adding a Flat File Log Source 170

Chapter 6: Users, Profiles, and Permissions 177

Security Overview 178

Notification Policies 179

User Profiles 184

Managing User Profiles 186

Restricted Analysts 188

Restricted Administrators 190

Active Directory Group Authorization 192

Person and Role Records 193

Creating a New Person or Role Record 195

User Accounts 196

LogRhythm Permissions Model 198

Entities and Permissions 201

Exercises 203

Exercise 1: Create a Notification Policy 204

Exercise 2: Create a User Profile 207

Exercise 3: Create a New Person Record 212

Exercise 4: Create a New User Account 215

LogRhythm Community Reference Links 217

Glossary 219

Administration Fundamentals │ Contents vii

 This page intentionally left blank.

viii Administration Fundamentals

CHAPTER 1
Introduction
Administration Fundamentals: Introduction 2
What is a SIEM? 3
A Unified Platform 4

Log Data 5
Log Providers 6

Log Messages Made Easy-to-Use 7

Uniform Data Classification 9

Classifications and Common Events 10

Types of Metadata 12

Event Qualification 13
Alarming and Reporting 15
Log Storage 16
Profile Types 17
Next Steps 18
Exercises 19
Exercise 1: Review Questions 20

Administration Fundamentals │ Introduction 1

 Administration Fundamentals: Introduction
Welcome to the LogRhythm Administration Fundamentals training course. The objective of this course is
to introduce you to the day-to-day administrative activities performed in the LogRhythm Platform. We
designed this course to take you through the common administrative activities of managing the
LogRhythm Platform. Use this manual as both an instructional tool during class and as a reference guide
in the future.

The objective of this chapter is to introduce you to LogRhythm and explain how it processes log
messages. The most common administrative activities for the LogRhythm Platform require that you are
familiar with the following topics:

The LogRhythm Platform
The Components and Services
Entities and Lists
Deploying and Configuring System Monitors
Configuring Log Sources
Notification Policies, People Records, and User Security

2 Chapter 1 | Introduction
What is a SIEM?

You may wonder why we are asking this question. We provide this explanation for those who come from
backgrounds outside of security intelligence. Defining a SIEM helps ensure everyone is beginning this
course with the same basic information.

A SIEM (Security Information and Event Management) platform seeks to provide a holistic approach to an
organization’s IT security. SIEM denotes a combination of services, appliances, and software products
that provide correlation and notification of events, and real-time analysis of security alerts generated by
network hardware and applications. A SIEM can also log security data and generate reports for
compliance purposes.

Chapter 1 | Introduction 3
 A Unified Platform

LogRhythm is much more than just a SIEM. LogRhythm empowers organizations to detect, respond to,
and neutralize emergent cyber threats, preventing damaging data breaches and cyber incidents.

LogRhythm’s Security Intelligence Platform integrates:

Next-generation SIEM and log management

Endpoint forensics, with registry and file integrity monitoring
Network forensics, with application ID and full packet capture
Behavioral analytics for holistic threat detection (users, networks, and endpoints)
Rapid unstructured and contextual search
End-to-end incident response orchestration work-flows to support team collaboration
SmartResponseTM automation framework
User and Entity Behavior Analytics (UEBA) services

LogRhythm addresses today’s most sophisticated cyber threats. The LogRhythm Platform attains full
visibility by aggregating log and machine data with network and endpoint data. LogRhythm’s patented
machine analytics technology continually performs real-time analysis on this activity, helping identify
previously unknown threats. When a threat is detected, analysts can quickly qualify and investigate it by
pivoting and drilling down into rich forensic data. The platform’s collaborative incident response orches-
tration and patented SmartResponse automation framework help security teams efficiently perform
Threat Lifecycle Management (TLM).

4 Chapter 1 | Introduction
Log Data

LogRhythm collects log data from a wide variety of sources: data related to systems, network devices,
and applications. More specific log data can be collected that relates to security, unauthorized activities,
misuse of company resources, user activity, file integrity, and many other common computing activities.

Chapter 1 | Introduction 5
 Log Providers

The devices in your network are generating thousands of raw logs at every moment. These logs are
generated in a wide variety of formats, and they represent varying degrees of importance in maintaining
and protecting your environment. LogRhythm processes log data to make information available to you in a
meaningful and uniform context.

Common devices and applications that provide log data are:

MS Windows, UNIX, Linux, and AS/400 servers

Firewalls, switches, and routers
Intrusion Prevention Systems (IPS) or Intrusion Detection Systems (IDS) devices
Application servers (web, database, and email)
And more

A Log Source is a type of log originating from a specific host. In LogRhythm, each log provider can
contribute one or more Log Sources.

Example
A Windows server would contribute three different Log Sources by default, one for each Windows
Event Log type:
- Application
- System
- Security

6 Chapter 1 | Introduction
Log Messages Made Easy-to-Use

Log messages are generated from many different types of systems and there are many different types of
log messages. Some of this log data is easily readable, but in many cases it is not. LogRhythm takes the
log messages and makes the data easy-to-use by parsing pieces of data into structured fields.

LogRhythm actively parses and breaks down the log message into core components, identifying what
kind of data the log message contains, the meaning behind the message, and the relative importance of
the action described in the message. The data parsed from the log messages is called metadata, which
can be defined as data about the data.

LogRhythm maintains a wide variety of common metadata fields that identify most data found within the
different log message types. This is how the “data about the data” is converted into the same language.
By converting many different types of log messages from many different types of systems into a common
language, or common metadata fields, LogRhythm has the ability to compare reasonably similar data and
then correlate data that otherwise may not have been relatable.

For example, a Windows server and a Unix server both produce log data about user login activity,
however the log data does not look the same. By parsing data into common metadata fields, searching for
that data in the mass of log messages is made easy using consistent terminology, or a consistent
language.

Because metadata is stored in databases using common metadata field names, it can be quickly refer-
enced for more efficient searching and allows for in-depth reporting and analysis.

Note: See LogRhythm Metadata in the Help Guide for a complete list of metadata fields.

Chapter 1 | Introduction 7
 Before and After Processing
This is a raw log message, pictured in the Microsoft Windows Event Viewer:

This is the same log message after it has been processed, pictured in the LogRhythm Log Viewer:

8 Chapter 1 | Introduction
Uniform Data Classification

Time Normalization is a process performed by the System Monitor to ensure timestamps all reflect the
same time zone.

Every log message processed successfully by LogRhythm will be assigned a Classification and a
Common Event. Classifications define the broad range of activity, and Common Events provide a more
descriptive context for the activity described in the log message.

There are three top-level Classification types (with additional sub-Classifications under each):

Audit - Account Created, Access Success, Authentication Success, etc.

Operations - Warning, Error, Critical, Network Traffic, etc.
Security - Reconnaissance, Suspicious, Malware, etc.

Metadata Extraction & Tagging is done by the Data Processor to actively parse and break down the log
message into core components, identifying what kind of data the log message contains, the meaning
behind the message, and the relative importance of the action described in the message.

Threat & Risk Contextualization is performed by the Data Processorto evaluate each log and provide a
Risk-Based Priority value. Higher value log messages are forwarded as Events to the Platform Manager
and indexed into the Events database.

Chapter 1 | Introduction 9
 Classifications and Common Events

To further define the type of activity being identified in a log message Classification, a Common Event is
assigned to every identified log message. Common Events are not intended to be highly specific;
however, they are meant to refine the Classification assignment into a more particular set of activities.

Under the Classification of Audit: Authentication Success, the following Common Events are contained:

User Logoff
User Logon
Computer Logoff
Computer Logon
Service Logoff
Service Logon

In the Common Events listed above, the act of authenticating is being described. However, each
Common Event gives you a better indication of what actually happened in a log message. If a Windows
computer connects to a network for the first time in a day, it will perform a Computer Logon with the
Domain Controller. Then, when a user accesses the same computer, a User Logon message will be
created to indicate the successful authentication activity for that user.

Common Events include data from many types of Log Sources. Remember, LogRhythm converts the
“data about the data” into the same language. By converting many different types of log messages from
many different types of systems into a common language, or common metadata fields, LogRhythm has
the ability to compare and correlate data that otherwise may not have been relatable.

10 Chapter 1 | Introduction
 Example
A log describing a user logging into a Unix host will be assigned to the Common Event of User
Logon. A log describing a user logging into a Windows host will also be assigned to the same
Common Event of User Logon. The same is true if a user were to log in to a database, website, or
other application. The activity is that a user is logging onto a system, application, etc.; therefore, the
common activity is User Logon.

Note: The previous image is only a small sampling of available Classifications and Common
Events.

Chapter 1 | Introduction 11
 Types of Metadata

There are three types of metadata in LogRhythm. Two types are parsed directly from the raw log
message.

Contextual metadata fields are directly parsed from log messages, usually text-based in nature,
and are descriptive in relation to the message.
Examples include: Login (Origin Login), Subject, Domain, and Object.
Quantitative metadata fields are directly parsed from log messages and can be used for numeric
comparisons.
Examples include: Bytes In/Out, Rate, and Size.

In addition to parsing metadata directly from the log message, LogRhythm derives some metadata from
the logs.

Derived metadata fields use parsed information from log messages and relate it to the LogRhythm
configuration information to provide additional context about the log message.
Examples include: Origin Entity, Impacted Known Host, and Direction.

12 Chapter 1 | Introduction
Event Qualification

Most log data can be overwhelming. It can be useful in forensic investigations or statistical data analysis,
but most of this data is generally unusable by itself without having additional context. Some log data is
considered "noise," meaning it is not useful in day-to-day operations.

The next step in the processing of data involves certain logs being identified as Events. An Event is a log
having more immediate operational, security, or compliance relevance. Events typically include logs that
are classified as errors, failures, or attacks.

To add context and thus be considered actionable, logs related to when a computer is updated, or when a
user browses to an unauthorized web site, or when a hacker attempts to break into an internal resource,
are flagged as Events.

Example
Log messages are generated by firewalls when one computer requests a connection to another
computer on the other side of the firewall.

Messages such as TCP Build Up, TCP Tear Down, # of Bytes Sent, and other messages are generated
by this communication. This activity can happen thousands of times in one second from hundreds of
different servers and is extremely "noisy". These logs are not typically recognized as Events; however, a
log message for a connection failure might be flagged as an Event.

Events consist of:

Less than 5% of the total number of logs collected

Actionable log items
o Actionable logs are more significant than other logs
o These logs include security related items (login failures, hacking attempts, elevated user
permissions granted)
o System related items (service or software failures, reboot messages)

Chapter 1 | Introduction 13
 Using Events

Once Events have been identified and stored by LogRhythm, they can be used in:

Real-time monitoring
Reports
Investigations
Alarms

Event data is accessible through a variety of locations within the system. You can perform log analysis
and monitor real-time data via the Dashboards. You can drilldown into Events to view more detailed
information about the log data. Alarms and Reports are also commonly driven from Event data.

Active Alarm Rules watch the live Event data as it is collected and will trigger an Alarm and notify a user
or system if certain criteria and/or thresholds are met.

Note: Logs that do not qualify as Events are available for reporting, investigating, and can be
correlated to trigger AI Engine Alarms; however, they are not used to trigger traditional Alarms.

14 Chapter 1 | Introduction
Alarming and Reporting

The LogRhythm Platform includes a real-time Alarming system that can notify users and systems when
certain criteria are met. In addition, the Alarming system includes SmartResponse (automatic remedi-
ation) actions for responding to certain scenarios observed by LogRhythm.

For less immediate needs, LogRhythm provides a full-featured Reporting Engine and system reports. You
can generate detailed or summary reports based on log data collected by the LogRhythm Platform.
Reports can be scheduled to run on a regular basis, or run on-demand. Reports can be delivered via email
once they have been created by the scheduled job process.

Alarms and Reports are pre-packaged in the LogRhythm Platform to assist with meeting compliance
requirements, including NERC CIP, GLBA, PCI DSS, SOX, FISMA, HIPAA, and more.

Note: For your reference, here are the acronyms all spelled out:
NERC CIP (North American Electric Reliability Corporation Critical Infrastructure Protection)
GLBA (Gramm-Leach-Bliley Act)
PCI DSS (Payment Card Industry Data Security Standard)
SOX (Sarbanes–Oxley)
FISMA (Federal Information Security Management Act)
HIPAA (Health Insurance Portability and Accountability Act

Chapter 1 | Introduction 15
 Log Storage

Log data is maintained and stored indefinitely by the LogRhythm Platform (provided there is enough disk
space to hold it). However, not all of the data is stored online indefinitely.

The following databases store specific log data as described below:

Events database—A component of the Platform Manager (PM). The Events database is the
central repository for logs identified as Events, it stores the raw log and metadata parsed from
those log messages. Data is stored here for a total of 90 days, by default.
Data Indexer—Allows for search-based analytics and provides indexing of data. The Data Indexer
(DX) stores both the raw log message and the metadata parsed from all logs sent to the Data
Processor (DP). Log data is stored here until storage capacity reaches 80%, or about 30 days on
average.
Archive—Provides long-term storage for all raw log messages that have been processed by
LogRhythm. Archives are stored indefinitely, allowing for access to historical data that may have
been removed from one of the above storage locations. Archives are usually stored in an external
storage location.

Data that is indexed (in a database) can be searched for investigative purposes, forensic research, and
system troubleshooting. Indexed data is data contained in any of the above databases, whereas Archived
data is data that has been stored and secured in the LogRhythm Archive files.

16 Chapter 1 | Introduction
Profile Types

Since much of the data collected by LogRhythm is security-related, access to that data on a user-by-user
or group-by-group basis is required. LogRhythm supports a wide variety of access options for user
accounts; each LogRhythm user is granted access under a specific security role.

Global Administrators have administrative access to the entire LogRhythm Platform. Global Admin-
istrators fully manage the following components:

Data Management Profiles, Active Directory Synchronization, and other aspects of the
Platform Manager
Users, Groups, Access Profiles, and User Accounts
System Monitors, Network Monitors, Log Sources, Lists, and Reports
Entities, Hosts, and Network Records
AI Engine Rules and Alarms
Web Console

Restricted Administrators can manage areas of the LogRhythm Platform dependent on the permissions
assigned via their Role Based Access Profile.

Global and Restricted Analysts have permissions to view data collected by LogRhythm.

Global Analysts can view all data collected.

Restricted Analysts have a limited view of collected data, usually limited by Entity or Log Source
List.

Chapter 1 | Introduction 17
 Next Steps
This course will focus on the day-to-day administration of the LogRhythm Platform for both Global and
Restricted Administrators. Topics covered in this course are:

LogRhythm Platform Overview

Entities and Lists
System Monitors
Log Sources
User Profiles

18 Chapter 1 | Introduction
EXERCISES
Introduction
Exercise 1: Review Questions 20

Chapter 1 | Introduction 19
 Exercise 1:
Review Questions

The purpose of this exercise is to verify your understanding of LogRhythm.

1. LogRhythm actively parses and breaks down the log message into core components, identifying
the data the log message contains, the meaning behind the message, and the relative importance
of the action described in the message. What is this process referring to?
______________________________________________________________

2. Every log message identified by the Data Processor is assigned what things (select all that apply)?
a. Time Normalization
b. Classification
c. Metadata
d. Threat & Risk Ratings
e. All of the Above

3. What are the 3 top level Classifications?

______________________________________________________________

4. What are Events?

a. Logs having more immediate operational, security, or compliance relevance
b. A type of error, failure, or attack
c. They are determined by Risk Based Priority values
d. All of the above

5. What are the main databases and what types of information do they store?
______________________________________________________________

6. True or False. There are 5 types of User Profiles: Global and Restricted Administrators, Global and
Restricted Analysts, and Notification Only.

20 Chapter 1 | Introduction
CHAPTER 2
Platform Overview
LogRhythm Components 22
Life of a Log in LogRhythm 23

System Monitors 26

Data Processors 27

Advanced Intelligence Engine 29

Platform Manager 30

Data Indexer 34
Client Console 35
Web Console 36
Platform Review 37
Exercises 39
Exercise 1: Access the LogRhythm Training Environment 40

Exercise 2: Explore the LogRhythm Deployment Manager 42

Administration Fundamentals │ Platform Overview 21

 LogRhythm Components

The objective of this chapter is to provide you with the foundation needed to understand the LogRhythm
Platform.

The LogRhythm Platform is comprised of the following major components:

System Monitors: Collects log data about the behavior of users, files, applications, and the
system; generates real-time forensic data to support analytics and incident response.
Data Processor (DP): Performs log processing and forwarding functions; archives data and
distributes both original and structured copies of data to other components for indexing, machine-
based analytics, and alarming.
Data Indexer (DX): Provides highly-scalable indexing and searching of machine and forensic data.
AI Engine: Rule-based and adaptive advanced analytics engine that evaluates real-time log data
to detect attacks, complex operations issues, changes in systems behavior, and more.
Platform Manager (PM): Provides alarming, notifications, case and security management, work-
flow automation, and centralized administration for the LogRhythm Platform.
Web Console: Web interface that provides easy access to analytic tools, alarms, and custom-
izable dashboards.
Client Console: Used to manage all aspects of a deployment, customize different views for
analysis and monitoring, and manage investigations.

All of these components work together to create the LogRhythm Platform.

22 Chapter 2 | Platform Overview

Life of a Log in LogRhythm
The following diagram illustrates the route of a log through the LogRhythm Platform.

Chapter 2 | Platform Overview 23

24 Chapter 2 | Platform Overview
Chapter 2 | Platform Overview 25
 System Monitors

The LogRhythm System Monitor, also known as SysMon, is responsible for all log data collection.
System Monitors can be installed on both Windows and UNIX platforms and communicate with the Data
Processor.

System Monitors can be leveraged to monitor local system performance, network and user activity, and
File Integrity Monitoring (FIM).

The Windows System Monitor includes extensive local and remote log collection capability. Many
advanced Log Source collection options are available with the Pro license, such as Cisco IDS integration
(via the Cisco SDEE [Security Device Event Exchange] interface), CheckPoint Firewall integration,
Universal Database Log Adapter (UDLA), and additional features for Windows Registry monitoring.

26 Chapter 2 | Platform Overview

Data Processors

System Monitors send log data directly to the Data Processor (DP). The Data Processor acts as a central
processing engine for log messages collected by the System Monitors. A single DP may have one or
more System Monitors reporting to it, but a System Monitor will only report to one DP at a time.

DPs are scalable both horizontally and vertically to support a small-to-large log collection load. This
scalability means that you can increase the size of an existing DP (scale it vertically) or add additional
DPs to your LogRhythm Platform (scale it horizontally).

The DP processes logs, sends copies of data to the Data Indexer, AI Engine, Platform Manager, and also
ensures all data is forwarded to an Archive location.

Log Storage (Archives)

Active Archive—binary, flat-file, non-compressed, and non-secured storage of all log files. Logs
exist here until the file becomes 10 MB in size or 7 days old, whichever comes first (Indexer
Database).
Inactive Archive—binary, flat-file, compressed, and secured long-term storage of all log files
collected by the DP.

Note: Archive files can be configured to be written to a remote storage location rather than
on the DP itself.

Services:
Mediator—This service is the heart of the DP. It is responsible for processing all log data collected
and forwarded by System Monitors. This service is performed by the Message Processing Engine
(MPE). The Mediator is responsible, for processing and storing of archives, for forwarding all
processed log messages to the platorm manager for storage in various LogRhythm databases, and
forwarding all successfully processed log messages to the AI Engine.

Chapter 2 | Platform Overview 27

 Message Processing

Log message processing is performed by the Message Processing Engine (MPE). The MPE is
responsible for identification, classification, event processing, and metadata processing. Each role is
described in detail below:

Log Identification—Every log processed by the MPE is first assigned a Common Event.
Common Event assignment is determined by a Log Processing Rule (MPE Rule) associated to its
Log Source Type.
Metadata Processing—LogRhythm parses, calculates, and derives metadata from log messages.
The metadata is stored in a database to speed performance when you use tools such as Search
and Reporting.
Log Classification—Each Common Event belongs to a higher-level Classification (e.g., Opera-
tions, Audit, or Security) and sub-Classification (e.g., Attack, Policy, Access Granted, etc.).

Example
A Common Event of User Account Created belongs to the Sub-Classification of Account
Created, which is a member of the top level Classification of Audit.

Example
The Common Event of Access to Restricted Application belongs to the Sub-Classification of
Suspicious, which is a member of the top level Classification of Security.

Event Processing—Some logs are identified as Events. This qualification is based partially on the
MPE Rule. Then the Risk Based Priority (RBP) calculation assigns a value that qualifies a log as
important enough to be an Event. Event log data is forwarded to the Platform Manager, stored in the
Events Database, and is displayed in the Console Dashboards.

28 Chapter 2 | Platform Overview

Advanced Intelligence Engine

The LogRhythm Advanced Intelligence (AI) Engine performs real-time analysis of all log messages
processed by LogRhythm. Not limited to Events data, all identified logs are forward directly from the Data
Processor to AI Engine for additional analysis.

AI Engine is a correlation and analysis component designed to detect previously undetectable, or

extremely difficult to detect, issues. Logs are evaluated using a complex pattern-matching rule set that
can correlate and detect sophisticated security or operational incidents, such as:

Sophisticated intrusions
Insider threats and thefts
Operational issues
Auditor compliance issues

Chapter 2 | Platform Overview 29

 Platform Manager

The Platform Manager (PM) is the central hub of the LogRhythm platform. For all LogRhythm deploy-
ments, there is one single operating PM. In small deployments, the Platform Manager can also host a
LogRhythm Data Processor (DP). In larger deployments, it should be a dedicated appliance.

The Platform Manager serves as the repository for Events, configuration and licensing information, and
the LogRhythm Knowledge Base. The PM contains the following databases and services:

Alarms Database — stores all Alarms and Alarm histories; data stored here has a 90 day time-to-
live (TTL), by default
Events Database — stores Event logs and metadata; 90 day TTL, by default
Case Management Database (CMDB) — stores all Cases created in the Web Console for an
indefinite period of time; storage retention is based on available disk space
Event Manager Database (EMDB) — this database should always be backed-up because it
stores the master configuration database for your LogRhythm deployment; it consists of the
following information:
o LogRhythm Knowledge Base (KB) —contains all processing rules, built-in reports, built-in
Alarm rules, and other processing-related information
o Configuration information — for all of the System Monitors, Log Sources, and Log Source
Types
o LogRhythm assets — records for all System Monitors, Data Processors, Platform
Managers, and other appliances
o Users — People records and User account records
o Lists — contains information about groups of Log Sources, users, groups, MPE Rules, and
other LogRhythm objects used by filters, reports, and Alarms.
o Entities — organizational units used to organize the LogRhythm Platform and to represent
the hosts and networks contained in your corporate IT infrastructure
Job Manager Service — responsible for all scheduled tasks within the LogRhythm Platform

30 Chapter 2 | Platform Overview

 Alarming and Response Manager (ARM) Service — responsible for SNMP and text file Alarm
notifications and SmartResponse actions generated by enabled Alarms

Chapter 2 | Platform Overview 31

 Platform Manager Services

Alarming and Response Manager

The Platform Manager's ARM Service is a Windows service responsible for processing Alarm Rules and
taking the appropriate response, such as sending a notification to people specified in an Alarm Rule or
performing SmartResponse auto-remediation actions.

The ARM service can perform the following types of notifications:

SMTP — simple text based email notifications sent to individual users or distribution lists
SNMP traps (versions 1, 2, and 3) — generated and sent to SNMP-enabled receivers

Text files — details for an Alarm can be written to a flat text file in a variety of formats, such as
comma-separated, tab-separated, or custom delimiter separated formats

Note: Email notifications for AI Engine Alarms can also be sent in HTML format, however these
are processed by the Notification service and not the ARM service. This was a new service intro-
duced in v7.3.

Job Manager
The PM's Job Manager service is responsible for running scheduled jobs and writing any scheduled
Reports to a specified network location. Scheduled jobs may include:

Scheduled Report generation

Active Directory (AD) synchronization; every 15 minutes

32 Chapter 2 | Platform Overview

 All LogRhythm component heartbeat monitoring
General health monitoring of LogRhythm components

Note: Both the ARM and Job Manager services are configured and controlled on the Platform
Manager tab of the Deployment Manager in the Client Console. The Start, Stop, and Restart
service buttons control both of these services.

Chapter 2 | Platform Overview 33

 Data Indexer

The Data Indexer (also known as the Indexer or DX) provides high-performance, distributed, and highly
scalable indexing and searching of machine and forensic data. Indexers store both the original log
messages and structured copies of metadata to enable search-based analytics.

The DX provides next-generation persistence and search capabilities and high performance, distributed,
highly scalable indexing of machine and forensic data. Indexers can be clustered in a replicated config-
uration to enable high-availability, improved search performance, and support for a greater number of
simultaneous users.

Data stored on the Indexer will be retained until the drive is 80% utilized. A micro-service, called
LogRhythm DX - Data Indexer Maintenance (GoMaintain), is constantly running and will remove older
indicies of data to make room for new data sent from the Data Processor.

34 Chapter 2 | Platform Overview

Client Console

The LogRhythm Client Console is a user interface for access into the LogRhythm Platform.

Administrators use this console to configure the LogRhythm Platform, perform log management activ-
ities, manage Reports, Alarms, user profiles, and monitor the health of LogRhythm.

This console also provides an interface for analysts to perform forensic searches, data analysis,
reporting, and personal Alarm creation.

The console is a 64-bit, high-performance component that can be accessed from a Windows platform
either directly on a workstation or via a remote connection such as Citrix or Remote Desktop Protocol
(RDP).

Chapter 2 | Platform Overview 35

 Web Console

The LogRhythm Web Console provides analysts with information in an easy-to-use web front-end. It is
built on modern web technology, including Elasticsearch, Lucene, HTML5, and more.

Like other LogRhythm components, the Web Console is a stand-alone component that can be installed on
a dedicated appliance or alongside the Platform Manager in smaller scale deployments.

36 Chapter 2 | Platform Overview

Platform Review

This image summarizes everything we just talked about in this chapter.

Chapter 2 | Platform Overview 37

 This page intentionally left blank.

38 Administration Fundamentals
EXERCISES
Platform Overview
Exercise 1: Access the LogRhythm Training Environment 40
Exercise 2: Explore the LogRhythm Deployment Manager 42

Chapter 2 | Platform Overview 39

 Exercise 1:
Access the LogRhythm Training Environment

The purpose of this exercise is to ensure that you are able to connect to your Training Virtual Machine
(VM).

1. Open a browser on your workstation and navigate to: logrhythm.instructorled.training

2. Enter your unique access code. Your Instructor will provide your access code.

3. Enter your First name and Last name and click OK. You do not need to enable password protection.

4. Select Lab from the top tool bar.

40 Chapter 2 | Platform Overview

 5. Click the Remote Desktop icon that says Connect to the lab.

6. The Remote Desktop session will start, and will probably default to a different login account. Click
the back-arrow to select the Administrator account.
Login to the virtual host using the Administrator account with the password logrhythm!1

7. Click the icon located on the Task Bar of your Training VM, to open the LogRhythm Client Console:

8. Log into the LogRhythm Client Console using the account: LogRhythmAdmin and password:
logrhythm!1

Note: logrhythm!1 will be used as a password thorughout the training course. Remember it!

Chapter 2 | Platform Overview 41

 Exercise 2:
Explore the LogRhythm Deployment Manager

The purpose of this exercise is to locate and explore the various areas of the Deployment Manager. Click
the Deployment Manager button at the top of the LogRhythm Client Console window.

From the Deployment Manager:

1. Which tab contains information for each System Monitor?

2. How many System Monitors are listed in this deployment?

3. Which tab contains information on the hosts and networks monitored by LogRhythm?

4. Which tab shows all of the Log Source Types currently supported by LogRhythm?

5. Are there any Alarm Rules currently enabled? If so, which ones?

6. From the top tool bar, navigate to the Help button and then select About LogRhythm. What is the
Core Knowledge Base Version?
______________________________________________________________

42 Chapter 2 | Platform Overview

CHAPTER 3
Object Management with Entities
and Lists
Entities 44
Organizing Entities 45

Adding Entities from a CSV File 47

Entity Contents: Network and Host Records 49

Network Records 51

Host Records 57

Lists 63
Using Lists 64

List Permissions 65

Managing Lists 67

Using Wildcards in Lists 69

Retiring and Activating Lists 70

Expiring Items 71

Exercises 73
Exercise 1: Exploring the Entity Structure 74

Exercise 2: Modifying an Entity Structure 77

Exercise 3: Create a List 84

Exercise 4: Modify a List 87

Administration Fundamentals │ Object Management with Entities and Lists 43

 Entities

The objective of this chapter is to introduce you to the Entity structure and List Manager which are used to
organize the devices and other objects in your organization. We'll begin with Entities.

An Entity represents a logical location, or container, used for organizing network records and host
records. Entities can be used for controlling access or permissions to those objects. In many respects,
Entities are much like Active Directory (AD) Organizational Units (OUs).

Entities can be viewed on the Entities tab of the Deployment Manager within the Client Console.

Entities contain two object types: Network records and Host records.

44 Chapter 3 | Object Management with Entities and Lists

Organizing Entities

Entities can be organized in different ways: geographical, departmental, and functional. How you define
your Entity structure depends on a few factors, which we'll explore below.

Geographical Entities
Organizing Entities geographically is a common method for grouping data which refers to physical
locations of assets in a company that has multiple locations. Companies that utilize this Entity structure
often have IT staff in multiple locations and delegate responsibilities directly to those locations. Reporting
on information is often performed both globally and regionally.

Departmental Entities
Often companies will choose to organize Entities into departments, such as Information Technology (IT),
Accounting, Engineering, Sales, and so on. Organizing into departments allows for granular risk and
threat assignment based on each job or departmental function. This type of organization is also common
when the company is centrally-located and does not need to organize data geographically. Departmental
Entities can also be designated as child Entities in geographic Entity structures, allowing for granular
organization by region and then into departments.

Functional Entities
Not as common as the above two methods, functional Entities allow for a permissions-based structure by
organizing types of devices together. In this structure all network routers might be grouped in an Entity
named Routers, all Windows workstations might be organized together, etc. This structure is specific and
requires effort to maintain; however, it does allow for a more specific set of permissions when configuring
Restricted Administrator accounts, if desired.

Chapter 3 | Object Management with Entities and Lists 45

 Root and Child Entities
Entities are organized using a parent/child relationship. Entities allow for top- level Root nodes that can
contain any number of Child nodes below it, which permits hybrid Entity structures. Root Entities are
listed below the Global Entity. With the proper credentials, you can add Root Entities to the structure and
then add Child Entities below. Network and Host records can then entered in each, as desired.

Entity Relationships to Networks and Hosts

Entities are important in LogRhythm because they establish a list of Known Hosts in your environment.
The Message Processing Engine (MPE), in the Data Processor, uses Network and Host records to
establish the Risk Based Priority (RBP) and associate logs and/or Events to Known Hosts.

If no entity or network record exists, the MPE will assume that any non-routable, for example 10.x.x.x or
192.168.x.x, IP address will be calculated as internal hosts where any routable IP will be treated as an
external host. For any internal IP addresses the entity assigned will be the same as the entity where the
collecting System Monitor Agent resides. For any external IP addreses the entity assigned will be the
Global Network.

Note: In the case where an entity does not exist, the MPE does not auto-create entities or
networks. It simply assigns the name of the entity where the System Monitor Agent lives into the
log's entity metadata field.

Example
If the sending System Monitor is assigned to the Boulder HQ Entity, the MPE will only analyze log
messages against Network and Host records that are assigned to Boulder HQ.

46 Chapter 3 | Object Management with Entities and Lists

Adding Entities from a CSV File

If you have several Entities to add, you can add them in bulk from a CSV file. The following table lists the
details that the CSV file should contain for each Entity.

Field Required? Description

Entity Yes The name to give to the Entity, up to 200 characters including
Name spaces.

Root Entity No To add this Entity as a Child Entity of an existing Entity, use this
field to assign the Root Entity. If you do not add a Root Entity, the
Entity will be added as a Root Entity.

Brief No A brief description of the Entity, up to 255 characters including

Description spaces.

Additional No A more detailed description or other information that you want to

Details include about the Entity, up to 2000 characters including spaces.

Each line in the CSV file should contain details for only one Entity. The details should be listed in the
following format:

Chapter 3 | Object Management with Entities and Lists 47

 Entity,Root Entity,Brief Description,Additional Details

Example
Entity1,,Description1,Details1
Entity2,Entity1,Description2,Details2
Entity3,Entity1,Description3,Details3

It is easy to create the file in a spreadsheet that allows you to save in CSV format, as pictured here:

Entity1 Description1 Details1

Entity2 Entity1 Description2 Details2

Entity3 Entity1 Description3 Details3

Important!
The CSV file should not contain a header row.
You cannot import more than 1,000 Entities at a time.
If the import file contains an Entity that already exists, or if the file contains any duplicate
entries, the existing Entity will be updated.

To add Entities from a file:

1. Create your CSV Entity file according to the guidelines above.
2. Log in to the Client Console as a Global Administrator, and then open the Deployment Manager.
3. From the File menu, click Add Entities from File.
4. Browse to and select the CSV file containing the Entities that you want to import, and then click
Open.

Note: Importing a large number of Entities, may take a while to complete.

5. While still in the Entities tab, click the Refresh icon in the main toolbar, or press F5.
You should now see the newly imported Entities in the Deployment Manager.

Note: To view the status of the import, click the Service Requests tab at the bottom of
the Deployment Manager.
If the import fails, you can review Console.log for more information. You can find
Console.log in the following location: %APPDATA%\LogRhythm\logs

48 Chapter 3 | Object Management with Entities and Lists

Entity Contents: Network and Host Records

In addition to the Permission model (see "Chapter 6, People" for a description of the Permissions model),
Entities serve to define how the assets being monitored are logically organized in your company. To facil-
itate this logical organization, Network and Host records are used to define the overall infrastructure
contained within an Entity.

Network Records
Network records define segments of your infrastructure that match how your IT department has defined
the IP topology (the method and layout of IP addresses) for your organization. This topology may be
defined by department, geography, or function.

Example
A Sales department may have IP addresses in a range from 192.168.1.0 to 192.168.255, and an
Engineering department may have two IP address ranges from 192.168.2.0 to 192.168.2.255 and
from 192.168.3.0 to 192.168.3.255. Other departments may have been assigned other ranges of
IP addresses.

There may be other topologies defined for your company that do not match this departmental schema. In
many networks, IT groups will use IP ranges that are not "Class C" ranges (0 to 255); they may be smaller
ranges of IP addresses.

Example
You may have a management network at your company that has the range of 10.2.1.15 to
10.2.1.107. This seemingly arbitrary range is an acceptable entry in an Entity Network.

Chapter 3 | Object Management with Entities and Lists 49

 Having defined Network records in LogRhythm allows it to provide a weighted importance to the log
information based on Hosts that reside or interact with these Networks. In other words, you can define
which Networks are more important relative to other Networks within your organization. This importance
plays a role in how Risk Based Priority (RBP) is calculated.

The importance defined in Network records (Risk and Threat) can be adjusted over time to refine the RBP
calculation generated by LogRhythm. In other words, you can fine-tune the data as you become more
familiar with the Log Sources.

Host Records
Host records define each known host within your organization. Host records allow for pinpoint accuracy in
the weighted importance of log information that comes from that host’s Log Sources.

Host records are created through one of two methods:

Automatically created when a new Log Source host is "accepted" into LogRhythm.
o The acceptance of a new Log Source host occurs when a new Log Source automatically
appears in the Log Source queue, or when you add Windows Log Sources using the
Windows Host Wizard.
Manually created by a LogRhythm administrator by choosing to add a Host record so they can
adjust the Threat and Risk values for that host.

Network and Host Record Relationships

"Known Hosts" are Host records defined in an Entity. Host records override the Network record's Threat
and Risk values, allowing you to modify the Threat and Risk ratings for specific hosts. Threat and Risk
settings in a Host record will override Network record Threat and Risk settings because they are more
specific to a single host.

A Network record can be configured to assign Threat and Risk to "Unknown Hosts", as well. Unknown
Hosts are not being polled, meaning that we are not collecting logs directly from them, and they are not
"Known Hosts" with corresponding Log Sources; they are hosts unknown to LogRhythm. These hosts are
often identified within log messages from other Log Sources, such as firewalls, routers, switches, or from
other host computers such as domain controllers, email servers, or web servers. These Unknown Hosts
may include devices such as tablets, smart phones, or laptops that are performing activities on your
network. Even though they are unknown to LogRhythm, these hosts can still (usually) have Threat and
Risk rating values assigned simply because they exist within one of your specified Network records.

The Threat and Risk values defined in Network records help to define the weighted importance of these
Unknown Hosts. The assigned Threat and Risk values for Networks are assigned automatically based on
the Network within which they reside and are used to determine the RBP values assigned to logs in which
information about these Unknown Hosts is included.

50 Chapter 3 | Object Management with Entities and Lists

Network Records

Network records identify and logically group a range of IP addresses to assign Risk Based Priority to logs
and determine Direction (such as inbound or outbound traffic) for the activity being observed. Network
records are used to represent a contiguous range of IP addresses that share a common Risk and Threat
profile.

Network records do not need to correspond to physical networks. Their function is to identify a contiguous
range of IP addresses that share a common risk threshold. For Direction identification, all undefined
network ranges are considered to be external in nature; although for more specific risk rating, Network
records may also be defined explicitly as external.

Managing Network Records

To manage Network records, open the Deployment Manager from the LogRhythm console, select the
Entities tab, then select the Entity where the Network record should be assigned. New Network records
can be created by right-clicking in the Entity Networks panel and selecting New Network.

Network records must contain a unique IP address range within a single Entity; there cannot be two
Networks with overlapping IP addresses within a single Root or Child level Entity.

Network records require that the zone be selected for the IP range being defined. You need to determine if
the Network is an internal network, if it is in the DMZ, or if it is a Known external Network.

Direction
Direction is defined by the zone configured in a Network record. There are three available choices for
zones:

Chapter 3 | Object Management with Entities and Lists 51

 Internal: this is a Network that exists wholly within the perimeter of an organization, with no Risk
or Threat automatically assigned
External: this is a Network that exists outside the company perimeter, with lower Risk and higher
Threat automatically assigned
DMZ: this is an internal Network that exists outside the organization's protected network perimeter,
with higher Risk and Threat automatically assigned

The automatic assignment of Risk and Threat values are performed by the Data Processor and cannot be
adjusted directly. However, the administrator-defined Risk and Threat values on a Network record do
impact the overall resulting RBP value.

Network records assist with identifying the Direction or flow of traffic; in other words, was information
headed into the company, headed out of the company, or did it stay within the company's network
perimeter?

For LogRhythm to infer, or identify, the Direction from a log message, all undefined or unknown network
ranges and IP addresses not explicitly defined within the Entity structure are assigned an External
Direction. Due to the fact that they are outside of your environment, unknown or undefined Networks are
automatically assigned a higher Threat and a lower Risk value. They are higher in Threat because they
exist outside the company (where threats live), and they are lower in Risk because they are not a
company asset (they exist outside the company).

You may choose to define a Known External IP range for those Networks that have Risk ratings lower
than other Unknown External Networks. These Known External Networks might include your business
partner's networks, B2B networks, or technology partner networks (such as PCI processing networks for
Visa or MasterCard) with which there is frequent traffic to and from your organization.

Since no Network records are defined by default, all IP ranges will be assumed by LogRhythm to be
External unless and until otherwise defined in the Entities. You should spend time defining Networks
within the Entity structure to assure that correct RBP values are assigned to log messages.

Assigning Risk and Threat

Both Risk and Threat values should be assigned to each Network record:

Network Risk Level—Risk ratings are assigned when the target, or Impacted Host, is identified in a log
message. Risk can be considered as the value of information or value of the assets contained on a host.

The Risk value set on the Network record will be applied to Unknown Hosts through inheritance
based on the defined IP addresses in the Network.
A value of 0 means no Risk is involved for this Network. A value of 9 means the most Risk (or
importance) is assigned to Network Hosts, Known or Unknown, that are impacted by the activity
described in the log.

Threat Level—Threat ratings are assigned when the Host (Orgin) that initiated the activity is identified in
a log. Threat can be considered as the potential damage that can come from this host as an attack, or how
much access this host has to other systems or assets within the company. Meaning, if hackers were to
compromise a system, how much damage could be done from this system. How many valuable assets
could the hacker gain access to, simply by being on this system?

52 Chapter 3 | Object Management with Entities and Lists

 The Threat value will be applied to Unknown Hosts through inheritance based on the defined
IP addresses in that Network record.
A value of 0 means that actions originating from this Network's hosts are not critical or important. A
value of 9 means that this Network's hosts should not be the source of outgoing actions or that the
Network's hosts represent the highest priority when they contain outgoing activity. In other words,
setting a Threat of 9 will increase RBP to the highest level when activity is originated from this
Network, thus increasing the likelihood of being noticed by analysts.

Chapter 3 | Object Management with Entities and Lists 53

 Add Network Records from a CSV File

If you have several Networks to add to an Entity, you can add them in bulk from a CSV file. The file
should contain the following details for each Network:

Field Required? Format Description

Network Yes String The name to give to the Network, up to 50

Name characters including spaces.

Brief No String A brief description of the Network, up to 255

Description characters including spaces.

Additional No String A more detailed description or other information

Details that you want to include about the Network, up
to 2000 characters including spaces.

54 Chapter 3 | Object Management with Entities and Lists

 Field Required? Format Description

Risk Level No Integer Assigns a corresponding risk level to the

Network, as follows:
0: None (no risk)
1: Low-Low (lowest risk)
2: Low-Medium
3: Low-High
4: Medium-Low
5: Medium-Medium
6: Medium-High
7: High-Low
8: High-Medium
9: High-High (highest risk)

Network No String The zone to which the Network should be

Zone assigned. If you enter a value for this field, it
must be one of the following: Internal,
External, DMZ
If this field contains any invalid values, the
Network will be imported with a zone value of
UNKNOWN HOST ZONE.

Network No country, The location of the Network by country, region,

Location country/region, and city. You can specify only a country, only a
country/region/city country and region, or all three values.
Each value must be a valid selection from
country, region, or city. For more information,
manually add an Entity Network and review the
valid options in the Location Selector.
If the location field is invalid or not formatted
correctly, the location will not be imported for
the Network.

Beginning Yes IP Address The first IP address in the IP range that defines
IP the Network.

Ending IP Yes IP Address The last IP address in the IP range that defines
the Network.

Each line in the file should contain details for only one Entity. The details should be listed in the following
format:

Network Name,Brief Description,Additional Details,Risk Level,Network Zone,Network

Location,Beginning IP,Ending IP

Chapter 3 | Object Management with Entities and Lists 55

 Example
Network1,Description1,Details1,RiskLevel1,Zone1,Location1,Beginning IP1,Ending IP1
Network2,,,,,,Beginning IP2,Ending IP2
Network3,Description3,Details3,,,Location3,Beginning IP3,Ending IP3

It is easy to create the file in a spreadsheet that allows you to save in CSV format, as pictured:

Network1 Description1 Details1 RiskLevel1 Zone1 Location1 BeginningIP1 EndingIP1

Network2 BeginningIP2 EndingIP2

Network3 Description3 Details3 Location3 BeginningIP3 EndingIP3

Important!
The CSV file should not contain a header row.
If any required fields contain invalid values, none of the Networks will be imported.
You cannot import more than 50,000 Networks at a time.
If the import file contains a Network that already exists, or if the file contains any duplicate
entries, the existing Network will be updated.

To add Networks from a file, do the following:

1. Create your CSV Network file according to the guidelines above.
2. Log in to the Client Console as a Global Administrator, and open the Deployment Manager.
3. Click the Entities tab.
4. Right-click the Entity to which you want to add Networks, and then click Add Networks from
File.
5. Browse to and select the CSV file containing the Networks you want to import, and then click
Open.

Note: Importing a large number of Networks may take a while to complete.

6. While still in the Entities tab, click the Refresh icon in the main toolbar or press F5.
You should now see the newly imported Networks in the Entity Networks panel for the selected
Entity.

Note: To view the status of the import, click the Service Requests tab at the bottom of the
Deployment Manager.
If the import fails, you can review Console.log for more information. You can find
Console.log in the following location: %APPDATA%\LogRhythm\logs

56 Chapter 3 | Object Management with Entities and Lists

Host Records

Host records identify and assign Risk and Threat values for Known Hosts, from which logs are collected,
or for Hosts of interest on a Network.

Chapter 3 | Object Management with Entities and Lists 57

 Log Sources and Host Records
Every Log Source has an associated Host record; you cannot configure a Log Source without a corres-
ponding Host record. Hosts may contribute more than one Log Source.

When logs arrive into the Data Processor, the information stored in the Host record (described in the topic
with the heading Adding Host Records) is applied to the log for the purposes of identification and
RBP calculations. Once a Host is identified, supplemental information recorded in a Host's record can be
inferred in additional metadata fields. The metadata inferred from a log message, based on the information
included in a Host record, might include a DNS name for the Known Host, IP addresses, and a WINS
name (Windows Internet Name Service), when applicable.

Pictured below is an example of the information found in a Host record that might not be explicitly stated
in a log message.

58 Chapter 3 | Object Management with Entities and Lists

Adding Host Records
Depending on your situation, you can manually add individual Host records to your deployment, or you
can batch import multiple Host records.

Add a Host Record Manually

Follow the instructions below to add a single Host record.

1. In the Client Console, open the Deployment Manager.

2. Select the Entities tab, and then select the Entity to which you want to assign the Host.

3. In the Entity Hosts pane at the lower-right of the window, click New, or right-click and select New
Host from the context menu. The Host window is displayed.
4. In the Host dialog box, open the Basic Information tab, and then enter details for the following:
Name (required): Enter the name assigned to the new host.

Important!
LogRhythm does not support hostnames that include spaces.

Host Zone (required): Select either Internal, DMZ, or External.

Chapter 3 | Object Management with Entities and Lists 59

 Operating System: Enter the operating system of the new host.
o Click next to the Operating System box. In the Operating System Selector window,
select the appropriate operating system in the list, and then click OK.
Operating System Version: Enter the version of the selected operating system that is
running on the new host.
Host Risk Level (required): This value represents the amount of risk incurred if the system
were to become compromised or the subject of some other issue. The Risk level is relevant
when the Host is the impacted system, target, or is acted upon by external forces.
o A value of 0 indicates that no risk is involved in the loss of this system.
o A value of 9 indicates the highest risk would be incurred if the host were
compromised.
Windows Event Log Credentials: If you want the System Monitor to use different creden-
tials for each Host when collecting Windows Event Logs, select the Use specified creden-
tials check box and provide the username and password to be used. If you do not select this
option, the System Monitor will use its own service credentials.

Important!
Multi-domain Event Log collection is only supported on Windows Vista, 7, 8, 2008,
or 2012; Windows XP, 2000, and 2003 are not supported.

5. On the Identifiers tab, enter Host Identifiers. Identifiers are used by the MPE to associate values
in a log message to the correct Host record. Enter all aliases a host may have, but do not enter
aliases that are subject to change. For example, a current IP that is assigned by DHCP could lead
to misidentified logs because the IP address changes. Available identifiers include:
Static IP addresses
Windows names
DNS names
6. On the Host Roles tab, enter key contacts for this host.
7. On the Threat Level tab, designate the amount of threat that is incurred if the host were to be the
origin of actions. First, select the Add to global Source Threat List check box if there is a Threat
level greater than 0.
A value of 1 (low-low) means that actions originating from this host are of little cause for
concern or are commonplace.
A value of 9 (high-high) means that this host should not be the source of outgoing actions and
that there is the greatest threat to security if such events are observed.
8. On the Additional Information tab, add any other pertinent information.
9. When finished, click OK.

60 Chapter 3 | Object Management with Entities and Lists

Adding Host Records via Batch Imports
Global Administrators can add a batch of Host records to an Entity using a copy and paste option or by
importing a file of host information. The feature allows you to review the hosts that were pasted from the
clipboard or hosts that were imported from a file prior to persisting them to LogRhythm. You have the
option to accept or reject the hosts in this manner using the Host Import Manager.

The feature is available via the Entities tab by selecting one of the following options from the context
menu:

Add Hosts from Clipboard

Add Hosts from File

Chapter 3 | Object Management with Entities and Lists 61

 Entities Reorganization Wizard

The Entities Reorganization Wizard provides a method to migrate Host and Network records to new
Entities. This wizard enables restructuring of the Entities to match changes in your network topology,
system placement, or logical arrangement of assets.

Note: The interface can seem misleading. At first glance, the tool looks as if it prompts you from
which Entity to pull items, when in reality the request is actually prompting you to choose the
destination for the move.

To run the Entities Reorganization Wizard:

1. Open Deployment Manager from the LogRhythm Client Console; select the Entities tab. From the
menu bar select Edit > Reorganization Wizard.
2. Select the Entity where you want to move existing Network and Host records; click Next.
3. Check all the desired items in the list; click Next. The Review Items window is displayed with the
status of the selected records.
4. Review the items in the list. To make changes, click Previous to return to the selection window.
Revise your selections and click Next to return to the Review Items window. Click OK. The
Review Items window is updated with the new status for the items in the grid.
5. Click Close to exit the Reorganization Wizard.

62 Chapter 3 | Object Management with Entities and Lists

Lists

Lists provide a method for organizing assets and information stored in LogRhythm. They are a logical
container that provide a convenient reference for functions such as Reports, Alarms, Investigations, AIE
Rules and Tails.

Lists allow you to group together common items by type so that analysts, and other LogRhythm objects
(such as Reports and Alarms) can quickly query or be assigned permissions to related data.

Various kinds of Lists are supported in LogRhythm, e.g., Log Source Lists that group together the various
log feeds such as Windows Event Logs or Syslogs. Other types of Lists include but are not limited to
Users, Groups, Hosts, or MPE Rules.

Lists are also used to accept data from outside sources, such as third party threat lists from Norse and
Symantec. Lists can be integrated for use in AI Engine Rules and Alarms, as well as custom black-lists.

Lists are accessible to all users and can be created by any user and then permissions can be configured
to specify if the List can be edited by the owner, a group of users, or everyone.

Chapter 3 | Object Management with Entities and Lists 63

 Using Lists

Lists are used by various features, such as data filters in the Dashboard, Investigator, or Tail tools. Lists
are used by the system Report Packages when they produce the compliance Reports. In fact, most
system-installed Lists are directly related to compliance packages.

For most non-administrative users, Lists provide an easy mechanism for selecting Log Sources when
creating a custom Investigation (Search) or when creating a filter for their Personal Dashboard. Analysts
can choose a List designed for their use, and be given the correct set of data automatically. As you
manage Lists by adding or removing items, analysts benefit because their investigations will always pull
current data each time they reference a List.

Note: We have discussed Log Source Lists, but all Lists operate in this manner. For example, if
a List has been configured for Privileged Users (users that have some degree of Administrative
Rights) and analysts perform a log search for data related to these users, they can simply
choose the Privileged Users List. As the Privileged Users staff changes over time, you can add
names and accounts to this List, and the analysts will always receive current data for users on
the List.

64 Chapter 3 | Object Management with Entities and Lists

List Permissions

The List feature is available to all users of LogRhythm. All users can create their own Lists; however,
Restricted Analysts that do not have access to all of the data within LogRhythm may not have the inform-
ation required to effectively create their own Log Source, User, or Host Lists. Typically, administrators
will create Lists.

The following is a table of the security permissions by List type:

Security Permission Description

Custom Created by users

System: Private This permission is provided by LogRhythm. The List items and
properties are controlled by LogRhythm and synchronized during a
Knowledge Base import. Except for controlling Read Access
(visibility), these Lists are locked for users.

System: Public This permission is provided by LogRhythm. The List items and some
properties can be edited.

Chapter 3 | Object Management with Entities and Lists 65

 Each List type may also contain the following Write Permissions:

Write Permissions

Read Permissions Private Public: Admins Public: Analysts Public: All

Private Owner

Public: All Admins Admins, Analysts Everyone

Public: Admins Admins

Public: Analysts Admins Admins, Analysts

Each List can be configured to have various Read Level permissions, which are detailed above. In each
case, Read is implied; however, as an option, you can configure a List with Restricted Read permis-
sions. The details for each are outlined in the table below:

Read Security Permission Description

Read Read permissions allow other users to see the members of the
List as well as use the List in search filters.

Restricted Read Restricted Read hides the members of a List while allowing the
List to be used in searches.

66 Chapter 3 | Object Management with Entities and Lists

Managing Lists

Lists are managed via the List Manager, located along the top of the Client Console. The List Manager
displays menu buttons, file menu options, and a standard context menu, which provide options to create
and manage Lists.

All users have access to the List Manager, which enables users to view, read, create, or retire Lists as
long as they have permissions to do so.

Lists are displayed in a searchable data table, allowing for quick filtering through use of the first-row data
filters. Viewing and management options are available when right-clicking on the table of Lists.

Working with Lists

The List menu buttons, from left to right, include Refresh, Create, and Properties:

The file menu options related to Lists include New, Clone, and Properties.

Chapter 3 | Object Management with Entities and Lists 67

 The context menu includes many of the standard selections. You can:

Create a new List

Clone an existing List
Check and uncheck Lists
Clear the filters of the List
Activate or Retire Lists via the Actions menu
Export the List grid to a file
View active and retired Lists
Edit the properties of a List

68 Chapter 3 | Object Management with Entities and Lists

Using Wildcards in Lists
Lists support the use of wildcard values. Host and User Lists are the most common Lists that utilize this
feature.

Lists utilize SQL-style wildcards, which commonly involve the percent (%) symbol to replace zero or more
characters.

Example
To find matches for super-user accounts that all contain admin_:

admin_robert
admin_patrick
admin_tom

Use the following wildcard pattern match:

admin_%

Example
Your company's naming convention for servers follows this pattern:

<geo><function><iteration>

<geo> is one of three geographic regions: EMEA, APAC, or AMER

<function> matches one of four items: FILE, MAIL, DC, WEB
<iteration> is a numerical sequence number: 1,2,3,4.

An example server would be: EMEAMAIL4.

If you want to create a match for all FILE servers, the wildcard pattern would be:

%FILE%

Chapter 3 | Object Management with Entities and Lists 69

 Retiring and Activating Lists

Lists cannot be removed permanently, but they can be hidden from view and removed from utilization in
filters, Alarm Rules, and reports by retiring the List.

To Retire a List:

1. Place a check mark in the Action field next to the List to be retired. Multiple Lists can be selected.
2. Right-click on the table of Lists and choose Actions > Retire.

To Activate a retired List:

1. Right-click on the table of lists and choose View > Retired Lists.

2. Locate the List and place a check mark in the Action field next to the List.
3. Right-click on the table of Lists and choose Actions > Activate.

70 Chapter 3 | Object Management with Entities and Lists

Expiring Items

LogRhythm Lists allow individual items to expire. An optional expiration setting removes List items after
the configurable amount of time has passed from when the List items were added.

List Expiring Values allows for reduced management and more accurate filtering for Lists containing
content that can become stale, such as Watch Lists of users or hosts. Expiring values also enables the
creation of new types of analytics where the content of a List changes.

Use Cases:
When an employee leaves a company, the newly disabled account should be monitored for any
activity for 90 days. After 90 days, monitoring on the account is no longer needed.
An AI Engine Rule is set up to recognize an abnormal amount of connections from an external IP
address. This activity by itself is not concerning, but is suspicious. The AI Engine Rule automat-
ically adds the IP to a List. This List is used by analysts to run daily investigations in order to
understand more about any activities related to the IP addresses. After a week, the IP address can
automatically drop off the List.
A computer is infected by malware and then cleaned, and it should be monitored after cleaning for
two weeks. A rule is created to pay special attention to devices for two weeks post-cleaning.

Chapter 3 | Object Management with Entities and Lists 71

 To add expiring items to a List:
1. Open the List Manager.
2. Double-click an existing List to open the List Properties window.
3. Select the Expiring Items check box, and then complete the following fields:
a. days. Enter the number days that must pass before these list items expire.
b. hours and minutes. Enter the number of hours and minutes that must pass before these list
items expire.
c. Log on Expiration. Select this check box to have log entries created when the List items
expire. Job Manager logs are stored in the jobmgr.log file and are logged in the Windows
Application Event log.

Note: Expired list items are logged only when the Platform Manager logging level is set to INFO
or higher. The default logging level is WARNING. For more information, please refer to Platform
Manager Basic Properties.

4. Click the List Items tab.

5. Add your desired List items.

6. Click OK to close the List Properties window.

72 Chapter 3 | Object Management with Entities and Lists

EXERCISES
Object Management with Entities
Exercise 1: Exploring the Entity Structure 74
Exercise 2: Modifying an Entity Structure 77
Exercise 3: Create a List 84
Exercise 4: Modify a List 87

Chapter 3 | Object Management with Entities and Lists 73

 Exercise 1:
Exploring the Entity Structure

The purpose of this exercise is to explore the existing Entity structure and record data about the current
configuration.

1. From the Deployment Manager, click the Entities tab.

2. How many Root Entities are listed in the structure? ___________

3. Expand some of the Root Entities by clicking on the expand icon ( ).
4. The Entities located below the Root Entities are known as Child Entities. How many Child Entities
are listed under the Root Entity named Boulder? _______
5. Click on the Boulder\IT Entity. Take note of the contents of this Entity:

6. How many Networks are listed under this Entity? _______

7. How many Hosts are listed under this Entity? _______

74 Chapter 3 | Object Management with Entities and Lists

 8. From this view, you can quickly see the relative importance of certain Networks and Hosts based
on their Risk or Threat rating.
a. What does a Risk Rating represent? (Circle the best answer.)
The importance of a Host or Network when a message originates from this location or
host
The importance of a Host or Network when a message impacts this host or location
b. What does a Threat Rating represent? (Circle the best answer.)
The importance of a Host or Network when a message originates from this location or
host
The importance of a Host or Network when a message impacts this host or location

9. Click inside the Action box to select the Host record identified by the IP address 192.168.99.101.
Double-click on it to edit it.

10. Change the entry in the Name field to: Corporate Email Gateway.
11. Then change the Host Zone to DMZ:

Note: LogRhythm supports three Zones: Internal, DMZ, and External. The Zones are
used to determine log directionality (External, Local, and Outbound). For more information
on Zones, please refer to the LogRhythm Help document, accessible from the Help menu
in the Client Console.

Chapter 3 | Object Management with Entities and Lists 75

 12. Click the button next to the Operating System field; select Linux and click OK.

Because this is a Linux system, you'll need to manually enter the specific OS version. Type
Debian 7 in the box under Operating System Version.

13. Click OK to close the Host record, and verify that the changes are reflected in the Entity Hosts
table:

76 Chapter 3 | Object Management with Entities and Lists

 Exercise 2:
Modifying an Entity Structure

The purpose of this exercise it to practice updating the Entity structure to better reflect the resources in
your environment. In this exercise you'll create a new Network and Host record.

Scenario: The current Entity structure is missing trusted External Hosts or Networks; thus all trusted
External Hosts and Networks are being treated as non-trusted External Hosts and Networks. This is
causing wrongly identified Events and false Alarms for hosts that do not pose a risk.

Task: Expand and reorganize the current Entity structure. You will need to move various Host and
Networks and adjust or assign Risk and Threat ratings for the trusted External Networks and Hosts.

Part One: Create a New Network record

Navigate to the Entities tab of the Deployment Manager:

1. Right-click in the Entities area and select New Root Entity.

2. In the Entity Name field, type Trusted External and type a description of Trusted External
Networks and Hosts. Click OK to save this new Entity.

Chapter 3 | Object Management with Entities and Lists 77

 3. Verify that the new Trusted External Root Entity now appears in the list of Entities:

4. Ensure that your new Trusted External Entity is selected, then right-click in the Entity Networks
panel and select New Network.

5. Now define the Network in the Network window.

a. Enter Trusted External Network 1 in the name field.
b. Enter the IP address range of 103.51.51.25 to 103.51.51.30 in the Network Address Space
fields.
c. Select External for the Network Zone.
d. Select Netherlands ⇒ Noord-Holland ⇒ Amsterdam as the location for this Network.

78 Chapter 3 | Object Management with Entities and Lists

 e. Add Trusted External Network, Trusted IP Range into the Brief Description field.
f. Select a Risk Level of 3 Low-High.

6. Select the Threat Level tab for this new Network:

a. Select Add to Global Source Threat List
b. Select 3 Low-High for the Network Threat
c. Enter This is our business partner's network in the Comments field
d. Click OK to save the new Network

Chapter 3 | Object Management with Entities and Lists 79

 Verify that the new Network record appears in the Entity Network panel:

Part Two: Create a new Host Record

1. In the Entity Hosts panel, right-click and select New Host.

2. In the Host window, use the following information to create this new Host record:
a. Name the Host Record Partner Webserver.
b. Select External for the Host Zone.
c. Configure the Host Location as Netherlands ⇒ Noord-Holland ⇒ Amsterdam.
d. Enter Partner B to B Webserver in the Brief Description field.

80 Chapter 3 | Object Management with Entities and Lists

 e. Select a Risk Level of 3 Low-High for this Host.

3. Click the Identifiers tab and enter the following configuration:

a. Enter 103.51.51.27 into the IP Address field
Click the Add button to have the address added to this Host record.

Important!
If you do not click Add, the address will not be saved with the Host record.

b. Enter web.partner.net into the DNS Name field and click Add.

Chapter 3 | Object Management with Entities and Lists 81

 c. Verify the IP address and DNS name appear in the Identifiers field.

Note: Notice it is assumed this host has a Windows name of web; however, that
name does not appear in the Identifiers field. Adding that name is optional and
should be very carefully considered for External Hosts.

4. Click the Threat Level tab and enter this configuration:

a. Select Add to Global Source Threat List.
b. Select 3 Low-High for the Host Threat.

5. Click OK to save this new Host record.

82 Chapter 3 | Object Management with Entities and Lists

 6. Verify that the Host record appears in Entity Hosts panel.

Exercise Follow-Up
This exercise was designed to specifically identify one Network and one Host from an external, trusted
source so that the Risk and Threat levels could be adjusted for logs that contain this information. The
Risk and Threat levels affect the risk based priority during the processing of logs which helps identify logs
Events within LogRhythm.

By configuring these Known Hosts and Networks with lower than usual External Risk and Threat ratings,
LogRhythm will be less likely to include logs (mostly security-related) from being identified as Events,
thus lowering the chance that false positive Alarms are triggered.

Note: These settings could affect whether a log becomes an Event, and potentially trigger an
Alarm. But, remember that all logs are sent to the AI Engine for correlation to identify threats, so
you would be notified if there was suspicious activity involving this host.

Alternatively, you could add this Network or Host record as an Exclude filter in Alarm Rules to
ignore these messages, if needed, to reduce false Alarms.

Chapter 3 | Object Management with Entities and Lists 83

 Exercise 3:
Create a List

The purpose of this exercise is to practice creating Lists.

Scenario: You are the LogRhythm administrator at a small consulting firm. You have been told by the
Director of Human Resources to monitor the activities of several employees who may have engaged in
suspicious activities:

Robert Doback
Dale Doback
Brennon Huff

Task: Follow the steps below to create a List and add these users to help monitor their activities. In
addition, you must modify the permissions of the List to prevent Robert Doback (a LogRhythm user) from
seeing it.

1. From the Client Console, click the List Manager button.

2. Right-click in the table of Lists and select New.
3. Select the User List type from the box, and click OK.

84 Chapter 3 | Object Management with Entities and Lists

 4. In the New User List Properties window enter the following Basic Configuration items.
a. In the List Name filed, enter Internal User Accounts.
b. In the Brief Description box, type Possible suspicious activity.
c. Verify the Permissions are set to Private for both Read Access and Write Access.

5. Click the List Items tab. This is where you enter the names of the users.
a. In the Add Item field, enter Dale Doback. Click the Add Item button to add the name
below.
b. Repeat this step to add Brennan Huff and Robert Doback.

Chapter 3 | Object Management with Entities and Lists 85

 c. Your List should contain three items.

6. Click Apply to save the changes to your new List.

7. Click OK to close the window.
8. You may not see your new List in the table. Click the Refresh button on the top-left side of the
screen and your List should appear (scroll down to the bottom of the table).

86 Chapter 3 | Object Management with Entities and Lists

 Exercise 4:
Modify a List

The purpose of this exercise is to practice editing a List.

Scenario: You just received information from the Human Reaources department that Robert Doback is
no longer under suspicion and you need to take him off the List.

1. Locate your newly created list in the List Manager, double-click it to open the List Properties
window.
2. Click the List Items tab, click on robert doback, and then click the Remove Selected button.
Verify the entry was removed.

3. Now that Robert is off the List, there is no need to keep this List Private. Navigate to the Basic
Configuration tab. Set Read Access and Write Access to Public Restricted Admin.

4. Click OK to save the list.

Chapter 3 | Object Management with Entities and Lists 87

 Questions:

1. How might you use a List to make your analysts' jobs easier?

2. Could you use a List to track all administrative activity on your network; and if so, how?

3. How might you use an IP List versus a known Host List?

88 Chapter 3 | Object Management with Entities and Lists

CHAPTER 4
System Monitors
System Monitor Overview 91
Supported Platforms for System Monitor Deployment 92

System Monitor Installation 94

System Monitor Permissions 95

System Monitor Acceptance 96

System Monitor Licensing 97

Data Processor Settings 99

Remote Collection Configuration: Syslog and Flow 100

Remote Collection Configuration: SNMP Trap Receiver 102
Endpoint Monitoring 103
User Activity Monitoring 104

File Integrity Monitor 105

Registry Integrity Monitoring 108

Data Loss Defender 109

Process and Network Connection Monitors 110

System Monitor Configuration Policy Manager 112

System Monitor Package Manager 113
System Monitor Updates 116

Initiate SmartResponses from a System Monitor 117

Exercises 119

Administration Fundamentals │ System Monitors 89

 Exercise 1: Create a New File Integrity Monitor Policy 120

Exercise 2: Create a New Data Loss Defender Policy 125

Exercise 3: Enable Endpoint Monitors 126

90 Administration Fundamentals │ System Monitors

System Monitor Overview

The objective of this chapter is to introduce you to the tasks required to manage the System Monitors in
your environment.

The System Monitor is a LogRhythm component that provides local and remote log data collection across
various operating systems, including Windows and UNIX platforms.

Log data can be collected either locally where a System Monitor is installed, or from remote Log Sources.
Locally, System Monitors can collect from Flat Files and other Log Sources, as well as System Monit-
oring Metrics, and utilize Endpoint Monitoring features built into the System Monitor itself. Remotely,
System Monitors may collect logs using several communication methods such as Windows Event Log
Remote Collection, Syslog, Flow Data (such as NetFlow, sFlow, IPFIXand J-Flow), CheckPoint
OPSEC, API based log sources and SNMP Trap collection.

System Monitors are licensed in one of two ways (Lite and Pro) and can be installed on Windows and
*NIX platforms, in both 32-bit and 64-bit configurations.

Chapter 4 | System Monitors 91

 Supported Platforms for System Monitor Deployment
The following table defines the certified and supported platforms for LogRhythm 7.4 System Monitor software.

LogRhythm 7.4 System Monitor Agents OS Support Levels

Operating System 32-bit/64-bit Support Level
Windows
Windows XP1 32-bit, 64-bit US
Windows 7 32-bit LS
Windows 7 64-bit CS
Windows 8 32-bit, 64-bit CS
Windows 8.1 32-bit, 64-bit CS
Windows 10 32-bit LS
Windows 10 64-bit CS
Windows Server 20031 32-bit, 64-bit US
Windows Server 2003 R21 32-bit, 64-bit US
Windows Server 2008 32-bit, 64-bit CS
Windows Server 2008 (Server Core Installation) 64-bit LS
Windows Server 2008 R2 64-bit CS
Windows Server 2008 R2 (Server Core Installation) 64-bit CS
Windows Server 2012 64-bit CS
Windows Server 2012 (Server Core Installation) 64-bit LS
Windows Server 2012 R2 64-bit CS
Windows Server 2016 64-bit CS
AIX
Aix 7.1 64-bit CS
Debian
Debian 6, 7 32-bit, 64-bit CS
Debian 8 64-bit CS
Oracle Hardened Linux
Oracle Hardened Linux 5.10, 6.4 32-bit, 64-bit CS
Oracle Hardened Linux 7 64-bit CS
Solaris
Solaris x86 10, 11 Intel-based 64-bit CS
Solaris SPARC sun4v 9, 10, 11 64-bit CS
Red Hat Enterprise Linux/CentOS
Red Hat Enterprise Linux 5, 6/CentOS 5, 6 32-bit, 64-bit CS
Red Hat Enterprise Linux 7/CentOS 7 64-bit CS
SUSE
SUSE Linux Enterprise Server 11, 12, 13 64-bit CS
Ubuntu
Ubuntu 12, 14, 16 64-bit CS

CS - Certified Supported
US - Unsupported
LS - Limited Support

92 Chapter 4 | System Monitors

For more information, please reference the Help guide or information on the Community.

Chapter 4 | System Monitors 93

 System Monitor Installation

Before installing a new System Monitor, review the information on LogRhythm's Community site, found
here:

https://community.logrhythm.com

When installing a LogRhythm System Monitor, you should ensure you have the correct platform installer
(32 or 64-bit versions). LogRhythm provides installation packages and installation guides for the various
platforms. Windows packages can even be deployed silently (pushed to machines remotely and installed
without interaction).

Installing the System Monitor requires that the settings for the initial Data Processor be configured. This
configuration is performed on the System Monitor Configuration Manager (in Windows) or via the scsm.ini
file on *nix systems located in the System Monitor's config directory, typically found in /opt/LogRhythm.
Keep in mind that the System Monitor will report to a single Data Processor; however, it can be configured
to have two backup Data Processors in case the primary goes offline or is otherwise unavailable.

The System Monitor requires that the local System Monitor IP address be set, as well. While this setting
can use an index value for its IP address, using the index value (0.0.0.0) is not recommended on all
systems. Use of the index value may return a local IP address of 127.0.0.1 (the loopback address) that
would prevent the System Monitor from communicating.

94 Chapter 4 | System Monitors

System Monitor Permissions

When installing a System Monitor into a Windows environment, consider the account under which that
System Monitor will operate. By default, the System Monitor will run using the Local System account,
which will give it sufficient permissions to gather local information; however, it will not have permissions
to poll remote hosts for Windows Event Logs.

To poll remote Windows logs, the LogRhythm System Monitor service will need to be modified to run
under a named service account with permissions to access remote Windows Event Logs and other admin-
istrative components on a remote machine.

Each account that will run a LogRhythm service must have the permissions documented in LogRhythms'
least privilege guide.

To configure a named account, use the Services Control panel found in Windows. Windows accounts
must be configured to collect logs remotely from the target systems. If you need more information about
using accounts with lesser or least privileges, please contact LogRhythm Support.

Chapter 4 | System Monitors 95

 System Monitor Acceptance

New System Monitors are not automatically available for use and will show in Pending status until
additional action is taken. Once a System Monitor has been configured and the service has been started,
the next step is to accept the System Monitor into the LogRhythm Platform. You must Accept and select
a license (pro or lite) for the System Monitor.

Optionally, if a host has been replaced, and the System Monitor along with it, you must Associate the
new System Monitor with an existing Host record. Associating a System Monitor will push the prior
System Monitor configuration to the new System Monitor, saving you time by not having to reconfigure all
the Log Sources associated to the System Monitor.

System Monitor acceptance is performed in the Client Console, on the System Monitors tab of the
Deployment Manager. All actions available on new System Monitors are listed in the following table.

Context Menu Description

Associate Associate the System Monitor to an existing active System Monitor

Agent Record.

Actions: Accept Accept the new System Monitor. The new System Monitor will be
displayed in the active grid.

Actions: Reject Reject the new System Monitor. The new System Monitor status will
change to Rejected but will still be displayed in the New System Monitor
grid.

Actions: Delete Delete a rejected System Monitor.

NOTE: If the System Monitor service is not stopped or if the System
Monitor is not uninstalled from the host where it resides, it will show up in
the New System Monitor grid again.

Properties View and/or edit the properties of the selected System Monitor.

96 Chapter 4 | System Monitors

System Monitor Licensing

Performed as part of the new System Monitor acceptance, you must assign an available license to the
System Monitor. By default, a System Monitor will be assigned a Pro license, although you can easily
change that selection.

When installed, the LogRhythm System Monitor contains components for both a Lite or Pro license. A Pro
licensed System Monitor can perform various advanced log integration or local host monitoring features
that a Lite licensed System Monitor can not. You can change the license for a System Monitor at any
time, thus unlocking or restricting the System Monitor features.

A complete list of features supported by license type for System Monitors are listed in the System
Monitor Functionality by License: Lite vs. Pro table which can be found in the Help guide.

Chapter 4 | System Monitors 97

 This is a small sample of the information contained in this table:

98 Chapter 4 | System Monitors

Data Processor Settings

Once a System Monitor has been accepted and assigned a license, you should check the Data Processor
(DP) settings for the new System Monitor. Data Processor settings allow a System Monitor to have
backup Data Processors configured. If the primary DP for a System Monitor were to go offline, the
System Monitor will automatically forward log information to the secondary or tertiary DP, whichever is
available. You can also validate the client host's IP address and the System Monitor communication port
for that System Monitor.

The Client Port (the TCP port from the Data Processor to the System Monitor) is by default set to 3333,
but that port can be set on a per System Monitor basis to allow bi-directional communication between the
System Monitor and DP. Keep in mind that the default communication port from the System Monitor to
the Data Processor is port 443.

Data Processor and Client Connection Settings for System Monitor are accessed by double-clicking on a
System Monitor located on the System Monitors tab of the Deployment Manager, and then selecting the
Data Processor Settings tab.

Note: The client host IP address may be listed as an index, starting with 0. When an index is
used or assigned by LogRhythm, the System Monitor is referencing the physical or logical
NIC of the host. Depending on the platform (Windows vs. *NIX) the 0 index may actually bind
the System Monitor to the host's loopback address (127.0.0.1), which will prevent the System
Monitor from communicating with a Data Processor. LogRhythm recommends an actual host
IP address be entered for a System Monitor in the Client Connection Settings field. There are
cases where using an index is valuable, specifically when a System Monitor is installed on a
DHCP-assigned host. In that case, it is better to assign the System Monitor to the IP address of
0.0.0.0., which will bind to every IP address on the host. If that option is unavailable, enter the
index value of the NIC that contains the DHCP IP address to which you wish the System
Monitor to bind.

Chapter 4 | System Monitors 99

 Remote Collection Configuration: Syslog
and Flow

In order for a System Monitor to collect logs from devices, servers, and applications via the Syslog
mechanism, the Enable Syslog Server setting must be selected.

Syslog messages are transmitted via the network, typically over UDP port 514, although both UDP and
TCP Syslog servers are supported. In some cases, the default Syslog port is not used within an envir-
onment. LogRhythm supports custom Syslog ports, and the Syslog Server can be set to listen on any
custom TCP or UDP port. Keep in mind that the System Monitor can listen on only one TCP and
UDP port pair at a time.

Example
If port TCP/UDP 551 is used instead of the default TCP/UDP 514, the System Monitor must be
bound to the new port 551, and it will no longer listen on port 514.

Syslog Relays
Every System Monitor supports collection of Syslog data direct from devices, servers, and applications,
or from a Syslog Relay, such as Syslog-NG or rSyslog device. The LogRhythm System Monitor requires
that the Syslog Relay's IP address be provided so that the individual Syslog messages can be identified
correctly for each Syslog source. When the System Monitor sees an IP listed here, it uses special
parsing, to determine the true source of the log.

LogRhythm processes each log message individually. If a Syslog message is provided by a Syslog
Relay, the Message Processing Engine (MPE) must understand where each log message originated so
that logs from a router or firewall are not processed, for example, along with Linux host messages,
because the log messages from each Log Source will be different.

100 Chapter 4 | System Monitors

System Monitors can be configured to listen for Syslog messages on multiple network interface cards
(NICs), allowing for versatility in deployments and to maximize its collection from Syslog feeds.

Note: Do not confuse the Syslog Relay Host with the LogRhythm Mediator Proxy, a
"LogRhythm Reference Architecture" that allows System Monitors to forward through a central
device much like Syslog Log Sources through an aggregator. For more information on the
LogRhythm Mediator Proxy, please contact LogRhythm Support.

Flow Data
NetFlow, sFlow, and J-Flow are network protocols that capture IP traffic information on a network,
typically used to monitor network traffic and perform statistical analysis of network usage. These
protocols are supported by many network devices, such as Juniper (J-Flow), Cisco (NetFlow), and
others.

System Monitors can collect NetFlow, sFlow, and J-Flow data. To collect this information, a Pro licensed
System Monitor's NetFlow/J-Flow or sFlow Server must be enabled in the System Monitor Agent
Properties window.

Most Flow data will be collected and stored in the Archives only, and will not be forwarded to the Platform
Manager as Events, by default.

LogRhythm's Network Monitor can collect and provide Flow data to the LogRhythm Platform, although
this data is not transmitted as Flow data. Network Monitor repackages this data as Syslog and transmits
that data across the normal Syslog channel.

Chapter 4 | System Monitors 101

 Remote Collection Configuration: SNMP
Trap Receiver

Another Pro license System Monitor feature is the ability to collect SNMP traps sent to the System
Monitor 's SNMP Trap Receiver.

LogRhythm supports both the older SNMP Version 1 and 2 traps, as well as the newer, encrypted
SNMP Version 3 traps.

You must know the required community string (for versions 1 and 2) or the SNMP Version 3 authen-
tication and encryption information to enable this feature.

102 Chapter 4 | System Monitors

Endpoint Monitoring

Every System Monitor has the ability to monitor several aspects of a host, including user activity, system
processes, and network connections.

Most of the features are available on the Lite System Monitor license, with one exception. Registry
Integrity Monitoring (RIM) is available only on Windows Pro licensed System Monitors.

In most cases, each feature needs only to be enabled to begin collecting information. For File Integrity
Monitoring (FIM), RIM, and Data Loss Defender (DLD) additional configuration is required (discussed in
the topics below).

Chapter 4 | System Monitors 103

 User Activity Monitoring

Located on the last tab under the Endpoint Monitoring settings in the System Monitor Agent Properties
window, User Activity Monitoring is employed by each of the endpoint monitor options. User Activity
Monitoring must be enabled before it can be used by the other endpoint monitors. If enabled, the System
Monitor will generate information when any user launches or kills a process, accesses/creates/deletes a
file, opens/closes network connections, and performs any logon/logoff activity.

User Activity Monitoring must be enabled on the User Activity Monitoring sub-tab under the Endpoint
Monitoring tab of a System Monitor for log on, process, and network connection activities.

Important!
User Activity Monitoring does come with a cost. It will add additional CPU and memory
overhead to the host when it is enabled.

104 Chapter 4 | System Monitors

File Integrity Monitor

File Integrity Monitoring (FIM) will monitor files and directories specified by one or more FIM Policies for
modifications to:

File reads
File contents
File permissions

FIM allows for monitoring in two modes:

Realtime monitoring (on Windows and some Linux systems)

Standard monitoring (on Windows and Linux)

Let's review how FIM works.

Standard FIM creates a hash signature of the file, or files in a directory, once per schedule and compares
the current file with the hash signature to detect changes. Standard FIM only captures the last change
made to a file. If it is scheduled to run once a day, it will only detect the most recent change to the file
even if the file was modified more than once within the past 24 hours. The hashing process is a CPU-
intensive operation, so it should not be scheduled too frequently (cycles of 5 minute or less) because if a
System Monitor has not finished its inventory of a directory between monitoring cycles, it will miss its
following cycle. Default cycles are often between 10 minutes and 24 hours. If a configuration for a file's
size is set to small, a hash signature will be created up to the maximum-defined size and FIM will issue a
warning that the entire file was not accounted for. This indicates that only the portion of the file, specified
by the maximum size, was hashed. Any remaining portion of the file will not be included in the hash, thus
having the potential for missed FIM Events if something were to change at the end of the file rather than
the beginning or middle of the file that was hashed.

Chapter 4 | System Monitors 105

 Realtime FIM utilizes the configuration of the Standard FIM, but it monitors files in real-time, which is
more RAM-intensive, for changes such as Add, Delete, Access Allowed, and Access Denied. The
Realtime FIM Events will show the full permissions for that file or folder after the changes were applied.
Permission changes will reflect the type of change such as Owner Changed, Group Changed, or Discre-
tionary ACL (access control list). If a change is made at the directory level, the permissions that
propagate down to the files and folders within that directory will also be recorded. Realtime FIM does
create a hash signature of each file monitored once per day; however, it does not rely upon this hash
signature for operation; the hash signature is created to satisfy a PCI requirement.

When FIM detects a change, the System Monitor will generate a log and send it to the Data Processor.
The generated FIM Events are treated like other logs within the LogRhythm Platform: they can be
forwarded for evaluation as an Event based on RBP, forwarded to AI Engine, used to generate Alarms,
and included in Reports.

Standard (scheduled) FIM is installed on every System Monitor; however, Realtime FIM requires an

additional driver, which is included with the Windows Agent Installer and some of the Linux Installers
(please refer to your specific Linux installer package to determine if Realtime FIM is available). The
Realtime FIM driver is not installed by default.

When possible, LogRhythm recommends that you use the Realtime FIM over the Standard FIM as it is
more accurate when monitoring files.

FIM features by Operating System (OS) type:

Type of Change Windows UNIX

File Contents ✓ ✓

File Permissions ✓

File Owner ✓ ✓

File Access ✓ ✓

Directory Contents ✓ ✓

Directory Permissions ✓

Directory Owner ✓ ✓

106 Chapter 4 | System Monitors

File Integrity Monitor Policies

FIM Polices can be created and edited using the File Integrity Monitor Policy Manager, found in the
Tools - Administration menu in the Client Console.

Default FIM policies are provided for common operating systems such as Windows 2008. The default
policies define common Windows and UNIX files and directories.

Each FIM policy contains configurations for the files and directories to monitor, the maximum file size,
and the schedule for monitoring. All of these configuration options are for Standard Mode FIM, although
Realtime Mode FIM uses only the file and directory definitions.

Chapter 4 | System Monitors 107

 Registry Integrity Monitoring

Windows registry keys contain important information necessary to the operation of the Windows OS.
These keys can be monitored to ensure they have not been modified.

Registry Integrity Monitoring (RIM) functions much like Realtime FIM. You must define a policy that
defines the Windows registry keys to monitor. The policy can be assigned to a Windows Pro licensed
System Monitor to monitor the local Windows Registry files.

RIM is always a Realtime monitoring function. You simply define which registry keys to monitor, and
RIM will monitor for any changes made to that key or any recursive keys.

Note: For more information on configuring RIM, reference LogRhythm's Help guide or
Community site.

108 Chapter 4 | System Monitors

Data Loss Defender

Data Loss Defender (DLD) monitors activity on a host's CD/DVD, USB, and Flash drives. It will monitor
for CD or DVDs inserted into a drive and for any memory devices (USBs, flash drives, hard disk drives,
cell phones, etc.) inserted into any of the USB ports on a host. If DLD detects one of these activities, it
can also eject the device or prevent the device from mounting and becoming available to the operating
system.

Data Loss Defender Policies

The DLD monitor requires a configuration policy prior to enabling. The DLD only contains the following
four options:

USB/Flash Drives
o Monitor
o Eject

CD/DVD Drive
o Monitor
o Eject

Note: The Eject option is available on Windows hosts only.

Chapter 4 | System Monitors 109

 Process and Network Connection Monitors

The final two options for endpoint monitoring are for the Process Monitor and Network Connection
Monitor. Both of these features allow for User Activity Monitoring (UAM), so the System Monitor will
collect log messages when a user launches a new process or opens a new network connection. These
logs are useful for many AI Engine Rules and compliance audit purposes.

Network Connection Monitor

Network connections can be independently monitored for network connections being opened and closed
on a Windows or UNIX host. The System Monitor will generate a log when a connection opens on the
host and another log when the System Monitor detects the connection has been closed. If enabled, the
Network Connection Monitor logs will contain UAM information about the users connected to the host at
the time the connection was opened or closed.

Logs include but are not limited to the following data:

Protocol
Local IP address and port
Remote IP address and port
Open time and close time
Duration

The Network Connection Monitor can be enabled to monitor:

Inbound TCP connections
Outbound TCP connections
Listening TCP/UDP sockets

110 Chapter 4 | System Monitors

 Example
This feature might be used to monitor secure connections made to systems via the PuTTY applic-
ation.

Process Monitor
Independently monitors when processes start and end on a Windows or UNIX host where the System
Monitor is running. The System Monitor will generate a log when a process starts on the host and another
log when the System Monitor detects the process has stopped. If enabled, the Process Monitor logs will
contain UAM information about the users connected to the host at the time the process was started or
stopped.

Log messages include but are not limited to:

Process name
Owner name
Start time
Duration

Chapter 4 | System Monitors 111

 System Monitor Configuration Policy
Manager

A System Monitor’s configuration policy determines where and how the logs that it collects are
processed. The polices that you assign to your System Monitors should be carefully considered to
optimize overall performance.

System Monitor configuration policies are configured and managed via the System Monitor Config-
uration Policy Manager, which you can access from the Tools menu of the Deployment Manager. Use it
to assign the same configuration policy to multiple System Monitors. When changes are made to a policy,
it updates all of the System Monitors that are assigned to it.

112 Chapter 4 | System Monitors

System Monitor Package Manager

The System Monitor Package Manager enables you to schedule automatic updates for multiple System
Monitors at one time. It is accessible from the Tools menu in the Client Console.

You can load an update package from Community to the LogRhythm Client Console and then schedule it
to be applied now or at a future date and time. When the System Monitors receive the package, they shut
down, update, and then restart automatically. You can use the System Monitor Package Manager to
upgrade or downgrade System Monitors.

Chapter 4 | System Monitors 113

 To download an Update Package
Before loading the package into the LogRhythm Client Console, you must first download the appropriate
package for your platform.

1. Navigate to the LogRhythm Community site (https://community.logrhythm.com).

Note: If you have not yet created an account on Community, you must do so before you
can access it.

2. From the top panel, click the Product documentation & downloads tab, and then make sure you
are on the SIEM tab on that page.
3. Click the appropriate Filter button to select the appropriate LogRhythm version, then click to select
the exact LogRhythm version for which you want to download the System Monitor update package.

4. Under System Monitor Agent Package Managers section, click the link for the System Monitor
package you want to download.

5. Save the download to a directory accessible by the Platform Manager.

114 Chapter 4 | System Monitors

Load the Package into the Client Console
The package must be loaded into the LogRhythm Client Console before it can be scheduled to update the
System Monitors.

1. Log in to the Client Console as a Global Administrator, and then click Deployment Manager.
2. In the Tools menu, click Administration, and then click System Monitor Package Manager.
The System Monitor Package Manager dialog box appears.
3. In the File menu, click New.
The System Monitor Package Properties dialog box appears.

Note: The Update Name and Description change when the package is loaded.

4. Click Browse, locate and select the upgrade package that you downloaded earlier, and then click
Open.
When the package is loaded, the Update Name and Description fields are populated in the System
Monitor Package Manager dialog box. You can change these items if you want.
5. Click OK to load the package into the LogRhythm Console.
The package should now be available in the System Monitor Package Manager.

Chapter 4 | System Monitors 115

 System Monitor Updates

The System Monitor software can be upgraded on-demand or according to a schedule specified in the
Schedule System Monitor Update window.

You can configure Windows and Linux System Monitors to receive automatic software updates via the
System Monitor Agent automatic update option, managed through System Monitor Agent configuration
policies. This eases your burden by removing dependencies on third party tools for updates. It also allows
you to take advantage of new features and improvements as soon as they become available.

You can adjust the number of System Monitors that get updated at one time in the Data Processor
Advanced Properties, to ensure the Mediator service on the Data Processor does not become
overloaded. The current default is ten System Monitors, as specified in the MaxAgentUpdates value
field. Global Administrators can view the update status, see the results, and rollback any updates, if
needed.

For additional details, please review the update guide found on the LogRhythm Community.

116 Chapter 4 | System Monitors

Initiate SmartResponses from a System
Monitor

SmartResponse actions can leverage custom or commercial programs and scripts, and they can be
executed when an associated Alarm Rule or AI Engine Rule is triggered. You can enable SmartRe-
sponses in LogRhythm by importing SmartResponse plugins. Plugins are self-contained binary files (*.lpi)
containing one or more actions. LogRhythm provides plugins that contain the most commonly requested
actions, such as disabling accounts or quarantining hosts. You can also develop your own SmartRe-
sponse plugins.

Manually executing SmartResponses remotely from a System Monitor allows you to more effectively
take action after observed suspicious activity. It saves time from having to manually perform the tasks,
and increases security protection by immediately taking actions to stop the threat.

Manual SmartResponse actions can be initiated by selecting one or more System Monitors from the
Deployment Manager’s System Monitor tab and then selecting the Initiate SmartResponse action. The
SmartResponse actions can be queued up or initiated immediately.

Chapter 4 | System Monitors 117

 This page intentionally left blank.

118 Administration Fundamentals

EXERCISES
System Monitors
Exercise 1: Create a New File Integrity Monitor Policy 120
Exercise 2: Create a New Data Loss Defender Policy 125
Exercise 3: Enable Endpoint Monitors 126

Chapter 4 | System Monitors 119

 Exercise 1:
Create a New File Integrity Monitor Policy

The purpose of this exercise is to practice creating FIM Policies.

In this exercise, you will be tasked with creating a new File Integrity Monitor (FIM) Policy to monitor
Microsoft Windows files for the host's, LRVM-XM's, file system. You'll also add monitoring for two
additional business-critical files.

Scenario: A server contains critical business assets. A System Monitor, with licensing for FIM, was
installed on this server. The critical files will need to be included in the configuration of a File Integrity
Monitor Policy so that the System Monitor can monitor these files for access or modifications.

Task: Follow the steps below to create a new FIM Policy that defines the files to monitor. The files reside
in the following locations on the LRVM-XM host (your Training VM):

File Name File Location

budget.xls c:\personal\robert\

pci_server_list.xlsx c:\corporate\assets\

120 Chapter 4 | System Monitors

 1. Navigate to the Deployment Manager in the Client Console.
2. Navigate to Tools > Administration > File Integrity Monitor Policy Manager:

Chapter 4 | System Monitors 121

 3. Locate and highlight the item Template: OS : Windows 64bit RT FIM, and then right-click and
select Clone.

4. The File Integrity Monitor Policy Properties window contains the configuration from the template.
This policy contains the Monitoring Configurations and Monitored Items that are critical for
Windows servers. From here, you can modify the policy to include the two files listed above.

Note: The Monitoring Configurations are set to monitor items Daily or Hourly. If an entry
contains a Max Depth value greater than 0, it will monitor a directory and the specified
number of sub-directories.

Most of the Monitored Items in this template are directories, not individual files.

122 Chapter 4 | System Monitors

 5. To configure this policy, you need to know the file size. Open Windows Explorer, locate both
files, and note their size:
c:\personal\robert\budget.xls: ___________
c:\corporate\assets\pci_server_list.xlsx: ___________

6. In the File Integrity Monitor Policy Properties window, right-click in the Monitoring Config-
urations panel and select New.
7. You will create a policy to monitor a file 512 KB in size (at least 5x the size of your largest file),
every 10 minutes for access, modifications, or changes in permissions. To do so:
a. Enter 10 Minute (512Kb) Depth 0 for the name
b. Ensure that the Interval is set to 10 minutes
c. Modify the Max Hashed File Bytes to 512KB
d. Enable all the Monitoring Flags

Click OK to save this configuration.

8. Right-click in the table of Monitored Items (at the bottom of the Properties window) and select New.

Chapter 4 | System Monitors 123

 9. Enter the location of the first file in the Path field, and ensure that 10 Minute (512Kb) Depth 0 is in
the Configuration field. Click OK.

10. Right-click in the table of Monitored Items and select New again.
Enter the location of the second file in the Path field, and ensure 10 Minute (512Kb) Depth 0 is in
the Configuration field. Click OK.
11. Verify that both files exist in the Monitored Items table.

12. Rename the File Integrity Policy LRVM-XM Windows Server 2016. Then click OK.
Verify that the new Policy is listed in the File Integrity Monitor Policy Manager window. Then
you can close the FIM Policy Manager window.

124 Chapter 4 | System Monitors

 Exercise 2:
Create a New Data Loss Defender Policy

The purpose of this exercise is to practice creating new Data Loss Defender (DLD) Policies.

Follow the steps below to create a new DLD Policy to monitor for the use of external drives or storage
devices on a host.

1. From the Deployment Manager, navigate to Tools > Administration > Data Loss Defender
Policy Manager.
2. From the File menu, select New.
3. Enter Default in the Policy Name field and enable all available options.

Note: If either type of device is used, the DLD Policy will eject the device (or issue a
forced unmount command) on the host.

4. Click OK to save the new DLD policy; verify that Default now appears in the Data Loss Defender
Policy Manager.

5. Close the Data Loss Defender Policy Manager window.

Chapter 4 | System Monitors 125

 Exercise 3:
Enable Endpoint Monitors

The purpose of this exercise is to practice creating and enabling Endpoint Monitoring features on a
SysMon, utilizing newly created FIM and DLD Policies.

Scenario: A server, LRVM-XM, has been identified containing critical business assets. A
LogRhythm System Monitor was installed on this server with license that allows for File Integrity Monit-
oring (FIM). The critical files have been included in FIM Policy and a DLD Policy was created to monitor
for the connection of external devices. User activity on this host should be monitored, when possible.

Task: Follow the steps below to enable the various Endpoint Monitors on LRVM-XM's System Monitor.

1. Navigate to the Deployment Manager.

2. Select the System Monitors tab, and then double-click on the LRVM-XM System Monitor.
3. Click the Endpoint Monitoring tab of the System Monitor Agent Properties window. Each
Endpoint Monitor function can be configured in tabs on the lower portion of the panel.

4. Check the box to Enable File Integrity Monitor. Verify the Mode is set to Standard.

126 Chapter 4 | System Monitors

 5. In the Policy box, select your newly created FIM Policy: LRVM-XM Windows Server 2008 R2.

6. Notice that the option to Include User Activity Monitor Data is not available for selection.
7. Navigate to the User Activity Monitor tab (at the bottom of the panel) and enable all the options.

8. Navigate back to the File Integrity Monitor tab. Now enable the Include User Activity Monit-
oring Data option.
9. Click on the Data Loss Defender tab and enable the Data Loss Defender using your new Default
Policy.

10. Click on the Process Monitor tab and ensure both options are enabled.

11. Click the Network Connection Monitor and enable all available options.

Chapter 4 | System Monitors 127

 12. Click Apply to update the configuration settings of the System Monitor, and then click OK to close
the Properties window.

Summary: In this exercise, all available Endpoint Monitors were enabled to meet the objectives specified
in the scenario. To monitor the User Activity on this server, all options for Process Monitoring and
Network Monitoring were enabled. These options allow LogRhythm, and more specifically the AI Engine,
to analyze normal and abnormal user behaviors.

128 Chapter 4 | System Monitors

CHAPTER 5
LogRhythm Log Sources
Log Sources Overview 130
Log Sources and Host Records 131
Adding Host Records 132

Adding Log Sources 133

Adding Log Sources from a File 134

Adding Log Sources from the System Monitor 137

Log Source Basic Configuration Tab 139

Log Source Additional Settings Tab 141
Flat File Settings Tab 143
UDLA Settings Tab 145
Syslog, Flow, and SNMP Log Sources 146
Automatic Log Source Acceptance 148
Windows Host Wizard 150
Exercises 151
Exercise 1: Adding Log Sources via a System Monitor 152

Exercise 2: Adding Log Sources Via the Windows Host Wizard 159

Exercise 3: Adding a Flat File Log Source 170

Administration Fundamentals │ LogRhythm Log Sources 129

 Log Sources Overview

Log Sources represent the individual log files, log feeds (such as Syslog, NetFlow, or SNMP), and data
feeds collected by LogRhythm. Log Sources are associated to Host records in the Entity structure.

In this chapter, we will introduce the Windows Host Wizard as a mechanism for quickly adding Host
records and Log Sources into LogRhythm. We'll also explore the non-Windows Log Sources, such as flat
file log collection, Syslog acceptance, and additional Log Sources. Log Processing Policies will be intro-
duced as a way to modify how logs are processed within the system at the Log Source layer.

130 Chapter 5 | LogRhythm Log Sources

Log Sources and Host Records

Every Log Source is associated to a Host record in the Entities tab. Host records must exist before you
can configure a new Log Source; however many Log Source Types will create the Host record automat-
ically.

The Host record association allows you to adjust the importance of logs via LogRhythm's Risk Based
Priority (RBP) Event forwarding. You can use the Host record's Threat and Risk ratings to adjust the
importance of a log. Each Log Source attached to a Host record will be adjusted by these ratings to be
more, or less, important than normal, depending on the settings for the host.

The Host record association also helps derive important metadata from a log such as Known Host,
Impacted Host, or Origin Entity based on the information found in the Entities tab.

Note: In order to add a new Log Source, a Host record must be present.

Chapter 5 | LogRhythm Log Sources 131

 Adding Host Records

When the System Monitor is installed on a host and accepted into LogRhythm, if no Host record is
already present, a Host record will be created automatically.

There are several other methods for adding new Host records to the LogRhythm platform:

For Windows hosts, you can use the Windows Host Wizard to add new host records.
You can add hosts directly in the Entity structure, allowing you to define the Host name and
Host Identifiers. This method is normally used for adding UNIX-based hosts or where System
Monitor will not be installed.
For network equipment such as firewalls, routers, and switches, Host records will be added
automatically when the device's Syslog feed is added into the System Monitor configuration.
Syslog Log Sources are covered later in this chapter.

132 Chapter 5 | LogRhythm Log Sources

Adding Log Sources

Aside from Windows, Syslog, Flow, and SNMP, all Log Sources must be added to a System Monitor
directly.

Note: In deployments where there is a large number of new Log Sources, you can configure
various levels of automatic Log Source acceptance.

Chapter 5 | LogRhythm Log Sources 133

 Adding Log Sources from a File

You can quickly and easily add Log Sources in bulk from a list in a CSV (comma-separated values) file.
This is a good way to preregister all of your Log Sources and then accept a few at a time, as time allows or
as your organization is prepared.

The CSV file must contain at least the IP address, and the import tool in LogRhythm will walk you through
the rest. A CSV file can also contain the following information (in the order specified):

Log Host IP address (required)

Log Entity
Log Source Type
Collection Host (the System Monitor Agent name, not the name containing the Entity and Host as
shown in the Collection Host column in Log Sources)
MPE Policy
File Path

You can include up to 50,000 Log Sources in one CSV file. Save the file somewhere accessible to the
Client Console.

To begin the import process, open the Log Sources tab and right-click in the space at the bottom of your
existing Log Sources and select Add Log Sources From File. Choose the file location and a preview
window will display what was imported. The Status column will show you whether your imported Log
Sources are ready to be registered (Valid) or if they are missing data (Invalid).

134 Chapter 5 | LogRhythm Log Sources

The entries will show Invalid if information is in the wrong field or it does not match what LogRhythm is
expecting; for example the Log Source Type you entered doesn't exactly match. If you have Invalid
entries, double-click on the entry to select any missing settings.

The Import screen will give you the option to Accept Valid Log Sources.

Chapter 5 | LogRhythm Log Sources 135

 The Valid Log Sources will be removed from the list and added to the Log Sources tab to await the first
collected log. Once a log has come in from that source, it will automatically start collecting with no further
intervention.

Note: This import does not assign a Date Parsing Format nor does it allow multiple flat files on
the same host.

136 Chapter 5 | LogRhythm Log Sources

Adding Log Sources from the System Monitor

Another way to add new Log Sources is from the System Monitor Agent Properties window for the
System Monitor that will be collecting the logs. Log Sources that require you to enter customized inform-
ation must be added from within the System Monitor tab in the Client Console. Types of logs that require
custom configuration for the System Monitor include flat files, UDLA, or any other Log Source that
requires the use of an API (application programming interface) for collection of logs.

To add a new Log Source, double-click an active System Monitor listed in the System Monitors tab of the
Deployment Manager to open the System Monitor Agent Properties window. Located at the bottom of
this properties window is a table of Log Sources from which this System Monitor will be collecting log
messages. Right-click within this table and select New to begin the process of adding a new Log Source
for collection by the System Monitor.

Chapter 5 | LogRhythm Log Sources 137

 The next set of topics will walk through the configuration options, seen here in the Log Message Source
Properties window, for different types of Log Sources.

Note: In deployments where there is a large number of new Log Sources, you can configure
various levels of automatic Log Source acceptance.

Log Sources that are excluded from this type of addition include Windows Event Logs, Syslog, Flow, and
SNMP type logs.

138 Chapter 5 | LogRhythm Log Sources

Log Source Basic Configuration Tab

The first set of configurations for any new Log Source is contained in the Basic Configuration tab of the
Log Message Source Properties window. This tab defines the Log Source Host (the server or device that
contains the Log Source), Collection Agent, and Log Message Source Type. You may also edit the auto-
generated Log Source Name and add a Brief Description to help other administrators understand the
purpose of this Log Source.

Log Source Host

Because a Host record must first exist in the Entity structure, you'll click the Host Selector button to
choose which host will provide the logs.

Note: Since this process began by choosing New on an System Monitor's table of Log Sources,
you do not need to specify the Collection Agent for these logs. The System Monitor name will
appear in the box automatically.

Log Source Type

Next, you will choose which Log Source Type you are configuring. Once the Log Source button has been
pressed, you are presented with the Log Source Type Selector window that organizes all Log Sources by
type: System and Custom types.

If the Log Source Type is known, part or all of the Log Source name can be entered into the Text Filter
then click the Apply button; the resulting list of Log Sources will be displayed and the best match should
be selected.

Chapter 5 | LogRhythm Log Sources 139

 Log Processing Policy
Lastly, you must choose which Log Message Processing Engine (MPE) Policy should be associated with
this Log Source. MPE Policies define how logs are stored within the platform and if it should be flagged as
an Event.

In most cases, LogRhythm Default will be selected. The LogRhythm Default policy should contain all
the system-defined Log Parsing Rules and Policies for this type of Log Source.

In rare cases, alternate policies are available for LogRhythm BETA policies or custom Log Processing
Policies. BETA policies are usually for BETA Log Source types or for alternate rule bases for new device
firmware. Custom Log Processing Policies provide flexibility in configuring log processing.

Example
You may want to change how logs are identified as Events. You may want certain kinds of logs to
be classified differently than the default and therefore change the Classification and Common
Events for a given log type, or choose to truncate the raw log message from a log so that it is not
saved in one of the LogRhythm databases.

140 Chapter 5 | LogRhythm Log Sources

Log Source Additional Settings Tab

The next step in adding a new Log Source is to validate the settings located on the Additional Settings
tab. These include Virtualization Settings, Log Data Management and Processing Settings, and Silent
Log Message Source Settings.

Virtualization Settings
Log virtualization is used for Log Sources that utilize Syslog to transmit logs to LogRhythm. It allows for
two scenarios:

When logs are collected for a cluster of servers or network devices that are treated as one device.
When collecting logs through multiple System Monitors for a single Log Source (where several
System Monitors are behind a Load Balancer) each System Monitor must associate the logs with a
virtual source, which is actually one physical host. Each virtual Log Source host will be listed in this
section of the configuration.

Log Data Management and Processing Settings

The Log Data Management and Processing Settings section allows you to override the MPE Policy
which specifies how logs will be managed for this particular Log Source.

The options available are:

Don't Archive—Do not write a copy of the log to archives

Drop Whole Log—Log messages will not be indexed (stored in the online databases)
Drop Raw Log—Only log metadata will be indexed

If you're certain that you will never need to reference particular logs, you also have the option to Filter
Raw Logs in the Log Source Virtualization settings to prevent the System Monitor from ever sending
specific logs to the LogRhythm Data Processor.

Chapter 5 | LogRhythm Log Sources 141

 Silent Log Message Source Settings
If you have a critical system or device in your environment, you want to make sure it is operational and
sending logs consistently. You can enable the Silent Log Message Source Detection option so you are
notified if LogRhythm does not receive logs from your specific Log Source. This setting requires that the
LogRhythm Silent Log Source Error Alarm Rule is also enabled so that Alarms are triggered to notify
of the issue.

Silent Log Source Detection is an invaluable tool to help detect when a Log Source stops collecting either
due to a System Monitor or host failure, remote Log Source host failure, or some other situation where
logs are no longer arriving into the platform. This lets you know when something unexpected occurs.

If enabled, you can set a threshold of time after which to Issue Warnings and Issue Error messages.

Important!
The last option in this tab allows you to check a box to "Start collection from the beginning of the
log." Unless directed by the LogRhythm Support team, this option should not be enabled.

142 Chapter 5 | LogRhythm Log Sources

Flat File Settings Tab

A flat file is a plain text file. For flat file type Log Sources, the Flat File Settings tab allows you to define
the location of the file or File Path, the Date Parsing Format, Multiline Log Message Settings, and
Directory Collection options.

File Path
The file path to the flat file log must be defined so the System Monitor knows where to collect the file's
contents. Flat file collection is normally performed by a System Monitor installed on the host that contains
the log file; however, each System Monitor supports remote flat file collection. A UNC (Universal Naming
Convention) path should be provided, which looks like this: \\ComputerName\SharedFolder\Resource.

Most flat file logs are written to a single file whose name does not change. When the log file has grown to
a certain size or age, it is moved by the system to a backup file, leaving a blank log file that contains the
same log file name as the previous. The host will continue to write messages to the blank log file. When
providing a path, you should include the base file name as the location. Exceptions to this rule are when
collecting logs from a directory of flat files.

Note: Remote flat file collection is not recommended for regular use due to problems that could
arise from network delay and for especially busy remote Log Sources.

Flat File Date Parsing

Dates from flat files are parsed separately from the MPE Rules, which are responsible for parsing the
metadata found in a log message. In order to correctly parse the date information from a flat file log
message, the format for the log messages must be defined. Other Log Source Types contain standard
date and time formats; however, in the case of flat file logs, each may contain a different format for its
date and time. Press the date selection button to view the system defined date formats. If a system
format does not match the format for your specific flat file, a custom date format can be defined.

Chapter 5 | LogRhythm Log Sources 143

 Multiline Log Settings
In some cases, flat file logs contain multiline log formats. Multiline logs are rare, although in most cases
they contain clear delimiters between log messages. For multiline logs, you must define a regular
expression (regex) to locate the start of a log message, the log delimiter, and the end of log message.

Directory Collection Options

Certain Log Sources, such as Microsoft's Internet Information Server (IIS), write logs to a directory where
each log file contains a unique name. For directory-based logs, the path to the directory must be provided,
and the Is Directory option should be checked.

In some cases, log directories may contain multiple file types; if so, the log file extension should be added
to the Inclusions field to ensure that only those log files are collected by the System Monitor .

Note: The LogRhythm System Monitor does not manage flat file log directories. Ensure that the
directories are periodically cleaned (old log files are removed from the directory) to keep the total
number of log files monitored to a minimum and to maximize System Monitor performance.
Many directory-based Log Sources have features to manage this function automatically.
Contact the device vendor for more information on your specific Log Source's log management
feature.

File Compression Settings

System Monitors support the ability to read compressed log files. If the flat file log is compressed,
indicate the type of compression by choosing one of the following:

None
gZip
tar
targzip
zip

144 Chapter 5 | LogRhythm Log Sources

UDLA Settings Tab

The LogRhythm Pro licensed System Monitor allows you to collect pseudo logs from a database with
configuration options found in the UDLA Settings tab.

Uses for UDLA

UDLA (Universal Database Log Adapter) Log Sources include, but are not limited to:

McAfee ePO Device Deployment

McAfee Network Access Control (NAC)
Microsoft SharePoint Audit Logs
Oracle Audit Logs
Sharepoint
WebSense
And many more

Connection Strings, Query Statements, and Output Format

UDLA Log Sources must be configured with an ODBC or OLE DB connection string, SQL Query
Statement, and Output Format. The LogRhythm Help guide contains connection, query, and output
format strings for supported UDLA Log Sources to help you with the configuration of the UDLA Settings.

Chapter 5 | LogRhythm Log Sources 145

 Syslog, Flow, and SNMP Log Sources

To add new Syslog, Flow, or SNMP Log Sources in the LogRhythm Platform, you simply check the box in
the System Monitor settings to enable the appropriate server. The System Monitor will automatically
begin to listen for new Syslog, Flow, or SNMP data feeds from Log Sources that have been configured to
send data to the System Monitor. Once the feeds from the Log Sources are recognized by the System
Monitor, the new Syslog, Flow, and SNMP Log Sources will appear in the New Log Sources queue, in
the Log Sources tab, with a status of Pending. New Log Sources can be edited, accepted, or rejected
directly from the Log Sources tab.

You must Accept the New Log Source before the System Monitor will begin collecting logs from it. The
Log Source must have a Log Source Type associated to it before it can be Accepted. You may need to
determine the Log Source Type, and Resolve Log Source Hosts before proceeding to Accept the Log
Source.

146 Chapter 5 | LogRhythm Log Sources

The acceptance queue allows for individual configuration or mass configuration of Log Sources of the
same type.

The Syslog Relay Host Entry Helps Identify the Original Log Source
A Syslog Relay Host, or Syslog aggregator, is a device that will accept Syslog messages from many
different Log Sources and forward all of those messages to the System Monitor Syslog receiver. This kind
of device is quite common in network areas that require limited firewall forwarding rules, such as DMZs or
other secure networks, where forwarding from a single device is preferable over having many devices
forwarding out of the secure network to a single receiver on the far side of the network.

The Syslog Relay Host configuration will strip the IP address from the Syslog message, which will reveal
the actual device that sent the log message to the Relay Host, thus allowing each individual Log Source,
even Log Sources of different types, to be identified by LogRhythm as the host of origin.

Chapter 5 | LogRhythm Log Sources 147

 Automatic Log Source Acceptance

You can also configure automatic acceptance of new Log Sources. You can configure Automatic Log
Source Acceptance for new Log Sources using an IP address range or a regex filter to determine the Log
Source Type. Your administration time is considerably reduced when on-boarding a large number of varied
Log Source Types by enabling LogRhythm to automatically determine the Log Source Type and accept
the Log Source that is collected via Syslog, Flow, and SNMP Trap Receiver.

Setting up Automatic Log Source Acceptance is performed through the Automatic Log Source
Acceptance Rule Manager, accessible from the Tools - Administration menu.

To create a new Automatic Log Source Acceptance Rule, click New and select the appropriate type from
the drop-down:

IP Range Rule: Choose this option to setup each Log Source Type with a specific range of IP
addresses, log interface type, log message source type, MPE policy, and which Entity the object
falls under. Once this is setup, identify whether to automatically resolve the host and identify the
Log Source Type or to automatically accept the Log Source.
Log Message Pattern Match Rule: Choose this option if there are Log Sources of various types
coming in. The Pattern Match Rule identifies Log Sources by a regular expression pattern match
rather than by IP address.

The configuration options allow you to search for Log Message Source Types in the drop-down list and to
select multiple Entities in which the collecting System Monitor could reside. You also have options to
resolve the host, apply the Log Source Type to the pending Log Source, and to accept the Log Source
without requiring Administrator interaction.

148 Chapter 5 | LogRhythm Log Sources

You can easily determine if a Log Source was automatically accepted into LogRhythm from within the Log
Sources tab in the Deployment Manager, as well as in the Log Source list when viewing the System
Monitor properties. The Acceptance Mode column will display Automatic or Manual.

Note: The Acceptance Mode column is located at the far-right of the grid but can be moved to
where you want it.

Chapter 5 | LogRhythm Log Sources 149

 Windows Host Wizard

Windows hosts and Windows Event Log type Log Sources can be added using the Windows Host
Wizard. The Windows Host Wizard can be run in a manual mode, allowing you to quickly add Host
records and Log Sources using a few pieces of host identity information.

The Windows Host Wizard is the recommended method for configuring LogRhythm to collect Windows
Event Logs. These logs are collected by a Windows System Monitor.

A System Monitor collects Windows Event Logs from the host that it is installed on and, depending on the
configuration, can collect Windows Event Logs from designated remote hosts. One System Monitor can
remotely collect from several Windows hosts.

The Windows Host Wizard is also Active Directory (AD) enabled, which means that you have the option
to scan domains for computers (Active Directory Discovery), then import computers (all or some) that are
found.

In order for the AD discovery to function, the LogRhythm appliance must be a member of a domain, and
credentials must be provided with access to browse AD.

150 Chapter 5 | LogRhythm Log Sources

EXERCISES
LogRhythm Log Sources
Exercise 1: Adding Log Sources via a System Monitor 152
Exercise 2: Adding Log Sources Via the Windows Host Wizard 159
Exercise 3: Adding a Flat File Log Source 170

Chapter 5 | LogRhythm Log Sources 151

 Exercise 1:
Adding Log Sources via a System Monitor

Part 1: Add a Windows Host Record

The purpose of this exercise is to practice adding Log Sources manually. In this exercise, you will add
Windows Log Sources from the System Monitor. This process is more manual than adding Log Sources
via the Windows Host Wizard; however, if you have the profile permissions of a Restricted Administrator
this is your only option.

Task: Follow the steps below to add a Windows host into the LogRhythm Platform under the San Jose
Entity. This host will contain three Log Sources. The three new Log Sources will be added into the
platform and assigned to a System Monitor for collection.

1. Navigate to the Deployment Manager by clicking the Deployment Manager button on the main
toolbar.
2. Navigate to the Entities tab.
A new Host record will need to be created in order to add the Log Sources on that host.
3. Locate and select San Jose from the list in the Entities panel.
4. Right-click inside the Entity Hosts panel for San Jose and select New Host.

152 Chapter 5 | LogRhythm Log Sources

 5. Complete the new Host record using the following information:
a. Host Name: Jefferson
b. Click the browse button (...) next to the Operating System field and select Windows.
c. Enter Windows 2012 into the Operating System Version field.
d. Change the Host Risk Level to 5 Medium-Medium.

6. Select the Identifiers tab for the Host record then enter Jefferson in the Windows Name field and
click Add:

7. Click OK to save this Host record.

Chapter 5 | LogRhythm Log Sources 153

 Part 2: Create the Log Sources for this Windows Host
1. Navigate to the System Monitors tab
2. Double-click on the only System Monitor in this Training environment, LRVM-XM.
3. The System Monitor Agent Properties window opens. Right-click in the table located in the lower
panel, and select New.

154 Chapter 5 | LogRhythm Log Sources

 4. In the Log Message Source Properties window, click the selector button located next to the Log
Source Host field.

5. In the Host Selector window, select the San Jose Entity from the left-hand column and then
Jefferson from the right-hand column, and then click OK.

Chapter 5 | LogRhythm Log Sources 155

 6. Click the selector button for the Log Message Source Type field.

7. In the Log Source Type Selector window, type Windows into the Text Filter box, then click Apply.
This will filter the list to those items with Windows in their name.
8. Find the Log Source Type named System - MS Windows Event Logging - Application.

Note: You may need to hover over the names of the Log Source Types, or increase the
size of the window, to locate the exact type. When you hover over an item, a tooltip will be
displayed showing the full name of the item.

9. Click to select the desired Log Source Type, then click OK to save.

156 Chapter 5 | LogRhythm Log Sources

10. A Log Message Processing Engine (MPE) Policy must be selected. Click on the drop-down
box and select LogRhythm Default.

11. Click OK to save this new Log Source.

Chapter 5 | LogRhythm Log Sources 157

 Part 3: Create Two Additional Windows Log Sources
Repeat the procedure outlined in Part 2 of this exercise to create two additional Log Sources for the host
named Jefferson:

System - MS Windows Event Logging - Security

System - MS Windows Event Logging - System

The following Log Sources should now be listed as Log Messages collected from the host named
Jefferson by this System Monitor Agent:

You can click OK to close this window now.

158 Chapter 5 | LogRhythm Log Sources

 Exercise 2:
Adding Log Sources Via the Windows Host Wizard

The purpose of this exercise is to practice adding Log Sources via the Windows Host Wizard. In this
exercise, you will be tasked with using the Windows Host Wizard to add Windows Log Sources from
three non-AD domain member Windows hosts.

Task: Using the Windows Host Wizard, add three Windows hosts into the LogRhythm Platform for the
San Jose IT Entity. Along with the new hosts, three Log Sources per host will be added into the system
and assigned to the System Monitor.

Note: If these hosts were part of an Active Directory domain, the Windows Host Wizard can be
used to discover Domain Computers and add them to LogRhythm automatically. However, it is
not uncommon to use this wizard manually to add a small number of known hosts without
scanning an entire AD Domain for new computers.

1. Navigate to the Windows Host Wizard by selecting Tools > Administration > Windows Host
Wizard.

The Settings window will be displayed. Since there is no domain available in this Training VM,
click OK to close this window.

Chapter 5 | LogRhythm Log Sources 159

 2. The Windows Host Wizard window will appear. Click the Import Computers button.

Note: If your LogRhythm Platform is connected to an Active Directory Domain, clicking

the Scan Domain for Computers button will request all machine records from the
primary Domain and add any hosts not already in LogRhythm as Host records.

160 Chapter 5 | LogRhythm Log Sources

 3. Make note of the Format required for your data entry. The format is the key to importing new
Windows hosts into LogRhythm manually.

The import process can be performed in several ways:

Add computers manually by typing information in the Data Entry Text field
Import Clipboard Text that was copied into the memory of the computer
Import Text File by uploading it into the wizard
For this exercise, we will enter the details for three new Windows hosts into the Data Entry Text
field. Only the computer name is required; if no other information is entered, the selected Default
LogRhythm Entity and Default Operating System will be assigned to the computers listed.
However, if you have Windows hosts that are a mixture between Windows XP/Windows 2003 and
Windows Vista/Windows 2008 or greater, then the Operating Systems will need to be specified
along with the computer name to ensure that the correct Log Sources are collected.
4. The format for the text you need to enter into the Data Entry Text field is as follows:
Computer Name, Operating System, LogRhythm Entity ID, IP Address, DNS Name,
LogRhythm Host Name, User Defined Tag

Note: Not all fields are required for the Windows Host Wizard; however, if more than
Computer Name is entered, then the format above must be followed. Entering blank data
separated by commas should be used to denote empty fields.

Note: The Entity can be modified later, by the Windows Host Wizard, prior to importing
the new Hosts into the LogRhythm Platform. All other fields can be modified post import,
through the Entities tab.

The following computers will be added in the Data Entry Text field:

Chapter 5 | LogRhythm Log Sources 161

 Computer Name Operating System IP Address

Wilson Windows 2016 192.168.99.230

Taylor Windows 2012 R2 192.168.99.231

Grant Windows 10 192.168.99.232

a. Enter the above information into the Data Entry Text box, using the appropriate format, and
a space character for empty fields that do not have specified information. Compare your
entry with the screen shot below:

Note: There is a blank space between the Operating System (OS) field and
IP address, because we've left the LogRhythm Entity ID field empty.

162 Chapter 5 | LogRhythm Log Sources

 Note: The name of the OS typed in the Data Entry Text box should match the
format of one of the Default OS versions listed in the drop-down menu.

b. Click Import Data Entry Text to add these computers to the Windows Host Wizard.
5. Verify that the three new hosts appear in the Windows Host Wizard.

Chapter 5 | LogRhythm Log Sources 163

 6. The Entity, used by default, was Boulder, but this is not the correct location for these hosts. The
Entity should be changed to San Jose/IT before moving forward. Click the Action box next to each
new host, then right-click in the table and select Actions - Change LogRhythm Entity.

7. Locate and select the San Jose/IT Entity, then click OK.

8. Click Yes to confirm the changes.

164 Chapter 5 | LogRhythm Log Sources

 9. Verify that San Jose/IT now appears in the Host Entity column.

Note: In this exercise, computers were added that do not exist in our Training envir-
onment. However, in your organization's environment, at this step in the process, you
would click the Query Computers button, or right-click and select Actions - Query
Computers. The System Monitor would then connect to the host to identify the Windows
Event Logs that actually reside there. In some cases, additional Log Sources may be
available on the host. The SysMon would require the use of a Service Account to access
the logs on the remote hosts.

10. Right-click the table of New Hosts and then click Actions > Accept > Assign Remote System
Monitor Agent to assign the new hosts to the existing System Monitor.

Note: For logs to be collected, the remote System Monitor must be running under a
Windows Service Account that has permissions to connect and collect Windows Event
Log information from these hosts. By default, a System Monitor uses the Local System
account, which will not have permissions on a remote host.

Chapter 5 | LogRhythm Log Sources 165

 11. Verify that the LRVM-XM System Monitor is listed, and click OK to accept this selection.

12. Click Yes to Confirm Assignment of the three new hosts.

13. Your new hosts no longer show in the current Windows Host Wizard view. Click the New Host tab.

14. Verify the three new hosts are here and that the information in the Windows Name, OS Version,
and IP Addresses match what was entered.

166 Chapter 5 | LogRhythm Log Sources

15. Click Next twice to continue to the New Log Sources tab of the Windows Host Wizard. Verify that
each host has three Log Sources: MS App Log, MS Security Log, and MS System Log. Verify
that the correct OS Version is listed for each host.

16. Click OK to close the Windows Host Wizard and save the new Host records.
17. Click the Entities tab in the Deployment Manager. Click to expand the San Jose Entity and click
the IT Entity. Verify that the three new Host records are here.

Chapter 5 | LogRhythm Log Sources 167

168 Chapter 5 | LogRhythm Log Sources
18. Click the Log Sources tab in the Deployment Manager, and then scroll through the list of
Log Sources to identify the nine new Log Sources that you just added using the Windows Host
Wizard.

Hint
Type MS into the filter field to select only MS Event Log Source Types.

Results:
Nine new Log Sources from three new Windows hosts have successfully been added to LogRhythm. The
Windows Host Wizard greatly simplifies the process by placing the Host records into the correct Entities.

Note: The three hosts added during this exercise will not send logs because they are not real
computers in our Training VM.

Chapter 5 | LogRhythm Log Sources 169

 Exercise 3:
Adding a Flat File Log Source

The purpose of this exercise is to practice adding flat file Log Sources. In this exercise, you will be tasked
with adding a flat file Log Source into the LogRhythm Platform.

Setup: You will need to run the classroom lab application, located on the desktop of your Training VM.

Part One: Start the Lab

1. Navigate to the Desktop of your Training VM. Locate the LabManager and double-click to open it.

2. Type 1 and press Enter to run the LogRhythm Administration Fundamentals - Adding a flar
file log source lab.

170 Chapter 5 | LogRhythm Log Sources

Part Two: Add a new Log Source to a System Monitor
Follow the steps below to add a new flat file Log Source to the LRVM-XM System Monitor. The new Log
Source Type is a Syslog File - LogRhythm Syslog Generator named syslogfile_0001.log and is
located at C:\flatFile.

1. Navigate back to the Deployment Manager in the LogRhythm Client Console.

2. Navigate to the System Monitors tab.
3. Double-click the System Monitor entry (LRVM-XM) to open the System Monitor Agent Properties
window.

4. Right-click within the table of Log Sources and select New.

5. In the Log Message Source Properties window, click the button to open the Log Message

Source Type selector. 

Chapter 5 | LogRhythm Log Sources 171

 6. In the Text Filter field, type syslog file, then click Apply.

Select System : Syslog File - LogRhythm Syslog Generator, and click OK.
7. In the Log Message Source Name field, type LRVM-XM Flat File App Log. Then click the Log
Message Processing Engine (MPE) Policy drop-down list and select LogRhythm Default .

172 Chapter 5 | LogRhythm Log Sources

 8. Click the Additional Settings tab. To configure the Silent Log Message Source Settings, select
the Enable Silent Log Message Source Detection box. Set the Issue WarningAfter to 10
minutes and Issue Error After to 30 minutes.

Note: This feature will send warning and error messages whenever this Log Source
ceases to send new logs to LogRhythm. This is an effective measure in detecting system
failures or applications that may have crashed or failed.

9.  Click the Flat File Settings tab. Type C:\FlatFile\syslogfile_0001.log, in the File Path field.

Chapter 5 | LogRhythm Log Sources 173

 10. Click on the button for Date Parsing Format field to open the Date Format Manager. Locate
the LogRhythm Syslog File format and click OK.

11. Then click OK to begin collection of logs contained in this flat file Log Source.
12. Verify that the new Log Source is listed in the table for the System Monitor Agent, and click OK to
close the System Monitor Agent Properties window.

13. Click on the Log Sources tab of the Deployment Manager. Locate the newly created Syslog File
Flat File App Log entry.

174 Chapter 5 | LogRhythm Log Sources

14. Verify that this new Log Source has collected messages successfully by looking at the Last Log
Message field:

Note: You may need to click the refresh button on the Deployment Manager before it
shows that the System Monitor is collecting logs from this Log Source. It can take up to
two minutes for a System Monitor to collect its first logs from a newly added Log Source.

Challenge Question:
Do you know why the Last Log Message shown in the image above is highlighted in red?
________________________________________________________________________________
________________________________________________________________________________

Chapter 5 | LogRhythm Log Sources 175

 This page intentionally left blank.

176 Administration Fundamentals

CHAPTER 6
Users, Profiles, and Permissions
Security Overview 178
Notification Policies 179
User Profiles 184
Managing User Profiles 186

Restricted Analysts 188

Restricted Administrators 190

Active Directory Group Authorization 192

Person and Role Records 193

Creating a New Person or Role Record 195

User Accounts 196

LogRhythm Permissions Model 198
Entities and Permissions 201

Exercises 203
Exercise 1: Create a Notification Policy 204

Exercise 2: Create a User Profile 207

Exercise 3: Create a New Person Record 212

Exercise 4: Create a New User Account 215

Administration Fundamentals │ Users, Profiles, and Permissions 177

 Security Overview

The objective of this chapter is to introduce you to the tasks required to manage the Users in your envir-
onment.

LogRhythm provides granular access rights for users of the system. You can also assign specific permis-
sions for user profiles as well as job related roles such as server and network administrators.

There are four levels of user access accounts that enable users to accomplish various tasks in the
LogRhythm Platform:

Global Administrators
Restricted Administrators
Global Analysts
Restricted Analysts

In addition to active users who are allowed to login to the Client and Web Consoles, LogRhythm provides
a mechanism for notifying people who do not have active user logins for LogRhythm. This Notification-
only role is accomplished via Person or Role records, which should not be confused with User records.

178 Chapter 6 | Users, Profiles, and Permissions

Notification Policies

Alarm Notification Policies govern the frequency and other notification details for Alarms. Notification
Policies are managed in the Notification Policy Manager accessible from the Tools - Distribution -
Notification and Collaboration menu in the Client Console. Notification Policies all require a Policy Name
and a set of configuration options that define how the Notifications will behave under the policy. When the
policy is created, you'll be asked if it should be Public or Private.

Public policies can be used by others to modify their notification preferences.

Private policies can be used only by the user who created it. Analysts can create their own private
Notification Policies.

An Alarm Notification Policy can then be selected for use in the Contact Methods tab in a Person or Role
record.

The three different types of Notification Policies are:

SMTP (email)
SNMP trap
Text file

Details about each of the Notification Policies are described below.

Chapter 6 | Users, Profiles, and Permissions 179

 SMTP (Email) Notification Policy

The Email Notification Policies window contains settings for how frequently an email should be sent to a
user and the metadata fields to be included in a notification for an Alarm. By default, this policy allows a
maximum of 10 emails to be sent over a period of 60 minutes; both of these values can be adjusted.

180 Chapter 6 | Users, Profiles, and Permissions

Alarm Notifications are sent in text format; however, if the option is selected, AI Engine Alarm notific-
ations can be sent in HTML format which allows for easier reading of a greater detail of information, as
shown in this example.

Chapter 6 | Users, Profiles, and Permissions 181

 SNMP Trap Notification Policy

Simple Network Management Protocol, or SNMP, Traps are messages sent to an SNMP Manager in your
environment. The Alarming and Response (ARM) service on the LogRhythm Platform Manager acts as
an SNMP agent to send SNMP Traps to an SNMP Manager. The SNMP Manager can then determine
what action to take based on the information it receives.

To utilize this type of notification, create a unique Role or Person record for each SNMP Trap Notification
Policy. Include the name of the SNMP Manager as the name of the Person record and the SNMP Trap
Notification Policy.

SNMP Trap Policies require you to define the version of SNMP that will be used for the notification.
LogRhythm supports SNMP versions 1, 2c, and 3. In each case, an IP address and port must be defined
for the local endpoint, which is the IP address of the Platform Manager, and the remote endpoint, which is
the receiver's IP address. You must also define a SNMP community string for SNMP Version 1 or 2, and
you must supply the advanced SNMP Version 3 security items1. Be sure to set the metadata values to be
included prior to saving the policy.

1SNMP receivers vary in their configuration and option support; the settings used by LogRhythm for SNMP traps should match
those of the receiver.

182 Chapter 6 | Users, Profiles, and Permissions

Text File Notification Policy

You can send alarm notifications to a text file using LogRhythm.

The Text file Alarm notification feature allows you to write Alarm notifications to a text file in near-real-
time. These Alarm records are formatted as a simple set of delimited text fields that can be read by many
different applications. For example, you can configure BMC PatrolAgent to collect alarm records and feed
them to an event/impact management system.

Text File Notification Policies require a name for the policy, a path to a file, field, and record delimiters, as
well as the file's text encoding and time zone. Text file notifications allow for a notification file to be "rolled
over" during a given time interval or maximum file size. File rollover is a process where a file is moved
from Active state, where the test file is open for reading and unlocked for writing, to an Inactive state,
where the platform has locked the file to writing but left it open for reading. When a file is rolled over, a new
file is created as the Active file and alarms will continue to be written to the new Active file.

Chapter 6 | Users, Profiles, and Permissions 183

 User Profiles

User profiles determine the level of access in the LogRhythm Platform by defining the role, Data
Processor access, and Log Source access for one or more User accounts. There are four User profiles;
the Restricted Administrator and Restricted Analyst profiles can be customized to specify granular levels
of access within the platform.

Restricting access by Entity is a convenient way to create User profiles that have access to all data
within a department, by customer account (for Managed Services Providers), or by geographic region.

The administrative User profiles are:

Global Administrators - This profile type has full control in LogRhythm and cannot be
customized.
Restricted Administrators - This profile type has permissions that permit configuration changes
as well as read-only functions (investigations, tails, alarms and reports). This access control is
segregated by Entity or by management permissions assigned to the profile.
o By default permissions to view and modify Host records, System Monitors, and Log Source
properties.
o Additional privileges can be assigned via the profile in the Management Permissions tab to
allow either View or Manage access to the different resources of the Deployment Manager
(LogRhythm permissions enforced).

The Analyst User profiles are:

Global Analyst—This profile type is allowed to view and use all data collected by LogRhythm. It is
a global-level account, and cannot have data restrictions placed upon it. All Log Sources and all
Data Processors can be accessed by this profile; however it does not allow access to any of the
administrative tools.

184 Chapter 6 | Users, Profiles, and Permissions

 Restricted Analyst—This profile type provides restricted visibility into collected log data by
limiting the user's scope. The purpose of a Restricted Analyst User profile is to give access only to
the data required to do their jobs without providing them with unnecessary data (data that they do
not have permission or clearance to view).

For more information, please see the LogRhythm Help Guide.

Chapter 6 | Users, Profiles, and Permissions 185

 Managing User Profiles

User profiles can be viewed and created in the User Profile Manager accessed from within the Tools -
Administration menu in the Client Console.

Cloning a User profile allows you to edit an existing User profile similar to one you want to create without
having to create it again. Highlight the User profile you want to clone and click the Clone button. Access
will be the same as the original profile until you make changes. The new profile is named the same as the
original profile with "_Clone" after it; rename it to whatever you want.

Restricting Permissions by Allowing or Denying Access

The permission model provides an explicit Allow or explicit Deny of access to data. You can choose the
model you prefer when creating a new User profile. Depending on the type of User profile and your organ-
ization, there are benefits to leveraging either an explicit Allow or an explicit Deny model. Select the
permissions model that is appropriate to the type of user assigned to the User profile.

In the Allow model, you must select at least one entity you grant access to. After its selected, it auto
populates the log sources from that Entity and they are seen under the Effective Log Sources tab. When a
new log source is added to the Entity, they automatically have access to it.

In the Deny model, you must select at least one entity you grant access to. However, access is denied to
all Log Sources by default, and specific Log Sources can be allowed explicitly. When new Log Sources
are added to an Entity, you must explicitly grant access to those new Log Sources. To deny access, use
the Log Source Access Rights tab and select the individual Log Sources.

186 Chapter 6 | Users, Profiles, and Permissions

The New User Profile Properties configuration allows you to set permissions to specific tools, Entities,
Log Sources, and Data Processors for each User profile.

Chapter 6 | Users, Profiles, and Permissions 187

 Restricted Analysts

Use the following procedure to create a Restricted Analyst User Profile (or a Global Analyst User Profile).
A Restricted Analyst will be created in this example:

1. From the Deployment Manager, navigate to the User Profile Manager by selecting Tools >
Administration > User Profile Manager.
2. Right-click in the Table of User Profiles and choose New. When creating a new profile, you can
select the Allow Access or Deny Access option. These options change the default access to Log
Source Lists and Log Sources, as follows:
a. Allow Access: The user profile is granted access to all Log Source Lists and Log Sources
in the Entities selected on the Entities tab. You can deny access to Log Source Lists or Log
Sources by adding them to the Log Sources Access Rights tab.
b. Deny Access: The user profile is denied access to all Log Source Lists and Log Sources.
You can grant access to Log Source Lists or Log Sources by selecting one or more Entities
on the Entities tab, and then adding Log Source Lists or Log Sources to the Log Sources
Access Rights tab.
3. Enter a profile name in the User Profile Name field.
4. Restricted Analyst should be displayed in the Security Role drop-down field.

Note: Restricted Analysts may optionally include access to AI Engine Events globally,
the use of the Second Look wizard tool, and the use of the LogRhythm API Access.

5. Click on the Data Processor Access Rights tab.

6. Select the DPs that this user profile should have access to by selecting the Grant check box
located next to the desired Data Processor Name. At least one DP must be selected. If this user
profile will be restricted by Entity, Log Source List, or individual Log Sources, rather than Data
Processors, All active online Data Processors can be selected.

188 Chapter 6 | Users, Profiles, and Permissions

 a. Clear the Specified Data Processors check box (which allows for granular Data Processor
selection).
b. Select the All active online Data Processors check box (to select all Data Processors
universally) and/or the All active archive Data Processors check box (to select all DPs
that manage Archive databases) as needed.
7. Next, select the Log Source Access Rights tab.
a. To restrict this profile by Log Sources in a List, select the Log Source Lists tab located
along the bottom of the New User Profile Properties window. Next, select the Grant check
box (and optionally the Deny check box) next to the log source list that will be included for
this profile.
b. To restrict this profile by individual Log Source, select the Log Sources tab located along
the bottom of the New User Profile properties window. Next, select the Grant check box
(and optionally the Deny check box) next to the Log Source that will be included for this
profile.
c. If any virtual Log Sources have been configured in the system, users may be restricted by
these using the Log Sources tab located along the bottom of the New User Profile
Properties window.
8. To restrict this profile by Entity, select the Entities tab on the New User Profile properties window.
Select the Grant check box (and optionally Include Child Entities check box) next to the Entity
that will be included for this profile.
9. Once the options for the Restricted Analyst have been selected, click OK to save this profile.

New User Profiles can be used when creating new User Accounts or when updating an existing User
Account on the People tab of the Deployment Manager.

Chapter 6 | Users, Profiles, and Permissions 189

 Restricted Administrators
Restricted Administrator User Profiles provide a mechanism for delegating access to maintain specific
Entities and components in the LogRhythm Platform. Restricted Administrators can manage or view any
components that their profile has given them access to or within their visible scope.

Restricted Administrators are given a limited view by default of the Deployment Manager, including the
Entity tab, which will display only Entities to which they have been given permissions, and they will be
unable to create additional Entities. Restricted Administrators can create new Networks and Hosts only
within their specified Entities by default, however additional permissions can be assigned to this role by a
Global Administrator.

Note: The Deployment Monitor is not available to the Restricted Administrator; this tool is
reserved for Global Administrators.

Creating a Restricted Administrator User Profile

Global Administrators can use the following procedure to create a Restricted Administrator Profile:

1. Navigate to Tools - Administration - User Profile Manager.

2. Right-click in the table of User Profiles and select New. When creating a new profile, you can
select the Allow Access or Deny Access option. These options change the default access to Log
Source Lists and Log Sources, as follows:
a. Allow Access: The user profile is granted access to all Log Source Lists and Log Sources
in the Entities selected on the Entities tab. You can deny access to Log Source Lists or Log
Sources by adding them to the Log Sources Access Rights tab.
b. Deny Access: The user profile is denied access to all Log Source Lists and Log Sources.
You can grant access to Log Source Lists or Log Sources by selecting one or more Entities
on the Entities tab, and then adding Log Source Lists or Log Sources to the Log Sources
Access Rights tab.
3. Enter a profile name in the User Profile Name field.

190 Chapter 6 | Users, Profiles, and Permissions

 4. Select Restricted Administrator from the Security Role drop-down list under Privileges.

Note: Restricted Administrator may optionally include access to AI Engine Events

globally, the use of the Second Look tool, and the use of the LogRhythm API Access.

5. Next, at least one Entity must be added in the Entities tab. This selection will give this Restricted
Administrator Profile permissions to all Log Sources, child Objects, and related Objects located
within each selected Entity.
6. Click the Data Processor Access Rights tab.
7. Select the Data Processors that this user profile should have access to by selecting the Grant
check box located next to the desired Data Processors. At least one Data Processor must be
selected. If this user profile is restricted by Entity, Log Source List, or individual Log Sources,
rather than Specified Data Processors, the All active online Data Processors check box can be
selected.
a. Clear the Specified Data Processors check box (which allows for granular Data
Processors selection).
b. Select the All active online Data Processors check box (to select all Data Processors
universally) and/or the All active archive Data Processors check box (to select all Data
Processors that manage Archive databases) as needed.
The Log Source Access Rights tab is not used by Restricted Administrators.
8. If required, add or assign further view or manage permissions from the management permissions
tab.
9. If required, add Smart Response Plugins that this account has access to execute.
10. If desired, this profile can be attached to an AD group for Authorization by clicking in the Active
Directory Group Authorization area. Choose an AD group (if Active Directory has been
integrated) with which to integrate this profile. Select the available options if the business email and
phone numbers should be synchronized, and if a Default Policy should be applied for notifications.

Note: All users that belong to the chosen AD group will immediately be given privileges to
the LogRhythm console as a Restricted Administrator with permissions defined by this
Restricted Administrator profile.

11. Once the options for the Restricted Analyst have been chosen, click OK to save this profile.
New User profiles may be used when creating new User accounts or when updating an existing
User account on the People tab of the Deployment Manager.

Chapter 6 | Users, Profiles, and Permissions 191

 Active Directory Group Authorization

An additional method for granting access to the LogRhythm Platform, is to create a User profile and
attach that profile to an Active Directory (AD) Group.

To use this feature, you must first enter the New Domain Properties in the Active Directory Domain
Manager found in the Platform Manager tab in the Client Console. The LogRhythm Platform must be
fully connected to your AD infrastructure. The LogRhythm Platform Manager host must be a member of
the domain, and the AD Synchronization Manager must be configured to synchronize with the domain.
You must select the Include in Active Directory Group-Based Authorization check box.

One thing worth noting, using the same AD username in multiple profile types can break AD Sync.

Note: AD Integration is not demonstrated during this class. For more information, please refer to
the LogRhythm Help Guide.

192 Chapter 6 | Users, Profiles, and Permissions

Person and Role Records

Located on the People tab of the Deployment Manager, Person and Role records identify an individual
person (Person record) or a group of users or possibly a machine account (a Role record) that can receive
notifications from the LogRhythm Platform, including Alarms and scheduled reports.

Person Records
Person records identify a single individual for the purposes of notification. Person records contain a first
and last name and at least one notification method.

Notification methods include:

SMTP (email)
SNMP traps
Text file

Person records can also include many optional contact methods such as phone, fax, and instant
messaging.

Chapter 6 | Users, Profiles, and Permissions 193

 Role Records
Role records are commonly used to define distribution lists for email notifications, or system notification
methods for SNMP traps. Role records require a display name and at least one contact method. The
Contact Method specified here can be used by the ARM (Alarming and Response Manager) service, if an
Alarm configured for notification is triggered for a Host associated with the Role.

Note: If users require access to the Web or the Client Console, they will first need a Person
record and then a User account must be created with the login ID and password. Person and
Role records by themselves do not allow access to login to the Web or Client Console.

194 Chapter 6 | Users, Profiles, and Permissions

Creating a New Person or Role Record
You can create a new Person or Role record using the following procedure:

1. From the Deployment Manager, click the People tab.

2. Right-click in the Table of Person and Role Records.
3. Choose New.
4. Do one of the following:
Click Yes for a Person Record (used for this demonstration).
Click No for a Role Record.
5. Enter a first, middle (optional), and last name in the boxes provided, and then click Create.
6. In the Contact Method area, click the down arrow to view the various options:
For email notifications, choose Business Email 1 (primary email).
For SMTP trap notifications, choose SNMP Trap.
For text file notifications, choose Text File.
7. Enter the details for the notification method in the area provided.

Note: SNMP traps and text files utilize the Alarm Notification Policy and do not require
any contact information.

8. Click the button next to the Alarm Notification Policy dialog box to choose (or create) a
Notification Policy for this contact method.
9. Click Save to submit the contact information to the record.
10. Verify that the contact information is saved in the area provided at the bottom of the Person
Properties window.
11. Click OK to save this record.

Note: For Role records, only a display name is required vs. first, middle, and last names.

Chapter 6 | Users, Profiles, and Permissions 195

 User Accounts

For individuals who require access into the Web Console or Client Console, Global Administrators can
create a User account attached to that individual's Person record. User accounts can be created for Role
records, as well; however, for security purposes, and to be able to track a user's activity within
LogRhythm, a User account is recommended only for Person records.

User accounts, by default, are stored within LogRhythm as MS SQL Server logins. You have the option to
integrate the LogRhythm Platform with Active Directory (AD); and can choose to utilize AD authentication
over MS SQL Server authentication for user access.

Note: Restricted Administrators do not have permissions to create User accounts.

To create a User account:

1. From the People tab in the Deployment Manager, highlight the Individual person or Role record that
requires the user account.
2. Right-click on the Individual person or Role record and choose Create User Account.
3. Enter the User Info in the Add LogRhythm User window:
a. Select if this user will be an AD user by checking the Windows Account check box; and if
so, only enter the domain and user name. Or click the button, then browse the domain
for the desired account.
b. If this user will not be an AD user, enter a user name and password, which will be used to
create a SQL Server login that will be published to all LogRhythm appliances.
4. Select a User Profile for this user.
5. If this User account is a MS SQL Server login with a weak password, ensure thatEnforce

196 Chapter 6 | Users, Profiles, and Permissions

 Password Policy is deselected so that the User account can be saved.
6. Click OK to save the User account.

Chapter 6 | Users, Profiles, and Permissions 197

 LogRhythm Permissions Model

In LogRhythm, you'll use what we call objects. Objects are defined as a component of the LogRhythm
Platform that users can create and manage such as Person records, Role records, saved Investigations,
FIM policies, Lists, AI Engine Rules, Alarm Rules, and Reports.

Objects can have permissions applied such as Private or Public.

Private permissions allow a user to create an object that is visible only to themselves.
Public permissions are set for all users and determine who else has the following permissions to
the object:
o Read (Use)
o Write (Edit)

The LogRhythm Platform contains a complex model that allows Global Administrators flexibility to assign
Analysts and Restricted Administrators permissions for accessing objects and data. The permissions
model, how to view the various components, and how to manage it, are defined next.

Viewing Object Ownership and Permissions

For all objects containing ownership and permissions, the information is displayed on that object's
Permissions tab.

For example, all users of the LogRhythm Platform will have a Person record, this is one example of an
object in LogRhythm. Here is a screenshot of a Person record object's Permissions tab:

198 Chapter 6 | Users, Profiles, and Permissions

Each object is assigned the following permissions:

A Read Access permission: This defines who can view this object.

An Owner: This is the account that created the object.

A Write Access permission: This defines the group of users who can edit the object properties.
A Default Entity: This field displays the Entity with which the object is associated. This defines
the object's visible scope in the platform.

Read Access
Read Access Permissions for objects, in general, define who can view the object. In the Person object
example above, the read access permissions would be accessed via the People tab of the Deployment
Manager.

Write Access
Write Access defines the user or group of users that can modify this object. The Write Access property
cannot be modified and is set when an object is created.

Owner
The account that is used when creating an object immediately becomes the "owner" and is granted write
access to that object. Except in rare cases where a group will be assigned as an owner by the LogRhythm
Platform, usually on System objects.

Chapter 6 | Users, Profiles, and Permissions 199

 The Owner of an object is the LogRhythm account that created the object. System objects that were
installed with the LogRhythm Platform will be owned by the LogRhythm Administrator, or owned by
"N/A" for some system objects, such as Lists. Custom objects (created by users) will be owned by the
User upon creation of the object.

Most system objects will be owned by the built-in account "LogRhythm Administrator," which is a Role
which happens to have an associated User record, but is not associated to a real person. Because the
LogRhythm Administrator account has an associated login, it can actually be personally used to login to
the LogRhythm Platform. For auditing purposes, administrators should create their own User account
with Global Administrator permissions, so that the system objects can be distinguished from custom
objects (that they created on their own).

200 Chapter 6 | Users, Profiles, and Permissions

Entities and Permissions

All objects within the LogRhythm Platform contain an ownership property to assist with delegating admin-
istrative privileges.

Object Ownership and Permissions

All objects belong to an Entity, but what exactly does this mean?

Restricted Administrators are given permissions to specified Entities. They are restricted to a subset of
objects defined by the Entities specified for their account. They can only view hosts, Log Sources,
System Monitors, Lists, etc., that belong to Entities for which they have been given permissions.
Because of this object ownership permissions model, Global Administrators should take caution to design
their Entity structure carefully with delegated administrative rights in mind.

For Global Administrators, object permission doesn't actually mean anything, because you have access
to all objects within the platform, and where that object lives has no impact on your ability to manage it.

Chapter 6 | Users, Profiles, and Permissions 201

 The Object Permissions Manager

What if an owner of an object leaves and you need to change the permissions of that object? The Object
Permissions Manager enables a Global Administrator to manage secured objects (Investigations, Tails,
Lists, and Alarm Rules). It enables the Global Administrator to set new read and write access permis-
sions for an object and to assign it to a new owner and/or Entity.

The Object Permission Manager can be accessed from the Tools menu in the Deployment Manager.

202 Chapter 6 | Users, Profiles, and Permissions

EXERCISES
People Records, Notification
Policies, and User Security
Exercise 1: Create a Notification Policy 204
Exercise 2: Create a User Profile 207
Exercise 3: Create a New Person Record 212
Exercise 4: Create a New User Account 215

Chapter 6 | Users, Profiles, and Permissions 203

 Exercise 1:
Create a Notification Policy

The purpose of this exercise is to practice creating new Notification Policies. In this exercise, you will be
tasked with creating a new Notification Policy for users who require the receipt of Alarms or scheduled
Reports via email.

Task: Create a new SMTP (email) Notification Policy. The SMTP policy will define which fields to include
in an email and how many Alarms are allowed to be sent to a recipient over the course of a specified time
period.

1. Click on the Tools Menu, then navigate to Distribution > Notifications and Collaboration >
Notification Policy Manager.
2. The Notification Policy Manager appears. Click the File menu, and select New SMTP Policy.

3. Click Yes to create a Public notification policy.

204 Chapter 6 | Users, Profiles, and Permissions

 4. Type Default in the Policy Name field. Leave the other settings at the default options for this
Default policy.
Notification Period—This option is set to one hour. The Maximum Notifications per Period,
by default, is 10.
Include Alarm Fields—Each selected metadata field will be included in the
email notification in the order in which it appears, when an Alarm is triggered.
Field Order—The field order arrows allow you to adjust each field's position. Simply
highlight a field that should be reordered and use the controls to adjust its position in the
notification.

5. Click OK. Verify that the new Default policy is listed in the Notification Policy Manager, and click
OK to close this window.

Chapter 6 | Users, Profiles, and Permissions 205

 Note: You can also navigate to the Notification Policy Manager window from within the
People tab in the Deployment Manager.

206 Chapter 6 | Users, Profiles, and Permissions

 Exercise 2:
Create a User Profile

The purpose of this exercise is to practice creating a new User Profile. User Profiles are created and
utilized for users that will be granted a limited set of permissions to the data collected by LogRhythm.

Scenario: Users from the New York office have requested access to the data collected from their site.
Currently, no specific User Profile exists to limit a user's access to only servers or devices in the New
York office, so one must be created.

Task: Create a new User Profile that will grant access to all data collected at the New York office, and
restrict access to any other Log Sources. Since the data is located within a single location, the User
Profile can be limited to one Entity, the New York Entity, and all its child Entities.

1. Click the Tools menu, and then select Administration > User Profile Manager.
2. Click New and select Allow Access.

Chapter 6 | Users, Profiles, and Permissions 207

 3. Enter New York Restricted Administrator in the User Profile Name field, verify that the Security
Role is set to Restricted Administrator.

4. Click to open the Data Processor Access Rights tab. Ensure the Grant check box located next
to LRVM-XM is selected:

Note: Every Restricted Administrator Profile must include access to at least one Data
Processor (DP). In this Training VM only one Data Processor exists; however, in some
cases there may be more than one Data Processor. The DP responsible for processing
the data from the New York Entity must be selected before users of this Profile can see
any data.
If the Profile will be restricted by Entity or Log Source, it is usually safe to select and grant
access to all Data Processors as the other filter will restrict the actual data visible to this
Profile.

208 Chapter 6 | Users, Profiles, and Permissions

 5. Select the Entities tab in the New User Profile Properties window.
6. Locate the entity titled New York and select the Grant check box and the check box:

7. Select the Management Permissions tab in the New User Profile Properties Window.
8. Expand the AI Engine and Monitor and Alarm permissions and select Manage AI Engines and
AI Engine Rules and then select Manage Global AI Engine Events and Manage Notifications.

Chapter 6 | Users, Profiles, and Permissions 209

 Note: The option to include Child Entities is only available in Restricted Analyst profiles,
in Restricted Administrators Profiles you do not have the option to select sub entities as
you have permission to the root enitity by default.

9. Click OK to save this User Profile. Verify that the New York Restricted Administration profile
appears listed in the User Profile Manager (as shown below). Click the Close button.

210 Chapter 6 | Users, Profiles, and Permissions

 1.
Note: You created a new User Profile to which Users who require access to data
collected from the New York Entity and its child Entities can be assigned.
Restricted Analyst profiles do not provide administrative access, but Users with this
profile can use Searching and Reporting capabilities.

Chapter 6 | Users, Profiles, and Permissions 211

 Exercise 3:
Create a New Person Record

The purpose of this exercise is to practice creating new Person records. In this exercise, you will be
tasked with creating a new Person record that will grant a limited set of permissions to the data collected
by LogRhythm.

Scenario: A user from the New York office has requested access to LogRhythm. A new Person record
for this new user must be created.

Task: Follow the steps below to create a new a Person record for the user located in the New York office.
This User account will utilize the Notification Policy you created in Exercise 1.

Note: The first step in creating a new User account is to add a Person record. Keep in mind that
a Person record only provides a mechanism for a person (or group) to be sent notifications for an
Alarm or report. Once a Person record has been created, a new User account can be created for
the new Person record.

1. Click the People tab of the Deployment Manager.

2. Right-click in the table of Person records and choose New. Click Yes to create a Person record for
an individual:

Note: In general, Roles are used for notification groups. Roles contain notification
methods to notify an email distribution group (or automated processes via SNMP traps or
a text files). Roles should not be used for individuals and, in general, should not be
associated with User login accounts.

3. This user's name is Robert Brown. In the Person Properties window enter Robert in the First
Name field and Brown in the Last Name field. Take note that the Display Name field is automat-
ically updated:
4. In the Contact Methods section, click the Contact Method Type drop-down menu and select
Business Email 1 (Primary Email) from the list.
5. In the Contact Information field, type: [email protected].

212 Chapter 6 | Users, Profiles, and Permissions

 6. Click the button located on the Alarm Notification Policy line, and then highlight the Default
SMTP Policy and click OK to close the Notification Policy Manager window.

7. Verify that Default appears in the Alarm Notification Policy line, and then click the Save button.

8. Verify that the email address appears in the Contact Methods table, located at the bottom of the
Person Properties window.

Hint
If the email does not appear in the Contact Methods table, make sure to click Save above.
If save is not clicked, the information entered in the Contact Methods section will not be
saved to the record, and no notifications can be sent to this user.

9. Click OK to save and close the window.

Chapter 6 | Users, Profiles, and Permissions 213

 10. Verify that the new user appears in the list of People. Notice the box in the Has Login column is
not checked. At this time Robert Brown is able to receive notifications from LogRhythm , but does
not have permissions to login to the LogRhythm Consoles.

214 Chapter 6 | Users, Profiles, and Permissions

 Exercise 4:
Create a New User Account

The purpose of this exercise is to practice creating User Accounts for logging into the LogRhythm
Consoles.

Scenario: Users from the New York office have requested access to the data collected from their site.
Currently, one user in the New York office, Robert Brown, has a Person record (created in Exercise 3) but
he cannot log in.

Task: Your task is to create a new a User account for Robert Brown. Robert will be assigned the new
Profile, created in Exercise 2, which will allow him access to the data collected in New York but limit his
access to data from any other Entity.

1. From the People tab of the Deployment Manager, locate the new Person record for Robert Brown
and highlight that record in the table. Right-click this Person record and select Create User
Account.
2. Enter rbrown in the User Login field. Select New York Restricted Administrator from the list of
User Profiles and select New York for the Default Entity. Then type a password into the Password
and Verify Password fields.

3. Click Apply, which will validate the password.

If Enforce Password Policy has been selected (recommended), clicking Apply will validate the
Password you specified to ensure it meets the criteria in the Policy of the Microsoft SQL Server to
ensure that a strong password has been specified. You might receive an Error message if the
password is not complex enough or if the passwords do not match in both password boxes.

Chapter 6 | Users, Profiles, and Permissions 215

 4. If the password meets the policy criteria, click OK to save this user account. If not, enter another
password (such as logrhythm!1) and repeat step 2 and 3 until the user account can be saved.
5. Verify that Robert Brown's record now contains information in the Login fields:

The User account created in this exercise was added directly to the MS SQL servers within the
LogRhythm Platform. If more than one LogRhythm appliance exists within a deployment, User
accounts are replicated between all servers.

Note: User accounts may also be created that integrate with Windows Domains. If the
LogRhythm Platform Manager (or XM) appliance is a member of a Windows Domain,
LogRhythm User accounts can be selected from Windows Domain User Accounts. If a
Domain account is used, no password is required when creating the User record because
the Domain Pass-Through authentication will be used to validate their login.

216 Chapter 6 | Users, Profiles, and Permissions

 SmartResponse Plugin:
LogRhythm https://community.logrhythm.com/t5/SmartRe
Community sponse/tkb-p/share-a-smartresponse

Reference Links
Global Administration
Administration Fundamentals Create GLPRs:

MPE parsing guide: https://community.logrhythm.com/t5/Training-

Bytes/Client-Console-Identify-chatty-sources-
https://community.logrhythm.com/t5/Other-
and-create-a-GLPR-to/ta-p/39643
downloads/LogRhythm-MPE-Rule-Builder-
Parsing-Guide/ta-p/29957 Filter logs at Agent:

Life of a Log Guide 7.3: https://community.logrhythm.com/t5/SysMon-

Collectors/Filter-Raw-Logs-at-System-Monitor-
https://community.logrhythm.com/t5/SIEM-
Agent-Level/m-p/41420
General-Discussions/Life-of-a-Log-Guide-
Version-7-3-TLM-Guide/m-p/40546 KB Release Notes:

Documents and Downloads (upgrade and https://community.logrhythm.com/t5/KB-user-

install files): guides/KB-Release-Notes/ta-p/31037

https://community.logrhythm.com/t5/Product- Tips and Tricks:

documentation-downloads/ct-p/Documentation
https://community.logrhythm.com/t5/Tips-
RIM Policies (Endpoint Monitoring): Tricks-webinars/April-Tips-amp-Tricks-
Webinar-on-How-to-Upgrade-to-LogRhythm-7-
https://community.logrhythm.com/t5/SIEM-
3/ta-p/39693
General-Discussions/Registry-Integrity-
Monitoring-resource/m-p/36752#M13557 Restoring Archives using SecondLook

https://community.logrhythm.com/t5/SIEM-
General-Discussions/Restoring-Archives-
AIE Fundamentals using-SecondLook-Wizard/m-p/34371#M12881
AIE Rules Simplified:

https://community.logrhythm.com/t5/AIE-
Rules/AIE-Rules-Simplified/m-p/41033#M561

MPE parsing guide:

https://community.logrhythm.com/t5/Other-
downloads/LogRhythm-MPE-Rule-Builder-
Parsing-Guide/ta-p/29957

Administration Fundamentals │ Index 217

 This page intentionally left blank.

218 Administration Fundamentals

GLOSSARY
A settings, Expiration, and other
rule properties. A rule can have
up to 3 rule blocks.
AD
Active Directory. AI Engine Rule Block
A sub component of an AI Engine
Advanced Intelligence Engine (AI Rule that defines configuration
Engine) parameters, or criteria, which
logs must meet in order for the
The LogRhythm component,
log to be considered satisfied by
sometimes referred to as AI
the Rule Block. A rule can have
Engine or AIE, that performs
up to 3 Rule Blocks. There are 9
high-level, real-time analysis of
distinct variations of Rule
log messages forwarded by the
Blocks.
Log Managers. The AI Engine
can elevate logs using a complex
pattern matching rule-set, which Alarm
correlates and detects sophist-
icated intrusions, insider threats, A record indicating that an Event
operational issues, and audit or triggered an Alarm rule.
compliance issues.
Alarm Card
AI Engine Rule An Alarm record that shows
Advanced Intelligence Engine Alarm details.
rule. A Knowledge Base object
that analyzes if logs meet Alarm Notification
specific criteria to generate an
Event from the AI Engine. The A notification of an alarm via a
rule contains settings for notification policy: SMTP (email),
Common Events, Event SNMP, or Text Files. The
Suppression, Alarm/Notification person, role, or group to notify is
set on the Alarm Rule Properties

Administration Fundamentals │ Glossary 219

 Notify tab. The Alarm Notification rules identify log messages by matching
Policies are set via the Notification Policy the fields to a specific log format or
Manager which is a distribution tool option pattern.
within Deployment Manager.

C
Alarm Suppression
A setting to suppress identical alarms Case Card
based on the Events triggering the alarm
The most basic element of a case in the
within a given time span.
Web Console Cases tab; provides basic
case information.
Application
A web application or a protocol; a record Case Management
that defines an application and its ports
A forensic tool for tracking and
and protocols so that the MPE rules can
documenting suspicious logs and alarms
identify a log origin. Applications are
that are believed to be related to the same
managed via the Application Manager
threat.
accessed from the Knowledge Tools
menu within Deployment Manager.
CBDM
ARM Classification Based Data Management.
Available in the Global Data Management
Alarming, Reporting, and Response
Settings found in the Platform Manager
Manager. A Windows service installed on
tab in the Client Console.
the Platform Manager, which is
responsible for processing Reports and
Alarm rules and taking the appropriate Classification
response.
A second-tier group used to categorize all
identifiable logs and Events. There is one
B or more Classifications associated with a
Classification Type. Classification Types
include: Audit, Operations, and Security.
Base-Rule
A Classification can have one or more
Part of the MPE Rule that contains a Common Events, which are associated
tagged regular expression (regex) used to with an MPE Rule.
identify the pattern of a log and isolate
interesting pieces of metadata. Using a
tagging system, these metadata strings Classification Type
can be directed to special fields used by A first tier group used to categorize logs
LogRhythm to better interpret a log or and Events. There are three types: Audit,
specifically identify it. In general, base- Security, and Operations. Classifications

220 Administration Fundamentals │ Glossary

 are grouped into one of these three types.
There is one Classification type for one or Data Processor (DP)
more Classifications. The central processing engine for logs
sent from the System Monitor Agents.
Client The DP contains the Mediator service,
which is responsible for log identification
Initiator of a session, such as a and classification. A DP can be installed
workstation or laptop. on the Platform Manager appliance or it
can be a separate appliance in the SIEM
deployment. Large environments may
Client Console need more than one Data Processor in the
The LogRhythm Platform component that deployment.
provides deployment administration and
user interaction from a thick-client
Graphical User Interface (GUI).
Deduplication
A process that recognizes and consol-
idates duplicate Event data from log
Common Event sources into a single, aggregate record.
A short plain-language description for the All raw log data is captured and archived
activity described in a log message. for accuracy and compliance, while the
Common Events are associated with log deduplication process eliminates
Classifications. A Common Event is redundant online data and optimizes
created and managed through the Tools - forensic search capabilities and storage
Knowledge menu via the Common Event utilization. Deduplication is a Log
Manager. Common Events are Processing Setting that can be set at the
associated with MPE rules (base and log source or log processing policy and
sub) located within the Tools - Knowledge can be overridden using a Global Log
menu MPE Rule Builder option. There is a Processing Rule (GLPR).
one to one relationship between an MPE
rule and a Common Event.
Deep Packet Inspection (DPI)
Analyzes network data using a variety of
D methods, including pattern matching,
heuristic modeling, signatures for session
Dashboard identification, application identification,
and metadata extraction.
A layout in the Console that contains
graphs and charts in easy-to-read
formats, which allows you to view Events Deployment Manager
and drilldown on the data for further invest-
A utility window in the LogRhythm Client
igation. The Web Console includes an
Console. People with LogRhythm
Executive Dashboard, Security Analyst
administrator credentials use it to
Dashboard, and an IT Operations
Dashboard, by default.

Administration Fundamentals │ Glossary 221

 configure and manage LogRhythm sites require multiple Entity records.
components and functionality such as Entities are displayed in a tab within
alarming and reporting. Deployment Manager.

Deployment Monitor Event

A window in the Client Console that A log having more immediate operational,
provides administrators with a near-real- security, or compliance relevance.
time view of the performance of Events typically include logs that are
LogRhythm including host status, host classified as errors, failures, or attacks.
performance metrics, database
utilization, Data Processor metrics, and
Data Processor volume. F

DNS FIM
File Integrity Monitoring. An Endpoint
Domain Name Server.
Monitoring tool that monitors files and
directories for modifications. There are
E two modes: Standard and Realtime.

EMDB Flow
Event Manager Database. A database on A collection of activity by a single user on
the Platform Manager that contains the a single application.
LogRhythm configuration information.

G
Engine
NetMon's packet processing component Global Data Management Settings
that classifies data during Deep Packet
Administrators can enable global options
Inspection.
that override settings at the Data
Processor, Log Source, and MPE Policy
Entity levels. Global settings are applicable in
both Classification Based and Standard
A record that represents a logical Data Management configurations. Data
grouping. It organizes the deployment in Management profiles simplify config-
host records, network records, and the uration based on the deployment’s data
LogRhythm components. Small management model. Data Management
deployments may contain one Entity, settings have been pre-packaged into
while large deployments that span many configurations which support various
deployment models and uses of the
product: Collection Optimized, Search

222 Administration Fundamentals │ Glossary

 Optimized, Performance Optimized, or
Custom. You have the option to manage IDS
these settings at a more granular level. Intrusion Detection System.

Global System Settings Investigator

Global System Settings, available on the A search tool in the Client Console that is
Platform Manager tab in the Client used to query the Events Database on the
Console, include Global Maintenance Platform Manager,or the Data Indexer via
Settings and Identity Inference. Database the Data Processor for a given date range
backup paths and time-to-live (TTL) and with specified criteria for Log Source
values are configured here. and field filters, among other settings. The
results are displayed in a layout that can
GLPR be configured and saved and includes
various grids, charts, and graphs,
Global Log Processing Rule. A including Network Visualization. The data
Knowledge Base object used to provide a results can be drilled into to provide more
way to override settings defined in the detailed information.
Classification Based Data Management
(CBDM) or standard Data Management
settings (Log Message Source and Log IP
Processing Policy). It provides a way to Internet Protocol.
apply data management settings across
all Data Processors, Log Sources, and
Log Processing Policies to logs that meet K
specific criteria. The manager is
accessed via the administration tools
menu within Deployment Manager. KB Modules
Pre-packaged, customizable content
applicable to a specific regulation or need,
I
such as reports, investigations, alarms, or
AI Engine rules, to name a few. An
Icon example is a compliance module for PCI
which would include reports, invest-
A small graphic on the page, which you igations, and AI Engine rules that provide
can select to open a dialog. data relevant in meeting PCI
requirements. Modules are managed
Identified Log using the Knowledge Base Manager
accessed from the Knowledge tools menu
A log that has been sent through the within the Client Console. Modules are
Message Processing Engine (MPE) and imported with a Knowledge Base
processed against MPE Rules for parsing depending on their settings.
and forwarding as appropriate to the
Platform Manager.

Administration Fundamentals │ Glossary 223

 Receiver Manager and a Policy Manager
KB Objects both access via the distribution tools
Defined LogRhythm items such as Alarm menu within Deployment Manager.
Rules, AI Engine Rules, Lists, Report
Packages, Packaged Reports, Report List Manager
Templates, FIM Policies, Investigations,
Tails, and GLPRs that can be associated A tool in the Client Console used to
with a KB Module. manage Lists. A List is a record of data for
a given type to allow for grouping similar
values together in one location that can
Knowledge Base then be used with all LogRhythm tools
A LogRhythm package that includes both that allow filtering. For example, a List
required and optional content shared may include all PCI compliance related
across a LogRhythm deployment. It Log Sources or suspicious hosts or
consists of the core Knowledge Base as privileged users. These Lists can then be
well as modules. The core Knowledge used in filters within Investigator,
Base includes content applicable to all Personal Dashboard, and Reports (to
deployments, such as log processing name a few) while allowing it to be
rules, policies, and classifications. The created/modified from one location.
Knowledge Base is imported using the
Knowledge Base Import Wizard Log Message
accessed from the Tools - Knowledge
menu within the Client Console. A log in its original form as it was received
by the LogRhythm System Monitor
Agent. A raw log displayed in the Web
L Console's Analyzer grid. See also "Raw
Log."
Layout
The arrangement of charts and graphs Log Source
(widgets) on the Web Console A record that represents a single source
Dashboard. Layouts can be saved for of log data that is collected from a host. It
Private or Public use. is associated with a Log Source host,
collection agent (System Monitor), and
Log Message Source Type. It has
LDS
specific data management and log
Log Distribution Services. A policy based processing settings and can have a MPE
solution that allows users to forward policy applied.
specific syslog and non-syslog log
messages to an external syslog receiver
over TCP or UDP. It consists of a Logarithmic graphs
A graph that shows the rate of change or a
skew of multiplicative factors over time.

224 Administration Fundamentals │ Glossary

 Logger Metadata
NetMon's flow output component that Details of a log message in a simple
processes the metadata into "flows". format within the LogRhythm databases.
Metadata is parsed directly from a log
message (explicit) or can be inferred from
LogRhythm Console a log message (implicit). Includes the
See "Client Console" or "Web Console." fields that LogRhythm parses, derives,
and calculates from collected log data.

LogRhythm Platform
MPE
The fully integrated Security Information
and Event Management (SIEM) solution, Message Processing Engine. As part of
which includes the collection of the Data Processor's Mediator service,
LogRhythm components that work the Message Processing Engine is
together to bring log management, responsible for log identification and
advanced log analysis, Event classification, Event processing, and
management, monitoring, and reporting metadata processing.
into one integrated solution.
MPE Policy
Lucene search A collection of MPE Rules designed for a
An open source text retrieval library specific Log Source Type such as Cisco
released under the Apache Software PIX or Windows 2005 Security Event
License. Log. Only Logs that are generated from
Log Sources that have an assigned MPE
Policy are processed by the MPE. There
M can be multiple policies for a single Log
Source Type to allow for flexibility in
assigning the policy to various Log
MAC Address
Sources.
A Media Access Control address (MAC
address), which is a unique identifier
assigned to network interfaces for MPE Rule
communications on the physical network A record associated with a specific Log
segment. Message Source Type that includes a
Common Event, Base-rule regular
expression, Sub-rules, and other
Mediator service
processing and policy settings used for
A service running on the Data Processor processing logs.
responsible for log identification and
classification.

Administration Fundamentals │ Glossary 225

 N R

NAT Raw Log

Network Address Translation. See "Log Message."

Navigation bar RBP

The selections at the top of the page that Risk-Based Priority. A calculation that
allow you to move between Web Console results in a number between 1 and 100. It
pages. The currently active page is is used to determine how serious or
shown in blue. critical an Event is, based on a number of
other rating and probability factors.

P
Report Center
Packet An analysis tool in the Client Console that
provides users the ability to manage
A unit of data carried by a packet-
report templates, reports, and report
switched network.
packages.

PCAP File S
An industry-standard format for containing
packet capture data.
SIEM
Security Information and Event
Platform Manager (PM) Management. See also "LogRhythm
The central hub of Event and incident SIEM."
management, reporting, analysis, and
configuration across the entire
SMTP
LogRhythm SIEM deployment. The
Platform Manager includes the Alarming, Simple Mail Transfer Protocol.
Reporting, and Response Manager
(ARM), which is a Windows service
responsible for processing Alarm rules SNMP
and taking the appropriate response. The Simple Network Management Protocol.
LogRhythm SIEM includes only one
Platform Manager per deployment, which
is installed on its own appliance. SSL
Secure Sockets Layer.

226 Administration Fundamentals │ Glossary

 Sub-Rule URL
Part of the MPE Rule that differentiates Uniform Resource Locator.
log messages that match the same Base-
rule using values in the log. Sub-rule tags
can include a regex that only applies to User Activity Monitoring
the string in a specific field to identify An Endpoint Monitoring tool that is used in
information such as a log / event identi- conjunction with FIM, DLD, Process
fication number, a message string, or Monitor, and Network Connection Monitor
even a user or group name. to include the user information related to
the log activity. It is managed from the
System Monitor Agent properties within
SysMon
Deployment Manager.
LogRhythm SysMon, also called System
Monitor Agents, collect and forward raw
log data to the SIEM's Data Processor. W
SysMon can be installed on both
Windows and UNIX platforms. SysMon Web Console
are also integrated into LogRhythm's
components to collect diagnostic Web interface that runs on a browser or
information about the SIEM. tablet; provides easy access to analytic
tools, alarms, and customizable
dashboards to view Events and Alarms
T identified by LogRhythm.

TCP Widget
Transmission Control Protocol. A mini-application, such as a chart or
graph, that provides content for
Dashboards. Widgets can be re-sized and
U
repositioned in page Layouts to modify
existing Dashboards or create new ones.
UDP
User Datagram Protocol. Windows Host Wizard
A tool that allows users to configure
Unidentified Log LogRhythm to collect Windows Event
Logs. It has the ability to scan domains
A log that has been sent through the
and allows users to import computers. It
Message Processing Engine (MPE) that
is accessed via the Tools - Administration
was not identified against any of the MPE
menu within Deployment Manager.
Rules.

Administration Fundamentals │ Glossary 227

 X

XM Appliance
An all-in-one LogRhythm appliance that
includes the Platform Manager, Data
Processor, and Data Indexer. In small
deployments the AI Engine and Web
Console might also be installed on the
XM.

Zone
Used in an Entity Host Record or
Network Record to indicate whether it is
located Internal, External, or in the DMZ.

228 Administration Fundamentals │ Glossary

LogRhythm Headquarters
4780 Pearl East Circle
Boulder, CO 80301
+1 303 413 8745

For more information about our Global Offices visit: https://logrhythm.com/contact/