Companies deploy our key management system for a number of reasons - meeting security best practices, meeting compliance requirements, ransomware protection, and so forth. Encryption with proper encryption key management is a crucial part of a defense in depth strategy. In addition to providing proper protection for encryption keys, did you know that your key management system (KMS) can play a bigger role? 

Let’s explore some ways you can leverage that KMS system!

With your encryption keys protected by the KMS there are opportunities to leverage the KMS for early warning of an attack. (I am using our own Alliance Key Manager as the basis for these points, if you use a different KMS there might be variations in how to accomplish these tasks.) Here are some suggestions:

Monitor the KMS audit logs

Almost all KMS systems produce audit logs of user and administrator activity. When an attacker attempts to get access to protected data this can produce unusual activity in the audit log. Watch for the anomalies - for example, an unusual user account making a key retrieval attempt, an unusual time of day or day of week for activity, and so forth. And you can watch for unusual key management functions being performed. For example, it is rare that you would decrypt your database. So, an attempt to perform a database decryption at 1am on a Saturday night should raise an alarm. All of this assumes that you have a SIEM or other tool to automate the monitoring and alerting. You can leverage the KMS audit log to help raise an alarm.

Monitor the KMS exception logs

Similar to the previous item, some KMS systems provide a separate exception log. Hackers probably don’t have access to KMS exception logs and you can use this to your advantage. Forward your exception logs to your SIEM or monitoring system and give KMS exceptions a high level of priority.

Monitor the KMS system logs

Your KMS probably runs in its own operating system environment. As an example, our Alliance Key Manager is delivered as a self-contained virtual machine that includes the Linux operating system. That means there are Linux system logs available for monitoring, too. If an attacker is attempting a brute force attack on the KMS, the system logs will have valuable real-time information to help identify the attack. Send the system logs to your SIEM for monitoring and alerts.

Monitor client-side certificates

Most KMS systems use client-side certificates to create a secure TLS session to the key manager. This often involves a CA certificate, client certificate and private key. Attackers may try to access these credentials using a non-standard user account. You can use this to your advantage, too. Restrict access to client-side credentials and monitor for access failures. If your system is humming along and you suddenly see access failures on KMS credentials you should send up a flare! This is almost certainly an indicator of an attack.

Monitor Windows Certificate Manager

If you are protecting data in a Windows environment the KMS credentials may be stored in the Windows Certificate Store. This gives you another ability to detect an attacker’s attempt to gain access to KMS credentials. Monitor activity on the Windows Certificate Store and raise an alert on unusual activity.

Monitor SQL Administrator functions and commands

If you are an attacker and you can get elevated DBA privileges you might try to decrypt the database before exfiltrating it. That would require activity on the KMS to retrieve or unlock the encryption key. You can catch this by monitoring SQL administration commands. (And you can monitor this on the KMS side for unusual key retrieve or unlock activity - A Twofer!). Consult with your database administrator on how SQL administrative commands are logged. All modern databases log this kind of activity.

Monitor privileged database accounts

Database engines often run under special privileged accounts. These accounts usually do not have authority to log onto a system and are restricted to database functions only. Monitor all of your privileged database user accounts for unusual activity. For example, attempting to assign a password to this kind of account is a big red flag. Use this to your advantage.

Monitor client side software changes related to the KMS

You are probably already monitoring the installation of suspect software on your systems. Consider monitoring any client-side KMS software changes, too. For example, the Microsoft SQL Server database makes calls to an Extensible Key Management provider program when you activate Transparent Data Encryption. Most KMS vendors deliver this EKM Provider software as a DLL. You should monitor any unexpected changes to this software and raise an alert.

As you can see there are lots of ways you can leverage your KMS system to improve your security posture. Most of the techniques described here are easy to implement and don’t require programming or changes to your applications. A very easy win!

Patrick