Least Privileged User

Current best practices dictate that all software be deployed with minimal user/account privileges. The Least-Privileged User approach helps reduce the potential impact if an attacker were to compromise a particular system or user account. This document describes the privilege footprint for typical LogRhythm deployments and provides guidance on how to restrict user permissions.

The LogRhythm SIEM runs as a set of services to support scalability and process isolation. Each service can run under a unique security context to enable greater flexibility in tuning privileges.

Software Version

This document applies to the LogRhythm SIEM version 7.14.x. Future versions of LogRhythm may require additional changes or configuration settings based on new features.

Unless otherwise stated, settings may also be applicable for 6.3.8 and 6.3.3 installations. Earlier installations may have slight variations or may not have specific features in the System Monitors.

LogRhythm Security Certifications

The LogRhythm SIEM runs as a set of independent services to support process isolation and scalability. Each service can run under a unique security context. This provides granularity of privilege assignment, along with the assurance that the service can only perform the functions for which it has been granted permission.

Both LogRhythm SIEM appliances and LogRhythm Software Solutions (LRSS) have a certified security policy applied during the build process as part of the standard LogRhythm hardening process. LogRhythm is also proud to hold the following certifications:

Version 6.3.4

• Defense Information System Agency (DISA) Security Technical Implementation Guide (STIG)
• Common Criteria EAL2+ (VID#10389)
• FIPS 140-2
• U.S. Army Certificate of Networthiness (CoN)

Version 7.1.X

Although certifications have not been attained at this time, LogRhythm still provides guidance and configuration to support evaluation against each of the certifications listed in the previous section.

Version 7.2

• Defense Information System Agency (DISA) Security Technical Implementation Guide (STIG)
• Common Criteria EAL2+ (VID#10389)
• FIPS 140-2
• U.S. Army Certificate of Networthiness (CoN)

Several of these security standards have a direct impact on user privilege and may meet the needs of your enterprise without further changes. If you have questions about any of these certifications, contact LogRhythm for the current guidelines and certification statements.

LogRhythm Account Types

A LogRhythm SIEM deployment contains the following types of user contexts:

• Platform Manager (PM) Version 7 (Formerly Event Manager). The Platform Manager provides alarming, notifications, case and security incident management, workflow automation, and centralized administration for a LogRhythm deployment. The Platform Manager can include an embedded AI Engine instance, a Web Console, or both. The Platform Manager is a required component in the LogRhythm solution, and each deployment has a single Platform Manager.
• Data Processor (DP) Version 7 (Formerly Log Manager). The Data Processor provides high-performance, distributed, and highly available processing of machine and forensic data. Data Processors receive machine and forensic data from collectors and forensic sensors. The Data Processor archives data and distributes both the original copy and the structured copy to other LogRhythm components for indexing, machine-based analytics, and alarming.
• Data Indexer (DX) Version 7 (Formerly Log Manager). The Data Indexer provides high-performance, distributed, and highly scalable indexing and searching of machine and forensic data. Data Indexers store both the original and structured copies of data to enable search-based analytics.
• In LogRhythm 7.1.4, the communication between the Data Processor and Data Indexer was improved, resulting in increased resiliency to data spikes and reliability of message delivery. These changes impact least privilege, as extra services were created and ports were changed.
• System Monitor Agents. LogRhythm System Monitor Agents are deployed on systems that require forensic monitoring, or to read logs from target systems in a scalable fashion. Agents are more difficult to lock down, as the privilege footprint can vary depending on which endpoint areas are being monitored and how the Agent is configured to collect data.
• LogRhythm Users. Users who access the LogRhythm SIEM are already configured to have minimal privileges on any LogRhythm-related system. These users are also already linked to LogRhythm-generated security roles in the LogRhythm data stores.

LogRhythm Security/Trust Boundaries

When evaluating least privilege, it often helps to understand the security zones or trust boundaries from a system perspective. For the LogRhythm SIEM, boundaries can vary by deployment footprint, but can be generalized.

Depending on the exact deployment footprint, the zones can collapse onto a single server (including the Agent), or be distributed across many servers, networks, and endpoint devices. In a large deployment, multiple appliances may be used, and certain data stores (for example, Report Archives or Inactive Log Archives) may be offloaded to separate storage systems not shown in Figure 1.

In terms of securing permissions, user privilege must be considered both within a zone and between zones. If permission is required to leave a security zone, then the privilege must be considered a higher threat, as it may enable the expansion of an attack if a malicious user has compromised a particular account.

Map Accounts to Security Boundaries

Services deployed on a Platform Manager, Data Processor, or Data Indexer (or colocated on an XM) are considered to be inside a LogRhythm-specific security zone. This zone is usually a set of one or more appliance devices provided by LogRhythm. Agents can be deployed on a wide variety of systems outside the XM zone, and, depending on the network topography, may be in multiple, differing security contexts. Based on feature usage and deployment pattern, some LogRhythm services may require access to remote hosts or other systems that have no LogRhythm software installed.

^{1 Applies only if function is offloaded from DP/PM/LM/EM environment}

^{2 Applies only if enabled}

Privilege Types

Each user context requires access to certain resources. To run in a Least-Privileged mode, each context should be locked down to only allow access to named resources. This section provides an overview of the types of resources required by LogRhythm services.

Shared Resource Access

Various LogRhythm components read and/or write to file locations or UNC paths on local machines, and, in some cases, to remote machines or remote file shares. In certain cases (for example, SmartResponse), the component may even need to execute scripts or software stored in the file share. Shared resource permissions are defined as a combination of the explicit file path and six standard permissions for Windows folders:

• Read. Grants permission to list the contents of the directory and read the contents of any files in the directory.
• Write. Grants permission to add files to the directory and write to files.
• Read and Execute. Grants permission to read and execute files in the directory. Note that, depending on the nature of the executable files, this may cause privilege escalation.
• Modify. Grants permission to modify the folder structure by creating, renaming, or removing subfolders.
• Full Control. Grants the account full control (all permissions) over the resource.
• Children Inherit. Determines that child folders should inherit the permissions of the parent.

Almost every LogRhythm service that requires shared resource access has a configurable path for the resource. By default, the resources are placed in a local installation directory. You can change the locations using either the service-specific configuration tool or the Advanced Properties options in the Console’s Deployment Manager.

Windows Registry Access

For LogRhythm components that require local or remote Windows Registry access, the permissions are defined by the registry key name and the 11 different standard Windows Registry permissions:

• Read Control. Grants permission to read the DACL (Discretionary Access Control List), which is generally required to identify which users have permissions.
• Write Owner. Grants permission to modify the container’s owner.
• Write DAC. Grants permission to change the permissions on the DACL. Delete – Grants permission to delete a key.
• Create Link. Generally not applicable; reserved by the operating system.
• Notify. Grants permission to request change notifications for registry keys or subkeys.
• Enumerate SubKeys. Grants permission to iterate through any subkeys.
• Set Value. Grants permission to set a value on the current object.
• Query Value. Grants permission to query a value on the current object.
• Full Control. Grants full control (all permissions) over registry key.
• Children Inherit. Determines that child keys should inherit the permissions.

If you are not familiar with setting advanced registry permissions, you can reach the settings by performing the following actions:

1. Start Registry Editor (note: Admin permissions are required to make changes).
2. Find the target key.
3. Right-click the key, and then click Permissions.
4. In the Permissions dialog box, click Advanced.
5. In the Advanced Security Settings panel, click the Effective Permissions tab.

Database Access

LogRhythm accounts only access the LogRhythm databases (EMDB, Data Indexer, etc.). By default, all database access is controlled through database accounts created during the installation and configuration of the LogRhythm software. Each account is tied to a database role that is defined in the setup scripts.

All LogRhythm database access requires the default SQL Server port 1433.

It is imperative to change all default passwords on initial deployment.

Communication (Ports)

LogRhythm services communicate with each other through a combination of reading/writing database values, and also through encrypted communication via network ports. If per-user, port-level security is required, permissions can be defined for each account based on the types and targets of communication and the default port numbers.

Other Resources

In certain cases, LogRhythm services may require elevated or extra permissions to access other resources such as third-party applications or specific system services. These requirements are noted as “Other Resources.”

For example, Agents can be configured to perform remote event log collection. This access may require creating accounts or adjusting privileges on the third-party system and linking the Agent security context to those accounts.

Prerequisites

LogRhythm runs on software and systems provided by third parties, including Microsoft, Oracle, and others. Each of these systems may have additional privilege or requirements not explicitly discussed in this document.

Of special note, all Windows-based services require access to the .NET Framework. However, none of the services use custom assemblies stored in the GAC.

Approaches to Least Privilege

As with all security policies, choosing the right balance of risk, functionality, and complexity depends heavily on the risk tolerance and standard policies of your company or agency. The approaches listed here are recommendations only, and they may or may not be appropriate given your particular policies, risk tolerance, deployment architecture, and IT staff levels

Define Required Functionality

As a general rule, if a function is not absolutely required, consider configuring all systems to block that function. With this in mind, the first step of any least-privilege setup is to determine which features are required to meet your business requirements. With regard to LogRhythm, the main questions will include:

• Core Services
• Do you need core services configured for high availability or disaster recovery?
• Do you offload log storage, reports, or any other state information from the application servers?
• Do you require a file-based notification system?
• Do you leverage SmartResponse? If so, do you execute from the Platform Manager or through the System Monitors?
• Data Processors
• Do you require offloaded archives?
• Does your Data Processor provide Log Distribution Services (LDS)?
• Agents
• Which log sources will each Agent collect from?
• Will any Agent collect logs from remote sources?

Isolate LogRhythm

As shown in Table 3, all LogRhythm components except for Agents can be deployed in an isolated security zone. The default appliance-based deployment uses local system accounts for this reason, as none of the services require access to non-LogRhythm equipment.

Agents can be deployed under a user context that is as restrictive as possible based on the type of information collected. See the Agent section for your specific operating system details.

Leverage Active Directory Accounts

If your environment requires the use of service accounts managed by Active Directory, best practice is to lock down the permissions for each service according to the guidance provided later in this document.

UNIX/Linux Agents

The *nix-based systems require different permissions because of the underlying operating system. By default, the *nix Agents are deployed to run under root because of the requirement to access port 514 to gather Syslog data.

To run a *nix Agent with non-root privileges, see the current instructions in the LogRhythm SIEM Help.