Blog Post

Tech Talk
4 MIN READ

Important Security Announcement

A11ey's avatar
A11ey
Former Employee
6 months ago

Hello LM Community!

Important Security Announcement
As part of our ongoing commitment to enhancing security for our customers, LogicMonitor will be requiring stronger security measures to protect your account. This page is to serve as both an announcement and a landing page for resources you may need. Your account will need to be in compliance with the following security mandates by December 31, 2024, to avoid any disruptions to your service. 

Please review the items below, and take appropriate actions to ensure a secure experience with LogicMonitor.

Security Mandates

  • Two-Factor Authentication (2FA)
    • Summary: Two-factor authentication (2FA) provides an extra layer of security for accessing any LogicMonitor account. With this upcoming change, users not using SSO (Single Sign-On) will be required to use 2FA. This means, in addition to a username and password, users will need to verify their identity using a third-party application such as Authy, an authentication token delivered via SMS/voice, or authenticate via email.
    • Quick Reference Guide (QRG)  
    • Supporting Documentation:
  • Linux Collectors Least Privilege
    • Summary:  Previously, LogicMonitor required collectors to use root credentials to collect data from the resources it monitored. As part of our commitment to increasing security standards, and meeting the feedback of our customer base, with the release of GD 36, we have introduced the capability of collectors to run using non-root credentials. We ask that customers promptly change to non-root credentials, which will improve security and reduce risk. Moving forward, LogicMonitor is requiring all Linux collectors to be migrated to run under non-root users. Our enhanced migration process allows this transition without uninstalling the collector or losing any data. Customers can follow either the prompt-based or silent migration processes to complete the transition.
    • Quick Reference Guide (QRG)
    • Supporting Documentation:
  • Windows Collectors Least Privilege 
    • Summary: Originally, LogicMonitor required Windows collectors to run using administrator (admin) credentials to collect data from the resources it monitored. As part of our commitment to the highest security standards, we have continued to invest in security features and risk mitigation for our customers. We have now extended the capabilities of collectors to utilize non-administrator (non-admin) credentials for data collection. 
      Moving forward, LogicMonitor is requiring all Windows collectors to be migrated to utilize non-administrator accounts to monitor their systems. Our enhanced migration process allows this transition, without uninstalling the collector or losing any data. Customers can follow the prompt-based migration processes to complete the transition to non-administrator accounts.
    • Non-admin essentially means moving away from an excessively privileged account for monitoring.

      Update on the Windows Collectors Least Privilege Security Mandate:

      What happens at the end of the year if collectors are still using administrative privileged accounts for the collector service and query user?
      Based on our customers’ unique environmental landscape and needs, if the collector is still configured to use accounts with Administrative privileges on December 31, 2024, we will not prevent collectors from communicating with LogicMonitor. We do however strongly recommend you utilize non-administrator accounts to monitor your systems as our migration process allows this transition, without uninstalling the collector or losing any data. We understand that 100% compliance with a non-admin is not possible, if the technology you’re monitoring REQUIRES administrative privileges. Logic Monitor is currently reviewing the best options in order to limit the attack surface in these scenarios, while also minimizing disruptions. Once we have refined the solutions that best fit customers’ unique circumstances, we will provide ample timing for our customers to implement any required changes.The goal of this security mandate is not to dictate how customers manage Windows accounts, but rather to help our customers better adopt security best practices (Principle of Least Privilege), as it relates to the collector service user and collector query user.
  • API Tokens
    • Summary:  Roles within the LogicMonitor platform define the permissions and configurations that determine a user's interactions. The administrator role, in particular, grants permissions across all areas of the platform, enabling administrators to perform any action, including those that are security-sensitive.
    • REST API tokens are used to authenticate requests to the REST API, allowing users to programmatically manage their LogicMonitor resources, dashboards, devices, reports, services, alerts, collectors, datasources, scheduled downtime (SDTs), and more.
    • To enhance security and maintain the integrity of our systems, we disabled the ability for customers to create API tokens using LMSupport user accounts or the default administrator role. This restriction helps prevent unauthorized access and potential misuse of elevated permissions, ensuring that API keys are generated and managed within a controlled and secure framework.
    • The combination of out-of-box (OOB) admin permissions with the use of an API token poses significant risks, potentially leading to unauthorized actions and disruptions within an LogicMonitor portal. Therefore, if you have previously created an API token, using LMSupport user accounts or administrator roles, you need to migrate to a new API token created under a new user or role with appropriate permissions.
    • Quick Reference Guide (QRG)
    • Supporting Documentation:
      • API Tokens
      • API Best Practices Guide (coming soon!)

LogicMonitor Security Best Practices

If you have any questions or need assistance, please contact our Technical Support Team.

Updated 15 days ago
Version 13.0
  • christykoontz's avatar
    christykoontz
    Icon for Community Manager rankCommunity Manager

    Two-Factor Authentication (2FA)

    Will access to the lmsupport account be affected by the new security mandates?
    No. Requiring two-factor authentication (2FA) or enabling RestrictSSO will not impact LogicMonitor’s ability to access customer portals via an active lmsupport account. If you encounter any issues, please open a
    support ticket so that it can be addressed as a priority. Additionally, any phone number associated with the LMSupport account is not utilized for 2FA.

    What authentication methods can be used?
    The following authentication methods are available for 2FA:

    • SMS
    • Email
    • 2FA Apps (such as Authy)
    • Phone Call to LogicMonitor Support (yes, this is an accurate form of authentication)

     

    Will LogicMonitor support other 2FA apps than Authy?
    Yes. LogicMonitor is currently upgrading its 2FA processing infrastructure to support additional 2FA applications such as Okta, Google Authenticator, and Authy, alongside other ToTP applications. This upgrade is on track to be completed by the end of August 2024. In the meantime, customers can enable 2FA and authenticate via voice, SMS, or email. For further details on 2FA Account Access, please refer to this page

    How will the 2FA mandate impact shared user accounts for use cases such as shared reports or NOC dashboards?
    In order to align with security best practices, LogicMonitor does not recommend using shared accounts. For use cases which require broader access, such as shared reports or NOC dashboards, and where a phone may not be available, user accounts can be configured to authenticate via Single Sign-On (SSO), or utilize 2FA via email for authentication.

    How can I bulk add or update users to prepare for enabling 2FA?
    LogicMonitor's API can be used to perform bulk tasks or programmatically manage your account. If you need assistance with bulk actions related to this mandate, please contact LogicMonitor Support.

    Please refer to the below additional documentation for relevant endpoints for leveraging the API:
    https://www.logicmonitor.com/swagger-ui-master/api-v3/dist/#/Users/addAdmin https://www.logicmonitor.com/swagger-ui-master/api-v3/dist/#/Roles/addRole https://www.logicmonitor.com/swagger-ui-master/api-v3/dist/#/Users/patchAdminById

    How will LogicMonitor verify phone numbers for compliance reporting?
    Phone Numbers are not verified by LogicMonitor, however customers’ phone numbers will need to be both in your possession and match the number set on your user account, to successfully authenticate via 2FA using phone number options. Phone numbers are no longer required for 2FA setup with portal V209, and users can now use an email account to get 2FA codes.

    If the customer is using SAML is 2FA still mandatory ? Any suggestions on the approach?
    SAML users are out of scope for mandatory 2FA, as they authenticate through their IdP. However, to follow best practices, we strongly recommend that their IdP requires 2FA.

    If the customer enables 2FA for a local user, will the dashboard work after implementing 2FA?
    Yes it will work; The customer will need to configure a valid e-mail address or phone number on the user account, and use their preferred 2FA option to authenticate.

    With our new mandate for valid phone numbers, are SSO users required to have a phone number?
    For 2FA, yes, which predates the email 2FA availability. The phone requirement was a hold over, which is going away per DEV-173012.

    Linux Collectors Using Least Privilege (non-root) Accounts

    Will data collection be affected by moving to non-root accounts?
    The Linux Collector service account is not typically used to retrieve data from remote devices. Data Collection from core LogicModules will not be affected as most devices monitored via Linux collectors are using either SSH, SNMP, or other credentials set under device properties during normal circumstances. However, if there are any custom modules, it is advisable for customers to review them to ensure they do not require root permissions.

    Windows Collectors Using Least Privilege (non-admin) Accounts

    How am I going to remotely monitor domain controllers without credentials?
    Credentials will still be needed, however limited to an account without the Administrator group. One time admin credential will be required to move from admin to non-admin. Post that, to monitor and for data collection etc. explicit credentials (non-admin) can be maintained (as wmi.user and wmi.pass) or if not maintained, data collection etc. will occur through service account.

    Will LogicMonitor provide a detailed list of requirements for access?
    Yes. LogicMonitor provides comprehensive documentation to guide you through the required configurations and permissions for access. Here are the key resources:

    • Windows Server Monitoring and Principle of Least Privilege:
      • Required Non-Admin Configurations: This document describes the necessary non-admin configurations for Windows Server monitoring, covering both WinRM and DCOM/WMI. It includes detailed descriptions of the groups and permissions involved. The document lists all the steps, and introduces the Windows_NonAdmin_Config.ps1 script, which automates these steps. Customers can use this document to understand the permissions being granted, perform manual configurations, or apply the script locally on each device, depending on their use case.
    • Migrating Windows Collector from Admin to Non-Admin User:
      • Migration Guide: This document focuses on migrating the Collector service account from admin to non-admin user. The script remains the same as earlier, however the use case for this document is for the service account only.
    • Configuring WinRM for Windows Collector:
      • WinRM Configuration: This document focuses on configuring WinRM for Windows collectors. It includes an introduction to WinRM, setting up an HTTPS listener, and detailing WinRM-specific properties in the agent.conf and sbproxy.conf files on the collector. The latter part of the document provides steps to automate the Windows non-admin configuration centrally through a Group Policy Object (GPO), using the same script, but applied via GPO, instead of manually on each domain device.

     

    How will this affect cross-domain trusts for monitoring? 
    Cross-domain monitoring should be possible by whitelisting the necessary domains in the trusted hosts list.

    Can collectors still be run as a local service account?
    Yes, collectors can still use local service accounts. We advise against using the local account (NTAuthority). Per the mandate, we encourage the use of a local non-admin service account, if you would like to use a local account. The collector installer itself will allow for this for the time being.

    Will I need to update LogicModules before or after making changes to the collectors?
    No, core LogicModules won’t be affected by the changes, and will not require any updates. However, if there are any custom modules, it is advisable for customers to review them to ensure they do not require administrator permissions.

    If I’m an MSP, how do I delegate this to each of my accounts?
    For MSP accounts, collectors are usually installed in the individual domains of each customer. Therefore, you will need to obtain the end customer’s approval and assistance to make any changes to the permissions related to the monitoring account. We recommend providing a list of collector IDs that will need to be migrated so these efforts can be coordinated. If you require assistance identifying which collectors are using administrator accounts, please contact LogicMonitor Support Team.

    Are there instructions for organizations that have 400+ windows servers? Does this complicate onboarding of new Windows Servers, since the same process would need to be completed for each new server being monitored?
    Please use the process outlined in the WinRM guidance to automate via GPO: https://www.logicmonitor.com/support/configuring-winrm-for-windows-collector#h-automating-winrm-non-admin-configuration

    For making the SDDL changes in the least privilege documentation, for the WMI Namespace Security, and Windows Service permissions, do these steps need to be performed on each of the collectors, on all monitored servers, or just once from a single server?
    For non-domain based setups, the steps can be completed on each machine. For Domain based setups, it is convenient to complete it via a GPO policy.

    For the Windows admin mandate, does this also apply to accounts specified with wmi.user/wmi.pass?
    The first target is to move the Collector service user (user account under which collector service runs) to a non-administrator account.

    When we allowed access to the WMI user on SCManager, we were able to query several windows services, but not various application services. Are the same steps to be followed for each service? Is it expected to get access to services other than SCManager? How are we able to query several services after enabling access on SCManager?
    The current script gives permissions to services not just under SCManager, but also to other services which are fetched currently in our script: $Services = Get-Service | Select-Object Name (basically Win32_Services), and also two (2) services, logicmonitor-agent and logicmonitor-watchdog. If any specific service is not covered in the above pool, then for that we have provided manual steps, which need to be followed on all the resources involved. Please see this supporting documentation for further details.

    Deprecation of Using LM Support and Default Administrator Role for API Usage

    Can you provide me with active API tokens that are currently built using the lmsupport user account?
    You can find details on active API tokens and their last usage information in the UI display tabs for "LMv1," "Bearer," and "Widget" tokens. Follow these steps:

    • Go to Settings
    • Access "Users and Roles" under "User Access"
    • Navigate to "LMv1 API Tokens" and filter based on "lmsupport" to see all LMv1 API tokens associated with the "lmsupport" user.
    • Navigate to "Bearer Tokens" and filter based on "lmsupport" to see all Bearer Tokens associated with the "lmsupport" user.

    For the usage details of those API tokens, refer to the audit logs. For more information, visit API Tokens.

    How do I get better logging of systems that are connecting to LogicMonitor via the API to find where I need to make updates?
    You can use the LM Portal Audit Log to determine the source IP address and API detail information. This will help you track down where to look for updates, or where the token might be utilized. For more information, please visit the Audit Logs Report.

    If LogicMonitor team members built an API token with the lmsupport account on our behalf, how do I know if it is still needed?
    You can check the “API Tokens” tab under “Users & Roles” in the LogicMonitor Portal, and review the “Last Used” date. If this field is empty or shows a non-recent date, you can consider disabling and later deleting the token, once it's confirmed to be non-impacting..

    How am I supposed to programmatically create and deploy collectors or user accounts without administrator rights to the API?
    LogicMonitor only requires customers to migrate to a token that is not under the lmsupport user account, or using the default administrator role. Customers can still create roles specific to their needs which allow managing permissions for both collectors and user operations. This way, you can programmatically create and deploy collectors or user accounts, while adhering to security best practices.

    Will LogicMonitor introduce an automation API token type?
    Currently, an “API Only” user can be created and assigned API tokens. For more details, please visit LogicMonitor Users and Roles.