Archive

Your SIEM relationship status: It’s complicated

On Facebook, when two parties are sort-of-kind-of together but also sort-of, well, not, their relationship status reads, “It’s complicated.” Oftentimes, Party A really wants to like Party B, but Party B keeps doing and saying dumb stuff that prevents Party A from making a commitment.

Is it like that between you and your SIEM?

Here are dumb things that a SIEM can do to prevent you from making a commitment:

  • Require a lot of work, giving little in return
  • Be high maintenance, cost a lot to keep around
  • Be complex to operate, require lots of learning
  • Require trained staff to operate

Simplify your relationship with your SIEM with a co-managed solution.

Certificates and Digitally Signed Applications: A Double Edged Sword

Windows supports the digitally signing of EXEs and other application files so that you can verify the provenance of software before it executes on your system.  This is an important element in the defense against malware.  When a software publisher like Adobe signs their application they use the private key associated with a certificate they’ve obtained from one of the major certification authorities like Verisign.

Later, when you attempt to run a program, Windows can check the file’s signature and verify that it was signed by Adobe and that its bits haven’t been tampered with such as by the insertion of malicious code.

Windows doesn’t enforce digital signatures or limit which publisher’s programs can execute by default, but you can enable that with AppLocker.  As powerful as AppLocker potentially is, it is also complicated to set up, except for environments with a very limited and standardized set of applications.  You must create rules for at least every publisher whose code runs on your system.

The good news, however, is that AppLocker can also be activated in audit mode.  And you can quickly set up a base set of allow rules by having AppLocker scan a sample system.  The idea with running AppLocker in audit mode is that you then monitor the AppLocker event log for warnings about programs that failed to match any of the allow rules.  This means the program has an invalid signature, was signed by a publisher you don’t trust or isn’t signed at all.  The events you look for are 8003, 8006, 8021 and 8024 and these events are in the logs under AppLocker as shown here:

AppLocker_Events to Look For

These events are described here, which is part of the AppLocker Technical Reference.

If you are going to use AppLocker in audit mode for detecting untrusted software remember that Windows logs these events on each local system.  So be sure you are using a SIEM with an efficient agent, like EventTracker, to collect these events or use Windows Event Forwarding.

Better yet, if you have EventTracker, don’t bother with AppLocker – use EventTracker’s automatic Digital Forensics Incident and Incident Response feature for unknown processes.  EventTracker watches each process (and soon each DLL) that your endpoints load and checks the EXE’s hash against your environment’s local whitelist (which EventTracker can automatically build). If not found there, EventTracker checks it against the National Software Reference Library.  If the EXE still isn’t found to be legit, EventTracker posts it to the dashboard for you to review.  EventTracker automatically provides publisher information if the file is signed, and other forensics such as the endpoint, user and parent process.  With one click you can check the process against anti-malware sites such as VirusTotal. EventTracker goes way beyond AppLocker in its ability to detect suspicious software and giving the tools and information to quickly determine if the program is a risk or not, including the use of digital signatures.

There are some other issues to be aware of, though, with digitally signed applications and certificates.  Certificates are part of a very complicated technology called Public Key Infrastructure (PKI).  PKI has so many components and ties together so many different parties there is unfortunately a lot of room for error.   Here’s a brief list of what has gone wrong in the past year or so with signed applications and the PKI that signatures depend on:

  1. Compromised code-signing server: I’d said earlier that code signing allows you to make sure a program really came from the publisher and that it hasn’t been modified (tampered).  But it depends on how well the publisher protects their private key.  And unfortunately Adobe is a case in point.  A while back some bad guys broke into Adobe’s network and eventually found their way to the very server Adobe uses to sign applications like Acrobat.  They uploaded their own malware and signed it with Adobe’s code signing certificate’s private key and then proceeded to deploy that malware to target systems that graciously ran the program as a trusted Adobe application.  How do you protect against publishers that get hacked?  There’s only so much you can do.  You can create stricter rules that limit execution to specific versions of known applications but of course that makes your policy much more fragile.
  1. Fraudulently obtained certificates: Everything in PKI depends on the Certification Authority only issuing certificates after rigorously verifying the party purchasing the certificate is really who they say they are.  This doesn’t always work.  A pretty recent example is Spymel a piece of malware signed by a certificate DigiCert issued to a company called SBO Invest.  What can you do here?  Well, using something like AppLocker to limit software to known publishers does help in this case.  Of course if the CA itself is hacked then you can’t trust any certificate issued by it.  And that brings us to the next point.
  1. Untrustworthy CAs: I’ve always been amazed at all the CA Windows trusts out of the box.  It’s better than it used to be but at one time I remember that my Windows 2000 system automatically trusted certificates issued by some government agency of Peru.  But you don’t have trust every CA Microsoft does.  Trusted CAs are defined in the Trusted Root CAs store in the Certificates MMC snap-in and you can control the contents of this store centrally via group policy
  1. Insecure CAs from PC Vendors: Late last year Dell made the headlines when it was discovered that they were shipping PCs with their own CA’s certificate in the Trusted Root store.  This was so that drivers and other files signed by Dell would be trusted.   That might have been OK, but they mistakenly broke The Number One Rule in PKI.  They failed to keep the private key private.  That’s bad with any certificate let alone a CA’s root certificate.  Specifically, Dell included the private key with the certificate.  That allowed anyone that bought an affected Dell PC to sign their own custom malware with Dell’s private key and then once deployed on other affected Dell systems to run it with impunity since it appeared to be legit and from Dell.

So, certificates and code signing are far from perfect — show me any security control that is.  I really encourage you to try out AppLocker in audit mode and monitor the warnings it produces.  You won’t break any user experience, the performance impact is hardly measurable and if you are monitoring those warnings you might just detect some malware the first time it executes instead of the 6 months or so that it takes on average.

Top 5 SIEM complaints

Here’s our list of the Top 5 SIEM complaints:

1) We bought a security information and event management (SIEM) system, but it’s too complicated and time-consuming, so we’re:

a) Not using it
b) Only using it for log collection
c) Taking log feeds, but not monitoring the alerts
d) Getting so many alerts that we can’t keep up with them
e) Way behind because the person who knew about the SIEM left

2) We’re updating technology and need to retrain to support it

3) It’s hard to find, train and retain security expertise

4) We don’t have enough trained staff to manage all of our devices

5) We don’t have trained resources to successfully respond to a security incident

What’s an IT Manager to do?
Get a co-managed solution, of course.
Here’s our’s. It’s called SIEM Simplified.
Billions of logs analyzed daily. See what we’ve caught.

The Cost of False IT Security Alarms

Think about the burglar alarm systems that are common in residential neighborhoods. In the eye of the passive observer, an alarm system makes a lot of sense. They watch your home while you’re asleep or away, and call the police or fire department if anything happens. So for a small monthly fee you feel secure. Unfortunately, there are a few things that the alarm companies don’t tell you.

1)      Between 95% and 97% of calls (depending on the time of year) are false alarms.

2)      The police regard calls from alarm companies as the lowest priority and it can take anywhere between 20-30 minutes for them to arrive. It only takes the average burglar 5 minutes to break and enter, and be off with your valuables.

3)      In addition to this, if your call does turn out to be a false alarm, the police and fire department have introduced hefty fines. It is about $130 for the police to be called out, and if fire trucks are sent, they charge around $410 per truck (protocol is to send 3 trucks). So as you can see, one false alarm can cost you well over $1,200.

With more than 2 million annual burglaries in the U.S., perhaps it’s worth putting up with so many false positives in service of the greater deterrent? Yes, provided we can sort out the false alarms which sap the first responder.

The same is true of information security. If we know which alerts to respond to, we can focus our time on those important alerts. Tuning the system to reduce the alerts, and removing the false positives so we can concentrate only on valid alerts, gives us the ability to respond only to the security events that truly matter.

While our technology does an excellent job of detecting possible security events, it’s our service, which examines these alerts and provides experts who make it relevant using context and judgement, that makes the difference between a rash of false positives and the ones that truly matter.