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â¦.
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:
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.
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.
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
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!
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.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?
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.
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.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?
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.
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.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?
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.
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.Q6. Some QSAs (and merchants) still complain that âQSAs are subjective.â Will there be more prescriptive assessment procedures?
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.
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.Q7. Does council plan to âcertifyâ any other security technologies, like you do for ASV vulnerability scanning?
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.
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.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?
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.
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.Enjoy!
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.
Possibly related notes:
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?
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
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
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
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
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
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
This is the 12th 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 pieces might seem out of context without reading earlier parts):
Validation of Log Review
Final and critical part of compliance-motivated log review is making sure that there is sufficient evidence of the process, its real-world implementation and diligence in following the log review process. The good news here is that the same data can be used for management reporting about the logging and log review processes, so you are not doing just for PCI DSS compliance.Letâs determine what documentation should be produced as proof of log review.
First, the common misconception is that having the actual logs provides that. That is not really true: âhaving logsâ and âhaving logs reviewedâ are completely different and sometime years of maturing the security and compliance program separates one and the other. Please make sure that your team members keep that in mind.
Just as a reminder, we have several major pieces that we need to prove for PCI DSS compliance validation. Here is the master-list of all compliance proof we will assemble. Unlike other sections, here we will cover proof of logging and not just proof of log review since the latter is so dependent on the former:
· Presence and adequacy of logging
· Presence of log review processes and its implementation
· Exception handling process and its implementation.
Now we can organize the proof around those areas and then build processes to collect such proof.
Proof of Logging
The first category is: proof of presence and adequacy of logging. This section is the easiest to prove out of the three.The following items serve as proof of logging:
1. Documented logging policy, covering both logged events and details logged for each event
2. System / application configuration files implementing the above policy
3. Logs produced by the above applications while following the policy.
As stated previously, your QSA is the ultimate judge of what proof of compliance will be adequate for your organization. These tips has been known to be found adequate, but see disclaimers in earlier parts for details.
Proof of Log Review
The second category: proof of log review processes and its implementation. This section is harder to prove compared to the previous one.The following items serve as proof of log review:
1. Documented logging policy, covering log review
2. Documented operational procedures, detailing the exact steps taken to review the logs
3. Records of log review tasks being executed by the appropriate personnel (some log management products create an audit log of reviewed reports and events; such audit trail should cover it â the case of manual review is covered below) â think about this item as âlog review logâ
4. Also, records of exceptions being investigated (next section) indirectly proves that log review is taken place as well.
Proof of Exception Handling
The third category: proof of exception handling process and its implementation. This section is by far the hardest to prove out of these three.The following items serve as proof of log exception process:
1. Documented logging policy, covering exceptions and their handling
2. Documented operational procedures, detailing the exact steps taken to investigate exceptions found during log review (this document)
3. A log of all exceptions investigated with actions taken (âlogbookâ)
The above evidence should provide ample proof that the organization follows PCI DSS guidance with diligence. Letâs focus on producing this proof â the table has the details.
| PCI Compliance Logging Sub-Domain | Proof of Compliance | How to Obtain Proof? |
| Proof of presence and adequacy of logging | Documented logging policy | Create policy, if not present |
| Proof of presence and adequacy of logging | System / application configuration files | After deployment, preserve the configuration files as a master copy |
| Proof of presence and adequacy of logging | Logs produced by the above applications | Collect sample logs and save as proof of compliance |
| Proof of log review | Documented logging policy | Create policy, if not present |
| Proof of log review | Documented operational procedures | <this document!> |
| Proof of log review | Records of log review tasks being executed | Either use the tool or create a âlogbookâ (format below) |
| Proof of log review | Records of exceptions being investigated | Create a âlogbookâ of investigations |
| Proof of exception handling | Documented logging policy | Create policy, if not present |
| Proof of exception handling | Documented operational procedures | <this document!> |
| Proof of exception handling | A log of all exceptions investigated | Create a âlogbookâ of investigations or âknowledge baseâ |
The critical item from the above list is âa logbookâ that is used to record exception follow-up and investigation, thus creating powerful evidence of compliance with PCI DSS requirements. In a more advanced form, the logbook can even grow into an investigative âknowledge baseâ that contains all past exception analysis cases.
To be continued.
Follow PCI_Log_Review to see all posts.
Possibly related posts:
- Incident Log Review Checklist
- All posts tagged PCI_Log_Review
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 11th 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 read in order- at this point we are pretty deep in the details and this piece might look out of context):
External Information Sources Investigation
Here is the procedure to follow in this case:
This procedure can be expanded to cover other sources of information available at the organization.
The main idea of this procedure it to identify and then query information sources (such as IdM, change management, integrity checking, network flow analysis, etc), based on the type of the exception log entry and then to identify its impact and the required actions (if any)
The procedure works to roughly identify the type of a log entry and then to query the relevant information sources. In some cases, then the log entry is deemed to be an indication of a serious issue, incident response process is triggered.
However, it sometimes happens that neither the preliminary analysis nor the query of external systems yields the results and the âexceptionâ log entry is exceptional. In this case, the collaborative workflow is triggered. See the next section for details
Escalation to Others Procedure â Collaborative Workflow
The investigation and escalation process is shown below:
![clip_image002[5]](http://lh4.ggpht.com/_eCy8mZux-aI/TQ-eISNHHmI/AAAAAAAANC8/dEKkh3o8I1Q/s1600-h/clip_image002%5B5%5D%5B3%5D.jpg "clip_image002[5]")
This process allows tapping into the knowledge of other people at the organization who might know what this âanomalyâ is about.
The main idea of this procedure it to identify and then interview the correct people who might have knowledge about the events taking place on the application then to identify its impact and the required actions (if any).
The very last resource is to query the application vendor; such info request is typically time consuming or even expensive (depends on the support contract available) so it should be used sparingly.
To be continued.
Follow PCI_Log_Review to see all posts.
Possibly related posts:
- Incident Log Review Checklist
- All posts tagged PCI_Log_Review
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
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
Recent:
- "You Got That SIEM. How What Do You Do?" at BayThreat 2010 in San Jose, CA
Presentation is embedded below and available here:
Upcoming:
- Webinar with Intel and NRF on Tokenization âAddress Network Security & Dramatically Reduce PCI DSS Scope with Gateway Tokenizationâ (Basic PCI DSS) on 12/14/2010 at 10AM PST
- Focus.com webinar with Tripwire âAchieve PCI Compliance and Ensure Security in a Data Delugeâ (Basic PCI DSS) on 12/15/2010 at 10AM PST
Enjoy!
This is the eighth 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:
Building an Initial Baseline Manually
To build a baseline without using a log management tool has to be done when logs are not compatible with an available tool or the available tool has poor understanding of log data (text indexing tool). To do it, perform the following:1. Make sure that relevant logs from a PCI application are saved in one location
2. Select a time period for an initial baseline: â90 daysâ or âall timeâ if logs have been collected for less than 90 days; check the timestamp on the earliest logs to determine that
3. Review log entries starting from the oldest to the newest, attempting to identify their types
4. Manually create a summary of all observed types; if realistic, collect the counts of time each message was seen (not likely in case of high log data volume)
5. Assuming that no breaches of card data have been discovered in that time period , we can accept the above report as a baseline for âroutine operationâ
6. An additional step should be performed while creating a baseline: even though we assume that no compromise of card data has taken place, there is a chance that some of the log messages recorded over the 90 day period triggered some kind of action or remediation. Such messages are referred to as âknown badâ and should be marked as such.
Example: Building an Initial Baseline Manually
Here is an example process of the above, performed on a Windows system in-scope for PCI DSS that also contains PCI DSS application called âSecureFAIL.â1. Make sure that relevant logs from a PCI application are saved in one location
First, verify Windows event logging is running:
a. Go to âControl Panelâ, click on âAdministrative Toolsâ, click on âEvent Viewerâ
b. Right-click on âSecurity Logâ, select âProperties.â The result should match this:
c. Next, review audit policy
Second, verify SecureFAIL dedicated logging:
a. Go to âC:\Program Files\SecureFAIL\Logsâ
b. Review the contents of the directory, it should show the following:
2. Select a time period for an initial baseline: â90 daysâ or âall timeâ if logs have been collected for less than 90 days; check the timestamp on the earliest logs to determine that
a. Windows event logs: available for 30 days on the system, might be available for longer
b. SecureFAIL logs: available for 90 days on the system, might be available for longer
Baselining will be performed over last 30 days since data is available for 30 days only.
3. Review log entries starting from the oldest to the newest, attempting to identify their types
a. Review all using MS LogParser tool (can be obtained http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en).
Run the tool as follows:
C:\Tools\LogParser.exe "SELECT SourceName, EventCategoryName, Message INTO event_log_summary.txt GROUP BY EventCategoryName FROM Security'" -resolveSIDs:ON
and review the resulting summary of event types.
b. Open the file âsecureFAIL_log-082009.txtâ in notepad and review the entries. LogParser tool above may also be used to analyze logs in plain text files (detailed instructions on using the tool fall outside the scope of this document)
4. Manually create a summary of all observed types; if realistic, collect the counts of time each message was seen (not likely in case of high log data volume)
This step is the same as when using the automated tools â the baseline is a table of all event types as shown below:
| Event ID | Event Description | Count | Average Count/day |
| 1517 | Registry failure | 212 | 2.3 |
| 562 | Login failed | 200 | 2.2 |
| 563 | Login succeeded | 24 | 0.3 |
| 550 | User credentials updated | 12 | 0.1 |
| 666 | Memory exhausted | 1 | 0.0 |
Assuming that no breaches of card data have been discovered in that time period, we can accept the above report as a baseline for âroutine operation.â However, during the first review it logs, it might be necessary to investigate some of the logged events before we accept them as normal (such as the last even in the table). The next step explains how this is done.
5. An additional step should be performed while creating a baseline: even though we assume that no compromise of card data has taken place, there is a chance that some of the log messages recorded over the 90 day period triggered some kind of action or remediation. Such messages are referred to as âknown badâ and should be marked as such.
Same as when using the automated log management tools, we notice the last line, the log record with an event ID = 666 and event name âMemory exhaustedâ that only occurred once during the 90 day period. Such rarity of the event is at least interesting; the message description (âMemory exhaustedâ) might also indicate a potentially serious issue and thus needs to be investigated as described below in the investigative procedures.
What are some of the messages that will be âknown badâ for most applications?
Guidance for Identifying âKnown Badâ Messages
The following are some rough guidelines for marking some messages as âknown badâ during the process of creating the baseline. If generated, these messages will be looked at first during the daily review process. MANY site-specific messages might need to be added but this provides a useful starting point.1. Login and other âaccess grantedâ log messages occurring at unusual hour[1]
2. Credential and access modifications log messages occurring outside of a change window
3. Any log messages produced by the expired user accounts
4. Reboot/restart messages outside of maintenance window (if defined)
5. Backup/export of data outside of backup windows (if defined)
6. Log data deletion
7. Logging termination on system or application
8. Any change to logging configuration on the system or application
9. Any log message that has triggered any action in the past: system configuration, investigation, etc
10. Other logs clearly associated with security policy violations.
As we can see, this list is also very useful for creating âwhat to monitor in near-real-time?â policy and not just for logging. Over time, this list should be expanded based on the knowledge of local application logs and past investigations.
After we built the initial baselines we can start the daily log review.
[1] Technically, this also requires a creation of a baseline for better accuracy. However, logins occurring outside of business hours (for the correct time zone!) are typically at least âinterestingâ to 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
