API Tokens can be used to authenticate requests to LogicMonitor’s REST API. API Tokens (LMv1 and Bearer tokens) enable you to control which users in your account use the REST API and monitor how often they use it. For security best practices in using API Tokens, see the following content:

• Generate Tokens on API Only Users
• Determining API v3 Swagger Permissions
• Apply the Principle of Least Privilege
• Use of API Tokens in Client Applications
• Managing API Tokens

API tokens serve as credentials for authenticating and authorizing API requests. When using API tokens, follow these practices:

• 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. Search LogicMonitor’s Audit Log for related events.
• 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 developers and users about the importance of API token security and best practices for handling them.

Unless you are using an API endpoint that requires these permissions, we recommend you avoid generating API tokens with them without explicit thought as they provide access which can pose a higher risk if misused:

*We recommend scoping your Resource access rather than providing access to All Devices.

This principle relates to the that every API token should have the minimum level of access necessary to perform its tasks. Avoid granting broad permissions to users assigned API tokens; instead, provide specific permissions required for each task or API endpoint. This minimizes the potential damage that could occur if a token is compromised.

LogicMonitor no longer allows generating API tokens assigned to users with the out-of-the-box Administrator role. For other out-of-the-box roles to consider aside from the Administrator role, LogicMonitor installs three other roles with fewer available permissions that can be considered:

• Readonly: The readonly role assigns view permissions to all platform areas; it provides no ability to make changes to the platform, with one exception: users with this role can create private dashboards.
• Ackonly: The ackonly role assigns view, acknowledge, and SDT permissions for alerts for all hosts and websites. It also includes permissions for managing device dashboards and creating private dashboards. Note: This may be named acksdtonly in older portals.
• Manager: The manager role assigns almost the same permissions as the administrator role, except for security-sensitive actions.

Additionally, LogicMonitor no longer allows generating API tokens assigned to the lmsupport user. This is unintended functionality being deprecated, as tokens should be assigned to users under your control instead of the support account used for troubleshooting and assistance.

LogicMonitor recommends you create a custom Role with the minimum permissions required. Additionally, we recommend every year to review permissions that are granted to API tokens.

LogicMonitor REST API v3 Swagger documentation contains a complete list of v3 API endpoints and Models related to the endpoints. You can expand each API endpoint to explore the details. It contains request and response parameters with examples and descriptions. For more information, see v3 Swagger doc.

The v3 APIs should be used instead of the v1 and v2 APIs as these are being sunset, for more detail on this see LogicMonitor REST API v1 and v2 Sunset.

These permissions apply to each API category, along with the location of the permission itself within UIv4.

LogicMonitor provides the ability to create an API Only user. For more information, see Users.

If toggled on, this option will allow the creation of a user only capable of API access. For such a user, only the Username, API Tokens, Roles, Status, and Notes fields are relevant. API-only users don’t have passwords or other user interface-specific fields, making them a more secure option if you create a dedicated user for an API-based integration. This is highly recommended instead of generating tokens associated with your normal login users.

Beginning December 9, 2021, a number of critical security vulnerabilities have been disclosed by the Apache Log4j project. For more information, see https://logging.apache.org/log4j/2.x/.

LogicMonitor has conducted a methodical evaluation of our exposure to these vulnerabilities and determined that the LogicMonitor platform is not affected. While we are aware that recent versions of the LogicMonitor Collector include affected versions of the log4j component, the Collector architecture has been purposely designed to mitigate such vulnerabilities. Because of this, we are confident that the log4j vulnerabilities are not materially exploitable within our customers’ environments.

However, we strongly recommend that you upgrade to GD 31.003 which addresses the security vulnerabilities by updating to log4j 2.17.1. For instructions on how to upgrade a Collector, see Managing Collectors.

On January 20, 2022, all Collectors version 30.001 or earlier will be automatically upgraded to MGD 30.002, which also addresses the log4j vulnerabilities. No action is required ahead of this date. You may upgrade to MGD Collector 30.002 before January 20 or you may wait for the automatic upgrade to occur. For more information, see MGD Release Update.

Overview

Before you can use the Microsoft Azure Active Directory (AD) IdP for Single Sign On (SSO), you must add the LogicMonitor app to Azure AD and configure the SSO integration.

Adding the LogicMonitor App to Azure AD

1. Sign in to the Azure portal and navigate to Azure Active Directory.
2. On the left navigation pane, select Enterprise applications and then select All applications.
3. Select New application.
4. From the Browse Azure AD Gallery page, enter “LogicMonitor” in the Search application field.
5. Select LogicMonitor from the results and then click Create.

The app is added to your tenant.

Configuring Azure AD SSO for LogicMonitor

1. In the Azure portal, navigate to the LogicMonitor app you just added.
2. Click Set up single sign on.

3. From the Users and groups page, add the users or user groups that will use SSO to log in to your LogicMonitor portal.
4. Select SAML as the single sign on method.
5. From the Basic SAML Configuration pane, click Edit.
6. Enter the following information:
   • Identifier (Entity ID)—The URL of your LogicMonitor portal
   • Reply URL (Assertion Consumer Service URL)—The following URL, replacing “yourportalname” with the correct name of your LogicMonitor portal: https://yourportalname.logicmonitor.com/santaba/saml/SSO/
   • Sign on URL— For more information, see the Entering the Sign on URL section.

7. Click Save.
8. Select the User Attribute & Claims.
9. Select Add a group claim.
10. Select the group options. For information on group options, see Add group claims to tokens for SAML applications using SSO configuration.
11. You can configure group claim to include the group display name for the cloud-only groups. For more information, see Emit cloud-only group display name in token.

12. Click Save.
13. Download the Federation Metadata XML file.

For information on how to configure SSO if you are using Microsoft Azure Active Directory (AD) IdP, see Single Sign On.

Entering the Sign-On URL

Use case 1: Disabled Multi Idp Support

If you have disabled the Multi Idp support option, enter one of the following URLs in the Sign-on URL field:

https://COMPANYNAME.logicmonitor.com/santaba/saml/login?userDomain=&url=
or
https://COMPANYNAME.logicmonitor.com/santaba/saml/login
or
https://COMPANYNAME.logicmonitor.com/santaba/saml/login?userDomain=USERDOMAIN&url=

Use case 2: Enabled Multi Idp Support

If you have enabled the Multi Idp support in Settings > User Access > Single Sign On. Enter the following URL in the Sign-on URL field:
https://COMPANYNAME.logicmonitor.com/santaba/saml/login?userDomain=USERDOMAIN&url=



Note: The <userDomain> must match with the domain name mentioned in the LogicMonitor SSO configuration.

Configuring LogicMonitor SSO for Azure AD

1. In the LogicMonitor portal, navigate to Single Sign On from the Settings menu.
2. Select the Enable Single Sign On checkbox.
3. Select a role from the Default Role Assignment dropdown menu.
4. From the Identity Provide Metadata, click Upload and select the XML file you downloaded in the previous section.
5. (Optional) To force users to authenticate using SSO, select the Restrict Single Sign On checkbox.
6. (Optional) Select a number of days to allow users to remain signed in for.
7. (Optional) Enable Single Logout (SLO).
8. Click Save.

Testing the Integration

1. In the Azure portal, select Single sign on from the left navigation pane.
2. From the Test single sign on with LogicMonitor panel, click Test.
3. Select Sign in as someone else.

4. When prompted, log in as a user who was assigned the LogicMonitor app in Azure AD.

If the integration was configured correctly, the user is logged in to the LogicMonitor portal and a new user is created in LogicMonitor with the default role you selected in the previous section.

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.

LogicMonitor Portal Certificate Renewal

LogicMonitor proactively manages certificate renewals for all portals. Certificates are renewed per LogicMonitor’s policies and before the expiration date, ensuring uninterrupted access and security. No action is required from your organization.

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

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

To log in to your LogicMonitor account after two-factor authentication has been enabled, enter your username and password.

For more information about enabling two-factor authentication, see Two-Factor Authentication in Security Settings.

You will be asked to select a two-factor authentication method:

1. Verify using a Multi-Factor Authenticator App (Recommended)
2. Get a Code Texted to
3. Get a Code via Phone Call to
4. Get a code via email [default option if no other options are available to the user]

1. Verify using a Multi-Factor Authenticator App (Recommended)

If you want to verify two-factor user identity using a Time-Based One-Time Password (TOTP) token. In that case, local users can add any authentication application that adheres to the TOTP RFC standard such as Okta, Google Authenticator, or Authy.

To register a user with an authentication app, the following steps must be followed:

1. Go to Profile > Setup 2FA app
   
2. Select Confirm to continue setting up 2FA.
3. Scan the QR code using an Authentication App or enter the Secret Key into the Authentication app.
   
4. Enter the code displayed on the Authentication Application.
   
5. Once you get a verified message, select Done.
   
6. You will get a confirmation for successful registration. Next time the user logs in, they will see the option to use an authenticator app to verify their identity.
   
7. (optional) To verify if the user has been registered for 2FA, go to Settings > User Access > Users and Roles > Users. Under the 2FA app column, you will see Configured orNot Configured.

2. Get a Code Texted to

1. Choose Get a code texted to and select Get Code. You will send an SMS text containing a verification code to the mobile device phone number in your LogicMonitor user account.
   
2. Once you receive the code, enter it into the LogicMonitor Check your phone page.
   
   
3. Select Continue. You will receive a success message and select continue to login. 
   

3. Get a Code via Phone Call to

1. Choose Get a Code via Phone Call to this option and Select Get Code. You will receive a phone call at the mobile device on file in your LogicMonitor account.

        2. Once you receive the code, simply enter it into the LogicMonitor Check your phone page.

          3. Select Continue. You will receive a success message and select continue to login. 

4. Get a code via email [default option if no other options are available to the user]

1. Choose Get a code via email and Select Get Code. You will send the 2FA code to your email when you select Get Code.
   
   
2. Check your email and enter the 2FA code, select Continue.
   
3. After continue you will be logged in or if an invalid code was enter, it will fail and present a prompt from the browser. 

For more information about enabling two-factor authentication, see Portal Settings.