PCI DSS & LEM

Are we the only ones using LEM (or at least looking at using LEM) for PCI?

Nope.  We use LEM and Tripwire for FIM.

10.4 is synchronizing changes to clock, which we can help detect changes to if it's reported by the system. Windows, for example, will log when the clock times are adjusted or changed to a non-synchronized source. You can also do something like build a filter for detection times reported in the past, or see in real-time as data's being misreported.

Not an actual solution to help synchronize clocks, but one that can alert to changes being made unexpectedly that might affect that.

Thanks for that Nicole!  Two follow-up questions...

Would you agree with LEM being able to satisfy the other PCI control objectives that I referenced above?

What specifically do I need to watch for to identify clock changes?

I am not sure how I missed some of these responses, must be buried. Yes, I agree about 10.2, 10.3, 10.5, and 10.7 (also listed in the blog).

On Windows, the clock sync fail events come from w32time (EventID w32time 11, 14, 17, 18, 22, 24, 25, 26, 27, 29, 31, 36, 38, 45, 46, 47, 48, 49, 51, 54, 63, 129, 131, 132, 133, 134, 135 all show problems with clock synchronization, though some might be the NTP server and not the NTP client, it's hard to tell). The out of the box rule template specifically looks for "unable to synchronize time" which is w32time 38.

For non-Windows, it probably depends on whether the device/OS/service logs it. I know some systems will, especially where time matters. You could also build filters or rules for excessive DetectionTimes older than a certain date, though it's not a relative date so it'd need to be someone whose clock was wayyyyy off. That might also be significant load for the rules engine, since it has to check every event's timestamp again to compare to your rule, but I can't say I've tried it. You could also build a filter for DetectionTime > InsertionTime to detect when an event timestamp in the log is newer than the system timestamp, but on Windows you'd expect both to be wrong if the clock is off.

Thanks Nicole!