Built-In Security for Appliances and Data

Download this manual as a PDF file

SL1 is specifically designed to provide a secure environment for monitoring your network. This section describes the security features included in SL1.

Use the following menu options to navigate the SL1 user interface:

  • To view a pop-out list of menu options, click the menu icon ().
  • To view a page containing all of the menu options, click the Advanced menu icon ().

Hardened Operating System

Each SL1 appliance includes a hardened version of the Linux operating system that is designed and engineered for high-security deployments. For example:

  • The operating system installs only those software packages that are required.
  • The operating system operates under a strictly limited or minimum number of ports open.
  • The operating system updates are owned by ScienceLogic
  • All data in transit between SL1 appliances is encrypted.
  • Insecure protocols such as, FTP, Telnet, and Rlogin, are disabled by default

Limited Open Ports

Each SL1 appliance uses a strictly limited number of ports. For the list of current required ports, see the section on Required Ports.

Firewalls and White Lists

SL1 includes multiple features that tightly control access to SL1 appliances.

Each SL1 appliance includes a built-in firewall. For Data Collectors and Message Collectors, the firewall allows communication to the central database only from other SL1 appliances. Even communication between other SL1 appliances is limited with the ScienceLogic "store and retrieve" architecture.

The built-in firewall for each SL1 appliance allows users to create "white lists". For example, because each Data Collector can be placed in an unsecured part of the network, the built-in firewall defines a very limited number of communications that will be accepted by the Data Collector. These limited communications make up the "white list" for each Data Collector. Devices that are not part of the white list cannot communicate with a Data Collector.

SL1 also allows administrators to create white lists for web access. System administrators can specify that users can connect to the user interface only from specified IP addresses. System administrators can also create "black lists" and prohibit web access (to a SL1 System) based on user name, the user's IP address, or both.

For example, suppose the system has performed the initial discovery session to discover the devices in your network. Suppose a device that was not discovered tries to connect and send information to a Data Collector, Message Collector, or All-In-One Appliance. The system will block the connection and incoming data. ScienceLogic firewalls and white lists prevent rogue devices from connecting to a SL1 appliance and sending information. SL1 Appliances accept asynchronous traffic only from devices that have been discovered in a discovery session.

Hardened Configuration on Each Appliance

Each SL1 appliance is configured to maximize security and minimize security risks.

Root Access

The ScienceLogic platform has been designed to operate without root privileges and command line access. By customer request, root access is enabled on all appliances. ScienceLogic strongly recommends that the root account be secured and enabled only when necessary for troubleshooting or custom configuration tasks. To disable root access, see the section on Changing Passwords and IP Addresses.

API

  • The API provides a single point of communication between an external site and the Database Server. The API insulates the Database Server; the external site cannot communicate directly with the Database Server but can communicate with the API.

All-In-One

  • The All-In-One Appliance supports TLSv1.2 services for secure sign-on.
  • Administrators can require that browser access to the All-In-One Appliance be authenticated and sent over HTTPS.
  • Administrators can require that authentication checks the originating IP address, to control where client requests originate during user login.
  • Users can be authenticated via LDAP, Active Directory (using the LDAP/Active Directory integration features), SSO, or by local SL1 authentication.
  • SL1 has built-in support for multi-factor authentication (MFA) using RSA SecurID.
  • Administrators can configure the All-In-One Appliance to use DoD certificates or your own certificates. You can install server-side certificates on the ScienceLogic All-In-One Appliance and then authenticate access to the All-In-One Appliance with a CAC or a client-side certificate associated with a user's web browser.
  • System administrators can also define blacklisting and whitelisting to further control access to the All-In-One Appliance.
  • All-In-One Appliances use unique session cookies to validate client requests.
  • System administrators can finely customize user access to the All-In-One Appliance to create a multi-tenant environment that meets the needs of management, system administrators, NOC personnel, and customers and clients. Each type of user can view and access only the information that is relevant to them. System administrators can define user access per user or create access templates to apply to each type of user.

Administration Portal

  • The Administration Portal supports TLSv1.2 services for secure sign-on.
  • Administrators can require that browser access to the Administration Portal be authenticated and sent over HTTPS.
  • Administrators can require that authentication checks the originating IP address, to control where client requests originate during user login.
  • Users can be authenticated via LDAP, Active Directory, SSO, or by local SL1 authentication.
  • Administrators can configure the Administration Portal to use DoD certificates or your own certificates. You can install server-side certificates on an Administration Portal appliance and then authenticate access to the Administration Portal with a CAC or a client-side certificate associated with a user's web browser.
  • System administrators can also define blacklisting and whitelisting to further control access to the Administration Portal appliance.
  • Administration Portal appliances use unique session cookies to validate client requests.
  • System administrators can finely customize user access to the Administration Portal to create a multi-tenant environment that meets the needs of management, system administrators, NOC personnel, and customers and clients. Each type of user can view and access only the information that is relevant to them.
  • The Administration Portal appliance communicates only with the Database Server appliance and no other SL1 appliance. All connections between the Administration Portal and the Database Server are encrypted in both directions.

Database Server

  • The Database Server initiates one-way communication with Data Collectors and Message Collectors through "data pull". Data pull uses a single TCP outbound port.
  • The Database Server receives inbound communication only from the Administration Portal. All connections between the Database Server and the Administration Portal are encrypted in both directions.
  • The Database Server uses X509 certificates with RSA 2048 encryption to establish sessions and authenticate communication with other SL1 appliances.

Data Collectors and Message Collectors

  • All communication between Data Collectors and Message Collectors and the Database Server is initiated by the Database Server and is unidirectional.
  • On the Data Collectors and Message Collectors, only port 7707 is used for communication with the Database Server. The Database Server uses X509 certificates with RSA 2048 encryption to establish sessions and authenticate communication with Data Collectors and Message Collectors.
  • Communication between the Database Server and each Data Collector uses TLS v1.2 negotiated through the database connection protocol. Both client and server software use the secure binaries and libraries, which are built with OpenSSL and is not vulnerable to the Heartbleed vulnerability.

  • SL1 uses the DHE-RSA-AES256-SHA cipher for OpenSSL. Thus, SL1 uses ephemeral Diffie-Hellman key exchange with RSA key authentication, 256-bit AES, and SHA-2 message digests. The Data Collector uses a 2048-bit RSA key for certificate verification.
  • By default, there is no way for the Data Collector(s) or Message Collector(s) to initiate communication with the Database Server(s).
  • Data Collectors and Message Collectors store information about only the devices that the Collector Group is configured to monitor. If a Collector Group is not configured to monitor a given device in the platform, the database on the Data Collector or Message Collector will not contain any information about that device.
  • The SL1 agent collects data from the device on which it is installed and transfers that data to the appliance performing message collection (usually, a Message Collector) using the HTTPS protocol. TCP port 443 must be open between the device on which the agent is installed and the Message Collector. To transfer data gathered by the agent to SL1, a Data Collector polls the Message Collector with the HTTPS protocol.

Multiple Tenancy and Segregation of Duties

Account Types

ScienceLogic administrators can enforce segregation of duties using account types. The platform includes the following account types:

  • Administrator. A user who is automatically assigned all access privileges in the platform.
  • User. A user who must be assigned access privileges in the platform. Regardless of assigned Access Keys:
  • Users cannot modify administrator accounts.
  • Users cannot make themselves or another user an administrator.
  • Users cannot grant or remove Access Keys that they have not been granted.
  • External Contacts. People who can receive Emails sent from the platform but do not have user accounts.

For details on creating and configuring user accounts, see the section on Organizations and Users.

Access Keys

ScienceLogic administrators can enforce segregation of duties using access privileges. In SL1, Access Keys allow administrators to define highly granular, customized access privileges for regular users. Access keys define what each user can view in the platform and which actions each user can perform.

An access key has two parts: the access key definition and the access hooks that are aligned with the access key.

  • An access hook is a granular privilege. For example, an access hook might be called "View Asset." This asset hook would allow a user to view access records. The access hook would not allow a user to create, edit, or delete an asset record.

Access hooks cannot be directly granted to a user account. To grant the "View Asset" privilege to a user, the access hook must be included in an access key .

  • An access key is a group of one or more access hooks. When you associate an access key with a user account, the user is granted all the access hooks within the key. For example, you could create an access key called "Manage Asset". That access key could include three hooks: view an asset record, edit an asset record, and create a new asset record.

For details on defining and using access keys, see the section Access Permissions.

Segregation by Organization

ScienceLogic administrators can use organizations to enforce segregating of duties in the platform.

Regardless of access keys, accounts of type "user" can access only pages and actions associated with their organization. For example:

  • Suppose your organization includes three regional offices. Suppose you define three organizations: Northeast, Headquarters, and West Coast.
  • Suppose each organization includes the devices located at the corresponding office.
  • Now suppose the account "JohnDoe" is of type "user" and is a member of the organization "West Coast". User JohnDoe would be able to view and act upon only devices that are included in the organization "West Coast". User JohnDoe would not be able to view or act upon the hardware at the other offices.
  • For this reason, SL1 allows you to assign each user a primary organization and an optional additional organization.
  • Now suppose that user "JohnDoe" needs to view the status of a device at headquarters. If you add a secondary organization to JohnDoe's account information, that user will now be able to view and act upon all the devices in the "Headquarters" organization.

NOTE: You can still use Access Keys to limit the access of each user, even within his or her own organization.

Credential Management

Credentials are access profiles (usually user name, password, and any additional information required for access) that allow the platform to retrieve information from devices and from software applications on devices. These profiles allow the platform to access external systems while maintaining the security of the access accounts. Users who need the platform to retrieve data from these external systems see only the name of the credential, not the user name, password, and network information. All credentials are encrypted on the SL1system.

You can use Access Keys to restrict access to the credential definitions.

To further support multi-tenancy, SL1 allows you to align each credential with one, multiple, or all organizations. You can also align a credential with no organizations. When you align an organization with a credential, you control who can view details about the credential, who can view the name of the credential, and who can apply the credential.

NOTE: When you align an organization with a credential, you are restricting only the users who can view and assign the credential. You are not restricting the devices and actions that can be associated with the credential. For example, you can align a credential only with the organization "Operations" but assign the credential to a device in the "Finance" organization.

Credentials that are aligned with an organization have the following behavior:

  • For each credential that is aligned with an organization, only administrators and users who are members of the aligned organization will be able to see the credential in the Credential Management page.
  • In the user interface, in any field or column that displays the name of the credential, users who are not members of the aligned organization will not see the credential name. Instead, these users will see either a dash character (-) or the text "Restricted Credential".
  • In the user interface, in any list from which users can select a credential, users who are not members of the aligned organization will not see the credential as an entry in the list.
  • In the user interface, in any page where the credential has already been assigned, users who are not members of the aligned organization will see only the name "Restricted Credential".
  • In the user interface, in any page where the credential has already been assigned, users who are not members of the aligned organization can save the page and maintain the credential. The credential will still appear to that user as "Restricted Credential".
  • In the user interface, in any page where the credential has already been assigned, users who are not members of the aligned organization can change the credential to a credential aligned with their organizations. However, those users cannot change the credential again and re-assign the "Restricted Credential". The entry for "Restricted Credential" is removed from the list of possible credentials.

For details on credentials, see the section on Discovery and Credentials.

User Policies

You can easily manage multiple user accounts using User Policies. User Policies allow you to define a custom set of account properties and key privileges (from the Account Permissions page) and then save them as a policy, for reuse. When you create a user account, you can use the User Policy to quickly apply settings to the new account. User policies can help you to enforce roles and consistent SOPs when creating user accounts in SL1.

User Policies have a dynamic relationship with their member user accounts. You can make a change to a user policy and the platform will automatically update the account settings for each member account. For example, suppose you create a user account called "John Doe" on the first of the month and use the user policy named "NOC users" to create the user account. Suppose you create another user account called "Jane Smith" on the fifth of the month and use the user policy "NOC users". Suppose on the 15th of the month, you add an additional Access Key to the "NOC users" policy. That additional Access Key will appear in the account for John Doe and Jane Smith as soon as the "NOC users" policy is saved.

For details on user policies, see the section on Organizations and Users.

Protection Against Injections and Cross-Site Scripting (Penetration Tests)

ScienceLogic uses automated penetration tests that are included in the Quality Assurance process for each release. ScienceLogic uses a variety of scanning tools such as Nessus and Burp to detect vulnerabilities in the user interface and platform. The tools specifically look for the OWASP Top Ten Vulnerabilities such as, various XSS, SQL injection, broken authentication, and session management.

ScienceLogic validates the Top Ten Security Configurations using the most current version of Nessus. Items such as validating functional level access controls and updating modules with known vulnerabilities are currently checked in both manual and automated fashion.

Bi-annually, ScienceLogic contracts with independent, third-party penetration testers to provide independent penetration testing. These third parties conduct bi-annual tests on current and upcoming SL1 releases with the intent of constantly increasing our security posture in response to the expanding set of known vulnerabilities identified by industry experts. Additional corporate and SaaS penetration testing is performed on an annual basis.

In addition, ScienceLogic customers often perform additional penetration tests tailored to their unique requirements. These companies report their findings back to ScienceLogic’s security team for remediation.

ScienceLogic responds to the penetration tests performed by ScienceLogic and ScienceLogic customers with the appropriate fixes and updates.

ScienceLogic customers may request an executive summary of ScienceLogic's penetration tests, but ScienceLogic customers must have a fully executed Non-Disclosure Agreement (NDA) that is signed by both parties to have access to this documentation.

Operating System Scan

The SL1 operating system is scanned daily to identify new vulnerabilities. Potential vulnerabilities are evaluated by the security team to determine the likelihood and impact of exploit on SL1. If the security team identifies high and critical vulnerabilities, they are escalated to engineering for remediation within the defined time frame.

Data Integrity

SL1 performs the following to ensure the integrity of data:

  • Leverages the xfs journaling file system type for added resiliency
  • Automatically detects and self-corrects most sources of database corruption
  • Validates data before insert into the database.
  • Routinely checks the status of all required platform processes and automatically restarts those that have stopped

  • Collects data once, stores the data in an intelligent manner, and uses the stored data in multiple parts of the platform, without requiring the compute burden of multiple collection sessions. For example, SL1 collects bandwidth data once, but performs normalization for different timespans, using the same set of collected data.
  • Does not require a dedicated Database Administrator. The Database Server is designed to be self-pruning and self-correcting.

Backups

SL1 includes two levels of built-in, scheduled backups:

  • Configuration Backup. Stores a local copy of the core database tables that are required to restore an instance of the platform, and optionally transfers the copy to an external system.
  • The platform automatically launches this backup every day, at the time you specify.
  • Optionally, the platform can automatically transfer this backup every day to an external system, at the time you specify. Configuration backups can be saved to a remote server. Multiple secure protocols are supported for file transfers such as, SFTP site, Secure NFS mount, or SMB 3.0 mount.
  • Full Backup. For instances of the platform in small-to-medium businesses, full backup makes a full backup of the Database Server.
  • Full backup includes all configuration data, performance data, and log data.
  • After backup, the platform automatically copies the compressed file to a remote system. The compressed backup can be copied to an FTP site, SFTP site, NFS mount, or SMB mount.
  • To conserve space, the compressed file is then removed from the Database Server appliance or All-In-One Appliance.

For details on backing up your instance of the platform, see the section on System Administration.

Disaster Recovery and High Availability

SL1 includes multiple options for high-availability, including high-availability for Database Servers and Data Collectors. For details on these configurations, see the section on Architecture.

SL1 also includes a disaster recovery option for Database Servers and All-In-One Appliances. For details on disaster recovery, see the section on Disaster Recovery.

Audit Logs

SL1 includes detailed audit logs of all platform activity, including:

  • System Logs of all platform activity. For example, starting and stopping key processes, backing up key databases, purging old database records, and other maintenance activities.
  • Audit Logs of all actions in SL1 that are generated by user or managed entities, including all logins by users; creating, editing, or deleting of any data, reports, or policies; and all events.
  • Access Logs of all user activity within SL1, including logins, logouts, notifications, and actions executed.
  • Device Logs that include all messages collected from a device by SL1. These messages include information from syslog, internal alerts, traps, Dynamic Applications, and email messages.