PCI Compliance Book Giveaway #2

OK folks, our PCI Compliance book has been out for a few months now, and Branden & I thought it would be fun to give away a copy with another contest! We have assembled a group of three independent judges who will look at the submissions and pick winners for each competition. The winner will receive a free, signed copy of the book! In fact, it would be one of those rare “dual-signed” copies with both of our signatures (and the book will have to travel from TX to CA – or from CA to TX – for this )

So, on to the second contest (first one).

Our book attempts to draw a middle line between the black & white “audit” style of looking at PCI DSS and the loosey-goosey “anything goes” view. We want to take a compliance-friendly and security-friendly, practitioners line. However, sometimes even a compliance guy has to be CREATIVE!

So our second challenge to you, in the comments below, please tell us about your MOST CREATIVE PCI DSS CONTROL you implemented, assessed or even witnessed.

HOWEVER, it will help your submission if such control was also ACCEPTED by a QSA. We will absolutely reject the creative control submissions that have no chance of making your environment PCI DSS compliant…

You’ve got about a week (until the end of December 21st), and we will announce the winners after the holidays!

It doesn’t matter if you comment here or on Branden’s blog, we will capture all of them.

Related posts:

• PCI Compliance Book Giveaway #1
• PCI Compliance Book Giveaway #1 –Results

PCI Compliance Book Giveaway–Results

Our PCI Compliance Book Giveaway has ended – with a bang!  The winning entry (submitted here) is below:

"Hilarious in a sad way, the worst PCI fail I ever had was getting
solicited by a Wedding / Bridal catalog company to assist them in
improving their online ordering and bridal catalog subscription
service. I had no contract with them, this was just a preliminary
"Let's see what we can do for you." They sent us their website, and
also e-mailed me a copy of their site's source code.
In the source code was an SQL dump of over 7 years of brides personal
information including names, addresses, birthdays, and FULL credit
card numbers, expiration dates, CCVs, card type, phone numbers, email
addresses, and unencrypted passwords.
In shock of seeing this, I called the potential client, said we
couldn't help them and deleted the data as completely as I could.
Eek!"

The winner, “James P”, please mail your address to authors@pcicompliancebook.info and we will mail you your signed copy of The PCI Book, 3rd edition. And, no, we won’t charge your credit card for that

The runner-up entries were:

“A very large retailer decides to reorganize their IT department to be more responsive and reactive. As part of that reorganization, they create a group titled 'Enterprise Monitoring' that is responsible for the care/feeding of the log management and analysis solutions. Centralized personnel that actually do the monitoring are pushed out to the business units where, according to IT management, the actual monitoring belongs. Everyone at the meeting announcing this decision says that the name. Enterprise Monitoring, needs to be changed because it gives the impression that the group does the monitoring, but they are over ruled.
Spin ahead almost a year later to their PCI assessment. The monitoring personnel that were pushed out to the business units were, surprise/surprise, were seen as new bodies that could be used for everything BUT monitoring. So, we have great log management and analysis solutions running, but no one has been monitoring anything for almost a year! When asked, the business units point to the Enterprise Monitoring group and say that it is their responsibility because they are 'Enterprise Monitoring'. DUH!” (source)

and

“I work with a stadium and arena concessions operation that once told me they were compliant because they put their card swipe readers on the counter and turned them around to face the customer. They no longer touched the cards so this made them compliant. True story.” (source)

and

“It’s a not a fail, but I certainly found humor in this. When enrolling in training with the PCI Security Standards Council, if you would like pay by credit card they ask that you write your CC#, CVV, Expiration, etc on the invoice and fax it or mail it to them. They note, it is a secure and password protected fax. I expected something a little more from the people who create the standards, but hey that’s one way to reduce your scope. Upon receiving the invoice, it was an LOL moment. ” (source)

MORE PCI Book CONTESTS ARE COMING!! Stand by….

"PCI Compliance", 3rd edition - Out On August 6, 2012

A new edition (3rd) of our book "PCI Compliance" is coming out on August 6, 2012.
It covers PCI DSS 2.0, as requested by many of our readers.  Other new materials include Emerging Technology and Alternative Payment Schemes, PCI for the Small Business, etc. A full ToC for this new edition is here.

Get the book in print or for Kindle!

Cloud HELP NEEDED: Cloud PCI Class Trainer(s)!

Are proficient in BOTH PCI DSS compliance and cloud computing security? If yes, you can help Cloud Security Alliance as well as build your security reputation AND make some money in the process!

Here is how: a few months ago, when I was still consulting, I have created a comprehensive full-day class on PCI DSS and cloud computing. More information is here and a brief description is pasted below:

“The first ever class dedicated to assessing and implementing PCI DSS controls in cloud computing environments covers how to think of and how to do PCI DSS in various cloud computing environments. Focused primarily on people familiar with PCI DSS, it starts from the “hype-free” cloud computing facts and then delves into key scenarios where PCI DSS and clouds overlap in the real world. You will learn where to look while assessing such environments and what pitfalls and mistakes to avoid. It will also cover the shared responsibility between service providers and merchants in implementing PCI DSS controls. Specifically, we will discuss how PCI DSS Requirement 12.8 applies to various cloud scenarios.

The class would be most useful to PCI DSS QSA, organizations offering PCI DSS consulting as well as merchants planning or implementing PCI compliance.”

At this point, I am unable to teach the class due to my employment. CSA is looking for instructors to teach this class in various locations.

Please contact me offline and then will share the current class materials privately as well as explain what this work entails (and connect you to the right people at CSA).

Finally, if you are only CURIOUS about PCI and/or cloud, please save the time you'd otherwise spend typing an e-mail to me….

PCI in the Cloud Class July 8: Location Finalized

Just  a quick announcements about my “PCI in the cloud” class that I am teaching this week.  The location has been finalized:
Location (map):
Ariba Silicon Valley Office
Sequoia Conference Room
910 Hermosa Court,
Sunnyvale, CA
(please use the main entrance and tell receptionist  that you are there for CSA PCI class, lunch and coffee will be provided)
Date: Friday July 8, 2011 at 9AM
There are still, I think, 2-3 seats left at $20/seat (beta price! must provide class feedback!!), so go and register here.

UPDATE: 7/4/2011 5:50PM Sorry, sold out! I will check with the host tomorrow about the room size and there is a slight chance that we can fit more than 25 people, but it is not a certainty.

Possibly related posts:

• PCI DSS in Cloud Computing Environments–THE Training

PCI DSS in the Cloud … By the Council

The long-awaited PCI Council guidance on virtualization has been released [PDF]. Congrats to the Virtualization SIG for the mammoth effort! I rather liked the document, but let the virtualization crowd (and press!) analyze it ad infinitum – I’d concentrate elsewhere: on the cloud! This guidance does not focus on cloud computing, but contains more than a few mentions, all of them pretty generic.

Here are some of the highlights and my thoughts on them.

Section 2.2.6 “Cloud Computing” does contain some potentially usable (if obvious) scope guidance:

“Entities planning to use cloud computing for their PCI DSS environments should  first ensure that they thoroughly understand the details of the services being offered, and perform  a detailed assessment of the unique risks associated with each service. Additionally, as with any  managed service, it is crucial that the hosted entity and provider clearly define and document the  responsibilities assigned to each party for maintaining PCI DSS requirements and any other  controls that could impact the security of cardholder data.“ [emphasis by A.C.]

Now, after spending the last few months working on a training class on PCI DSS in the cloud for Cloud Security Alliance (in fact, I am still finishing the exercises for our July 8 beta run), the above sounds like a total no-brainer. However, I know A LOT of merchants “plan” to make the mistake of “we use PCI-OK cloud provider –> then we are compliant”, which is obviously completely insane (just as PA-DSS payment app does not make you PCI DSS compliant…and never did).

Further, the council guidance clarifies the above with:

”The cloud provider should clearly identify which PCI DSS requirements, system components, and services are covered by the cloud provider’s PCI DSS compliance program. Any aspects of the  service not covered by the cloud provider should be identified, and it should be clearly  documented in the service agreement that these aspects, system components, and PCI DSS requirements are the responsibility of the hosted entity [aka “merchant” – A.C.] to manage and assess. The cloud provider
should provide sufficient evidence and assurance that all processes and components under their  control are PCI DSS compliant.” [emphasis in bold by A.C.]

The above is actually a gem, a nicely condensed version of a pile of challenges and hard problems, all nicely summarized. Indeed, “PCI in the cloud” is largely about the above paragraph, but … there is A LOT OF DEVIL in the details I’d like to draw your attention to the fact that providers have to “provide sufficient evidence and assurance” as opposed to just saying “we got PCI Level 1.” There is a big lesson for cloud providers in  it…

In further sections (section 4.3, mostly), there is some additional useful guidance, such as:

“In a public cloud, some part of the underlying systems and infrastructure is always  controlled by the cloud service provider. The specific components remaining under the control of the cloud provider will vary according to the type of service—for example, Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS). […] Physical separation  between tenants is not practical in a public cloud environment because, by its very nature, all  resources are shared by everyone.” [emphasis by A.C. again; this reminds us that PCI does NOT in fact require such ‘physical’ separation of assets]

On top of this, the Council folks also highlight some of the additional cloud security challenges, affecting PCI DSS, such as (page 24, section 4.3):

• “The hosted entity has limited or no visibility into the underlying infrastructure and related security controls.
• “The hosted entity has no knowledge of ―who‖ they are sharing resources with, or the potential risks their hosted neighbors may be introducing to the host system, data stores, or other resources shared across a multi-tenant environment.” [the section in bold is kind of a hidden big deal! think about it – your payment environment may blow up since your cloud neighbor just annoyed LulzSec by something they said on Twitter…]

The guidance counters these and other challenges with additional controls:

“In a public cloud environment, additional controls must be implemented to compensate for the inherent risks and lack of visibility into the public cloud architecture. A public cloud environment could, for example, host hostile out-of-scope workloads on the same virtualization infrastructure as a cardholder data environment. More stringent preventive, detective, and corrective controls are required to offset the additional risk that a public cloud, or similar environment, could introduce to an entity’s CDE.” [notice MUST, not “may” or “should”; also notice REQUIRED and not “suggested” or “oh wow, would it be nice if…” ]

And if you don’t have such additional controls, then: “These challenges may make it impossible for some cloud-based services to operate in a PCI DSS compliant manner.”

In any case, it was definitely a fun and useful read; hopefully future detailed guidance on PCI in the cloud is coming (given that virtualization SIG took a few years, I am looking forward to 2017 or later here)

BTW, my PCI DSS in the cloud training class will happen on July 8 in Bay Area and you can still sign up.

PCI DSS in Cloud Computing Environments–THE Training

It took many long weeks to create and now it is …. OUT!!! Sign up here now if you are in Bay Area on July 8, 2011. The training is being offered free by the Cloud Security Alliance (well, we ask for $20 to offset the pizza costs) in exchange for your feedback and participation is very limited. I would not be surprised if future production “runs” would cost its attendees 30x-50x of the above “price” since this is a full-day class focused solely on PCI DSS and cloud environments (likely 9AM-4PM with a few breaks).

The initial PCI DSS Cloud  Training Class to be held in Silicon Valley on July 8, 2011, exact location to be determined.

The first ever class dedicated to assessing and implementing PCI DSS controls in cloud computing environments covers how to think of and how to do PCI DSS in various cloud computing environments. Focused primarily on people familiar with PCI DSS, it starts from the “hype-free” cloud computing facts and then delves into key scenarios where PCI DSS and clouds overlap in the real world. You will learn where to look while assessing such environments and what pitfalls and mistakes to avoid. It will also cover the shared responsibility between service providers and merchants in implementing PCI DSS controls. Specifically, we will discuss how PCI DSS Requirement 12.8 applies to various cloud scenarios.

The class would be most useful to PCI DSS QSA, organizations offering PCI DSS consulting as well as merchants planning or implementing PCI compliance.

BTW, in addition to the class materials, I am preparing some “goodies” such as control spreadsheets and implementation tips that should work for various cloud and payment environments. There will be some fun exercises as well!

See you there! I will post updates and maybe even some materials as time progresses.

What To Do When Logs Don’t Help: New Whitepaper

Here is a hard problem: you MUST log, but there are no logs to enable. Or, what is no less common, logs are so abysmal that they don’t help – and don’t fit the regulatory mold (example: PCI DSS Requirement 10.2 and 10.3). Or, logs are “out there in the cloud” and you cannot get them, but compliance is here and requires them.

What to do?

The answer to this eternal question is in my new whitepaper that I have written for Observe-IT (observeit-sys.com)

Executive summary:

This paper covers the critical challenges implementing PCI DSS controls and suggests creative solutions for related compliance and security issues. Specifically, the hard problem of security monitoring and log review in cloud, legacy, and custom application environment is discussed in depth. Additionally, clarification of key PCI DSS compensating controls is provided. This paper will help you satisfy the regulatory requirements and improve security of your sensitive and regulated data.

Short version [PDF] (5 pages)

Extended version [PDF] (13 pages)

As usual, the vendor was paying the bill, but thinking and research are all mine (SecurityWarrior Consulting)

Enjoy!

Possibly related posts / past whitepapers:

• Two New Logging Resources Published 
• New SIEM Whitepaper on Use Cases In-Depth OUT! 
• Another Fun SIEM Whitepaper

PCI Webcast Q&A

From the webcast I’ve done awhile back, here are some fun Q&A that I volunteered to answer. PCI DSS literati reading this blog, don’t freak out – this is BASIC since the webinar was for Level4 ecommerce merchants.

Q: I have a hosted Card Service Provider, are the SSL tunnel with certificates good enough security?  What PCI say about this?
A:  Well, “SSL tunnel with certificates” is good security (at least compared to no SSL!), but is it enough? Not really. PCI DSS has a long list of other security controls which need to be implemented - for example, if are and e-commerce merchant, web application security is extremely important, likely more so than SSL.

Q: Another crystal ball question. Do you think the day will come when merchants are not permitted to store credit card information in order to be PCI compliant?
A: Well, merchants are not permitted to store CVV data today, merchants are not permitted to store PAN in cleartext and they are strongly discouraged to store PANs at all today (example) – all as per PCI DSS. I do not foresee a complete ban on PAN storage, but these rules might well become stronger.  If

Q: If we are not processing cards at all, but instead are protecting client lists, how much security is needed?
A: The beauty of this question is that it is up to you to determine that risk. There are no regulations to compel you so you have to make your own decisions based on your own research. The answer might vary from “none” (if these are essentially public) to “a lot” if loss of those lists will destroy your business.

Q: What about ACHDirect processing?
A: Not under PCI – all risks are yours, same as above. In recent years, a lot of smaller companies have been attacked by ACH credential stealing malicious software.

Q: The question about 2 or 3 things to secure their system.  Could they not just go to dial up credit terminals?
A: They sure can a net will help protect the card data.

Q: How can a criminal use stolen card data for themselves?
A: Charge cards themselves, resell them in bulk, manufacture cards for resale and use (if Track2 data is available), buy and resell goods, buy software and then pirate it, etc, etc, etc. Think what you’d do if you are given a “free credit card”

Q: Retailer that use MPLS networks have historically not had to encrypt data over a "private" network connection like MPLS.  Do you expect MPLS to require data  encryption and firewalling like you find with networks served by public internet connections?
A: No, this is not a “public” network defined in PCI DSS,  at least to the best of my knowledge. So, while encryption and firewalls are “a good idea”, they are not “the law.”  Requirement 4.1 states that “Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks”

Q: When we went to our website provider to close ports as we said it was not PCI compliant. we were told that because there was no CC data being taken through the  site (it's informational only), it doesn't have to be PCI compliant. Is that true?
A: Not exactly true. Public servers are in scope and must be scanned for vulnerabilities; having less open ports will help you have less vulnerabilities exposed to Internet.  Now, if you don’t accept credit cards at all in your business, then obviously your website is not under PCI DSS.

Q: We have a third party vendor that handles our payments; what tools can we use to audit our vendor?
A: Likely, you're talking not about technical tools, but “legal tools” like SLA, agreements, etc.

Q: To be totally honest, we save the CVV number. This is because is it a huge annoyance to have to call the customer every time we need to charge the card. Is there another solution so we don't have to contact our customers for their CVV number?
A: It is OK to save the CVV if you accept the fact that can never be PCI DSS compliant and will always be in violation of your agreement with your acquiring bank. If I were you, I’d ask you acquiring bank about how to do recurring payments without saving the CVV – it IS possible.

Q: Besides a firewall and web application firewall what other layer of security can be used?
A: Yes, many (if you are under SAQ D) – please read PCI DSS. Examples include log management, configuration management, IDS/IPS, FIM, etc, etc.

Q: What about credit card data stored in QuickBooks?
A: QB does have encryption, do you use it? PANs stored in this application are just like any other stored complete PANs: they need to be encrypted.

Q: What IDS/IPS system would you recommend?
A: Snort is free and is hard NOT to recommend for that reason.

Q: I use PayPal website Pro integrated into my site to process payments. Do I still need a firewall to be PCI DSS compliant?
A: It depends how it is used, but most likely yes (and not just a firewall). Read this for details.

Q: If we use a swipe machine, are we storing data, or is it just transmitted?
A: Depends on the machine, likely just transmitted but older machines are known to store data and should be replaced, whenever possible.

Q: How about some websites/books for learning web security
A: Key web security: OWASP and WASC.

Q: What products/solutions do you recommend for managing logs from different types of applications (e.g., web applications) and systems (e.g., /var/log/*) ?
A: Many tools exist with prices from $0 to (literally) millions, here are some of my favorite free log tools.

Q: How do I know if a website is PCI compliant before I accept credit cards? Should the web host give me a certificate?
A: Ah, good question and you are not the only one to wonder about that. But there's no good answer! Many security seals exist (and some mention PCI DSS scanning on them), but their credibility is frequently called into question.

Q: Why hasn't the term 'passphrase' taken off?  I tell all my users, use a pass phrase, with proper punctuation and spacing.
A: Hard to say, this is a really good way to create long while memorable passwords.

Q: We still transmit our payment card data over telephone lines. Is that less risky?
A: Yes, much less risky. Dial-up terminal makes PCI DSS easier and genuinely reduces the risks to cardholder data

Q: On the Who/What do Hackers Target question, what are the constraints for including the company data?  Are all companies included or only ones that require PCI compliance?
A: All data is potentially under risk – but payment card data (and now ACH credentials) are easier to profit from, if you are a criminal. Many companies use PCI DSS to learn about security and then expand their knowledge to protect other kinds of data, beyond the card numbers.

Enjoy the basics!

Possibly related posts:

• Blatant: buy our PCI book NOW!

Peculiar Bit on Compliance vs Risk (Again)

So, yes, seatbelts. One of my favorite compliance metaphors lately, which I have considered infallible (and used everywhere). After all, everybody knows that seatbelts save lives and there is plenty of reliable evidence of that, coming from DoT / NHTSA studies (this one, BTW, is worth a skim for the infosec crowd, for sure), etc. So, we all know that….

However, the other day I was in Russia, traveling to Lake Baikal in particular (long story, but it has to do with my wife’s love of exotic locations, both tropical and permafrost-bound)

Given that it was still winter and given that roads in Russia are …mmm…. not, most locals simply drive on the ice of a lake – it is way smoother, shorter and faster than “doing the road thing.” Besides, that is the only way to reach some lake islands in winter (bonus question for advanced readers: how do the locals get to those islands when the lake is already frozen [no boats], but the ice is too thin for cars or already broken down [no cars]? Answer)

In any case, we got into a car and I started to fasten the seatbelt. At that very moment, the driver looked at me funny and said something along the lines of “Wow, having suicidal thoughts lately, aren’t you?”

And at that moment, risk collided with compliance in my head. Boom! I was one of one of those rare environments where your risk model is completely different (from the one regulators imply when building the regulations) and traditional compliance rules just don’t apply. By the way, even traffic police there will never fine you for “driving on the lake with seatbelts off.”

Well, all others must go do PCI compliance

RSA 2011 PCI Council Interview

Just like last year, I did this great interview with Bob Russo, the GM of PCI Council. There is no audio recording,  what follows below are my notes reviewed by the Council. Italic emphasis is added by me for additional clarity.

Q1. PCI DSS 2.0 is out. What do you think its impact is, so far?
A:

We are just entering the implementation phase, but it seems like there is no major impact yet, it is definitely too early to say what the impact would be.
Using data discovery – merchants looking to confirm that PAN data does not exist outside of the defined PCI DSS scope - seem to be becoming more prominent and this seems to be a direct result of PCI DSS 2.0. Accidental exposure of cardholder data is a known risk. By identifying where the data truly resides first, through a tool or a methodology, should aid organizations in their assessment efforts and ongoing security.
By the way, despite moving to the longer three year process, we can still update the standard in between via errata mechanism [described here – added by A.C.] or using additional guidance produced by the Council and SIGs. For example, if there is a new threat, we can issue additional guidance on how to deal with it within the framework of PCI DSS.

Q2. QSA assessment quality is said to be improving due to QSA QA. On the other hand, reports of many SAQs being “inaccurate” are fairly widespread. Is anything being done to improve SAQ quality at Level2 and smaller merchants?
A:

Well, some merchants do “answer Yes to every question”- is that what you mean by inaccurate?! We see education as the answer to this. For example, there are plans for making SAQ easier to fill in– think about a TurboTax type model for SAQ – a wizard process for answering the pertinent SAQ questions and for presenting the right questions to the merchant in a logical order.
Education efforts can help a merchant understand that honest and accurate SAQ are for “their protection.” Everyone needs to include security in their daily process. The Council will seek to help by providing additional guidance on how to become more secure, comply with the Standards and how to validate that compliance. Some of this is being addressed with the new general Awareness Training we have launched, offering a high level overview of what PCI is and the role that every employee plays in keeping card holder data secure.

Q3. While we are on the SAQ theme, can anything be done to have more merchants stay compliant, not just get validated every year and then forget about PCI DSS until the next validation?
A:

Definitely, more education is needed and we are trying to fill that vacuum, like with the Awareness Trainings we have rolled out. For example, educating merchants that PCI DSS is about data security – not checkbox compliance - is a big focus. Merchants also need to be reminded that they need to get secure and compliant and stay secure and compliant. It requires ongoing vigilance. Unfortunately, some merchants think that “PCI DSS is about a questionnaire and a scan” and this mentality needs to be addressed by educating merchants about data security.

Q4. Visa new EMV rules might make merchants in Europe and Asia care even less about payment data security. What do you think the impact of the new rules will be on PCI?
A:

It is too early to tell at this stage as the rules were announced last week [first week of February 2011 – A.C.]. In essence though, this is a compliance or reporting issue. Nothing has changed for the Council or the standards. PCI DSS still remains the foundation for card security for all payment brands. Ecommerce merchants in those regions remain still must adhere to the PCI DSS even with the new rules. In essence, the new rules imply that the merchants do not need to continue validate compliance, however, we understand that the merchants still has to become and stay compliant, and have proof of that even before considering this program by that brand.
As far as we know, acquirers still plan to get their merchants compliant and validated, so “nothing has changed” for them in the new VISA program. Also, according to public information on the new program, acquirers can still be fined for non-compliance under the new rules as well. This should continue to lead them to get their merchants PCI compliant to reduce the risk of the acquiring bank.
It’s early to tell what merchants think and how they will react to this at this time.

Q5. Will PCI DSS ever move away from the model where the merchants are either compliant with the entire PCI or they are not? Isn’t it better if 100% of merchants implement 10 critical controls vs 10% of all merchants implement 100% of controls?
A:

We are continuing to look at ways for merchants and others in the payment chain to reduce and minimize their card data environment. Some technologies can help, but only if done right. That is why we are putting so much effort in really scrutinizing these technologies to ensure that they are indeed effective, and under circumstances.
For those just starting their compliance journey, using the PCI milestones and Prioritized Approach [see here – A.C.] will also increase in the future. For example, in the new standards we suggest a risk based approach to compliance programs. Mitigate the biggest risks first and you are doing yourself a great favor and moving that much closer to compliance. As an example of this, updating requirement 6.2 to allow vulnerabilities to be ranked and prioritized according to risk. You will hear more from the Council about this in 2011.

Q6. Some QSAs (and merchants) still complain that “QSAs are subjective.” Will there be more prescriptive assessment procedures?
A:

Compliance cannot be absolute and completely objective since merchant environments differ greatly. For example, look at compensating controls – they are an example of flexibility with working with the Standards.
If we get more rigid, and do not include flexibility within the Standard for compensating controls, more people will believe that PCI DSS is forcing them to do things “our way.” We think the current standard is at or close to a balance in this regard, allowing security and flexibility to protect card data within everyone’s own unique environment. People should feel free to ask the PCI Council if there is any doubt about a particular QSA decision.
The Council also receives details on QSA performance, outside of just merchants. We keep a close watch on this to ensure a consistent level of QSA performance. Also, merchants are not the only ones who can report bad QSAs to the Council. [I suspect, although I am not sure, that they are talking about other QSAs here – A.C.]
In addition, we hope that more organizations will take advantage of our Internal Security Assessor program to help their internal employees better understand the process of an external assessment and how to maintain a strong security program between assessments.

Q7. Does council plan to “certify” any other security technologies, like you do for ASV vulnerability scanning?
A:

We do not currently have plans to do so. More guidance will likely be released on using technologies to help with PCI DSS compliance and data security. There are no plans to certify other security technologies in a manner similar to vulnerability scanning and ASVs.
Many technologies, such as possibly logging and log review, may get additional guidance in the future. While the DSS 2.0, added a sub-requirement for payment applications to support centralized logging [PA-DSS Requirement 4.4 – A.C.], it is a known area where many merchants are struggling and additional guidance could go a long way.

Q8. There is definitely a need for more scoping guidance, especially for complex environments, involving virtualization, cloud providers, 3rd party partners, etc. When will scoping SIG guidance be released?
A:

PCI DSS 2.0 does recommend using data discovery for better scoping. We’ve reinforced that all locations and flows of cardholder data should be identified and documented to ensure accurate scoping of cardholder data environment. Merchants should not be guessing at what the scope is, but completely and objectively determine that scope. Simple scoping guidance is a challenge. It is difficult to create a single set of parameters that one can undertake to determine the scope of PCI applicability across a complex environment. It is an inherently complicated task.
However, we hope to provide some additional guidance on this process soon, perhaps, a few steps at a time to begin to help merchants better understand this process.

Enjoy!
Possibly related notes:

• RSA 2010 EXCLUSIVE PCI Security Standards Council Interview

Proactive and Continuous Compliance? For Real?

At one of the first security conferences I ever attended (probably in 2001 or so), there was this vendor dude who would not stop rambling about continuous compliance. I listened to him and it suddenly dawned on me: what an awesome idea! Running a security-focused, ongoing, multi-regulation program that delivers value to both business units and reduces risk – what’s not to love here?

However, over the years I’ve gotten more cynical on this matter; we all know our beloved security industry does this to people As I said in my infamous “Top PCI DSS Security Marketing Annoyances”, ““Ongoing compliance” theme is awesome. Sadly, a majority of your customers [I was addressing security vendors in that post – A.C.] don’t do it like this (to their own loss – this why it is sad). They still have assessment-time rush, pleasing the assessor approach and checklist-oh-we-are-DONE! mentality. If you want to sell continuous compliance, you need to educate them first!”

Despite such sentiment, I still love the idea of continuous, proactive, cross-regulatory approach to compliance. A mere fact that most organizations don’t do it like this, should not discourage the education efforts to make this more common.

In fact, some recent research indicates that maybe – just maybe – the tide is turning and organizations will start revolting against the “annual assessment rush”, “audit mentality” and “audit done? see ya next year, security!” themes. Even if very weak, there are other indicators that the value of running an ongoing compliance program with technical control assessment automation is growing more popular and newer tools may make it more real. Verizon Breach 2010 report and Verizon PCI report also seem to indicate that compliance programs help security, while annual compliance audits only work to unearth negligence and incompetence. The drive to operationalize PCI DSS controls (example) and to stay compliant (example) also seems to be growing, at least among the larger merchants. One more example comes from the whole FISMA theater – NIST folks now are all about “continuous monitoring” for FISMA compliance (see this FAQ).

In light of this, maybe the times of continuous, [more] automated compliance are upon us? It so happens that I’d be doing a SANS webcast to explore this topic on February 11. Join the conversation as well as a fight for useful and continuous compliance in service of security.

Is continuous compliance a reality at your organization? Are you doing something 9, 6, 3 months before the annual PCI DSS assessment? Do you meet the auditor once a year? Or do you make an effort to stay compliant?

Complete PCI DSS Log Review Procedures, Part 18 FINAL

Once upon a time, I was retained to create a comprehensive PCI DSS-focused log review policies, procedures and practices for a large company.  They are focused on PCI DSS compliance, but based on generally useful log review practices that can be utilized by everybody and with any regulation or without any compliance flavor at all. The practices can be implemented with commercial log management or SIEM tools, open source log analysis tools or manually. As you well know, tools alone don’t make anybody compliant!

This is the FINAL, 18th post in the long, long series  (part 1, part 2, part 3 – all parts). A few tips on how you can use it in your organization can be found in Part 1. You can also retain me to customize or adapt it to your needs.

And so we end our Complete PCI DSS Log Review Procedures. Please start reading from Part 1 – at this stage we are deep in the details and these sections might seem out of context without reading earlier parts:

References

The following references are useful for PCI DSS log review program and log management in general:

SANS CAG/CSC

“Twenty Critical Security Controls for Effective Cyber Defense: Consensus Audit Guidelines”

http://www.sans.org/critical-security-controls/

Specifically, the relevant control on audit logs is shown below:

“Critical Control 6: Maintenance, Monitoring, and Analysis of Audit Logs”

NIST 800-92 Logging Guide

“Guide to Computer Security Log Management: Recommendations of the National Institute of Standards and Technology by Karen Kent and Murugiah Souppaya”

http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf

NIST 800-66 HIPAA Guide

“An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule ”

http://csrc.nist.gov/publications/nistpubs/800-66-Rev1/SP-800-66-Revision1.pdf

Appendix A Recommended Logbook Format

Logbook entry:

1. Date/time/time zone this logbook entry was started

2. Name and role of the person starting the logbook entry

3. Reason it is started: log exception (copied from log aggregation tool or from the original log file), make sure that the entire log is copied, especially its time stamp (which is likely to be different from the time of this record) and system from which it came from (what/when/where, etc)

4. Detailed on why the log is not routine and why this analysis is undertaken

5. Information about the system that produced the exception log record or the one this log exception is about

a. Hostname

b. OS

c. Application name

d. IP address(s)

e. Location

f. Ownership (if known)

g. System criticality (if defined and applicable)

h. Under patch management, change management, FIM, etc

6. Information about the user whose activity produced the log (if applicable)

7. Investigation procedure followed, tools used, screenshots, etc

8. Investigative actions taken

9. People contacted in the course of the log analysis

10. Impact determine during the course of the analysis

11. Recommendations for actions, mitigations (if needed)

Follow PCI_Log_Review to see all posts.

Possibly related posts:

• Incident Log Review Checklist
• All posts tagged PCI_Log_Review

Complete PCI DSS Log Review Procedures, Part 17

Once upon a time, I was retained to create a comprehensive PCI DSS-focused log review policies, procedures and practices for a large company.  They are focused on PCI DSS compliance, but based on generally useful log review practices that can be utilized by everybody and with any regulation or without any compliance flavor at all. The practices can be implemented with commercial log management or SIEM tools, open source log analysis tools or manually. As you undoubtfully know, tools alone don’t make anybody compliant!

This is the 17th, one before last,  post in the long series of 18 posts (part 1, part 2, part 3 – all parts) – this is a very important part as it contains the summary of key periodic operational procedures. Please consider reading from Part 1 – at this stage we are deep in the details and these sections might seem out of context without reading earlier parts. A few tips on how you can use it in your organization can be found in Part 1. You can also retain me to customize or adapt it to your needs.

And so we continue with our Complete PCI DSS Log Review Procedures:

Periodic Operational Task Summary

The following chapter contains a summary of operational tasks related to logging and log review. Some of the tasks are described in detail in the document above; others are auxiliary tasks needed for successful implementation of PCI DSS log review program.

Daily Tasks

The table below contains daily tasks, responsible role that performs them as well as what record or evidence is created of their execution:

Task	Responsible Role	Evidence
Review all the types of logs produced over the last day as described in the daily log review procedures	Security administrator, security analyst, (if authorized) application administrator	Record of reports being run on a log management tool
(As needed) investigate the anomalous log entries as described in the investigative procedures	Security administrator, security analyst, (if authorized) application administrator	Recorded logbook entries for investigated events
(As needed) take actions as needed to mitigate, remediate or reconcile the results of the investigations	Security administrator, security analyst, (if authorized) application administrator, other parties	Recorded logbook entries for investigated events and taken actions
Verify that logging is taking place across all in-scope applications	Application administrator	Create a spreadsheet to record such activities for future assessment
(As needed) enabled logging if disabled or stopped	Application administrator	Create a spreadsheet to record such activities for future assessment

Weekly Tasks

The table below contains weekly tasks, responsible role that performs them well as what record or evidence is created of their execution:

Task	Responsible Party	Evidence
(If approved by a QSA) Review all the types of logs produced on less critical application over the last day as described in the daily log review procedures	Security administrator, security analyst, (if authorized) application administrator	· Record of reports being run on a log management tool. · Record of QSA approval for less frequent log reviews and reasons for such approval
(As needed) investigate the anomalous log entries as described in the investigative procedures	Security administrator, security analyst, (if authorized) application administrator	Recorded logbook entries for investigated events
(As needed) take actions as needed to mitigate, remediate or reconcile the results of the investigations	Security administrator, security analyst, (if authorized) application administrator, other parties	Recorded logbook entries for investigated events and taken actions

Monthly Tasks

The table below contains daily tasks, responsible role that performs them as well as what record or evidence is created of their execution:

Task	Responsible Party	Evidence
Prepare a report on investigated log entries	Security analyst, security manager	Prepared report (to be filed)
Report on observed log message types	Security analyst, security manager	Prepared report (to be filed)
Report on observed NEW log message types	Security analyst, security manager	Prepared report (to be filed)
(If approved by a QSA) Review all the types of logs produced on non-critical applications over the last day as described in the daily log review procedures	Security administrator, security analyst, (if authorized) application administrator	· Record of reports being run on a log management tool. · Record of QSA approval for less frequent log reviews and reasons for such approval
(As needed) investigate the anomalous log entries as described in the investigative procedures	Security administrator, security analyst, (if authorized) application administrator	Recorded logbook entries for investigated events
(As needed) take actions as needed to mitigate, remediate or reconcile the results of the investigations	Security administrator, security analyst, (if authorized) application administrator, other parties	Recorded logbook entries for investigated events and taken actions

Quarterly Tasks

The table below contains daily tasks, who performs them as well as what record or evidence is created of their execution:

Task	Responsible Party	Evidence
Verify that all the system in scope for PCI are logging and that logs are being reviewed	Security analyst, security manager	Recorded logbook entries for review and exception follow-up
Review daily log review procedures	Security analyst, security manager	Updates to logging procedures; change log
Review log investigation procedures	Security analyst, security manager	Updates to logging procedures; change log
Review collected compliance evidence	Security analyst, security manager	Compliance evidence; evidence review log
Review compliance evidence collection procedures	Security analyst, security manager	Updates to procedures; change log

Annual Tasks

The table below contains daily tasks, who performs them as well as what record or evidence is created of their execution:

Task	Responsible Party	Evidence
Review logging and log review policy	CSO	Policy changes; change log; policy review meeting minutes
Review compliance evidence before the QSA assessment	PCI DSS compliance project owner	Meeting minutes or other record
Live tests with anomalies	As needed	Logs or other records of such tests

To be continued.

Follow PCI_Log_Review to see all posts.

Possibly related posts:

• Incident Log Review Checklist
• All posts tagged PCI_Log_Review

Complete PCI DSS Log Review Procedures, Part 16

Once upon a time, I was retained to create a comprehensive PCI DSS-focused log review policies, procedures and practices for a large company.  They are focused on PCI DSS compliance, but based on generally useful log review practices that can be utilized by everybody and with any regulation or without any compliance flavor at all. The practices can be implemented with commercial log management or SIEM tools, open source log analysis tools or manually. As you undoubtfully know, tools alone don’t make anybody compliant!
This is the 16th post in the long series  that is nearing the end (part 1, part 2, part 3 – all parts). A few tips on how you can use it in your organization can be found in Part 1. You can also retain me to customize or adapt it to your needs.
And so we continue with our Complete PCI DSS Log Review Procedures (please consider reading from Part 1 – at this stage we are deep in the details and these sections might seem out of context without reading earlier parts):

Management Reporting

In addition for compliance evidence, validation activities can be used to report the success of a log management program, processes and procedures to senior management. The data accumulated in the above sections as proof of organization-wide PCI DSS compliance can also be used for management reporting. Specifically, the following are useful reports that can be produced from the data:
· Presence and adequacy of logging
o Percentage of all systems / regulated data systems covered by logging (the latter should be 100%)

· Presence of defined  log review processes and their implementation
o Log policy and procedure changes
o Application under log review
o Log entries reviewed

· Exception handling process and its implementation
o Log exceptions handled by type, analyst name, etc
o Exception escalated to incident response
o (if relevant) Risk reduced due to timely escalation or incident prevention
o Resources saved due to timely escalation or incident prevention
o Application performance improvement due to log review

· Other log management program reporting
o Overall compliance readiness (PCI DSS and other)

Finally, let’s summarize all periodic operational tasks the organization should be executing in connection with log review.
To be continued.
Follow PCI_Log_Review to see all posts.
Possibly related posts:

• Incident Log Review Checklist
• All posts tagged PCI_Log_Review

Complete PCI DSS Log Review Procedures, Part 15

Once upon a time, I was retained to create a comprehensive PCI DSS-focused log review policies, procedures and practices for a large company.  They are focused on PCI DSS compliance, but based on generally useful log review practices that can be utilized by everybody and with any regulation or without any compliance flavor at all. The practices can be implemented with commercial log management or SIEM tools, open source log analysis tools or manually. As you undoubtfully know, tools alone don’t make anybody compliant!

This is the 15th post in the long, long series  (part 1, part 2, part 3 – all parts). A few tips on how you can use it in your organization can be found in Part 1. You can also retain me to customize or adapt it to your needs.

And so we continue with our Complete PCI DSS Log Review Procedures (please consider reading from Part 1 – at this stage we are deep in the details and these sections might seem out of context without reading earlier parts):

PCI Compliance Evidence Package

Finally, it is useful to create a “PCI Compliance Evidence Package” based on the established and implemented procedures to show it to the QSA. It will help establish your compliance with three key of PCI DSS logging requirements:

· Presence and adequacy of logging

· Log review

· Exception handling

While it is possible to prepare the evidence package before the assessment, it is much easier to maintain it on the ongoing basis. For example, keep printed or electronic copies of the following:

1. Logging policy that covers all of the PCI DSS in-scope systems

2. Logging and log review procedures (this document)

3. List of log sources – all systems and their components (applications) from the in-scope environment

4. Sampling of configuration files that indicate that logging is configured according to the policy (e.g. /etc/syslog.conf for Unix, screenshots of audit policy for Windows, etc)

5. Sampling of logs from in-scope systems that indicate that logs are being generated according to the policy and satisfy PCI DSS logging requirements

6. Exported or printed report from a log management tools that shows that log reviews are taking place

7. Up-to-date logbook defined above

This will allow always establishing compliant status and proving ongoing compliance.

To be continued.

Follow PCI_Log_Review to see all posts.

Possibly related posts:

• Incident Log Review Checklist
• All posts tagged PCI_Log_Review

Complete PCI DSS Log Review Procedures, Part 14

Once upon a time, I was retained to create a comprehensive PCI DSS-focused log review policies, procedures and practices for a large company.  They are focused on PCI DSS compliance, but based on generally useful log review practices that can be utilized by everybody and with any regulation or without any compliance flavor at all. The practices can be implemented with commercial log management or SIEM tools, open source log analysis tools or manually. As you undoubtfully know, tools alone cannot and do not make anybody compliant!

This is the 14th post in the long, long series  (part 1, part 2, part 3 – all parts). A few tips on how you can use it in your organization can be found in Part 1. You can also retain me to customize or adapt it to your needs.

And so we continue with our Complete PCI DSS Log Review Procedures (please consider reading from Part 1 – at this stage we are deep in the details and these sections might seem out of context without reading earlier parts):

Example Logbook Entry

Here is an example following the above pattern:

1. Date/time/time zone this logbook entry was started: November 23, 2009, 4:15PM PST

2. Name and role of the person starting the logbook entry: Anton Chuvakin, principal consultant.

3. Reason the logbook entry is started: log exception (copied from log aggregation tool or from the original log file), make sure that the entire log is copied, especially its time stamp (which is likely to be different from the time of this record) and system from which it came from (what/when/where, etc):

Time/date of log: 10/21/2009 10:01:23 PM PST

System: OLGA.example.com

4. Detailed on why the log is not routine and why this analysis is undertaken: this event ID (Windows event ID 11) from this application event source (Source crypt32) was never seen before on any of the systems where logs are reviewed across our organization.

5. Information about the system that produced the exception log record or the one this log exception is about

a. Hostname: OLGA.example.com

b. OS: Windows XP SP 3

c. Application name: N/A

d. IP address(s): 10.1.1.1

e. Location: Home office

f. Ownership (if known): Olga Chuvakin, President and CEO

g. System criticality (if defined and applicable): critical, main laptop of the executive

h. Under patch management, change management, FIM, etc: yes

6. Information about the user whose activity produced the log: N/A, no user activity involved

7. Investigation procedure followed, tools used, screenshots, etc: procedure for “Initial Investigation” described above

8. Investigative actions taken: following the procedure for “Initial Investigation” described above, it was determined that this log entry is followed by a successful completion of the action logged. Specifically, on the same day, 1 second later the following log entry appeared:

This entry indicates the successful completion of the action referenced in our exception log entry and thus no adverse impact from the error/failure is present.

9. People contacted in the course of the log analysis: none

10. Impact determine during the course of the analysis: impact was determined to be low to non-existent; no functionality was adversely affected, no system was at risk.

11. Recommendations for actions, mitigations (if needed): no mitigation needed, added this log entry to baseline to be ignored in the future as long as the subsequent log entry exists.

The logbook of that sort is used as compliance evidence since it establishes log exceptions follow-up, required in item 10.6.a of PCI DSS validation procedure, which states “Obtain and examine security policies and procedures to verify that they include procedures to review security logs at least daily and that follow-up to exceptions is required.”

The logbook (whether in electronic or paper form) can be presented to a QSA or other auditor, if requested. I recommend retaining the log book for 3 years or at least 2x of the log retention period (1 year for PCI DSS)

To be continued.

Follow PCI_Log_Review to see all posts.

Possibly related posts:

• Incident Log Review Checklist
• All posts tagged PCI_Log_Review

Complete PCI DSS Log Review Procedures, Part 13

Once upon a time, I was retained to create a comprehensive PCI DSS-focused log review policies, procedures and practices for a large company.  They are focused on PCI DSS compliance, but based on generally useful log review practices that can be utilized by everybody and with any regulation or without any compliance flavor at all. The practices can be implemented with commercial log management or SIEM tools, open source log analysis tools or manually. As you undoubtfully know, tools alone don’t make anybody compliant!

This is the 13th post in the long, long series  (part 1, part 2, part 3 – all parts). A few tips on how you can use it in your organization can be found in Part 1. You can also retain me to customize or adapt it to your needs.

And so we continue with our Complete PCI DSS Log Review Procedures (please consider reading from Part 1 – at this stage we are deep in the details and these sections might seem out of context without reading earlier parts):

Logbook – Evidence of Exception of Investigations

How to create a logbook that proves that you are reviewing logs and following up with exception analysis, as prescribed by PCI DSS Requirement 10? The logbook is used to document everything related to analyzing and investigating the exceptions flagged during daily review. While the same logbook approach is used in the incident handling process (such as SANS Incident Response Workflow), in this document it is utilized as compliance evidence.

The logbook should record all systems involved, all people interviewed, all actions taken as well as their justifications, what outcome resulted, what tools and commands were used (with their results), etc.

Here is one recommendation for a logbook entry:

Recommended Logbook Format

Logbook entry:

1. Date/time/time zone this logbook entry was started

2. Name and role of the person starting the logbook entry

3. Reason it is started: log exception (copied from log aggregation tool or from the original log file), make sure that the entire log is copied, especially its time stamp (which is likely to be different from the time of this record) and system from which it came from (what/when/where, etc)

4. Detailed on why the log is not routine and why this analysis is undertaken

5. Information about the system that produced the exception log record or the one this log exception is about

a. Hostname

b. OS

c. Application name

d. IP address(s)

e. Location

f. Ownership (if known)

g. System criticality (if defined and applicable)

h. Under patch management, change management, FIM, etc.

6. Information about the user whose activity produced the log (if applicable)

7. Investigation procedure followed, tools used, screenshots, etc

8. Investigative actions taken

9. People contacted in the course of the log analysis

10. Impact determine during the course of the analysis

11. Recommendations for actions, mitigations (if needed)

To be continued.

Follow PCI_Log_Review to see all posts.

Possibly related posts:

• Incident Log Review Checklist
• All posts tagged PCI_Log_Review

Complete PCI DSS Log Review Procedures, Part 10

Once upon a time, I was retained to create a comprehensive PCI DSS-focused log review policies, procedures and practices for a large company.  It is focused on PCI DSS, but based on generally useful log review practices that can be utilized by everybody and with any regulation or without any compliance flavor at all.

This is the tenth post in the long, long series (part 1, part 2, part 3 – all parts). A few tips on how you can use it in your organization can be found in Part 1. You can also retain me to customize or adapt it to your needs.

And so we continue with our Complete PCI DSS Log Review Procedures:

Exception Investigation and Analysis

A message not fitting the profile of a normal is flagged “an exception.” It is important to note that an exception is not the same as a security incident, but it might be an early indication that one is taking place.

At this stage we have an individual log message that is outside of routine/normal operation. How do we figure out whether it is significant, determine impact on security and PCI compliance status?

Initial Investigation

The following high-level investigative process (“Initial Investigation”) is used on each “exception” entry (more details are added further in the document):

Specifically, the above process makes use of a log investigative checklist, which is explained below in more details.

 

1. Look at log entries at the same time: this technique involves looking at an increasing range of time periods around the log message that is being investigated. Most log management products can allow you to review logs or to search for all logs within a specific time frame. For example:

a. First, look at other log messages triggered 1 minute before and 1 minute after the “suspicious” log

b. Second, look at other log messages triggered 10 minute before and 10 minute after the “suspicious” log

c. Third, look at other log messages triggered 1 hour before and 1 hour after the “suspicious” log

 

2. Look at other entries from same user: this technique includes looking for other log entries produced by the activities of the same user. It often happens that a particular logged event of a user activity can only be interpreted in the context of other activities of the same user. Most log management products can allow you to “drill down into” or search for a specific user within a specific time frame.

 

3. Look at the same type of entry on other systems: this method covers looking for other log messages of the same type, but on different systems in order to determine its impact. Learning when the same message was products on other system may hold clues to understanding the impact of this log message.

 

4. Look at entries from same source (if applicable): this method involves reviewing all other log messages from the network source address (where relevant).

 

5. Look at entries from same app module (if applicable): this method involves reviewing all other log messages from the same application module or components. While other messages in the same time frame (see item 1. above) may be significant, reviewing all recent logs from the same components typically helps to reveal what is going on.

 

In some cases, the above checklist will not render the result. Namely, the exception log entry will remain of unknown impact to security and PCI DSS compliance. In this case, we need to acquire information from other systems, such as File Integrity Monitoring, Vulnerability Management, Anti-malware, Patch Management, Identity Management, Network Management and others.

To be continued.

Follow PCI_Log_Review to see all posts.

Possibly related posts:

• Incident Log Review Checklist
• All posts tagged PCI_Log_Review

Complete PCI DSS Log Review Procedures, Part 9

Once upon a time, I was retained to create a comprehensive PCI DSS-focused log review policies, procedures and practices for a large company.  It is focused on PCI DSS, but based on generally useful log review practices that can be utilized by everybody and with any regulation or without any compliance flavor at all.

This is the ninth post in the long, long series (part 1, part 2, part 3 – all parts). A few tips on how you can use it in your organization can be found in Part 1. You can also retain me to customize or adapt it to your needs.

Today’s section covers one of the most critical parts of any log review process – the main daily workflow! Pay attention, please

And so we continue with our Complete PCI DSS Log Review Procedures:

Main Workflow: Daily Log Review

This is the very central piece of the log review – comparing the logs produced over the last day (in case of a daily review) with an accumulated baseline.

Daily workflow follows this model:

This diagram summarizes the actions of the log analyst who performs daily log review. Before we proceed, the issue of frequency of the log review needs to be addressed.

Frequency of Periodic Log Review

PCI DSS requirement 10.6 explicitly states that “Review logs for all system components at least daily.” It is assumed that daily log review procedures will be followed every day. Only your QSA may approve less frequent log reviews, based on the same principle that QSAs use for compensating controls. What are some of the reasons when less frequent log reviews may be approved? The list below contains some of the reasons why daily log review may be performed less frequently than every day.

· Application or system does not produce logs every day. If log records are not added every day, then daily log review is unlikely to be needed

· Log review is performed using a log management system that collects log in batch mode, and batches of logs arrive less frequently than once a day[1]

· Application does not handle or store credit card data; it is only in scope since it is directly connected to

Remember that only your QSA’s opinion on this is binding and nobody else’s!

How does one actually compare today’s batch of logs to a baseline? Two methods are possible; both are widely used for log review – the selection can be made based on the available resources and tools used. Specifically:

Out of the two methods, the first method only considers log types not observed before and can be done manually as well as with tools. Despite its simplicity, it is extremely effective with many types of logs: simply noticing that a new log message type is produced is typically very insightful for security, compliance and operations.

For example, if log messages with IDs 1,2,3,4,5,6 and 7 are produced every day in large numbers, but log message with ID 8 is never seen, each occurrence of such log message is reason for an investigation. If it is confirmed that the message is benign and no action is triggered, it can be later added to the baseline.

So, the summary of comparison methods for daily log review is:

 

· Basic method:

o Log type not seen before (NEW log message type)

 

· Advanced methods:

o Log type not seen before (NEW log message type)

o Log type seen more frequently than in baseline

o Log type seen less frequently than in baseline)

o Log type not seen before (for particular user)

o Log type not seen before (for particular application module)

o Log type not seen before (on the weekend)

o Log type not seen before (during work day)

o New user activity noted (any log from a user not seen before on the system)

 

While following the advanced method, other comparison algorithms can be used by the log management tools as well.

After the message is flagged as an exception, we move to a different stage in our daily workflow – from daily review to investigation and analysis.

---

[1] While such rare collection is not recommended, it is not entirely uncommon either.

To be continued.

Follow PCI_Log_Review to see all posts.

Possibly related posts:

• Incident Log Review Checklist
• All posts tagged PCI_Log_Review