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 their implementations, and it is incumbent upon our customers to operate these controls in alignment with the security requirements of their organizations. Similarly, the foundational security of our Collectors is based upon the 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 encourage our customers to review the following security best practices and apply those in accordance with their risk appetites.

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 1.3 encryption. Sensitive customer data—such as operating system versions, SNMP community strings, API passwords, device configuration files, NetFlow data, and personal data about your end users—is automatically encrypted prior to 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 immediately resolve any defects found by these professional hackers.

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 certification and AICPA SOC2 Type 2 compliance.

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.

As a general rule, you should limit the assignment of the “Administrator” role to as few individuals as possible. Instead, we recommend the use of the “Manager” role for individuals’ day-to-day access. The primary difference in these roles is that “Manager” does not have the ability to run arbitrary scripts on the Collector, either through the Collector Debug facility or by creating/editing LogicModules.

Alternately, you can create your own roles and apply least privilege based on the level of access that best fits your deployment structure and requirements. But as an overall philosophy, we recommend that manage permissions to LogicModules and Collectors are applied conservatively.

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

End-User Authentication

LogicMonitor supports end-user authentication using either our “stock” userid/password system or SSO via integration with your SAML v2 compliant Identity Provider (IdP).

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

Our in-product two-factor authentication is not available when using our SAML integration. Instead, you can configure IdP to require a particular level of assurance—such as a second authentication factor—for SAML assertions sent to LogicMonitor. Just as with our stock authentication, we recommend that you configure your IdP to require two-factor for end-users assigned to privileged roles.

Network Access Allow List

Many of our customers access their LogicMonitor portals only from systems residing within their corporate networks. Where this is the case we recommend using our network allow list feature, which limits access to your portal from a pre-populated set of IP address ranges. Although your portal has built-in protections against brute-force authentication attacks, defining an allow list provides a more complete line of defense. For more information on defining an allow 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) prior to accessing your portal.

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.

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 approximately 20 failed attempts.

Collector Security

The LogicMonitor Collector has been carefully designed and developed with high security in mind. All communications made by the Collector are outbound: either within your LAN to the devices it has been assigned to monitor, or outbound to the LogicMonitor platform. See About the LogicMonitor Collector for details on the specific TCP and UDP port numbers in use.

The Collector uses publicly signed certificates to authenticate the LogicMonitor platform; and the platform authenticates the Collector via a strong credential which undergoes regular rotation. This mutual authentication process, coupled with TLS encryption of the traffic, protects against any possible man-in-the-middle attack between the Collector and the LogicMonitor platform.

In the course of normal operation, Collectors receive a payload of “metadata” for each device they are assigned to monitor. This metadata includes the hostname, access credentials, and specific LogicModules which need to be applied. This device metadata is treated as sensitive and is stored only in memory. Note that in their default configuration, Collectors may cache health and performance data they have collected by writing this data to disk. This data is not typically considered sensitive, but the feature can be disabled as necessary, as discussed in Collector Caching.

Operating System Hardening

Even though the Collector has been designed with security at 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 prior to release, its traffic patterns may look suspicious to anti-malware tools such as heuristic antivirus or intelligent endpoint detection and response services. If you elect to run such software on Collector systems, be aware that it may interfere with the Collectors operations and will require an exemption.

Symptoms of anti-malware interference include frequent Collector service restarts and process crashes. To avoid these issues, you will need to 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. For Collector release versions and details, see Collector Versions.

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 prior to release as part of our acceptance testing processes. Alternately, 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.