Securing the host system

Each application or command on a system is potentially a security hole that could provide unauthorized users a way to get into the system.

The PingDirectory software has a minimal set of dependencies. As a pure Java application, its primary dependency is the Java Virtual Machine (JVM). However, troubleshooting and support data collection tools might rely on other operating system utilities to obtain information about the state of the underlying system.

Take steps to reduce the potential for compromise of network services, including:

Keep any software that can’t be removed from the system up to date.

Install all operating system security patches and software updates in a timely manner. Operating system and software updates do have the potential to cause unforeseen problems. Thoroughly test all updates in a staging environment before production.

Monitor security-related mailing lists and news feeds, and consider following security experts on social media. The sooner you know about operating system or software vulnerabilities, the sooner you can take action to minimize the exposure while waiting for and testing the appropriate patches.

The most basic forms of filesystem protection are file permissions and filesystem encryption. Any portion of the filesystem that contains sensitive data should be accessible only to the account used to run the server.

PingDirectory software provides support for encrypting database contents, backups, LDIF exports, and other content. You can also gain additional protection by enabling filesystem encryption to help protect against unauthorized access to the underlying storage.

Always set the system clock to the correct time.

The server installation guide makes several tuning recommendations to help ensure software runs smoothly.

Consider running the PingDirectory software in a Docker image or some other type of container to help isolate the server from other software and processes on the system.

Containerization encourages adopting a DevOps philosophy, which streamlines the process for deploying new instances of the software using a reliable and repeatable process. DevOps is good for disaster recovery because containers enable you to quickly create a new server instance if an existing instance fails.

Containerization can also offer other security-related benefits. For example, containers frequently don’t provide direct shell access to the instance, reducing the chance that an attacker can gain access to server data through that avenue. If you subscribe to the DevOps blue-green strategy, in which configuration changes get applied by spinning up new instances with the desired settings rather than updating existing instances, unauthorized configuration changes are easier to detect and revert.

Keep the Java Virtual Machine (JVM) up to date with the latest patches.

Run the most recent major release of the JVM that the PingDirectory software supports because it can offer support for additional security features that are not available in older versions.

If administrators can access the underlying system, then the mechanism they use to do so should be as secure as possible.

All shell access must occur over an encrypted session that uses strong authentication, such as relying on SSH keys rather than passwords, and ideally using a second authentication factor like TOTP or U2F.

Keep the number of users authorized to access the system to a minimum, and ensure each authorized user has their own account rather than sharing accounts across multiple individuals. This makes it easier to audit access and identify which administrator made a given change. Using separate accounts also avoids problems that might arise whenever the credentials need to be changed. With a separate account per administrator, each has their own distinct credentials.

The account used to run and manage the PingDirectory software itself should not be able to directly authenticate to the underlying system. Instead, each user authorized to interact with the PingDirectory software on the underlying system must authenticate with their own account before using some mechanism, such as su or sudo on UNIX-based systems, to interact with the server software.

The accounts for the users who manage the PingDirectory software and the account used to run that software should be configured with the minimum set of capabilities required to perform their duties. Those who manage the underlying system might require full access, but those who just maintain the PingDirectory software can be given restricted access. If possible, restrict the set of commands that those users can invoke and their access to other running processes and areas of the filesystem.

If a system account becomes compromised or its owner leaves, terminate that account as quickly as possible. While managing system accounts is usually best left to a centralized naming service like LDAP, this is not recommended for the accounts used to manage the PingDirectory software itself because an issue with the server might prevent users from authenticating to the system to address it. Local file-based accounts are the most reliable, but it is important to keep a current list of all users with access to these systems and of all systems they can access with those credentials so that the credentials can quickly be revoked if necessary.

Even if PingDirectory server administrators are not granted shell access to the underlying system, it is still possible to manage the server.

Most administrative functions can be performed remotely over secure LDAP or HTTP connections.

The web-based administration console provides support for managing the server configuration and schema. It also provides access to a variety of status information, including monitor entries, active alarms, and administrative alerts.

If you extract the PingDirectory software onto your local system, then you will also have access to a variety of command-line tools that can interact with the server remotely.

Auditing provides vital information for diagnosing problems or investigating security breaches.

Most operating systems provide an audit mechanism that records information about system events. This can include basic information like keeping a record of sign on attempts, but it might also be possible to capture more detailed information like recording each command that is invoked or each file that is accessed.

Make sure that logging and auditing are properly tuned to record an appropriate amount of information without impeding system performance. You might also want to ensure that system logs are recorded locally and sent to a remote system to ensure higher availability and to reduce the likelihood that an attacker who gains access to the system will be able to cover their tracks.