INFORMATION SECURITY BRIEFING Session 1 - PCI DSS v3.0: What Has Changed? Session 2 - Malware Threats and Trends Session 3 - You've Been Breached: Now What?
PONDURANCE: WHY ARE WE HERE? Goal: Position Pondurance as an authority in Information Security through the education of our clients and prospective clients Execution: Host quarterly Information Security Briefings with quality topics and speakers at no cost Participate in industry associations such as ISSA, INSPN, OWASP and Midwest Contingency Planners Briefing Format: 3 sessions covering: Session 1 Topics related to Information Security compliance and management Session 2 Quarterly discussion on Malware Threats and Trends Session 3 Panel discussion on current challenges in Information Security 2
TODAY S AGENDA Session 1 - PCI DSS v3.0: What Has Changed? Presenter: Jeff Foresman, Pondurance Partner Session 2 - Malware Threats and Trends Presenters: Chris Blow & Dustin Hutchison, Pondurance Directors Session 3 - You've Been Breached: Now What? Moderator: Ron Pelletier, Pondurance Partner Speakers: Jerry Reichard, Federal Bureau of Investigation (FBI) Dr. Marcus Rogers, Purdue University Mark Swearingen, Hall Render Chuck Taylor, Office of the Indiana Attorney General Reception - Drinks, Appetizers, and Networking 3
PCI DSS V3.0: WHAT HAS CHANGED?
EXPECTATIONS This presentation is. Intended to give you an overview of the changes in the PCI DSS standard This presentation is not. Training on the PCI DSS v3 standard Going to prepare you to do a self assessment Going to teach you how to scope a PCI DSS assessment Going to answer specific questions you have about your companies scope, segmentation or compliance 5
PCI DSS V3 AGENDA Payment Card Security Standards Overview PCI DSS v3 Changes 6
PAYMENT CARD SECURITY STANDARDS OVERVIEW 7
PCI SSC OVERVIEW The PCI Security Standards Council (PCI SSC) is responsible for the development, management, education, and awareness of the PCI Security Standards The Council's five founding global payment brands are: American Express Discover Financial Services JCB International MasterCard Worldwide Visa Inc. Enforcement of compliance and determination of any noncompliance penalties are carried out by the individual payment brands and not by the PCI SSC 8
PCI SSC SECURITY STANDARDS The PCI SSC has issued the following security standards: PCI DSS Addresses the security of applications, databases, systems and networks that process, transmit and store cardholder data PCI PA-DSS Addresses the security of payment applications used to authorize credit and debit card transactions to insure the application works in a manner compliant to PCI DSS PCI PTS Addresses the security of PIN based transactions for device vendors and manufactures PCI P2PE Addresses the security requirements for Point To Point Encryption (P2PE) solution providers to validate their hardware-based solutions 9
PCI DSS V3 CHANGES 10
PCI DSS V3 GENERAL CHANGES Added a new column to describe the intent of each requirement, with content derived from former Navigating PCI DSS guidance document For the security policies and daily operational procedures (formerly requirements 12.1.1 and 12.2), assigned a new requirement number and moved requirements and testing procedures into each of s 1-11 Updated language in requirements and/or corresponding testing procedures for alignment and consistency Separated complex requirements and testing procedures for clarity and removed redundant or overlapping testing procedures Enhanced testing procedures to clarify level of validation expected for each requirement 11
PCI DSS V3 CHANGES SCOPE The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment (CDE) The CDE is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data Examples of system components include but are not limited to the following: Systems that provide security services (for example, authentication servers), facilitate segmentation (for example, internal firewalls), or may impact the security of (for example, name resolution or web redirection servers) the CDE Virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors Network components including but not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances Server types including but not limited to web, application, database, authentication, mail, proxy, Network Time Protocol (NTP), and Domain Name System (DNS) Applications including all purchased and custom applications, including internal and external (for example, Internet) application 12
PCI DSS V3 CHANGES SCOPE At least annually, confirm the accuracy of the PCI DSS scope by identifying all locations and flows of cardholder data To confirm the PCI DSS scope, perform the following: The assessed entity identifies and documents the existence of all cardholder data in their environment, to verify that no cardholder data exists outside of the currently defined CDE Once all locations of cardholder data are identified and documented, the entity uses the results to verify that PCI DSS scope is appropriate (for example, the results may be a diagram or an inventory of cardholder data locations) The entity considers any cardholder data found to be in scope of the PCI DSS assessment and part of the CDE. If the entity identifies data that is not currently included in the CDE, such data should be securely deleted, migrated into the currently defined CDE, or the CDE redefined to include this data The entity retains documentation that shows how PCI DSS scope was determined. The documentation is retained for assessor review and/or for reference during the next annual PCI DSS scope confirmation activity 13
PCI DSS V3 CHANGES SECTION 1 1.1.2 1.1.2 1.1.3 Clarified what the network diagram must include and added new requirement at 1.1.3 for a current diagram that shows cardholder data flows. 1.1.2 Current network diagram that identifies all connections between the cardholder data environment and other networks, including any wireless networks 1.1.3 Current diagram that shows all cardholder data flows across systems and networks Clarified examples of insecure services, protocols, and ports to specify SNMP v1 and v2. 1.1.5 1.1.6 1.1.6.b Identify insecure services, protocols, and ports allowed; and verify that security features are documented for each service. Examples of insecure services, protocols, or ports include but are not limited to FTP, Telnet, POP3, IMAP, and SNMP v1 and v2. Clarification 14
PCI DSS V3 CHANGES SECTION 2 2.2.2 2.2.2 2.2.3 2.4 2.4 Split requirement at 2.2.2 into two requirements to focus separately on necessary services, protocols and ports (2.2.2), and secure services, protocols, and ports (2.2.3). 2.2.2 Enable only necessary services, protocols, daemons, etc., as required for the function of the system. 2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, filesharing, Telnet, FTP, etc. New requirement to maintain an inventory of all system components in scope for PCI DSS. 2.4 Examine system inventory to verify that a list of hardware and software components is maintained and includes a description of function/use for each. Clarification 15
PCI DSS V3 CHANGES SECTION 3 3.4.1 3.4.1 Clarified that logical access for disk encryption must be managed separately and independently of the native operating system authentication and access control mechanisms, and that decryption keys must not be associated with user accounts. 3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts. Clarification 16
PCI DSS V3 CHANGES SECTION 3 Split requirement 3.5.2 into two requirements to focus separately on storing cryptographic keys in a secure form (3.5.2), and in the fewest possible locations (3.5.3). 3.5.2 also provides flexibility with more options for secure storage of cryptographic keys. 3.5.2 3.5.2 3.5.3 3.5.2 Store secret and private keys used to encrypt/ decrypt cardholder data in one (or more) of the following forms at all times: Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key Within a secure cryptographic device (such as a host security module (HSM) or PTS-approved point-ofinteraction device) As key components or key shares, in accordance with an industry-accepted method Clarification 3.5.3 Store cryptographic keys in the fewest possible locations. 17
PCI DSS V3 CHANGES SECTION 3 3.6.6 3.6.6 Clarified principles of split knowledge and dual control. 3.6.6 If manual clear-text cryptographic keymanagement operations are used, these operations must be managed using split knowledge and dual control. Split knowledge of keys, such that key components are under the control of at least two people who only have knowledge of their own key components; AND Dual control of keys, such that at least two people are required to perform any key-management operations and no one person has access to the authentication materials (for example, passwords or keys) of another. Clarification 18
PCI DSS V3 CHANGES SECTION 5 5.1.2 5.3 New requirement to evaluate evolving malware threats for any systems not considered to be commonly affected by malicious software. 5.1.2 For systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software New requirement to ensure that anti-virus solutions are actively running (formerly in 5.2), and cannot be disabled or altered by users unless specifically authorized by management on a per-case basis. 5.3 Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users, unless specifically authorized by management on a case-by- case basis for a limited time period. 19
PCI DSS V3 CHANGES SECTION 6 6.2 6.1 Switched the order of requirements 6.1 and 6.2. 6.1 is now for identifying and risk ranking new vulnerabilities and 6.2 is for patching critical vulnerabilities. Clarified how risk ranking process (6.1) aligns with patching process (6.2). 6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as high, medium, or low ) to newly discovered security vulnerabilities. New security vulnerabilities are identified. A risk ranking is assigned to vulnerabilities to include identification of all high risk and critical vulnerabilities. Processes to identify new security vulnerabilities include using reputable outside sources for security vulnerability information. Clarification 20
PCI DSS 6.1 / 6.2 GUIDANCE The intent of this requirement is that organizations keep up to date with new vulnerabilities that may impact their environment Sources for vulnerability information should be trustworthy and often include vendor websites, industry news groups, mailing list, or RSS feeds Once an organization identifies a vulnerability that could affect their environment, the risk that the vulnerability poses must be evaluated and ranked. The organization must therefore have a method in place to evaluate vulnerabilities on an ongoing basis and assign risk rankings to those vulnerabilities. This is not achieved by an ASV scan or internal vulnerability scan, rather this requires a process to actively monitor industry sources for vulnerability information. Classifying the risks (for example, as high, medium, or low ) allows organizations to identify, prioritize, and address the highest risk items more quickly and reduce the likelihood that vulnerabilities posing the greatest risk will be exploited. 21
PCI DSS V3 CHANGES SECTION 6 6.5.6 6.5.11 New requirement for coding practices to document how PAN and SAD is handled in memory. 6.5.6 Coding techniques document how PAN/SAD is handled in memory, to minimize potential exposure. 6.5.6 is a best practice until June 30, 2015, after which it becomes a requirement. New requirement for coding practices to protect against broken authentication and session management. 6.5.11 Broken authentication and session management are addressed via coding techniques that protect credentials and session IDs, including: Flagging session tokens (for example cookies) as secure Not exposing session IDs in the URL Implementing appropriate time-outs and rotation of session IDs after a successful login Preventing User IDs and passwords from being overwritten through application account functions 6.5.11 is a best practice until June 30, 2015, after which it becomes a requirement. 22
PCI DSS V3 CHANGES SECTION 6 6.6 6.6 Added flexibility by changing webapplication firewall to automated technical solution that detects and prevents webbased attacks. Added note to clarify that this assessment is not the same as vulnerability scans required at 11.2. 6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods: Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes This assessment is not the same as the vulnerability scans performed for 11.2. Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic. Clarification 23
PCI DSS V3 CHANGES SECTION 7 7.1.1 New 7.1.1 to cover definition of access needs for each role, to support requirements 7.1.2 through 7.1.4. 7.1.1 Define access needs for each role, including: System components and data resources that each role needs to access for their job function Level of privilege required (for example, user, administrator, etc.) for accessing resources Clarification 24
PCI DSS V3 CHANGES SECTION 8 Enhanced requirement to include guidance for how users should protect their authentication credentials, including password/phrase reuse and changing password/phrase if there is suspicion that it has been compromised. 8.5.7 8.4 8.4 Develop, implement, and communicate authentication procedures and policies to all users including: Guidance on selecting strong authentication credentials Guidance for how users should protect their authentication credentials Instructions for users not to reuse previously used passwords That users should change passwords if there is any suspicion the password could be compromised Clarification 8.5.1 New requirement for service providers to use different authentication credentials for access to different customer environments. Effective July 1, 2015 8.5.1 Additional requirement for service providers: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer. 25
PCI DSS V3 CHANGES SECTION 9 Clarified the intent of the requirement to identify, distinguish between, and grant access to onsite personnel and visitors, and that badges are just one option (they are not required). 9.2.x 9.2.x 9.2 Develop procedures to easily distinguish between onsite personnel and visitors, to include: Identifying new onsite personnel or visitors (for example, assigning badges) Changes to access requirements Revoking or terminating onsite personnel and expired visitor identification (such as ID badges) Clarification 9.3 New requirement to control physical access to sensitive areas for onsite personnel, including a process to authorize access, and revoke access immediately upon termination. 9.3 Control physical access for onsite personnel to the sensitive areas as follows: Access must be authorized and based on individual job function. Access is revoked immediately upon termination, and all physical access mechanisms, such as keys, access cards, etc., are returned or disabled. 26
PCI DSS V3 CHANGES SECTION 9 9.9.x New requirements to protect point-of-sale devices that capture payment card data from tampering or unauthorized modification or substitution. Effective July 1, 2015 9.9 Examine documented policies and procedures to verify they include: Maintaining a list of devices Periodically inspecting devices to look for tampering or substitution Training personnel to be aware of suspicious behavior and to report tampering or substitution of POS devices NOTE: This includes card-reading devices used in card-present transactions (that is, card swipe or dip) at the point of sale. This requirement is not intended to apply to manual key-entry components such as computer keyboards and POS keypads. 27
PCI DSS V3 CHANGES SECTION 10 10.1 10.1 10.2.5 10.2.5 Clarified that audit trails should be implemented to link access to system components to each individual user, rather than just establishing a process. 10.1 Implement audit trails to link all access to system components to each individual user. Enhanced requirement to include changes to identification and authentication mechanisms (including creation of new accounts, elevation of privileges), and all changes, additions and deletions to accounts with root or administrative access. 10.2.5 Use of and changes to identification and authentication mechanisms including but not limited to creation of new accounts and elevation of privileges and all changes, additions, or deletions to accounts with root or administrative privileges Clarification 28
PCI DSS V3 CHANGES SECTION 10 10.2.6 10.2.6 10.6 10.6.x Enhanced requirement to include stopping or pausing of the audit logs. 10.2.6 Verify the following are logged: Initialization of audit logs Stopping or pausing of audit logs Clarified the intent of log reviews is to identify anomalies or suspicious activity, and provided more guidance about scope of daily log reviews. Also allowed more flexibility for review of certain logs events periodically, as defined by the entity s risk management strategy. 10.6.1 Review the following at least daily: All security events Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD Logs of all critical system components Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion- prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.) Clarification 29
PCI DSS V3 CHANGES SECTION 11 Enhanced requirement to include an inventory of authorized wireless access points and a business justification (11.1.1) to support scanning for unauthorized wireless devices, and added new requirement 11.1.2 to align with an already existing testing procedure, for incident response procedures if unauthorized wireless access points are detected. 11.1.x 11.1.x 11.1 Implement processes to test for the presence of wireless access points (802.11), and detect and identify all authorized and unauthorized wireless access points on a quarterly basis. 11.1.1 Maintain an inventory of authorized wireless access points including a documented business justification. 11.1.2 Implement incident response procedures in the event unauthorized wireless access points are detected. Note: Methods that may be used in the process include but are not limited to wireless network scans, physical/ logical inspections of system components and infrastructure, network access control (NAC), or wireless IDS/IPS. 30
PCI DSS V3 CHANGES SECTION 11 11.3 New requirement to develop and implement a methodology for penetration testing. 11.3 Develop and implement a methodology for penetration testing that: Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115) Includes coverage for the entire CDE perimeter and critical systems Includes testing from both inside the network, and from outside of the network attempting to get in Includes testing to validate any segmentation and scope-reduction controls Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in 6.5 Defines network-layer penetration tests to include components that support network functions as well as operating systems Includes review and consideration of threats and vulnerabilities experienced in the last 12 months Specifies retention of penetration testing results and remediation activities results Effective July 1, 2015. PCI DSS v2.0 requirements for penetration testing must be followed until then. 31
PCI DSS V3 CHANGES SECTION 11 11.3.4 New requirement, if segmentation is used to isolate the CDE from other networks, to perform penetration tests to verify that the segmentation methods are operational and effective. 11.3.4 If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from in-scope systems. 32
PCI DSS V3 CHANGES SECTION 11 11.5 11.5 11.5.1 Increased flexibility by specifying change detection mechanism rather than only file integrity monitoring. 11.5 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly. New requirement to implement a process to respond to any alerts generated by the change-detection mechanism (supports 11.5) 11.5.1 Implement a process to respond to any alerts generated by the change detection solution. Clarification 33
PCI DSS V3 CHANGES SECTION 12 PCI DSS v2 PCI DSS v3 Change 12.1.2 12.2 12.4.1 Moved former 12.1.2 for an annual risk assessment process to 12.2, and clarified that the risk assessment should be performed at least annually and after significant changes to the environment. 12.2 Implement a risk-assessment process that: Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.) Identifies critical assets, threats, and vulnerabilities Results in a formal risk assessment New requirement for information security responsibilities to be assigned such that separation of duties is maintained for security functions. 12.4.1 Information security responsibilities must be assigned such that separation of duties for security functions is maintained. For example, persons tasked with monitoring or auditing a security control should not also be responsible for administering that control. Type 34
PCI DSS V3 CHANGES SECTION 12 12.8 12.8 12.8.2 12.8.2 Clarified intent to implement and maintain policies and procedures to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data. 12.8 Maintain and implement policies and procedures to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data Clarified what the service provider s agreement / acknowledgement must include 12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers will maintain all applicable PCI DSS requirements to the extent the service provider handles, has access to, or otherwise stores, processes, or transmits the customer s cardholder data or sensitive authentication data, or manages the customer's cardholder data environment on behalf of a customer. 35
PCI DSS V3 CHANGES SECTION 12 12.8.5 12.9 New requirement to maintain information about which PCI DSS requirements are managed by the service provider, and which are managed by the entity. 12.8.5 Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity. New requirement for service providers to acknowledge in writing to the customer that they will maintain all applicable PCI DSS requirements to the extent the service provider handles, has access to, or otherwise stores, processes or transmits the customer s cardholder data or sensitive authentication data, or manages the customer's cardholder data environment on behalf of a customer. Effective July 1, 2015 36
Q&A Jeff Foresman jeff.foresman@pondurance.com