Security Event Manager Appliance Security and Data Protection

solarwinds_worldwide_llc over 9 years ago 4 minute read time

Here on the Security 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 SEM'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

SEM 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 SEM 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), SEM 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

SEM’s web console provides a secure read-only view of data and access to SEM’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).
SEM 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 SEM 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 SEM as if it were unmodified.
All access via SEM’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 SEM appliance is insert-only, only removed to make room for new data and never “updated” or edited (except accumulated metadata).
Access to SEM 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 Security 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.

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.

SEM 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 SEM 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.