LogicMonitor Security Best Practices

Overview

The security of your LogicMonitor implementation is a shared responsibility between LogicMonitor and your organization. The LogicMonitor portal provides numerous features that allow our customers to manage the security of the LM Envision application, and it is incumbent upon our customers to operate these controls in alignment with the security requirements of their organizations, while taking into account the recommendations provided below. Additional information on our overall approach to security and architecture can be found here.

Similarly, maximum security of the LogicMonitor Collectors requires strong security, of the customer networks on which they have been deployed, and we rely on our customers to maintain sufficient security on these systems. We strongly encourage our customers to review and apply these security best practices.

Portal Security

The LogicMonitor platform includes many features that protect your data automatically. All information sent over the public internet is automatically encrypted in transit using TLS version 1.2 or newer encryption. Confidential customer data—such as operating system versions, SNMP community strings, API credentials, device configuration files, and NetFlow data—is automatically encrypted before storage.

Our software is developed using a secure development lifecycle, by which security considerations are taken at each step: through design, development, testing, and release. We regularly engage professional penetration testing firms to validate the security of our platform and resolve any defects found by these professional hackers on time.

Our operational systems are based on security-hardened Linux, and we continually scan for vulnerabilities and apply patches regularly to mitigate security risks. The overall security of our platform operations is validated by our maintenance of both ISO 27000 standards certification and AICPA SOC2 Type 2 compliance. Additional information can be found at our Trust Center portal.

Role Assignment and Management

The principle of least privilege is one of the fundamental constructs in information security, and LogicMonitor provides a fine-grained Role-Based Access Control (RBAC) system to allow for its application.

We recommend you create your roles and apply the principle of least privilege based on the level of access that best fits your deployment structure and requirements. As an overall philosophy, we recommend that “manage” permissions to LogicModules and Collectors are applied very conservatively as this allows the user to run arbitrary scripts on the Collector: either through the Collector Debug facility or by creating/editing LogicModules.

 If using our pre-configured roles, you should limit the assignment of the default “Administrator” role to as few individuals as possible. For most of your users, we recommend using the “readonly” or “ackonly” roles for individuals’ day-to-day access. The primary difference between these two roles is that “readonly” only can view the data in the portal and “ackonly” can acknowledge alerts and configure SDTs.

Actions you should take:

• Apply the principle of least privilege to all roles
• Use the “manage” permissions to LogicModules and Collectors very conservatively
• Limit the default “Administrator” role to as few individuals as possible
• Apply the principle of least privilege to the “lmsupport” user account, which is used by LogicMonitor with remote support access to customer portals for troubleshooting purposes

For more information on creating and assigning roles, see Roles.

API Tokens 

LogicMonitor supports the ability to create API Tokens, such as LMv1 and OAuth 2.0 Bearer Tokens, to authenticate to our platform. When doing so, we strongly recommend that API Tokens be created and assigned to an “API Only” user as this user type does not have a password, or other user interface-specific fields, making it a more secure option. Additionally, users who are assigned API Tokens should be assigned a Role with permissions limited to those necessary for the API endpoints being used. 

Actions you should take when using API Tokens in your client-side application code:

• Keep Tokens Secret: API tokens are like passwords; they grant access to resources. Keep them secret and avoid hardcoding them in your application’s client-side code or publicly accessible repositories.
• Secure Storage: Store tokens securely on the client side. Avoid storing them in plain text or using insecure storage mechanisms like local storage or cookies. If deploying tokens in server-side applications, use environment variables or a secure secrets management system (preferred) to store and access them.
• Audit Logs: Keep audit logs of token usage to monitor for suspicious activity and unauthorized access attempts. Platform audit logs are searchable within the portal and can be integrated with existing customer SIEM or log management systems via its API.
• Single Purpose: Generate unique tokens for each client or application. One token should only be used from one source location and for one purpose.
• Educate Users: Educate your developers and users about the importance of API token security and best practices for handling them.
• Never assign administrative privileges to API tokens – this is never required for API functionality.
• Do not assign API tokens to the remote access support user called “lmsupport”.

For more information on LogicMonitor’s REST API, see Using LogicMonitor’s REST API. 

For more information on the lmsupport user, see Users.

End-User Authentication

LogicMonitor supports two methods of end-user authentication: 

a. Our “stock” userid/password system (OR)

b. SSO via integration with your SAML v2 compliant Identity Provider (IdP). While customers can use either option, we recommend using SSO with your IdP.

When using our stock authentication, we strongly recommend that two-factor is applied to all accounts. As noted above, any roles that include “manage” permissions to LogicModules and Collectors are security-sensitive and should be protected accordingly.

When using an SSO integration with your SAML 2.0 IdP, we strongly recommend that you configure your IdP to require two-factor for all end-users with access to the LogicMonitor portal. Our in-product two-factor authentication is not available when using our SAML integration as your IdP has replaced our authentication practices.

Note: By December 31st, 2024, all customer accounts locally provisioned within the portal (i.e. not via SAML) will be required to utilize two-factor authentication.

Actions you should take:

• Use SSO via SAML and your IdP whenever possible
• Always use two-factor authentication for all accounts

Network Access Allow List

Although your portal has built-in protections against brute-force authentication attacks, we recommend defining an allowed list of approved IP address ranges to provide a more complete line of defence. For more information on defining an allowed list of IPs, see Configuring the Portal Settings.

Note that access to your portal via our mobile applications is subject to your network allow list configuration. In a typical configuration, your mobile devices would first need to connect to the corporate network (e.g. using a VPN) before accessing your portal.

The action you should take:

• Define and configure an allowed list of IP addresses for portal access

Audit Log Integration

LogicMonitor maintains an in-product audit log feature, which records authentication actions, configuration changes, and other notable events within your portal. If you maintain a SIEM or other log aggregation/analytics service you might consider using our REST API to export your audit logs into that platform. Once in your central log management system, you can typically configure notifications for certain types of information and retain data in alignment with existing data retention policies.

The action you should take:

• Leverage our REST API to export your audit logs into your SIEM

For more information on LogicMonitor’s audit logs or exporting audit logs via the REST API, see About Audit Logs and LogicMonitor REST API  documentation respectively.

Number of Login Attempts

LogicMonitor provides security against brute-force attacks. CAPTCHA starts after 5 failed login attempts and accounts are locked after 20 failed attempts.

Collector Security

The LogicMonitor Collector has been carefully designed and developed with high security in mind. Communication between the Collector and the LogicMonitor platform uses HTTPS/TLS with publicly-signed certificates to prevent man-in-the-middle attacks between itself and the LogicMonitor platform. Each Collector is cryptographically keyed to the LogicMonitor platform via a strong credential that undergoes regular rotation. All confidential monitored device data handled by the Collector is stored in memory and never written to disk. Additionally, customers have the option to utilize industry-recognized credential vault solutions for device credential storage.

Running Collectors with the least privilege

LogicMonitor’s best practices dictate that the Collector be installed with the least possible privileges within the customer’s environment, avoiding running it as a root, local administrator, or domain administrator account.

Further, the Collector should be provided with the least possible privileges to gather instrumentation for any given device; typically, read-only rights are sufficient. Access configuration for each device is entirely within LogicMonitor customers’ control, and its support documentation provides details on how to configure the minimum required permissions. 

The action you should take

• Always install and run your Collectors with the least amount of privilege per the below references

Information on installing Collectors with least privilege can be found here:

•  Service user migration to non-root for Linux 
• Service user migration to non-administrator for Windows
• Query user migration to non-administrator for Windows using WinRM 
• Query user migration to non-administrator for Windows using WMI 

Operating System Hardening

Even though the Collector has been designed with security at the top of mind, the application can only be as secure as its foundational infrastructure. As such, we recommend that the systems on which your Collectors are installed undergo security hardening in alignment with industry best practices.

For the most comprehensive approach, we recommend the application of the hardening guidelines specified in CIS Benchmarks at the “Level 1 – Server” configuration profile.

Where the application of the full CIS benchmark is not possible, the following should be considered as a minimal set of baseline security controls:

•     Set strong passwords for administrative accounts
•     Change other default passwords as applicable
•     Disable guest accounts and unnecessary network services
•     Protect the system from the public internet using either a host-based or network-based firewall
•     Stay current with vendor-provided security patches

Anti-Malware Exemptions

Although the Collector has undergone rigorous security testing before release, its traffic patterns may look suspicious to anti-malware tools such as heuristic antivirus or intelligent endpoint detection and response services. Although the LogicMonitor Collector binaries are signed by a widely trusted root CA if you elect to run such software on Collector systems, be aware that it may interfere with the Collector’s operations and will require an exemption.

Symptoms of anti-malware interference include frequent Collector service restarts and process crashes. Although not recommended, you can configure a recursive exclusion for the LogicMonitor Collector application directory. The default directories which require a recursive exclusion are as follows:

Windows: C:\Program Files\LogicMonitor\

Linux: /usr/local/logicmonitor/

See the following resources for more information on setting exclusions in common anti-malware packages:

•     Symantec Endpoint Protection: Excluding a file or a folder from scans
•     ESET: Exclude files or folders from scanning in ESET Windows home products
•     Sophos: Global Exclusions
•     FortiClient: Managing the AntiVirus exclusion list

Vulnerability Scanning and the Collector

The Collector is a Java application and is run under a (Java Runtime Environment) JRE included with the Collector installer. Historically these were based upon the Oracle JRE though more recent versions include a JRE based on the OpenJDK standard.

Invariably, security researchers eventually discover defects and vulnerabilities in seemingly every JRE release. Although the LogicMonitor Collector is essentially never affected by the types of security issues discovered in the JRE, we address these issues proactively by including the latest stable JRE version with each Early Access Collector release. 

If your vulnerability scanning system does identify potential security issues with the JRE these can safely be ignored. Any security vulnerability that could be exploited by the Collector’s operations would be addressed before release as part of our acceptance testing processes. Alternatively, if you prefer not to ignore the notifications, reported vulnerabilities in the JRE can typically be addressed by updating your Collectors to the most recent version.

Additionally, LogicMonitor applications including the Collector are scanned daily for software-level vulnerabilities. As you install the Collector package on your filesystem, you may detect Software Composition Analysis (SCA) vulnerabilities in the directory path. If you have already installed the latest Collector version, rest assured that you will always be up-to-date on our latest security fixes, which later can have new vulnerabilities that will be addressed in a future release. This is a continuous cycle given that vulnerability information itself is changing continuously which LogicMonitor is constantly analyzing and addressing.

For more information on Collector release versions, see Collector Versions.

Collector Updates

LogicMonitor typically updates the Collector software every 3 to 4 weeks. We recommend updating the installed collectors to the latest release to have all the latest functionalities, security improvements, and bug fixes. Check Release Notes to see the latest versions and subscribe to the updates.

Also, once a year a MGD (Mandatory update) will be released. Going forward, the MGD becomes the minimum required version. To let customers upgrade collectors at their convenience, we send a communication at least 30 days before the scheduled auto-upgrade date. On the auto-upgrade date, we upgrade only those collectors which are still below the MGD version. 

The action you should take:

• Ensure you are running the latest version of Collector software

For more information on collector versions, see Collector Versions.

Additional recommended portal security settings

Configuration Location	Attribute	Recommended Setting	Notes
Portal Settings	IP Allowlisting	Enabled	Limits access based on IP address, IP Range, IP Mask, or Hostname
Single Sign On	Allow Single Sign On	Enabled	Enables customers to manage the user identities with access to their LogicMonitor portal
Single Sign On	Restrict Single Sign On	Enabled (If “Require Two-Factor Authentication for all Roles and Users” is Disabled)	Customers may have reasons to not have SSO EnforcedRecommend enabled if 2FA is not enforced
Portal Settings	Require Two-Factor Authentication for all Roles and Users	Enabled (If “Restrict Single Sign On” is Disabled)	This is only available if “Restrict Single Sign On” is not enforced
Portal Settings	Require Two-Factor Authentication for Remote Session	Enabled (if “Enable Remote Session” is Enabled AND “Require Two-Factor Authentication for all Roles and Users is Disabled)	This is only applicable if “Enable Remote Session” is Enabled
Portal Settings	User Session Timeout	<= 8 hours	A lower value helps minimize the probability of user account abuse
Portal Settings	Suspend user after N days of inactivity	>0, <=90 days	A lower value minimizes the probability of compromise of unused accounts
Portal Settings	Disable API tokens after N days of inactivity	>0, <=365 days	A lower value minimizes the probability of compromise of older API accounts
Portal Settings	Email domains allowlist	Enabled	Enforces email destination to only those domains authorized by the customer
Portal Settings	Enable Test Script	Disabled	If this functionality is required, it should ONLY be enabled as needed and then disabled
Portal Settings	Remote Session	Disabled	If this functionality is required, it should be used according to the principle of least privilege.  Note that the Remote Session feature can be controlled at the account-wide level, Collector level, and user level.  For more information, see Remote Session.
Portal Settings	Allow scripts in a dashboard text widget	Disabled	Scripting is a powerful feature and should only be enabled when needed
Portal Settings	Allow Shared Reports	Disabled	Restricts report access to only logged-in users
Portal Settings	Enable Collector Debug	Disabled	Collector Debug is a powerful feature and should only be enabled when needed
Portal Settings	Enable Keep Me Signed In	Disabled	Minimizes login sessions active at any given time
Portal Settings	Keep Me Signed In days limit	>0, <= 30 days	Only applicable if “Enable Keep Me Signed In” is Enabled