• Save
PCI DSS and Logging: What You Need To Know by Dr. Anton Chuvakin
Upcoming SlideShare
Loading in...5
×
 

PCI DSS and Logging: What You Need To Know by Dr. Anton Chuvakin

on

  • 8,989 views

PCI DSS and Logging: What YOU Need To Know by Dr Anton Chuvakin...

PCI DSS and Logging: What YOU Need To Know by Dr Anton Chuvakin

Logging is a critical element in your security program, and it features prominently in PCI. Many merchants, including Higher Ed institutions, can have difficulty implementing all the requirements. In this session one of the leading Logging and SEIM experts will map the PCI DSS logging requirements to a set of actionable procedures and tasks that you can use to achieve and maintain compliance. Bring your questions!

Statistics

Views

Total Views
8,989
Views on SlideShare
8,970
Embed Views
19

Actions

Likes
7
Downloads
0
Comments
0

1 Embed 19

http://www.linkedin.com 19

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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.

PCI DSS and Logging: What You Need To Know by Dr. Anton Chuvakin PCI DSS and Logging: What You Need To Know by Dr. Anton Chuvakin Presentation Transcript

  • 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
  • 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
  • The Requirements
  • 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!
  • Verizon Reports on Logs
    5
  • … 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Remember – You MUST Do This TODAY!
    However …
    …. while all of this sounds nice (?)
    HOW to actually do it???
  • 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
  • THE  “How NOT To Do It”
    #1 Buy some kinda box (Log management, SIEM, etc) from a vendor and never touch it
    15
  • So, How to Actually DO IT!?
    How to actually
    “WALK THE WALK”
    from reading PCI DSS to having a compliance log management process
    16
  • Log Policy
    Adequate logging, that covers both logged event types and details
    Log aggregation and retention (1 year)
    Log protection
    Log review
    17
  • 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
  • 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
  • Log Review At a Glance
    20
  • 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
  • Log Review Process
    22
  • Example….
    23
  • 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
  • Let’s Do It! Step 1
    25
  • 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
  • Step 4
    27
  • 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
  • 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
  • Step 6
    30
  • Investigations at a Glance
    31
  • Review Log Entry
    32
  • But Who Would Do That?
    33
  • Escalate On Log Entry
    34
  • 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
  • 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!
  • 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
  • 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
  • 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/
  • 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
  • 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
  • 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
  • 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
  • Dead But Not Forgotten..
    Every time you think “PCI DSS OR security,”
    god kills a kitten!