Here on the Log & Event Manager product team we often get questions about how we maintain our appliance and ensure integrity of the data we collect. We previously published this KB article, but this post includes a quick recap of the critical areas relevant to LEM's end-to-end security.

 

This diagram is a good overview of the specific areas of interest, with even more detail in the sections below.

LEM security diagram2.png

 

Hardened Operating System

 

LEM applies security elements at just about every level to include the OS. Since the product is deployed as a virtual appliance, several security measures are applied at the OS level to include:

 

  • A Debian Linux core operating system with all unnecessary ports, protocols, processes and services/daemons disabled.
  • Operating system and application maintenance is performed regularly with LEM upgrades, for both security and stability updates.
  • No root level access – in fact, all passwords are randomly generated per-appliance, and even our internal teams don’t have knowledge of them in advance.
  • Minimal access to the appliance - only via virtual appliance console or SSH.
    • For low level appliance configuration (including things like networking and backup configuration), LEM includes a menu driven command line interface that requires a username/password via SSH over a nonstandard port.
  • Remote configuration access can also be disabled or restricted by IP address, and an appropriate usage banner can be displayed.
  • Internal logging and auditing.

 

Web Console Security

 

LEM’s web console provides a secure read-only view of data and access to LEM’s configuration. This access can be restricted and further secured.

 

Security features applied to the web console include:

  • Encrypted Console access that is certificate based over secure HTTP
    • Option to deploy a CA-signed certificate in addition to the included self-signed certificate
    • Option to disable HTTP access in favor of only HTTPS
  • Additional console access limitation applied on a per IP basis.
  • Local or Active Directory users with role based access. The roles available are:
    • Administrator - Users who have full access to the features and capabilities within the web console.
    • Auditor/Guest - Users who have extensive view rights to the system, but cannot modify anything other than their own filters.
    • Monitor - Users who can access the Console, but cannot view or modify anything, and must be provided a set of filters.
    • Contact - Users who cannot access the Console, but do receive external notification.
    • Reports – Users who can only run Reports, but cannot access the Console for real-time monitoring.
  • Password complexity requirement for local users (AD users inherit AD policy).
  • LEM active responses are pre-configured and not "open" scripted (and don't accept input on the client-side).

 

Data Storage Security

 

The crux of securing the LEM appliance is ensuring the data cannot be altered. To that end the following measures have been applied:

 

  • Data storage is encrypted and hashed – should access to the appliance be breached, data can’t be tampered with and served back to LEM as if it were unmodified.
  • All access via LEM’s tools to data storage is read-only, ensuring that data cannot be altered regardless of the role assigned to the user.
  • Data added to the LEM appliance is insert-only, only removed to make room for new data and never “updated” or edited (except accumulated metadata).
  • Access to LEM reports can be further restricted by IP address and leverage certificate-based TLS communication.

 

Log Collection Security

 

As logs are collected, chain of custody is ensured – again, to prevent as much tampering as possible.

 

  • Logs are collected on the agent as close to real-time as possible, ensuring data lives on disk a minimum amount of time.
  • Windows Event Log data is collected using the Event Log API, not relying on data to be written to disk to be collected.
  • Where appropriate, LEM tools avoid collecting personally identifiable information. SQL Auditor, for example, does not include full queries and responses, which could have personal data in either the statement or the response.
  • Logs collected using the Log & Event Manager agent are protected in transit with FIPS-approved TLS/SSL encryption algorithms.
  • When communication is interrupted, data is buffered to disk in a binary format, not the original modifiable log content.

 

Archives

 

Security is not limited to the data that sits on the Virtual Appliance. In the event archives are used and need to be restored, their integrity is also maintained.

 

  • Database and log archives are encrypted and hashed to prevent tampering

 

Internal Auditing

 

Detailed auditing of all appliance activity is enabled by default, and can be leveraged in both alerts and reports. This includes:

 

  • Change Auditing - All changes to rules, reports, filters, searches, widgets and other internal element.
  • Access Audit - Successful and Failed attempts to access the web and reporting console.
  • Rule Activity – Any rule that fires creates a full audit trail of the actions taken.
  • Report Activity – Any time a report is generated automatically or manually.
  • Search – All search activity is recorded and includes the source IP and username.
  • Built-in audit reports that can be scheduled and reviewed.

 

SolarWinds Security Processes

 

Our internal security practices are leveraged with every product release.

 

  • LEM is Common Criteria certified, which includes both product and processes
  • Vulnerability scans are ran during the product development cycle and reported issues addressed
  • Time is allotted during each release cycle to include security updates, patches, and fixes
  • Internal response plans to assess critical vulnerabilities (like Shellshock), reported external vulnerabilities, and reported customer vulnerabilities via your own internal scans

 

 

If you’ve got any questions about how LEM security is maintained, or any features we might have missed, let us know – another part of security is recognizing that our processes must be constantly improved.