25
Jan
14

PCI DSS v3 Requirement 10.6

I was on a call the other day and we were walking through requirement 10 of the PCI DSS v3 to ensure we had everything covered regarding changes.  One of the other people on the call gasped and told all of us to look at requirement 10.6.

 “Review logs of all other system components periodically based on the organization’s policies and risk management strategy, as determined by the organization’s annual risk assessment.”

The person who gasped said, “You don’t think they mean ALL other systems as in everything do you?”

We all looked at the Guidance column for advice and saw that it said:

 “Logs for all other system components should also be periodically reviewed to identify indications of potential issues or attempts to gain access to sensitive systems via less-sensitive systems.  The frequency of the reviews should be determined by an entity’s annual risk-assessment.”

The tests 10.6.1 and 10.6.2 also refer to “all other systems” as well.  In the end, we came to agreement that the new version of the PCI DSS does call out that all systems, even those out of scope, need to have their log data reviewed based on their risk to the organization.

Talk about a “How in the Hell did we miss that?” kind of moment.

Worse is that we know a lot of organizations are going to push back very, very hard on this requirement.  They sized their security information and event monitoring (SIEM) solution based on their cardholder data environment (CDE) and Category 2 systems, not their entire networks.  But it gets even worse because this is not a requirement that you can put off until 2015, this requirement needs to be complied with immediately when going to the new version of the PCI DSS.  Oops!

But if this is not enough, the Council used that word “periodically” in the requirement.  In the guidance they state, “The frequency of the reviews should be determined by an entity’s annual risk-assessment.”  So there is another requirement for the risk assessment.  Your risk assessment must define why log data of all systems is only reviewed once a month/quarter/year/etc.  However, if you are routing all log data from all systems/devices into a SIEM, it should be reviewed in almost real-time.

Congratulations to all those SIEM vendor sales people out there as it will likely be a very good year for all of you.

Just wanted to provide you all with the heads up.

About these ads

10 Responses to “PCI DSS v3 Requirement 10.6”


  1. 1 LJ
    March 4, 2014 at 7:05 PM

    At some point Business and Security individuals will come out of the weeds and attempt undestanding the true intent of 10.6..and other DSS requirements. This is guidance on mature security practices that organizations should practice for ALL DATA. PCI tends to be the focus and we can obviously limit scope to the CDE and it’s interconnecting devices, but does that mean we should practice good security for PAN data only? What about SSN’s, DMV data, and Pii -

    What you are required to do is demonstrate functionality of processes. A process works or it doesnt – it may be crappy and involve people and technology, but a process is a process and an accepted document by the business is law according to I.T and the PCI SSC. I think what is important is that we try to learn what PCI DSS 2 and 3 will teach us about good security practice and move those types of controls across all environments and all data types. You can see in 3.0 the added language to support ‘reason’ and ‘method’ of these practices so that it helps evolution of security in technologies, people and process enterprise wide.

    Again.. “according to organizations policies and risk management strategy….”

    I hope companies are not just writing I.T. standards and process to only address PCI systems.

    Plain English –

    If you have a technology and process to centrally log and monitor activities on PCI in-scope systems, it might be a good idea to expand….check your logs – all logs needs to be centrally located and monitored for suspicious activity and at the very least on record to ensure when something does happen you can maybe put back together the past in hopes you have a leg to stand on in litigation….its a good idea…like a seat-belt.

    :0/ PCI Compliance is a Whoop of a time right…

  2. 2 DN
    February 3, 2014 at 10:42 AM

    PCIGuru,

    I have just finished a word for word comparison of the v2.0 to v3.0 and after reading the documents and reading 10.6 as a whole entitie, I tend to agree with the others with this.

    10.6.1 states that on a daily basis you have to reveiw the following:
    - All Security Events
    - Logs of all system components that store, process, transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD
    - Logs of all critical system components
    - Logs of all servers and system components that perform security functions (along with some examples)

    There are a number of pieces that are not included in this list such as:
    - Admin Workstations (if they don’t transmit/process CHD)
    - Sorry page webservers (not critical, do not perform security functions, do not transmit CHD)
    - To me this is a lot of the devices in Categories 2c and 2x in the Open PCI Scoping Document.

    This relaxes the rules for log monitoring, not restricts them.

    All other logs that are not security logs. So things like application, system logs, and application specific logs in a Windows environment.

    This is to say, that on a workstation you would review the login/logout events, all the time, but you would not neccessarily care that there is an application/printer error on the machine that is being generated every time the computer reboots.

    This focuses the security team to review what is “important.” Not that an application error every reboot is not important, and may be the indicator of compromise, but image having to trace back every event for every workstation in an organization. That would be a huge amount of work and turn merchants off of PCI complaince.

    • February 5, 2014 at 6:20 AM

      The unfortunate fact of life is that, after the Target/Neiman/Michaels/et.al. breaches, I think you will see more QSAs demanding more and better logging and the review of that log data. These breaches appear to have started well outside of the cardholder data environment (CDE) that then led to the breach of the CDE. As merchants get savvier with security, the attackers will get more and more sophisticated with their attack techniques. That will demand merchants stepping up with better detection and monitoring techniques which will require more log data to analyze as well as other changes in security and monitoring practices. The PCI DSS does not have to change to support this as the bulk of these practices are already there, it is their execution that most organizations are lacking.

      • 4 DN
        February 5, 2014 at 8:59 AM

        You are right, and I completely agree with you here, but this leads to a slippery slope of bringing systems into scope for PCI. Based on your interpretation of requirement 10.6, re-read the BaU section and basically what they are saying is that you need to have the scanning (IDS/IPS, FIM, and Vulneralbity), and Log review on your entire network. This is also aluded to in the section for assesors in the second paragraph (…, it is not acceptable for an entity to apply PCI DSS requirements to only a sample of their environment).

        Also requirement 1.4, does that now include all workstations on the corporate network, in-scope of PCI or not?

        I think the biggest issue right now, is the Category 2.c and 2.x systems on the corporate network. Because these systems are outside the PCI zone and free on the corporate network, they are forgotten about and lost when it comes to compliance tasks, especially the configuration and hardening because they would not then fit the “corporate standard” of server builds, or break monitoring tools.

        V3 of the standards attempt to highlight this issue by providing a clear statement on how systems are deamed out of scope (Network Segementation section, page 11), however this may lead to backlash where merchants are complaining that the DSS is not expanding the scope of requirements.

        The challenge for QSAs is to be able to properly identifiy those 2.c and 2.x systems and ensure that they are in fact properly secured from other systems.

  3. 5 Sébastien
    January 30, 2014 at 4:12 AM

    Requirement 10.6.2 may deal with all other logs than the “security events logs” but only for CDE system components ?

  4. 6 Luis
    January 30, 2014 at 1:54 AM

    Yeah, you are pretty right there… but as my subconscious cannot accept the fact that we need to log everything, I am trying to see it differently now: “as determined by the organization’s annual risk assessment.” The Risk Analysis guide explains that the scope of this analysis may not be the same as the CDE.

    —- ” The risk assessment process should include people, processes, and technologies that are involved in the storage, processing, or transmission of CHD including those that may not be directly involved in processing CHD but still have the potential to impact the security of the CDE—for example, perimeter building security at the facility where the CDE is located. Consideration should also be given to business processes outsourced and/or managed by third-party service providers or merchants.” —-

    It would be feasible that this 10.6.2 refers to the systems not involved directly into the CDE, but the ones outside them which are inside the risk analysis scope.

    Maybe I am lurching a bit here, but I wanted to share my thoughts.

    Regards.

    • January 30, 2014 at 6:47 AM

      We’ve gone round and round internally on this just as the comments here. In the end, the only thing that makes sense is that is concerns all other systems not considered a category 1 (processes, stores or transmits CHD) or 2 (connected systems). So that defines everything else. As you point out, how often the review occurs is up to the company’s risk assessment. In theory, that could cause the log data to be reviewed monthly, semi-annually or even annually. Not that I think that’s a good idea, but you could do it.

  5. 8 Luis
    January 27, 2014 at 10:40 AM

    Hi PCIGuru,

    Maybe I am wrong, but I do not perceive it as including all the system logs in the SIEM. I think it refers to include in the SIEM all system logs in the CDE which are not the ones explicitly written in the 10.6.1 section. That would make the 100% of the CDE logs.

    BTW thanks for your periodical posting: it helps a lot to the people not used to PCI auditing.

    Regards,
    Luis.

    • 9 Carl
      January 29, 2014 at 2:51 PM

      Agreed. Take a look at the definition of “system components” in the new glossary, and plug it into the 10.6.2 wording. It is only for items in scope for PCI. I think you’re off base here.

      • January 29, 2014 at 5:14 PM

        From a logic standpoint, what is the point of requirement 10.6.2 when the rest of 10 covers logging for everything that is in-scope. If requirement 10.6.2 is truly only for in-scope systems, then what was all of the rest of 10 for? Beside, 10.6.2 would then totally contradict the rest of 10. That is why we think it’s everything else that is out of scope.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

FishNet Security is looking for experienced QSAs for their PCI practice. If you are an experienced QSA and are looking for a change, go to the Web site (http://www.fishnetsecurity.com/company/careers), search for 'PCI' and apply.

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response to too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

January 2014
M T W T F S S
« Dec   Feb »
 12345
6789101112
13141516171819
20212223242526
2728293031  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 908 other followers


Follow

Get every new post delivered to your Inbox.

Join 908 other followers

%d bloggers like this: