Cyber-attacks are executing at much faster speeds now. In the past you might find that an attacker waited weeks or months after gaining access to your system before stealing sensitive data. Those days are mostly gone. An attacker now can execute in a few minutes or hours. Early detection is critical for interrupting an attack. And a fast response is crucial to stopping the attack.

There is a good chance that you are already encrypting your sensitive data to prevent it from being used for extortion by a ransomware attacker. If you are already encrypting your data, you are also probably using a key management system (KMS) to store your encryption keys. That is a security best practice, and the right thing to do.

Are you ready for the next step?

Did you know that your KMS can play an important part in early detection of an attack? Your key management system should be collecting key retrieval activity into real-time logs. For example, our Alliance Key Manager logs every single action that takes place including key creation, retrieval, deletion, and so forth. Why not use these logs to help detect an attack? After all, the attacker is going to try to steal the data, and that means there will likely be activity on the key manager. And that means a KMS log can help you thwart an attack.

How can we implement this in a real environment?

Our Alliance Key Manager solution comes with log forwarding capability already built in. It is easy to start forwarding the KMS activity log to your SIEM solution using the common syslog-ng protocol. All SIEMS can ingest the KMS activity log, so just start forwarding them.

Next, train your SIEM to detect anomalies. A good SIEM is really good at anomaly detection! So let’s put it to work. Here are some KMS events that should be early warning signs of an attack in progress:

• Retrieving an encryption key at an unusual time of the day.
• Retrieving an encryption key on an unusual day.
• Failure to retrieve a key for an extended period of time.
• Unusually high level of key retrieval requests.
• Unexpected user attempts to retrieve a key.
• Attempts to retrieve a key that does not exist.
• Failed TLS negotiation to retrieve a key.
• Key retrieval request from an unusual IP address.

As you can see there are many events or patterns that can indicate the activity of an attacker. And KMS logs are likely to show this activity early in the attack. Training your SIEM to alert on this activity is usually pretty easy to do, but that depends on the functions of the SIEM.

Another big bonus for integrating the KMS with your SIEM is that many SIEMS can now take pro-active and automatic steps to thwart an attack. In addition to alerting the IT staff of a potential attack, some SIEM solutions can execute scripts that take a database off-line, or even take the key manager off-line. You can get very creative with the automatic responses to a cyber-attack.

Your KMS can be your “canary in a coal mine”. The features are there ready to be put to use.

If you are running our Alliance Key Manager solution just raise a problem ticket with our support team to get some pointers on how to forward logs to your SIEM. It will be easy to do.

Patrick