6 Replies Latest reply on Dec 12, 2013 3:45 PM by byrona

    PCI DSS & LEM

    byrona

      I just finished reviewing the PCI DSS control objectives and as best I can tell LEM will address the following objectives: 10.2, 10.3, 10.5, 10.6, and 10.7.  The document locate HERE indicates that it will address 10.4 through I am not sure how?

       

      I would like to get confirmation that this all sounds correct and know if I have missed anything, thanks!

        • Re: PCI DSS & LEM
          byrona

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

          • Re: PCI DSS & LEM
            nicole pauls

            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.

            1 of 1 people found this helpful
              • Re: PCI DSS & LEM
                byrona

                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?

                  • Re: PCI DSS & LEM
                    nicole pauls

                    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.