PCI DSS and Logging: What You Need To Know by Dr. Anton Chuvakin
•
26 gostaram•20,201 visualizações
This document summarizes key points from a presentation about PCI DSS logging requirements and best practices. The presentation covers: 1. The main PCI DSS logging requirement (Requirement 10) and what it entails, such as collecting, storing, protecting, and reviewing logs. 2. Common myths and mistakes organizations make around PCI logging, such as thinking a log management tool alone ensures compliance. 3. The importance of establishing a log review process to detect security issues and satisfy PCI requirements, including reviewing logs daily using automated tools.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a PCI DSS and Logging: What You Need To Know by Dr. Anton Chuvakin
Semelhante a PCI DSS and Logging: What You Need To Know by Dr. Anton Chuvakin (20)
Mais de Anton Chuvakin
Mais de Anton Chuvakin (20)
Último
Último (20)
PCI DSS and Logging: What You Need To Know by Dr. Anton Chuvakin
- 1. PCI DSS and Logging: What You Need To Know Dr. Anton Chuvakin SecurityWarrior LLC www.securitywarriorconsulting.com Author of “PCI Compliance” PCI Workshop Indianapolis, May 2011
- 2. Outline PCI DSS and logging PCI logging myths and mistakes The hardest + important: log review Setting up a review process Conclusions and Actions Items Q&A
- 4. The Key Piece: Requirement 10 In brief: Must have good logs Must collect logs Must store logs for 1 year Must protect logs Must review logs daily (using an automated system) Requirement 10 for Logging is in SAQ D ONLY!
- 5. Verizon Reports on Logs 5
- 6. … This Year “If there is one positive note that we can squeeze out of these statistics around active measures, it’s that discovery through log analysis and review has dwindled down to 0%.” 6
- 7. PCI DSS Requirement 10.1 What it is? “Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.” What it means? This means that every log of user action should have a user name in it What will QSA check for? ”Verify through observation and interviewing the system administrator, that audit trails are enabled and active for system components” What you MUST do? Log all admin access, actions; make sure logs are tied to user names
- 8. PCI DSS Requirement 10.2 What it is? “Implement automated audit trails for all system components” What it means? Make sure you log all PCI-mandated events on all in-scope systems What will QSA check for? ”Through interviews, examination of audit logs, and examination of audit log settings” verify that this is being done” What you MUST do? Enable logging on all PCI DSS scope systems
- 9. PCI DSS Requirement 10.5 What it is? “Secure audit trails so they cannot be altered.” What it means? Collected logs must be protected from changes and unauthorized viewing What will QSA check for? ”Interview system administrator and examine permissions to verify that audit trails are secured so that they cannot be altered” What you MUST do? Store logs on a secure system and log all access to logs
- 10. PCI DSS Requirement 10.5.3 What it is? “Promptly back up audit trail files to a centralized log server or media that is difficult to alter.” What it means? Logs must be centrally collected What will QSA check for? ” Verify that current audit trail files are promptly backed up to a centralized log server or media that is difficult to alter” What you MUST do? Deploy a log server to collect logs from all PCI systems
- 11. PCI DSS Requirement 10.6 What it is? “Review logs for all system components at least daily. Log reviews must include those servers that perform security functions…, authorization, and accounting protocol servers.” What it means? Collected logs must be reviewed daily What will QSA check for? ”Obtain and examine security policies … to verify that they include procedures to review … logs at least daily and that follow-up to exceptions is required. Through observation and interviews, verify that regular log reviews are performed for all system components.” What you MUST do? Establish a log review process and follow it
- 12. PCI DSS Requirement 10.7 What it is? “Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis.” What it means? Collected logs must be stored for ONE YEAR. What will QSA check for? ”Verify that audit logs are available for at least one year and processes are in place to restore at least the last three months’ logs for immediate analysis.” What you MUST do? Make sure that all PCI logs are stored for a year
- 13. Remember – You MUST Do This TODAY! However … …. while all of this sounds nice (?) HOW to actually do it???
- 14. How NOT To Do it? #4 PCI compliance = collecting logs #3 You need to read every log every day? #2 I can lie to a QSA about my daily review procedures
- 15. THE “How NOT To Do It” #1 Buy some kinda box (Log management, SIEM, etc) from a vendor and never touch it 15
- 16. So, How to Actually DO IT!? How to actually “WALK THE WALK” from reading PCI DSS to having a compliance log management process 16
- 17. Log Policy Adequate logging, that covers both logged event types and details Log aggregation and retention (1 year) Log protection Log review 17
- 18. Log Policy Example “Logs must have: A timestamp Protected data OR sensitive credential must never be included in a log” “Logs produced by University IT resources must be examined on a regular basis in order to protect University IT resources and data. “ 18
- 19. PCI Log Review Log review practices, patterns and tasks – how to look? What to find? Exception investigation and analysis – how to react when found? Validation of these procedures and management reporting – how to prove? 19
- 20. Log Review At a Glance 20
- 21. Wait A Moment … Why? Assure that card holder data has not been compromised by the attackers Detect possible risks to cardholder data, as early as possible Satisfy the explicit PCI DSS requirement for log review. Maybe: help protect other data 21
- 22. Log Review Process 22
- 23. Example…. 23
- 24. Baseline Enable collection Confirm message parsing Select a baseline period: 90 days Summarize messages by type over time Remove known “bad messages” Accept the baseline 24
- 25. Let’s Do It! Step 1 25
- 26. Baseline Enable collection Confirm message parsing Select a baseline period: 90 days Summarize messages by type over time Remove known “bad messages” Accept the baseline 26
- 27. Step 4 27
- 28. Baseline Enable collection Confirm message parsing Select a baseline period: 90 days Summarize messages by type over time Remove known “bad messages” Accept the baseline 28
- 29. Step 5 Known Bad EXAMPLES Login and “access granted” log messages at unusual hour Modifications log messages outside of a change window Any log messages produced by expired user accounts Reboot/restart messages outside of maintenance window Backup/export of data outside of backup windows Log data deletion Logging termination on system or application Any change to logging configuration Any log message that has triggered any action in the past 29
- 30. Step 6 30
- 31. Investigations at a Glance 31
- 32. Review Log Entry 32
- 33. But Who Would Do That? 33
- 34. Escalate On Log Entry 34
- 35. Validation of PCI Log Compliance Presence and adequacy of logging Presence of log review processes and its implementation Exception handling process and its implementation. 35
- 36. Project Plan List of PCI in-scope systems AND applications external, payment processing, others Find out what logging is done on them What events, what details Close the gap between current and PCI-required levels Plan log collection Syslog, Windows, devices, databases, etc Define retention period (1 year) Create log review policies and procedures Implement log review and other tasks – DO IT!
- 37. Conclusions PCI and logs: log, collect, protect, review A log box is NOT (not…not…not!) PCI compliance Log policy is a tool to define what to log and how to look Review process is the key part: think PURPOSE, not TOOLS 37
- 38. How To “Profit” From Compliance? Everything you do for PCI compliance, MUST have security benefit for your organization! Examples: log management, IDS/IPS, IdM, application security , etc
- 39. More Resources Log reviews procedures and tasks: http://chuvakin.blogspot.com/search/label/PCI_Log_Review Blog: www.securitywarrior.org Podcast: look for “LogChat” on iTunes Slides: http://www.slideshare.net/anton_chuvakin Papers: www.info-secure.org and http://www.docstoc.com/profile/anton1chuvakin Consulting: http://www.securitywarriorconsulting.com/
- 40. Want a PCI DSS Book? “PCI Compliance” by Anton Chuvakin and Branden Williams Useful reference for merchants, service providers, vendors – and everybody else in PCI DSS land! http://www.pcicompliancebook.info
- 41. Questions? Dr. Anton Chuvakin Security Warrior Consulting Log management , SIEM, PCI DSS Email:anton@chuvakin.org Site:http://www.chuvakin.org Blog:http://www.securitywarrior.org Twitter:@anton_chuvakin Consulting:http://www.securitywarriorconsulting.com
- 42. More on Anton Consultant: http://www.securitywarriorconsulting.com Book author: “Security Warrior”, “PCI Compliance”, “Information Security Management Handbook”, “Know Your Enemy II”, “Hacker’s Challenge 3”, etc Conference speaker: SANS, FIRST, GFIRST, ISSA, CSI, RSA, Interop, many, many others worldwide Standard developer: CEE, CVSS, OVAL, etc Community role: SANS, Honeynet Project, WASC, CSI, ISSA, OSSTMM, InfraGard, ISSA, others Past roles: Researcher, Security Analyst, Strategist, Evangelist, Product Manager
- 43. Security Warrior Consulting Services Logging and log management strategy, procedures and practices Develop logging policies and processes, log review procedures, workflows and periodic tasks as well as help architect those to solve organization problems Plan and implement log management architecture to support your business cases; develop specific components such as log data collection, filtering, aggregation, retention, log source configuration as well as reporting, review and validation Customize industry “best practices” related to logging and log review to fit your environment, help link these practices to business services and regulations Help integrate logging tools and processes into IT and business operations SIEM and log management content development Develop correlation rules, reports and other content to make your SIEM and log management product more useful to you and more applicable to your risk profile and compliance needs Create and refine policies, procedures and operational practices for logging and log management to satisfy requirements of PCI DSS, HIPAA, NERC, FISMA and other regulations More at www.SecurityWarriorConsulting.com
- 44. Dead But Not Forgotten.. Every time you think “PCI DSS OR security,” god kills a kitten!
Notas do Editor
- RequiredAll University IT resource logs must include:• A timestamp. It is expected that the system’s clock is synchronized using an application such asthe Network Time Protocol (NTP) Service.• Protected data must never be included in a log.• Cleartext authentication credentials (i.e. passwords) must never be included in a log.RecommendedWhen relevant, University IT resource logs should include:• User IDs or other identifiers• Dates, times, and details of events key to the operation of the IT resource• Records of successful and rejected system access attempts• Records of successful and rejected access to University data and other IT resources• Changes to IT resource system configuration• Use of privileged access or operations (to include the use of privileged accounts)• Use of system utilities and applications===============3.2 Log ReviewLogs produced by University IT resources must be examined on a regular basis in order to protectUniversity IT resources and data. Frequency and nature of log monitoring and review depends on therisks to the relevant IT resource and underlying data.Factors used to help determine the time period for review of logging activities include:• Criticality of the IT resource or underlying data• Type of data and its classification stored on the IT resource• Past experience of IT resource vulnerability, exploitation, and/or misuse• Extent of system interconnectedness• The primary purpose of logging on the IT resource• Legal requirements
- The procedures will be provided for using automated log management tools as well as manually when tools are not available or not compatible with log formats produced by the application.
- In other words, “Periodic Log Review Practices” are performed every day (or less frequently, if daily review is impossible) and any discovered exceptions or are escalated to “Exception Investigation and Analysis.” Both are documented as prescribed in “Validation of Log Review” to create evidence of compliance. We will now provide details on all three types of tasks.
- The basic principle of PCI DSS periodic log review (further referred to as “daily log review” even if it might not be performed daily for all the applications) is to accomplish the following:Assure that card holder data has not been compromised by the attackersDetect possible risks to cardholder data, as early as possibleSatisfy the explicit PCI DSS requirement for log review.Even given that fact that PCI DSS is the motivation for daily log review, other goals are accomplished by performing daily log review:Assure that systems that process cardholder data are operating securely and efficientlyReconcile all possible anomalies observed in logs with other systems activities (such as application code changes or patch deployments)In light of the above goals, the daily log review is built around the concept of “baselining” or learning and documenting normal set of messages appearing in logs. Baselining is then followed by the process of finding “exceptions” from the normal routine and investigating them to assure that no breach of cardholder data has occurred or imminent.
- be investigated and escalated as a security incident.Building an Initial Baseline Using a Log Management ToolTo build a baseline using a log management tool perform the following:Make sure that relevant logs from a PCI application are aggregated by the log management toolsConfirm that the tool can “understand” (parse, tokenize, etc) the messages and identify the “event ID” or message type of each logSelect a time period for an initial baseline: “90 days” or “all time” if logs have been collected for less than 90 daysRun a report that shows counts for each message type. This report indicates all the log types that are encountered over the 90 day period of system operationAssuming that no breaches of card data have been discovered , we can accept the above report as a baseline for “routine operation”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.
- Make sure that relevant logs from a PCI application are aggregated by the log management toolsAt this step, we look at the log management tools and verify that logs from PCI applications are aggregated. It can be accomplished by looking at report with all logging devices:
- be investigated and escalated as a security incident.Building an Initial Baseline Using a Log Management ToolTo build a baseline using a log management tool perform the following:Make sure that relevant logs from a PCI application are aggregated by the log management toolsConfirm that the tool can “understand” (parse, tokenize, etc) the messages and identify the “event ID” or message type of each logSelect a time period for an initial baseline: “90 days” or “all time” if logs have been collected for less than 90 daysRun a report that shows counts for each message type. This report indicates all the log types that are encountered over the 90 day period of system operationAssuming that no breaches of card data have been discovered , we can accept the above report as a baseline for “routine operation”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.
- be investigated and escalated as a security incident.Building an Initial Baseline Using a Log Management ToolTo build a baseline using a log management tool perform the following:Make sure that relevant logs from a PCI application are aggregated by the log management toolsConfirm that the tool can “understand” (parse, tokenize, etc) the messages and identify the “event ID” or message type of each logSelect a time period for an initial baseline: “90 days” or “all time” if logs have been collected for less than 90 daysRun a report that shows counts for each message type. This report indicates all the log types that are encountered over the 90 day period of system operationAssuming that no breaches of card data have been discovered , we can accept the above report as a baseline for “routine operation”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.
- Guidance for Identifying “Known Bad” MessagesThe 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.Login and other “access granted” log messages occurring at unusual hourCredential and access modifications log messages occurring outside of a change windowAny log messages produced by the expired user accountsReboot/restart messages outside of maintenance window (if defined)Backup/export of data outside of backup windows (if defined)Log data deletionLogging termination on system or application Any change to logging configuration on the system or application Any log message that has triggered any action in the past: system configuration, investigation, etcOther 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.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.”
- Frequency of Periodic Log ReviewPCI 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 neededLog review is performed using a log management system that collects log in batch mode, and batches of logs arrive less frequently than once a dayApplication 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!While such rare collection is not recommended, it is not entirely uncommon either.
- Specifically, the above process makes use of a log investigative checklist, which is explained below in more details.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:First, look at other log messages triggered 1 minute before and 1 minute after the “suspicious” logSecond, look at other log messages triggered 10 minute before and 10 minute after the “suspicious” logThird, look at other log messages triggered 1 hour before and 1 hour after the “suspicious” logLook 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.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.Look at entries from same source (if applicable): this method involves reviewing all other log messages from the network source address (where relevant). 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 compliance. In this case, we need to acquire information from other systems, such as File Integrity Monitoring (FIM), Patch Management (PM), Change Management (CM) and others.
- 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.
- Just to remind, 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 implementationException handling process and its implementation.Now we can organize the proof around those areas and then build processes to collect such proof.
- Log management and Security Information and Event Management (SIEM) product selection - how to pick the right SIEM and logging product?Develop log management or SIEM product selection criteria (related writing)Identify key use cases aligning log management and SIEM tools with business, compliance and security requirementsPrepare RFP documents for SIEM, SEM, SIM or log managementAssist with analyzing RFP responses from SIEM and log management vendorsEvaluate and test log management and SIEM products together with internal IT security teamAdvise on final product selectionLogging and log management policyLogging and log management policy - how to develop the right logging policy? What to log?Develop logging policies and processes for servers and applications , log review procedures, workflows and periodic tasks as well as help architect those to solve organization problemsInterpret regulations and create specific and actionable logging system settings , processes and log review procedures (example: what to log for PCI DSS?)Plan and implement log management architecture to support your business cases; develop specific components such as log data collection, filtering, aggregation, retention, log source configuration as well as reporting, review and validationCustomize industry "best practices" related to logging and log review to fit your environment, help link these practices to business services and regulations (example)Help integrate logging tools and processes into IT and business operationsSIEM and log management product operation optimization - how to get more value out of the tools available?Clarify security, compliance and operational requirementsTune and customize SIEM and log management tools based on requirementsContent developmentDevelop correlation rules, reports and other content to make your SIEM and log management product more useful to you and more applicable to your risk profile and compliance needsCreate and refine policies, procedures and operational practices for logging and log management to satisfy requirements of PCI DSS, HIPAA, NERC, FISMA and other regulationsTraining - how to get your engineers to use the tools best?Provide the customized training on the tools and practices of log management for compliance, IT operations, or security needs (example training conducted)Develop training on effective operation and tuning of SIEM and log management tools to complement basic vendor training.