RisknCompliance Blog

Thoughts On Delivering Meaningful Outcomes in Security and Privacy

Category: PCI DSS (page 1 of 2)

Hello PCI SSC… Can we rethink?

This is a detailed follow-up to the quick post I wrote the Friday before the Labor Day weekend,  based on my read at the time of the PCI SSC’s Special Interest Group paper on “Best practices for maintaining PCI DSS compliance”1 published just the day before.

The best practices guidance is by and large a good one though nothing of what is discussed is necessarily new or ground breaking. The bottom line of what the paper discusses is the reality of what any person or organization with electronic information of some value (and who doesn’t today?) needs to do… which is that there is no substitute for constant and appropriate security vigilance in today’s digital world.

That said,  I am not sure this guidance (or anything else PCI SSC has done so far with PCI DSS including the new version 3 taking effect at the end of the year) is going to result in the change we need… the change in how PCI organizations are able to prevent or at least able to detect and contain the damage caused by security breaches in their cardholder data environments (CDEs). After all, we have had more PCI breaches (both in number and scale) over the past year than at any other time since PCI DSS has been in effect.

One is then naturally forced to question why or how does PCI SSC expect a different result if  PCI DSS itself hasn’t changed fundamentally over the years. I believe a famous person no less than Albert Einstein had something to say about doing the same thing over and over again and expecting different results.AE

If you have had anything to do with the PCI DSS over the last several years, you are probably very familiar with the criticism it has received from time to time.  For the record, I think PCI DSS has been a good thing for the industry and it isn’t too hard to recognize that security in PCI could be much worse without the DSS.

At the same time, it is also not hard to see that PCI DSS hasn’t fundamentally changed in its philosophy and approach since its inception in 2006 while the security threat environment itself has evolved drastically both in its nature and scale over this period.

The objective of this post is to offer some suggestions for how to make PCI DSS more effective and meaningful for the amount of money and overheads that merchants and service providers are having to spend on it year after year.

Suggestion #1 : Call for Requirement Zero

I am glad the best practices guidance1 highlights the need for a risk based PCI DSS program. It is also pertinent to note that risk assessment is included as a milestone 1 item in the Prioritized Approach tool2 though I doubt many organizations use the suggested prioritization.

In my opinion however, you are not emphasizing the need for a risk based program if your risk assessment requirement is buried inconspicuously under requirement #12 of the 12 requirements (12.2 to be specific). If we are to direct merchants and service providers to execute a risk based PCI DSS program, I believe the best way to do it is by  making risk assessment the very first thing that they do soon after identifying and finalizing the CDE they want to live with.

As such, I recommend introducing a new Requirement Zero to include the following :

  • Identify the current CDE and try to reduce the CDE footprint to the extent possible
  • Update the inventory of system components in the CDE (Current requirement 2.4)
  • Prepare CDE Network diagram (Current requirement 1.1.2) and CHD flow diagram (Current requirement 1.1.3). I consider this to be a critical step. After all, we can only safeguard something valuable if we know it exists. We also talked about how the HIPAA Security Rule could use this requirement in a different post.
  • Conduct a Risk Assessment (Current requirement 12.2)

Performing a risk assessment right at the beginning will provide the means for organizations to evaluate how far they need to go with implementing each of the 200+ requirements. In many cases, they may have to go well over the letter of certain requirements and truly address the intent and spirit of the requirements in order to reduce the estimated risk to acceptable levels.

Performing the risk assessment will also (hopefully) force organizations to consider the current and evolving threats and mitigate the risks posed by these threats. Without the risk assessment being performed upfront, one will naturally fall into the template security mindset we discussed here. As discussed in the post, template approaches are likely to drive a security program to failure down the road (or at least make it ineffective).

Suggestion #2 : Discontinue all (requirements) or nothing approach

A true risk management program must mean that the organizations should have a choice not to implement a control if they can clearly articulate the risk associated with not implementing it is truly low.

I think PCI DSS has a fundamental contradiction in its philosophy of pushing a all-or-nothing regulation while advocating a risk based approach at the same time. In an ideal world where organizations have limitless resources and time at their disposal, they could perhaps fully meet every one of the 200+ requirements while also addressing the present and evolving risks. As we know however, the real world is far from ideal in that the organizations are almost always faced with constraints all around and certainly with the amount of resources and time available at their disposal.

Making this change (from all or nothing approach) of course will mean a foundational change in PCI DSS’ philosophy of how the whole program is administered by PCI SSC and the card brands. Regardless, this change is too important to be ignored considering the realities of business challenges and the security landscape.

Suggestion #3 : Compensating controls

As anyone that has dealt with PCI DSS knows, documentation of compensating controls is one of the most onerous aspects of PCI DSS, so much so that you are sometimes better off implementing the original control than having to document and justify the “validity” of the compensating control to your QSA. No wonder then, that a book on PCI DSS compliance actually had a whole chapter on the “art of compensating control”.

The need for compensating controls should be based on the risk to the cardholder data and not on not implementing the requirement itself. This should be a no-brainer if PCI SSC really wants PCI DSS to be risk based.

If the risk associated with not implementing a control is low enough, organizations should have a choice of not implementing a compensating control or at least not implementing it to the extent that the DSS currently expects the organization to.

Suggestion #4 : Reducing compliance burden and fatigue

As is well known, PCI DSS requires substantial annual efforts and related expenses. If the assessments involve Qualified Security Assessors (QSAs), the overheads are much higher than self-assessments. Despite such onerous efforts and overheads, even some of the more prominent retailers and well-funded organizations can’t detect their own breaches.

The reality is that most PCI organizations have limited budgets to spend on security let alone on compliance with PCI DSS. Forcing these organizations to divert much of their security funding to repeated annual compliance efforts simply doesn’t make any business or practical sense, especially considering the big question of whether these annual compliance efforts really help improve the ability of organizations to do better against breaches.

I would like to suggest the following changes for reducing compliance burden so that organizations can spend more of their security budgets on initiatives and activities that can truly reduce the risk of breaches:

  • The full scope (of all 200+ requirements or controls) may be in scope for compliance assessments (internal or by QSA) only during the first year of the three year PCI DSS update cycle. Remember that organizations may still choose not to implement certain controls based on the results of the risk assessment (see suggestion #2 above)
  • For the remaining two years, organizations may be required to perform only a risk assessment and implement appropriate changes in their environment to address the increased risk levels. Risk assessments must be performed appropriately and with the right level of due diligence. The assessment must include (among other things) review of certain key information obtained through firewall reviews (requirement 1.1.7), application security testing (requirement 6. 6), access reviews (requirement 7), vulnerability scans (11.2) and penetration tests (11.3).

 Suggestion #5 : Redundant (or less relevant) controls

PCI SSC may look at reviewing the value of certain control requirements considering that newer requirements added in subsequent versions could reduce the usefulness or relevance of those controls or perhaps even make them redundant.

For example, PCI DSS v3 requirement around penetration testing has a considerable change compared to the previous version. If the organization were to perform the penetration tests appropriately, there should not be much need for requirement 2.1 especially the rather elaborate testing procedures highlighted in the figure.

PCIDSSreq21

There are several other requirements or controls as well that perhaps fall into the same category of being less useful or even redundant.

Such redundant requirements should help make the case for deprecation or consolidation of certain requirements.  These requirements also help make the case for moving away from the all or nothing approach or philosophy we discussed under #2.

 Suggestion #6 : Reduce Documentation Requirements

PCI DSS in general requires fairly extensive documentation at all levels. We already talked about it when we discussed the topic of compensating controls above.

Documentation is certainly useful and indeed strongly recommended in certain areas especially where it helps with communication and better enforcement of security controls that help in risk reduction.

On the other hand, documentation purely for compliance purposes must be avoidable especially if it doesn’t help improve security safeguards to any appreciable extent.

…………………………………………………

That was perhaps a longer post than some of us are used to,  especially on a blog. These are the suggestions that I can readily think of. I’ll be keen to hear any other suggestions you may have yourself or perhaps even comments or critique of my thoughts.

References

1Best Practices for Maintaining PCI DSS Compliance (pdf)  by Special Interest Group, PCI Security Standards Council (SSC)
2PCI DSS Prioritized Approach (xls download)

Hello PCI SSC…

Hello PCI SSC,

You had me on board until I saw this statement in your guidance1 released yesterday.

“However, using risk as the basis for an organization’s information security program does not permit organizations to avoid or bypass applicable PCI DSS requirements or related compensating controls. In order to achieve compliance with PCI DSS, an organization must meet all applicable PCI DSS requirements.”

I believe we need a change in your “all requirements mandatory” approach. I think it leads to compliance fatigue and misguided spend of already limited security budgets.

I’ll explain in another blog post to come soon.

References
1Best Practices for Maintaining PCI DSS Compliance (pdf)  by Special Interest Group, PCI Security Standards Council (SSC)

 

PCI Breaches – Can we at least detect them?

Almost all Payment Card Industry (PCI) breaches over the past year, including the most recent one at Supervalu appear to have the following aspects in common:

1. They involved some compromise of Point of Sale (POS) systems.

2. The compromise and breaches continued for several weeks or months before being detected.

3. The breaches were detected not by the retailer but by some external entity – FBI, the US Secret Service, Payment processor, card brands, issuing bank etc.

4. At the time the breach was disclosed, the retailers appear to have had a passing PCI DSS certification.

Anyone that has a reasonable understanding of the current Information Security landscape should know that it is not a matter of “if” but “when” an organization will get compromised. Given this humbling reality, it only makes sense that we must be able to detect a compromise in a “timely” manner and hopefully contain the magnitude of the breach before it gets much worse.

Let’s consider the following aspects as well:

  1. PCI has one of the more prescriptive regulations in the form of PCI DSS and PA DSS than any other industry. As a case in point, consider the equivalent regulations for Electronic Health Records systems (EHRs) in the United States – the EHR Certification regulation (PA DSS equivalent) requirements highlighted yellow in this document and the Meaningful Use regulation (PCI DSS equivalent) requirements highlighted green. You will see that the PCI regulations are a lot more comprehensive both in breadth and depth.
  1. PCI DSS requires merchants and service providers to validate and document their compliance status every year. For the large retailers that have been in the news for the wrong reasons, this probably meant having a external Qualified Security Assessor (QSA)  performing a on-site security assessment and providing them with a passing Report on Compliance (ROC) every year.
  1. As for logging and monitoring requirements that should help with detection of a potential compromise,  both PCI DSS (Requirement 10)  and PA DSS (Requirement 4) are as detailed as they get in any security framework or regulation I am aware of.
  1. Even if you think requirement #10 can’t help detect POS malware activity, there is PCI DSS requirement 12.2 that requires a security risk assessment to be performed at least once a year. The risk assessment must consider the current threats and vulnerabilities. Given the constant stream of breaches, one would think that the POS malware threats are accounted for in these risk assessments.
  1. These large merchants have been around for a while and are supposed to have been PCI DSS compliant for several years. And so, one would think they have appropriate technologies and processes to at least detect a security compromise that results in the scale of breaches they have had.

So, what do you think may be the reasons why the retailers or the PCI regulations are not effective in at least detecting the breaches? More importantly, what changes would you suggest, both to the regulations and also to how the retailers plan and execute their security programs? Or perhaps even to how the QSAs perform their assessments in providing passing ROCs to the retailers?

I’m keen to hear your thoughts and comments.

Compliance obligations need not stand in the way of better information security and risk management

I couldn’t help write this post when I noticed this press release based on an IDC Insights Survey of Oil & Gas Companies. I don’t have access to the full report so I am basing my comments solely on the contents of the press release.

I found the following two findings (copied from the press release) to be of interest :

  • Security investments are not compliance driven. Only 10% of the respondents indicated that they are using regulatory compliance as a requirement to justify budgets.
  • Tough regulatory compliance and threat sophistication are the biggest barriers. Almost 25% of respondents indicated regulatory environment as a barrier to ensuring security. In addition, 20% of respondents acknowledged the increasing threat landscape.

The good news here is that only 10% of the respondents used Regulatory Compliance needs to justify budgets. What that tells me (I hope it is the case) is that the remaining 90% make budgetary decisions based solely on the information security risks that their  businesses face and not on the risks of not complying with regulations or audits. I would commend them for it… and I don’t think any good auditor (regulatory or internal/external) would have a problem with it either if the organization was able to “demonstrate” that the risk of not complying with a particular regulatory requirement was very low. Agreed.. you still need to be able to “demonstrate” which isn’t easy if one hasn’t been diligent with risk assessments.

The not-so-good news to me is the 25% number (I realize it might be low enough for some people)..  that of folks indicating that regulatory compliance is a barrier to ensuring security. For those folks, I say “It really doesn’t need to be a barrier”, not if you have good   information risk management governance and processes. I don’t know a single regulation that would force you to implement specific controls no matter what. Even if you are faced with an all-or-nothing regulation like PCI DSS, you can resort to using compensating controls (see here and here for some coverage of PCI DSS Compensating controls) to comply with a specific mandatory requirement.  To repeat my argument in the previous paragraph, an auditor would be hard-pressed to fault you if you were able to clearly articulate that you went about the compliance program  methodically by performing a risk assessment and prioritizing (by risk level) the need for specific controls required by the regulation. If you did that, you would focus on ”ensuring security” and not ignoring it for the sake of compliance.

May we suggest some priority adjustments to your PCI DSS Compliance program?

It isn’t any news that achieving PCI DSS Compliance continues to be onerous for many merchants out there. PCI DSS is after all an all-or-nothing regulation meaning that not passing even one of over 200 requirements could prevent you from getting there. And then, if you do become compliant, there is really no assurance that you will have 100% security. This is something we have known all along to be true for any regulation and now we have one more statistic from the 2010 Verizon Data Breach Investigation Report to prove it …  21% of organizations facing payment card data breaches were compliant with PCI DSS at the time of the breach.

So, may be it is time to rethink our approach to PCI DSS compliance, in terms of how do we get there by way of addressing controls that carry higher breach risks before the others. That will at least help improve your  organization’s security posture against potential breaches even if you are nowhere close to meeting all PCI DSS requirements.   I think recent breach surveys or reports are a great source to identify such controls  with an objective of prioritizing the remediation initiatives in the right order. Such prioritization should help in achieving a better security posture sooner, as we’ll see below.

I am not the first one to suggest a prioritized approach to achieving PCI DSS compliance. In fact, PCI SSC already has guidance on this, though the guidance itself is somewhat dated having been issued back in February 2009. Since then,  the threat environment has probably evolved somewhat and exploitation of certain  vulnerabilities isn’t quite of the same order relative to others. Therefore, I suggest leveraging the data breach findings to make necessary prioritization adjustments.

Here are some findings from three recent reports on which I am basing my recommendations:

#

Report

Findings

Relevant Controls (Our Analysis)

1

Verizon Data Breach Investigations Report 2010

· 61% of the breaches were discovered by a third party

· 86% of victims had evidence of the breach in their log files

· Technology – Monitoring, correlation, reporting and alerting off the log events

· Process – Regular reviews of logs, log reports or alerts

· People – Clear definition and assignment of responsibilities around log reviews and incident response

2

Verizon Data Breach Investigations Report 2010

· 94% of breached records had malware as one of the causes and 96% of breached records involved hacking

· 51% of malware was installed or injected remotely by the attacker (by obtaining privileged access to the system or other means such as SQL Injection)

· 85% of records breached by malware involved the attacker gaining backdoor access to the system

· 81% of records breached by malware involved data being sent to an external entity or site

· 86% of records breached by hacking involved use of stolen login credentials

· 86% of records breached by hacking involved use of stolen login credentials

· 89% of records breached by hacking involved SQL Injection

· 92% of records breached by hacking used web applications as the attack pathway

· Technology – Proper configuration and lockdown of systems, strong access credentials, access controls or assurance, assessment of web applications and remediation for OWASP Top 10 vulnerabilities, deployment of Web Application Firewalls, Logging/Monitoring/Reporting/Alerting of important events on critical systems

· Process – Configuration reviews, OWASP Top 10 vulnerability management, access assurance in the form of ongoing role/privilege management processes and periodic access certifications, regular reviews of logs, log reports or alerts, effective security incident response

· People – Clear definition and assignment of responsibilities around configuration reviews, access certifications, log reviews and incident response

3

Verizon Data Breach Investigations Report 2010

· More than 50% of breaches remain undiscovered for months or more

· 61% of the breaches were discovered by 3rd parties, and not the victim organization itself

· Technology – Monitoring, correlation, reporting and alerting off the log events

· Process – regular reviews of logs, log reports or alerts

· People – Clear definition and assignment of responsibilities around log reviews and incident response, User awareness and training

4

Verizon Data Breach Investigations Report 2010

· Few breaches were caused due to exploitation of vulnerabilities for which a patch was available.

· Likelihood of exploitation of an unpatched vulnerability is far less as compared to a vulnerability caused by a configuration issue.

Lockdown (secure configuration) of systems may receive higher priority over application of vendor patches unless there is a specific reason not to do so

5

Leaking Vault – Five years of data breaches – July 2010

· Drives/Media and hacking were the top two breach vectors

· Documents and Fraud (Social Engineering) have been increasing in prominence as threat breach vectors recently

· Of the breaches that involved hacking, SQL Injection, stolen credentials and malware accounted for most breaches

· Technology – Disk/Tape encryption, appropriate system lockdown to prevent use of media such as USB drives , Encryption of unstructured data (documents), Refer to controls in #2 against hacking

· Process – Physical Security, Encryption and Key Management

· People – Awareness and Training

6

Ponemon Institute – Annual Cost of Cybercrime study – July 2010

· The most costly cyber crimes are those caused by web attacks, malicious code and malicious insiders, which account for more than 90 percent of all cyber crime costs per organization on an annual basis.

· The average number of days to resolve a cyber attack was 14 days with an average cost to the organization of $17,696 per day. The survey revealed that malicious insider attacks can take up to 42 days or more to resolve.

Refer to #2 above

Here then is a summary of the key controls in the above table, relevant PCI DSS requirements and priorities from the PCI SSC Guidance.

Key Control (Our Analysis)

Relevant PCI DSS Requirement Numbers (See Notes below)

Secure Configuration and Lockdown

1.1.5 (2), 1.2 (2), 2.1 (2), 2.2.3 (3), 2.2.4 (3), 2.3 (2)

Web Application Security

6.5 (3)

Strong Access Credentials including periodic changes in credentials (e.g. password)

8 (4)

Access Assurance (Least Privilege access based on users’ business or job roles, timely revocation of access privileges)

7 (4), 12.2(6), 12.5.4(6), 12.5.5(6)

Logging, Monitoring and Reporting

10.1(4), 10.2(4), 10.3(4), 10.4(4), 10.5(4), 10.5(6), 10.7(4), 12.2(6), 12.5.2(6),

Encryption (Data at rest, media), Physical security of media

3.3(5), 3.4(5), 3.5(5), 9.5(5), 9.6(5), 9.7(5), 9.8(5), 9.9(5)

Security Incident Response

12.5.3(6), 12.9(6)

Security Awareness and Training

12.3(6), 12.3.10(6), 12.4(6), 12.6(6)

Note: Numbers in brackets are the priority numbers from the PCI SSC guidance. Numbers in the guidance range from 1 through 6. A lower number indicates a higher priority.

As we can see from the table, there are several requirements which if addressed sooner, will actually improve an organization’s security posture against potential breaches, based on what we know from the recent breach studies.  I would recommend increasing the priority of the requirements in red to at least 3 if not 2. I do realize that organizations may not be able to afford to address too many requirements at a higher priority. If that is the case, you may want to review the current priority 2 and 3 requirements against the key controls in the table above and then decide to push some of them lower down the priority order as applicable.

Hope this is useful! As always, we welcome your thoughts and comments.

RisknCompliance Services Note

We at RisknCompliance track about a dozen of such reports every year and maintain a up-to-date database of the current security threats and vulnerabilities at a detailed level. We are able to leverage this knowledge in  providing our clients with  a much-wanted third-party assessment of their risk management or audit methodologies and  programs. After all, security risk assessments and audits form the very foundation of risk management or audit programs, so we believe it is critical that every organization fine-tunes its methodologies and  knowledgebase.

Please contact us here if you would like to discuss your needs. We will be glad to talk to you with the details and how we could be of assistance to you.

Verizon 2010 Data Breach Investigations Report – Key takeaways for Security Assessors and Auditors

The Verizon 2010 Data Breach Investigations Report (DBIR) released last week has some interesting findings, just as it did last year. What makes it special this year is that Verizon partnered with the United States Secret Service in developing this report. I don’t intend to discuss all the statistics in this blog (will do so in another upcoming blog) but as you will see explained in the report, the Secret Service’s involvement has thrown new light into some of the findings.

My intention here is to highlight the significance of such a report to security and audit practitioners with the objective of improving the quality of their risk assessments or audits and more importantly, help make the right recommendations to management.  From my experience as a security practitioner and an occasional auditor, I can tell that we may not always be using all the available information to help improve the quality of our risk assessments or audits. And, I think reports such as the Verizon DBIR can provide some valuable help from that standpoint.

Let me explain what I mean… Deliverables for any risk assessment or audit typically include a list of findings and for each finding, we provide an explanation of the risk, the risk severity  (High, Medium, Low) and suitable recommendations for risk mitigation or remediation.  The management would then proceed to remediate various gaps in priority based on our risk rankings. Considering that risk is a product of likelihood and impact (I like the OWASP risk rating methodology, so will use it here), it is important that we get the impact and likelihood right.  Impact is largely a function of the organization’s characteristics including various technical and business factors seen in the methodology. On the other hand, likelihood is a function of threats and vulnerabilities.  I think the DBIR can be a useful reference in estimating the likelihood.

For example, the DBIR says that external agents were responsible for about 78% of the breaches whereas about 48% were caused by insiders. These numbers can be used to arrive at a better objective estimate  of the likelihood that these threat agents may cause any harm. Similarly, the DBIR also says that  48% of the breaches involved privilege misuse, 40% resulted from hacking  and 38% utilized malware. These numbers can be used for objective estimation of the likelihood that associated vulnerabilities could be exploited. The OWASP methodology has an illustration for such objective risk estimation.

These are but a couple of examples. The DBIR has a wealth of information that can be useful to auditors and security practitioners alike, both in improving the quality of their work as well as in being able to defend their risk rankings. We all realize that risk rankings almost always have a level of subjectivity in them but I think reports like the DBIR can be leveraged to make them as objective as possible. A very good example is the risk level one might normally assign to a case of unpatched vulnerability versus a configuration issue.  It may not be readily obvious that one might need to be assigned a higher risk level over another until you read the DBIR. The DBIR tells us that the likelihood of exploitation of an unpatched  vulnerability is far less as compared to a vulnerability caused by a configuration issue. If we didn’t leverage the DBIR (and assuming both issues had equal impacts), we might assign equal risk levels to both the findings or worse, we might assign the unpatched vulnerability a higher risk level.

Over the next couple of weeks, I plan to be blogging with a detailed commentary on some of the findings in the report including a special post on how the report can be leveraged to enhance the effectiveness of PCI DSS programs.

Hope this is useful! As always, we welcome your thoughts and comments.

RisknCompliance Services Note

We at RisknCompliance track about a dozen of such reports every year and maintain a up-to-date database of the current security threats and vulnerabilities at a detailed level. We are able to leverage this knowledge in  providing our clients with  a much-wanted third-party assessment of their risk management or audit methodologies and  programs. After all, security risk assessments and audits form the very foundation of risk management or audit programs, so we believe it is critical that every organization fine-tunes its methodologies and  knowledgebase.

Please contact us here if you would like to discuss your needs. We will be glad to talk to you with the details and how we might be of assistance to you.

Logging for Effective SIEM and PCI DSS Compliance …. UNIX, Network Devices and Databases

In one of my previous blogs, I covered the importance of logging the “right” events for an effective Log Management or Security Information and Event Management (SIEM) deployment … see here or here for a discussion on the two technologies. The blog also provided a suggested listing of the Windows or Active Directory events that you might want to log from a PCI DSS Compliance standpoint.

Clearly, no amount of investment in your Log Management or SIEM solution is going to do much good, unless you have been able to generate all the right logs to begin with … see a related discussion with the recognized PCI Expert and Author, Dr. Anton Chuvakin here.

I would like to extend my suggested list in the previous post to cover a few other systems here,  specifically UNIX/LINUX, Network Devices and Databases. Note that this list is only a starting point so you can work with the respective System Specialists or Administrators in your organization to generate these events.

UNIX/LINUX Logging for Effective SIEM and PCI DSS Compliance

 

Logging of Network Devices for Effective SIEM and PCI DSS Compliance

Database Logging for Effective SIEM and PCI DSS Compliance

PCI DSS – Quick and Dirty?

I recently received a tweet titled “PCI DSS Compliance – Quick and Dirty”. I think it is safe to say that such a title is bound to grab immediate attention of anyone that has been associated with PCI DSS in one form or another. I immediately clicked the link on the tweet which took me to this page.

Not sure what the tweet’s originator meant to convey…  Neither am I  sure there is anyone that knows or has a quick and dirty approach to PCI DSS Compliance. Not unless perhaps, yours is a highly mature Security and Data Protection program…. I mean really high, perhaps the 90th percentile or higher.   PCI DSS being perhaps the most prescriptive security standard out there, the reality is that most organizations will have a fair bit of work to do before they can claim compliance.

The link on the tweet points to the “Prioritized Approach for PCI DSS”. The document was put out by PCI SSC to assist merchants and Service Providers in undertaking a prioritized remediation effort when they may have gaps in a large number of control requirements.  As the document says, the prioritized approach was developed based on extensive feedback from assessments, breaches and investigations, among other things.

Quoting from the document itself… “It is not intended as a substitute, short cut or stop-gap approach to PCI DSS compliance”.

And then, there is this quote … “To achieve PCI DSS compliance, an organization must meet all PCI DSS requirements, regardless of the order in which they are satisfied or whether the organization seeking compliance follows the PCI DSS Prioritized Approach”.

That said, as a security practitioner, I really wish there will come a day when compliance with a standard like PCI DSS can be quick and dirty for most organizations.

New details released regarding Internal Security Assessor (ISA) program for PCI DSS

PCI SSC has just released new details regarding the training schedule for the ISA program. The program is obviously PCI SSC’s response to the often heard complaints from merchants and service providers about high costs involved with maintaining PCI DSS compliance.  Be sure to read the program validation requirements as well as the FAQs.

Key requirements to note are:

  1. ISAs have to be on full –time employment with the sponsor companies. Specifically , ISAs will not retain the certification upon termination of employment and so can’t carry the certification to a new employer.
  2. ISAs need to be recertified annually. The recertification process includes ISA Program training and passing the examination every year.
  3. ISAs have to be part of a dedicated Internal Audit department.

Important to note is the scope/objective of the ISA program which reads as “to improve the organization’s understanding of the PCI DSS, facilitate the organization’s interactions with QSAs, enhance the quality, reliability, and consistency of the organization’s internal PCI DSS self-assessments, and support the consistent and proper application of PCI DSS measures and controls”.  It also says that the “ISA qualification does not entitle an ISA to perform special functions or conduct QSA Assessments".

Here is another interesting blog post on this topic.

Logging for PCI DSS Compliance

PCI DSS has had specific requirements for logging and review of those logs for sometime now. The logging requirements (under Requirement 10 ) have a primary objective of supporting forensics in the event of a breach of cardholder data. I believe it is fair to say that PCI DSS has played a large role in bringing into limelight the topic of Log Management, in effect creating an assured market for several vendors who are vying for a piece of the PCI business out there.

While most Log Management vendor solutions are featured enough and support quick deployments (normally a selling point one hears from most vendors), I believe it is important for PCI merchants and service providers to take that with a grain of salt. Granted that most vendor solutions have features for effective log parsing, normalization, reporting, alerting etc… As I am sure anyone that has worked on PCI DSS (or for that matter any Log Management or SIEM deployments) would attest, an effective deployment requires deliberate planning and ground work. And in my view, the most critical step for an effective Log Management solution (and most certainly those focused on PCI DSS Compliance) is the very first step, which is Log Generation (see NIST 800-92 Guide to Computer Security Log Management to learn more about Log Management processes). After all, you can get to managing and analyzing logs only if you generate them and more importantly from a PCI DSS standpoint, generate all the right logs!

To illustrate the point, below is a partial suggested list of events you might want to log on Windows and Active Directory. One really can’t overemphasize the need for various system administrators to work closely with the PCI readiness teams to make this happen. I have also included sample mappings to PCI DSS requirements, the likes of which you can use to demonstrate due diligence to your QSA.

Hope you find this information useful and I welcome your comments!

 

#

Event Description

Windows Event Id#

 

– Vista or Windows Server 2008

PCI DSS (version 1.2.1) Requirements

Logon events  

1

Successful Logon – Privileged users only

4624

6.3.3, 8.1, 8.5.1, 8.5.4, 8.5.6, 10.2.2

2

Logoffs – Privileged users only

4634

6.3.3, 8.1, 8.5.1, 8.5.4, 8.5.6, 10.2.2

3

Failed Logon attempts – All users

4625

6.3.3, 8.1, 8.5.1, 8.5.4, 8.5.6, 10.2.2

4

Account Lockouts – All users

4740

8.5.13, 10.2.4

5

Account Lockout Release – All users  

4767

8.5.13, 10.2.2, 10.2.4 

6

Privilege escalation through “Run as”

?

10.1, 10.2.1, 10.2.2

 

Object access events  

7

All access to folders containing Cardholder Data

5143

10.2.1

8

Changes to access privileges on folders containing Cardholder Data

4670

10.2.1,10.2.2

9

Changes to ownership on folders containing Cardholder Data (“Take Ownership”)

4670

10.2.1,10.2.2

10

All access to files containing Cardholder Data

4663,?

10.2.1

11

Changes to access privileges on files containing Cardholder Data

4670

10.2.1

12

Changes to ownership on files containing Cardholder Data (“Take Ownership”)

4670

10.2.1,10.2.2

13

Creation or deletion of files in folders containing Cardholder Data

4660, 4663  (Delete)

 

10.2.1

14

Access to (Read, Modify or Delete)  Security Event Logs by anyone other than the Windows system or the account used for log collection by the Log Management Solution

?

10.2.2, 10.2.3, 10.2.6, 10.2.7, 10.5

15

Changes to %SYSTEMROOT%\SYSTEM32  folder contents (System Level Object)

5143

10.2.7

16

A registry value was modified (System Level Object)

4657

10.2.7

 

 Account Management 

17

User Account Created

4720

7.1.4, 8.1, 8.5.1,10.2.2

18

 User Account Enabled

4722

7.1.4, 8.1, 8.5.1, 8.5.6,10.2.2

19

Password Change/Reset Attempted

47239(Change), 4724(Reset)

8.5.3, 8.5.9

20

Account Password Set

4738(?)

8.5.3, 8.5.9

21

User Account Disabled

4725

6.3.3, 7.1.4, 8.1, 8.5.1,8.5.4, 8.5.5,10.2.2

22

User Account Deleted

4726

6.3.3, 7.1.4, 8.1, 8.5.1,8.5.4, 8.5.5,10.2.2

23

User Account Changed

4738

6.3.3, 7.1.4, 8.1, 8.5.1,10.2.2

24

Security Group Created

4727 (Global Group)

4731 (Local Group)

6.3.3, 7.1.1, 7.1.4,10.2.2

25

Security Group Member Added

4728(Global Group)

4732(Local Group)

6.3.3, 7.1.2,10.2.2

26

Security Group Member Removed 

4729(Global Group)

4733(Local Group)

6.3.3, 7.1.4, 8.1, 8.5.1,8.5.4, 8.5.5,10.2.2

27

Security Group Deleted

4730(Global Group)

4734(Local Group)

6.3.3, 7.1.4, 8.1, 8.5.1,8.5.4, 8.5.5,10.2.2

 

Directory Service access events  

28

Creation of new group policies

?

10.2.2, 10.2.7

29

Changes to group (Active directory) or server policies

?

10.2.2, 10.2.7

30

Application of group policies to a container

6144(?)

10.2.2, 10.2.7

 

Privilege use events 

 

Privilege use (Failure only) for the following user groups:

 

31

Server or Domain Administrators

4674(?)

10.2.2

32

Account Operators

4674(?)

10.2.2

33

Accounts (User, service or process) with access to Cardholder Data

4674(?)

10.2.2

 

System events  

34

Windows – Starting up

4608

10.2.2

35

Windows – Shutting down

4609

10.2.2

36

An authentication package was loaded by the Local Security Authority.

4610

10.2.5

37

A trusted logon process has registered with the Local Security Authority.

4611

10.2.5

38

Internal resources allocated for the queuing of security event messages have been exhausted, leading to the loss of some security event messages.

4612

10.2.3, 10.2.6, 10.2.7, 10.5

39

A notification package was loaded by the Security Accounts Manager

4614

10.2.5

40

Server time out of synchronization with Domain Controller

4616(?)

10.4

 

Windows updates 

41

Windows Software Update Services – Successes and Failures

?

6.1

Older posts