HITRUST Common Security Framework Summary of Changes
|
|
|
- Erick Brown
- 9 years ago
- Views:
Transcription
1 HITRUST Common Security Framework Summary of Changes Apr-14 CSF 2014 V6.1 Incorporates changes in PCI-DSS v3 and updates stemming from the HIPAA Omnibus Final Rule. Includes mappings to the v1. Fundamental to HITRUST s mission is the availability of a Common Security Framework (CSF) that provides the needed structure, clarity, functionality and cross-references to authoritative sources. The initial development of the CSF leveraged nationally and internationally accepted standards including ISO, NIST, PCI, HIPAA, and COBIT to ensure a comprehensive set of baseline security controls. The CSF normalizes these security requirements and provides clarity and consistency, reducing the burden of compliance with these requirements that apply to healthcare organizations. HITRUST ensures the CSF stays relevant and current to the needs of organizations by regularly updating the CSF to incorporate new standards and regulations as authoritative sources. This interim 2014 CSF (v6.1) release includes changes based on feedback from the community and an updated set of cross-references and security requirements based on the 2013 release of the HIPAA Final Rule (Omnibus), PCI-DSS v3.0, and ISO/IEC 27001:2013 and 27002:2013, as well as the early 2014 release of the NIST Framework for Improving Critical Infrastructure Cybersecurity. The table below provides a summary of the changes to the CSF broken down by Specification and Implementation Requirement. Other Updates In conjunction with this CSF update, HITRUST has taken the opportunity to also make updates to its CSF Assurance Program. 1
2 Green text indicates an addition to the control/requirement. Red text indicates a deletion from the control/requirement. CSF 0.a 1 0.a 1 0.a 2 ISO/IEC ID.GV-4 ISO/IEC ISO/IEC (a) ISO/IEC ISO/IEC ISO/IEC (d) ISO/IEC (e)(1) ISO/IEC (f) ISO/IEC ISO/IEC ISO/IEC (e) ISO/IEC ISO/IEC ISO/IEC (a) ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC (b) ISO/IEC (f) ISO/IEC (c) ISO/IEC ISMS addresses all information security risks, including cybersecurity This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission of HITRUST, LLC. 2
3 0.a 2 0.a 3 01.a 1 PR.IP-7 ISO/IEC ISO/IEC (b) ISO/IEC ISO/IEC (c) ISO/IEC (d) ISO/IEC (e) ISO/IEC (f) ISO/IEC (g) ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC (b) ISO/IEC (c) ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC ISO/IEC (b) ISO/IEC (c) ISO/IEC (d) ISO/IEC (e) ISO/IEC (g) ID.GV-3 PDCA requirement Consistent with relevant legislation policy language 3 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
4 01.a 2 01.b 1 01.b 1 01.b 1 01.b 1 01.b 1 01.b 1 01.b 1 01.b 1 01.b 1 Removed: Removed: Removed: Removed: Updated: Updated: ISO/IEC A DE.CM-3 PR.AC-1 PR.AC-4 PCI DSS v PCI DSS v2 8.1 Monitoring of guest/anonymous, shared/group, emergency and temporary accounts Registration/de-registration part of requirement to manage identities and credentials Consistent with need-to-know, needto-share language 01.b addresses user registration but does not require formally assigning the responsibilities for administering accounts to an individual or team; this will be addressed by 05.c Requirement not addressed in 01.b but is addressed in 01.q, which is already mapped. PCI DSS v2 8.1 Requirement is addressed by 01.p PCI DSS v2 8.2 PCI DSS v PCI DSS v PCI DSS v v Language is contained in level 3 vice level 1 remapped in PCI DSS v3 remapped in PCI DSS v3 4 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
5 01.b 1 01.b 1 01.b 1 01.b 1 01.b 1 01.b 2 01.b 3 Updated: Updated: Updated: Removed: Updated: Removed: PCI DSS v PCI DSS v PCI DSS v v PCI DSS v PCI DSS v PCI DSS v PCI DSS v PCI DSS v3 8.4 ISO/IEC A ISO/IEC A PCI DSS v2 8.2 remapped in PCI DSS v3 remapped in PCI DSS v3 remapped in PCI DSS v3 Requirement is addressed in 01.f level 1 remapped in PCI DSS v3 Language is contained in level 3 vice level 1 01.b 3 Account creation, modification, disabling, and removal actions shall be automatically logged and audited providing notification, as required, to appropriate individuals. PCI DSS v Identical language is contained in 09.aa, 3, which is already mapped to This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
6 01.c PCI Data 01.c 1 01.c 1 01.c 1 A service provider shall protect each organization s hosted environment and data by: i. ensuring that each organization only runs processes that only have access to that organization s cardholder data environment, and ii. restricting each organization s access and privileges to only its own cardholder data environment. Updated: PCI DSS v3 A.1.1 PCI DSS v3 A.1.2 ISO/IEC A PR.AC-4 PCI DSS v PCI DSS v Specific language for a service provider to restrict access and privileges of users and processes to an entity s cardholder data environment is specific to PCI Access permissions consistent with privilege management remapped in PCI DSS v3 01.c 1 The allocation of privileges Privileges shall be allocated to users on a need-to-use basis and on an event-by-event basis in line with the access control policy (e.g. i.e. the minimum requirement for their functional role, e.g., user or administrator, only when needed). PCI DSS v New content for is addressed by existing CSF 01.c content in 1 6 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
7 01.c 1 01.c 2 01.c 2 01.c 2 01.c 2 01.c 2 01.c 2 The allocation of privileges for all systems and system components shall be controlled through a formal authorization process. None Subject to PCI Compliance 2 Regulatory Factor Removed: Administrator or operator registration and deregistration shall be in accordance with the defined process and the sensitivity and risks associated with the system (see 01.b). Updated: Updated: Removed: Access controls are implemented via an automated access control system. PCI DSS v Administrative change PR.DS-5 NIST SP r4 AC-2 PCI DSS v PCI DSS v PCI DSS v PCI DSS v PCI DSS v Modified language to specifically address the requirement No PCI references remain in level 3 after PCI DSS v was moved to 01.v as PCI DSS v3 8.7 Consistent with requirement to allow authorized users to determine whether access authorizations assigned to business partners are valid This particular requirement is duplicative of the same requirements in 01.b, for which AC-2 is already mapped; other AC-2 requirements remain valid for this control remapped in PCI DSS v3 remapped in PCI DSS v3 Requirement content is completely new and does not map to 01.c 2; requirement is not supported by any other cross-reference at level 2 7 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
8 01.c 2 01.c 2 01.c 3 01.c 3 Removed: Subject to PCI Compliance, 2 Regulatory Factor Removed: PCI DSS v3 A.1.1 Process privileges map to 01.c PCI DSS v3 A.1.2 Administrative change DE.CM-3 Organizational (i.e., user) access and privileges maps to 01.c No PCI references remain in level 3 after PCI DSS v was moved to 01.v as PCI DSS v3 8.7 Consistent with requirement to audit execution of privileged functions on information systems 01.c 3 The organization shall restrict the use of database management utilities to only authorized database administrators. Users shall be prevented from accessing database data files at the logical data view, field, or field-value levels. Column-level access controls shall be implemented to restrict database access. PCI DSS v Requirement is more closely related to 01.v, Information Access Restriction, rather than 01.c, Privilege Management; content and PCI mapping moved; content not specific to remaining mappings for this level 01.d 1 x. passwords shall be prohibited from being reused for at least four (4) generations for users or six (6) generations for privileged users; and Administrative change Language updated to reflect NIST/CMS/PCI requirements and consistency with 01.f for password management 8 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
9 01.d 1 01.d 1 01.d 1 01.d 1 01.d 1 01.d 1 01.d 1 01.d 1 Removed: Removed: Removed: Removed: Updated: Updated: Updated: PR.AC-1 PCI DSS v PCI DSS v PCI DSS v PCI DSS v PCI DSS v PCI DSS v PCI DSS v PCI DSS v PCI DSS v PCI DSS v Password management is part of credential management remapped in PCI DSS v3 incorporated into v with v incorporated into v with v ; control requirement addressed in 01.d Requirement not addressed by language in 01.d level 1; requirement is addressed by 01.q level 1 remapped in PCI DSS v3 remapped in PCI DSS v3 remapped in PCI DSS v3 01.d 1 Alternatively, passwords/phrases must have a strength (entropy) at least equivalent to the parameters specified above. PCI DSS v PCI DSS v updated to in v3; language added to reflect additional flexibility afforded by the updated PCI control 9 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
10 01.d 2 01.d 2 01.d 2 Updated: Removed: ISO/IEC A PCI DSS v2 8.4 PCI DSS v PCI DSS v remapped in PCI DSS v3 Requirement is addressed in 01.f 1 01.e 1 01.e 1 01.e 2 The following procedures shall be carried out to ensure the regular review of access rights by management: i. user's access rights shall be reviewed after any changes, such as promotion, demotion, or termination of employment, or other arrangement with a workforce member ends; and ii. user s access rights shall be reviewed and reallocated when moving from one employment or workforce member arrangement to another within the same organization. HIPAA (a)(3)(ii)(C) PR.AC-4 ISO/IEC A Omnibus Rule expanded requirement for termination procedures from employees to all types of workforce members Recertification supports access permission management 10 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
11 01.f 1 01.f 1 01.f 1 01.f 1 01.f 1 01.f 1 01.f 1 01.f 1 01.f 1 Removed: Removed: Removed: Updated: Updated: Updated: Updated: ISO/IEC A PR.AC-1 Consistent with credential management PCI DSS v requirement addressed in 01.d PCI DSS v Requirement is addressed by 01.p PCI DSS v Requirement is addressed by 01.p PCI DSS v PCI DSS v3 8.4 PCI DSS v PCI DSS v PCI DSS v PCI DSS v PCI DSS v PCI DSS v remapped in PCI DSS v3 remapped in PCI DSS v3 remapped in PCI DSS v3 remapped in PCI DSS v3 11 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
12 01.f 1 01.g 1 01.g 1 01.h 1 01.h 1 01.i 1 01.i 1 01.i 2 01.i 2 Password management policies shall be developed, documented, and adopted and communicated to all users to address the need to: PCI DSS v3 8.4 ISO/IEC A PR.AC-2 ISO/IEC A PR.PT-2 PR.PT-3 ISO/IEC A ISO/IEC A ID.AM-4 Modified to support updated lanagueage in PCI DSS v3 Physical access protections for unattended user equipment Protections for removable media addressed by clean desk requirements Networks and network services are information assets to which users are authorized access Cataloguing is consistent with requirement for the identification of external information systems 12 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
13 01.i 2 PR.IP-1 Baseline configuration requirement related to identification of necessary ports and services 01.j PCI Data 01.j 1 01.j 1 01.j 1 01.j 1 01.j 1 The organization shall incorporate two-factor authentication for remote network access originating from outside the network by personnel (including users and administrators) and all third parties (including vendor access for support and maintenance). Updated: PCI DSS v3 8.3 DE.CM-1 PR.AC-1 PR.AC-3 PR.PT-4 PCI DSS v PCI DSS v PCI requirement is more stringent than existing language in 01.j level 1 Addresses monitoring requirements for remote and wireless access Addresses credential and authentication requirements Directly related to management of remote user access Addresses access controls for networks remapped in PCI DSS v3 13 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
14 01.j 1 01.k 1 01.l 1 01.l 2 01.m 1 01.m 1 Remote access to business information across public networks shall only take place after successful identification and authentication. Remote access by vendors and business partners (e.g., maintenance, reports or other data access) Vendors accounts for remote maintenance shall be disabled unless specifically authorized by the management. If remote maintenance is performed, the organization shall closely monitor and control any activities, with immediate deactivation after use. Remote access to business partner accounts shall also be immediately deactivated after use. Removed: PCI DSS v PR.AC-1 PR.PT-3 PR.IP-1 PCI DSS v3 1.1 PCI DSS v Updated the language to reflect the addition of business partners to the remote access restriction Addresses identification and authentication requirements for equipment Addresses physical access to ports / network equipment Specifying allowable ports and services is part of baseline / configuration management Supports sub-requirement PCI DSS v , which are mapped to the control Requirement renumbered to in PCI DSS v3 14 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
15 01.m 1 01.m 2 PCI DSS v ISO/IEC A Requirement renumbered to in PCI DSS v3 01.m 2 A baseline of network operations and expected data flows for users and systems shall be established and managed. Separate domains shall then be implanted by controlling the network data flows according to applicable flow control policies. DE.AE-1 Added language from NIST framework for additional clarity. 01.m 2 01.m 2 01.m 2 01.m 2 01.m 2 ID.AM-3 PR.AC-4 PR.AC-5 PR.DS-5 PR.PT-4 Data flow requirement Restricting access via VLANs for user groups is related to the requirement to manage access permissions Segregation requirement Segmentation is one mechanism used to help prevent data leakage Requirements apply to all network segments, including those for communications and control 15 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
16 01.n 1 01.n 1 01.n 1 01.n 2 01.n 2 01.n 2 01.o 1 01.o 1 01.o 2 DE.AE-1 PR.AC-3 PR.DS-5 DE.CM-1 PR.AC-5 PR.PT-4 PR.AC-5 PR.DS-5 ID.AM-3 Deny all, permit by exception policy supports establishment of a baseline of network operations and expected data flows Related to restriction of a user s ability to connect to the internal network Specified network protections help prevent data leakage Requirement to limit number of remote connections is specifically made to support comprehensive network monitoring Provides requirements supporting network segregation Requirements apply to all network segments, including those for communications and control Requires segregation and protections between internal and external network Specified network protections help prevent data leakage Requires routing controls to be based on positive source and destination address checking mechanisms 16 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
17 01.o 2 01.p 1 01.p 1 01.p 1 01.p 3 Updated: Updated: PR.PT-4 PR.AC-1 PCI DSS v PCI DSS v PCI DSS v PCI DSS v ISO/IEC A Specifies protection of internal directory services and IP addresses, which also supports protection of communications and control networks Secure log on procedures support identity and credential management requirements remapped in PCI DSS v3 remapped in PCI DSS v3 01.q PCI Data The organization shall not use group, shared, or generic IDs, passwords, or other authentication methods as follows: i. generic user IDs are disabled or removed. ii. shared user IDs do not exist for system administration and other critical functions. iii. shared and generic user IDs are not used to administer any system components. PCI DSS v3 8.5 PCI requirements are more stringent than existing language in 01.q 1 17 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
18 01.q PCI Data 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.) PCI DSS v PCI requirement specific to service providers 01.q PCI Data 01.q 1 01.q 1 Where other authentication mechanisms are used (e.g., physical or logical security tokens, smart cards, and certificates), use of these mechanisms shall be assigned as follows: i. authentication mechanisms must be assigned to an individual account and not shared among multiple accounts. ii. Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access. Updated: PCI DSS v3 8.6 PR.AC-1 PCI DSS v2 8.1 PCI DSS v PCI requirement related to unique credentials is more stringent; placed in PCI segment Specifically addresses user identification and authentication requirements, e.g., verifiable unique IDs remapped in PCI DSS v3 18 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
19 01.q 1 01.q 1 01.q 1 01.q 1 Removed: Updated: PCI DSS v2 8.3 PCI DSS v PCI DSS v3 8.5 PCI DSS v PCI DSS v3 8.1 No relevant language in 01.q level 1 (language in level 2 addresses communications through an external network rather than originating from outside the network); requirement is addressed by 01.j level 1 remapped in PCI DSS v3 User authentication for use of information technology is explicitly addressed by 01.q, User identification and authentication New content in 8.1 is addressed by existing content in 01.q 1 01.q 1 01.q 2 01.q 2 Before allowing access to system components or data, tthe organization shall require verifiable unique ID's for all types of users Removed: PCI DSs v ISO/IEC A PCI DSS v2 3.2 Modified existing content to more accurately reflect the requirement Requirement for authentication is related to authentication of the payment card rather than the user; content in 3.2, 3.2.1, and is better addressed in 09.q, Information handling procedures 19 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
20 01.q 2 During the registration process to provide new or replacement hardware tokens, in-person verification shall be required PCI DSS v is addressed by in-person registration requirement for tokens; language added for clarity 01.q 2 01.q 2 01.r 1 01.r 1 01.r 2 01.s 1 01.s 1 Removed: PCI DSS v PCI DSS v3 8.6 PR.AC-1 PCI DSS v ISO/IEC A PR.AC-4 PR.AC-4 New requirement related to unique credentials but specific to service providers; content placed in PCI segment New requirement related to unique credentials is more stringent; content placed in PCI segment Specifically addresses password (credential) management Requirement not addressed by language in 01.r level 1; requirement is addressed by 01.q level 1 Requires user identification, authentication, and authorization for access to system utilities Requires user identification, authentication, and authorization for access to system utilities 20 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
21 01.s 1 01.s 1 01.s 2 01.t 1 01.t 1 01.u 1 Updated: PR.DS-5 PR.PT-3 ISO/IEC A ISO/IEC A PCI DSS v PCI DSS v ISO/IEC A Restricting access to system utilities helps prevents misconfiguration (intentional or not), which supports data leakage prevention Directly related to the control of access to systems and assets remapped in PCI DSS v3 01.v PCI Data Where there is an authorized business need to allow the copying, moving, and storage of cardholder data onto local hard drives and removable electronic media for personnel accessing cardholder data via remote-access technologies, the organization s usage policies shall require the data be protected in accordance with all applicable PCI DSS requirements. PCI DSS v Requirement specific to cardholder data / PCI DSS 21 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
22 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows: 01.v PCI Data i. all user access to, user queries of, and user actions on databases are through programmatic methods. only database administrators have the ability to directly access or query databases. ii. PCI DSS v3 8.7 Requirements specific to cardholder data 01.v 1 01.v 1 01.v 1 01.v 2 Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes). PR.AC-4 PR.DS-5 PR.PT-3 ISO/IEC A Directly related to information access restriction Information access restriction directly supports DLP Directly related to the control of access to systems and assets 22 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
23 Updated: 01.v 3 For individuals accessing covered sensitive information (e.g., covered information, cardholder data) from a remote location, prohibit the copy, move, print (and print screen) and storage of cardholder data this information onto local hard drives and removable electronic media, unless explicitly authorized for a defined business need. PCI DSS v Updated language to correct discrepancy between covered information and cardholder data and make the requirement more generic 01.v 3 The organization shall restrict the use of database management utilities to only authorized database administrators. Users shall be prevented from accessing database data files at the logical data view, field, or field-value levels. Column-level access controls shall be implemented to restrict database access. PCI DSS v3 8.7 Requirement was moved from 01.c, Privilege Management, as it is most closely related to 01.v, Information Access Restriction. Language more specific to cardholder data added in the PCI segment 01.w 2 01.x 1 01.x 1 PR.AC-5 ISO/IEC A PR.DS-1 Sensitive system isolation directly related to network segregation Encryption requirements supports protection of data at rest 23 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
24 01.x 1 01.y 1 01.y 1 01.y 1 01.y 1 01.y 3 02.a 1 02.a 1 02.a 1 02.a 1 PR.IP-1 PR.AC-3 PR.DS-2 PR.DS-3 PR.IP-1 ISO/IEC A ISO/IEC A DE.DP-1 ID.AM-6 ID.GV-3 Provides baseline configuration requirements for mobile devices Remote access requirements Encryption requirements supports protection of data in motion/transit Requires return of equipment Sets baseline configuration requirements for teleworking equipment General language regarding security roles and responsibilities, which would include identification, protection, detection, response and recovery Specifically addresses roles & responsibilities Roles & responsibilities include compliance (legal, regulatory) language 24 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
25 02.a 1 02.a 1 02.b 1 02.b 1 02.b 1 02.c 1 02.c 1 02.c 1 02.c 1 PR.IP-11 PCI DSS v ISO/IEC A PR.DS-5 PR.IP-11 ID.AM-6 ID.GV-3 PR.DS-5 PR.IP-11 Requires establishment of security roles and responsibilities; HR-related Requirement for security policies and procedures to clearly define information security responsibilities for all personnel is addressed by 02.a, Roles & Responsibilities (prior to employment) Trustworthy personnel help prevent data leakage Specifically addresses screening requirements Terms & conditions of employment address requirement to ensure workforce members understands their roles & responsibilities Terms address legal requirements for data protection Terms address confidentiality requirements Terms and conditions of employment include screening requirements 25 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
26 02.c 2 02.d 1 02.d 1 02.d 1 02.d 1 02.d 1 02.d 1 02.d 1 02.d 1 02.d 1 ISO/IEC A ISO/IEC A DE.CM-6 DE.DP-1 ID.AM-6 PR.AT-1 PR.AT-2 PR.AT-3 PR.AT-4 PR.AT-5 Contains requirement to implement processes to conduct monitoring activities General language regarding roles & responsibilities; specific language related to monitoring (detect) Specifies management responsibility to ensure workforce members understands their roles & responsibilities Requires all users to be informed of their roles & responsibilities Requires all users to be informed of their roles & responsibilities Requires third party users (e.g., contractors) to be informed of their roles & responsibilities Requires all users to be informed of their roles & responsibilities Requires all users to be informed of their roles & responsibilities 26 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
27 02.d 1 PR.IP-11 Specifically addresses security in HR issues, such as a workforce development program 02.d 2 These usage policies shall address the following if applicable: i. explicit management approval (authorization) to use the technology; Updated: PCI DSS v Requirement was confounded with another statement; which was also corrected 02.d 2 These usage policies shall address the following if applicable: ii. explicit management approval (authorization) to use the technology; iii. authorization authentication for use of the technology; iv. acceptable uses of the technologies (see 07.c); PCI DSS v Requirement was confounded with another statement; which was also corrected 02.e PCI Data The organization shall ensure the importance of cardholder data security is included in a formal security awareness program for all personnel. PCI DSS v Awareness requirement for cardholder data is specific to PCI 27 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
28 02.e PCI Data 02.e 1 02.e 1 02.e 1 02.e 1 02.e 1 02.e 1 The organization shall periodically inspect payment card device surfaces to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device). PCI DSS v ISO/IEC A ID.GV-3 PR.AT-1 PR.AT-2 PR.AT-4 PR.AT-5 Requirement is PCI-specific Education addresses legal requirements for data protection Requires all users to be educated on their roles & responsibilities Requires all users to be educated on their roles & responsibilities Requires all users to be educated on their roles & responsibilities Requires all users to be educated on their roles & responsibilities 28 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
29 02.e 2 The organization s security personnel shall receive specialized security education and training appropriate to their role/responsibilities. Train developers in secure coding techniques, including how to avoid common coding vulnerabilities. Ensure developers understand how sensitive data is handled in memory. PCI DSS v3 6.5 New training requirement added to 6.5 in PCI DSS v3 02.e 2 02.e 2 02.f 1 02.f 1 02.g 1 When an employee or other workforce member moves to a new position of trust,... PCI DSS v3 9.9 Supports mapping of PCI DSS v PCI DSS v ISO/IEC A PR.IP-11 HIPAA (a)(3)(ii)(C) Requirement to provide training on payment card device tampering and substitution is consistent with equipment education, training and awareness in 08.e; content is PCIspecific and added to the PCI segment Sanctioning workforce members for security violations is included in HR practices Omnibus Rule expanded requirement for termination procedures from employees to all types of workforce members 29 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
30 02.g 1 PR.IP-11 Access termination is included in HR practices 02.g 2 02.g 2 02.h 1 02.h 1 The organization shall have a documented termination process for all employees and other workforce members. The organization provides appropriate personnel with access to official records created by a terminated employee or when the arrangement of a workforce member ends. The organization shall define any valid duties after termination employment or when the arrangement of a workforce member ends and shall be included in the employee's or workforce member s contract or other arrangement. The communication and the terms and conditions of employment or other workforce arrangement continuing for a defined period after the end of the employee's, contractor's or third party user's employment or other workforce arrangement. HIPAA (a)(3)(ii)(C) ISO/IEC A ISO/IEC A PR.IP-11 Omnibus Rule expanded requirement for termination procedures from employees to all types of workforce members Return of assets is part of termination, which is included in HR practices 30 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
31 02.i 1 Upon termination at least within 24 hours. Changes of employment or other workforce arrangement (e.g. transfers) shall be reflected in removal of all access rights that were not approved for the new employment or workforce arrangement. Access changes that identifies them as a current member of the organization. If a departing employee, contractor, third party user or other workforce member has known passwords for accounts remaining active, these shall be changed upon termination or change of employment, contract, agreement, or other workforce arrangement. Access rights to information assets and facilities shall be reduced or removed before the employment or other workforce arrangement terminates or changes, depending on the evaluation of risk factors including: i. whether the termination or change is initiated by the employee, contractor, third party user, other workforce member, or by management and the reason of termination; ii. the current responsibilities of the employee, contractor, workforce member or any other user; and HIPAA (a)(3)(ii)(C) Omnibus Rule expanded requirement for termination procedures from employees to all types of workforce members 02.i 1 ISO/IEC A This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
32 02.i 1 02.i 1 02.i 1 02.i 1 02.i 1 03.a 1 03.a 1 03.a 1 Updated: Updated: PR.AC-1 PR.AC-4 PR.IP-11 PCI DSS v v PCI DSS v PCI DSS v ID.BE-3 ID.GV-4 ID.RM-1 Password (credential) changes due to termination supports credential management requirements Access changes due to personnel transfer supports requirement to manage access permissions, including least privilege and separation of duties Removal of logical access rights is part of the HR termination process remapped in PCI DSS v3 remapped in PCI DSS v3 Requirement to prioritize organizational mission, objectives and activities is part of risk strategy development Directly supports cybersecurity risk management Addressed by organizational strategy requirements 32 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
33 03.a 1 Elements of the risk management program shall include: management s clearly stated level of acceptable risk; 3. ID.RM-2 Clarified risk tolerance requirement 03.a 1 Elements of the risk management program shall include: management s clearly stated level of acceptable risk, informed by its role in the critical infrastructure and healthcarespecific risk analysis; 3. ID.RM-3 Added requirement to consider role and healthcare-specific risk analysis in the determination of risk tolerance 03.a 1 RS-MI-3 Mitigation or acceptance of risk associated with vulnerabilities are both addressed at a program level 03.b PCI Data Formal risk assessments shall be performed at least annually and upon significant changes to the environment. The assessments shall identify critical assets, threats and vulnerabilities. PCI DSS v PCI requirements exceed the requirements specified in level 2 33 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
34 Removed: 03.b 1 Subject to PCI Compliance, Subject to State of Massachusetts Data Protection Act Administrative change PCI requirements are more consistent with the requirements in 03.b, level 2 03.b 1 1 Regulatory Factor They may be quantitative, semi- or quasiquantitative, or qualitative but shall be consistent and comparable Administrative change Intended to specifically include the most common approach to risk assessment 34 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
35 03.b 1 Risk assessments (analysis) used to determine whether a breach of unsecured protected health information (PHI) as a breach is defined by the Secretary of Health and Human Services is reportable to the Secretary must demonstrate there is a low probability of compromise (lo pro co) rather than a significant risk of harm. The methodology shall, at a minimum, address the following factors: i. the nature of the PHI involved, including the types of identifiers involved and the likelihood of re-identification; ii. the unauthorized person who used the PHI or to whom the disclosure was made; iii. whether the PHI was actually acquired or viewed; iv. the extent to which the risk to the PHI has been mitigated; and v. any other factors/guidance promulgated by the Secretary. HIPAA Specifically addresses the new requirements for breach risk analysis under the HIPAA Omnibus Rule 03.b 1 03.b 1 HIPAA cross reference ISO/IEC ISO/IEC A ISO/IEC A ID.RA-1 Asset vulnerabilities must be identified in order to address new vulnerabilities as required in the control language 35 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
36 03.b 1 03.b 1 Removed: ID.RA-3 PCI DSS v External environment is addressed in level 2 but the initial requirement in level 1 is general enough to map this control (e.g., new attack sources) PCI risk analysis requirements are more stringent than what s required in 03.b, level 1. Requirements are consistent with level 2, with the exception of the requirement for annual assessment as opposed to one every two years. 03.b 2 Subject to PCI Compliance, Subject to FISMA Compliance, Subject to Administrative change PCI requirements are more consistent with the requirements in 03.b, level 2 03.b 2 03.b 2 03.b 2 03.b 2 2 Regulatory Factor DE.AE-4 ID.RA-4 ID.RA-5 PCI DSS v Potential impact of a vulnerability should it be successfully exploited is determined as part of the risk analysis Although risk is addressed in level 1, requirement to specifically identify impact and likelihood isn t addressed until level 2 Although risk is addressed in level 1, requirement to specifically identify impact and likelihood isn t addressed until level 2 PCI DSS v was remapped to Requirements are consistent with level 2, with the exception of the requirement for annual assessment as opposed to one every two years. 36 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
37 03.c 1 The organization implements and the associated organizational information systems are prioritized and maintained; and document the remedial information and other organizations are documented. ID.RA-6 Language specifically addresses organization-wide priorities for risk response plans but earlier language updated for clarity 03.c 1 03.c 1 03.c 1 03.c 2 03.d 1 03.d 1 03.d 2 PR.IP-12 PR.IP-7 RS.MI-3 ISO/IEC A ISO/IEC A ISO/IEC A ID.GV-4 PR.IP-7 ID.RA-1 Mitigation of risk associated with vulnerabilities is part the risk management process Primary purpose of remediation is to ensure protections are improved as part of the risk management lifecycle Language specifically addresses risk responses and prioritization Ensures risk management processes are continuously updated to reflect changes in the environment Language specifically addresses updating of the risk management program to reflect changes in the environment (continuous improvement) New assets must be identified to reflect changes in risk 37 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
38 03.d 2 03.d 2 03.d 2 ID.RA-3 ID.RA-4 ID.RA-5 General language on changes in the environment (e.g., new attack sources) Addresses changes in the organization that affect risk Requires the program to be updated to reflect changes in risk, which includes threats, vulnerabilities, likelihoods and impacts per 03.b and 03.c The organization shall ensure policies are documented, communicated (known to all parties) and in use for the following: 04.a PCI Data i. managing firewalls, ii. managing vendor defaults and other security parameters, iii. protecting stored cardholder data, iv. encrypting transmissions of cardholder data, v. protecting systems against malware, vi. developing and maintaining secure systems and applications, vii. restricting access to cardholder data, viii. identification and authentication, ix. restricting physical access to cardholder data, x. monitoring access to network resources and cardholder data, and xi. security monitoring and testing. PCI DSS v3 1.5 PCI DSS v3 2.5 PCI DSS v3 3.7 PCI DSS v3 4.3 PCI DSS v3 5.4 PCI DSS v3 6.7 PCI DSS v3 7.3 PCI DSS v3 8.8 PCI DSS v PCI DSS v PCI DSS v Requirement to provide documented policies is addressed by 04.a, level 1; cross references placed in level 1 due to PCI regulatory factor but content placed in PCI segment to ensure specific requirements are addressed in support of a PCI audit or assessment 38 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
39 04.a 1 04.a 1 04.a 1 04.a 1 04.a 1 04.a 1 04.a 1 04.a 1 Removed: Subject to PCI Compliance, Subject to HITECH Breach Notification Requirements, Subject to 1 Regulatory Factor CMS cross reference NIST cross reference Removed: Administrative change CMSRs 2012v1.5 PL-1 (HIGH) ISO/IEC A ID.GV-1 ID.GV-3 ID.GV-4 NIST SP r4 PL-1 PCI DSS v HITECH breach notification requirements incorporated into the HIPAA Administrative Simplification at Subpart D Requirement to establish an information security policy is addressed by 04.a Specifically addresses general information security policy requirement Addresses legislative, regulatory and other requirements in information security policy Requires information security policy to address risk assessment and management Requirement to establish an information security policy is addressed by 04.a Policy review requirement is addressed by 04.b 39 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
40 04.a 1 04.a 1 Removed: PCI DSS v PCI DSS v3 1.5 PCI DSS v3 2.5 PCI DSS v3 3.7 PCI DSS v3 4.3 PCI DSS v3 5.4 PCI DSS v3 6.7 PCI DSS v3 7.3 PCI DSS v3 8.8 PCI DSS v PCI DSS v PCI DSS v a addresses general policy requirements but does not address specific policy for service providers; requirement is addressed by 05.k, Addressing Security in Third Party Agreements, for which is already mapped Requirement to provide operational procedures is addressed by 05.a, level 3; cross references placed in level 1 due to PCI regulatory factor but content placed in PCI segment to ensure specific requirements are addressed 04.a 1 04.b 1 An information security policy shall be developed, published, disseminated and implemented. The information security policy document shall state management's commitment Removed: An information security policy shall be developed and implemented to provide the framework for setting management objectives for all aspects of security. PCI DSS v Policy requirement maps to 04.a Administrative change Policy requirement maps to 04.a 40 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
41 04.b 1 04.b 1 04.b 1 04.b 1 04.b 1 04.b 1 04.b 2 05.a 1 05.a 1 05.a 1 Removed: CMS cross reference CMS cross reference Removed: Updated: Removed: HIPAA cross reference Removed: HIPAA cross reference Removed: HIPAA cross reference CMSRs 2012v1.5 SA-1 (HIGH) CMSRs 2012v1.5 SA-1 (HIGH) ISO/IEC A ID.GV-1 ID.GV-3 PCI DSS v PCI DSS v PCI DSS v HIPAA (a)(3)(ii)(A) HIPAA (a)(3)(ii)(B) HIPAA (a)(3)(ii)(C) Requirement for annual reviews is in level 2 vs. level 1 Requirement for annual reviews is in level 2 vs. level 1 Related to the cyber requirement for general information security policy as the CSF control addresses policy review Requires policy updates when legislative, regulatory and other requirements change Requirement is focused on policy remapped in PCI DSS v3 Verified no relevant content remains Verified no relevant content remains Verified no relevant content remains 41 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
42 05.a 2 i. ensure that goals are identified and considered, and address organizational and healthcare-specific requirements, and.. ID.BE-2 Addresses requirement for organizations to consider their place in critical infrastructure 05.a 2 05.b 1 05.b 2 05.b 2 05.b 2 05.c 1 Removed: Removed: ID.BE-3 ID.GV-2 RS.CO-2 PCI DSS v PCI DSS v ISO/IEC A Specifically related to management requirements around information security strategy Consistent with control specification Addresses evaluation of information received from monitoring and reviewing of security incidents 05.b addresses security coordination but does not require formally assigning responsibilities for monitoring, analyzing and distributing security alerts; this will be addressed by 05.c 05.b addresses security coordination but does not require formally assigning responsibilities for distributing security incident response and escalation procedures; this will be addressed by 05.c 42 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
43 05.c 1 Information security roles & responsibilities shall be coordinated and aligned with internal roles and external partners. ID.GV-2 specifically addresses allocation of responsibilities; Framework language added for clarification 05.c 1 The organization shall formally assign the following specific information security responsibilities to an individual or team: i. establishment, documentation and distribution of security policies and procedures; ii. monitoring and analyzing security alerts and information, and distributing security alerts, information and analysis to appropriate personnel; iii. establishment, documentation and distribution of security incident response and escalation procedures to ensure timely and effective handling of all situations; iv. administering user accounts, including additions, deletions and modifications; and v. monitoring and controlling all access to data. PCI DSS v PCI DSS v PCI DSS v PCI DSS v Formal assignment of specific information security responsibilities is best addressed by 05.c, Allocation of Information Security Responsibilities s 43 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
44 05.d 1 05.e 1 05.e 1 05.f 1 05.f 2 05.f 2 05.f 2 05.g 1 05.g 1 ID.BE-1 ISO/IEC A PR.DS-5 DE.DP-4 ISO/IEC A RS.CO-2 RS.CO-3 ID.RA-2 RS.CO-5 Specifically addresses supply chain requirements for new information assets Confidentiality agreements support DLP Specifically addresses contact with authorities Requires procedures for reporting Requires sharing consistent with response plans, which is supported by testing Requirement specific to contact with special interest groups: share and exchange information about threats, or vulnerabilities Requirement specific to contact with special interest groups: provide suitable liaison points when dealing with information security incidents (see 11.c) 44 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
45 05.g 2 05.h 1 05.h 1 05.h 1 05.h 1 05.h 1 05.h 1 05.h 1 ISO/IEC A ISO/IEC A ID.GV-4 ID.RM-1 ID.RM-2 ID.RM-3 PR.IP-7 PR.IP-8 Periodic review of the information security program ensures governance and risk management processes continue to address information and cybersecurity risks Periodic review of the information security program helps ensure the program continues to address stipulated requirements Periodic review of the information security program helps ensure the program continues to address stipulated requirements Periodic review of the information security program helps ensure the program continues to address stipulated requirements Periodic review of the information security program ensures continuous improvement Sharing of information re: control effectiveness with appropriate stakeholders is part of the third-party information protection program review 45 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
46 05.i 1 05.i 1 05.i 1 Updated: HIPAA cross reference HIPAA (b)(43) DE.AE-1 ID.AM-3 Prior content in (b)(3) was deleted in the Omnibus Rule; (b)(4) was subsequently renumbered Expected data flows must be understood in order to support control requirements for identification of risk and minimal access (note level 2 also requires monitoring of connections) Requires the organization to identify information provided or otherwise accessible by 3 rd parties in order to evaluate the risks they represent; supports mapping requirement in 09.m 05.i 1 05.j 1 05.j 1 Due diligence, including an evaluation of the information security risks posed by external parties, shall be carried out to identify any requirements for specific controls where access to sensitive information (e.g., covered information, cardholder data) by external parties is required prior to establishing a formal relationship with the service provider. PCI DSS v PR.AC-3 PR.AT-3 Language updated to better reflect the intent of the control, 05.i, Identification of Risks Related to External Third Parties, and PCI DSS v , which requires a risk analysis prior to establishing a formal relationship Addresses customer access Addresses customer role and responsibilities 46 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
47 05.k PCI Data 05.k 1 The organization shall identify and document information about which PCI DSS requirements are managed by each service provider, and which are managed by the organization. Removed: Subject to PCI Compliance, Subject to HITECH Breach Notification Requirements, Subject to 1 Regulatory Factor Removed: PCI DSS v Administrative change New requirement in PCI DSS v3 requiring formal delineation of responsibility for PCI controls with a third party service provider HITECH breach notification requirements incorporated into the HIPAA Administrative Simplification at Subpart D 05.k 1 xxi. intellectual property rights (IPRs) and copyright assignment (see 6. b) and protection of any collaborative work (see 5.e); xxii. involvement of the third party with subcontractors, and the security controls these subcontractors need to implement; and xxiii. conditions for renegotiation/termination of agreements HIPAA (b)(1) Omnibus Rule specified the Covered Entity is not required to obtain satisfactory assurances from a BA for its BAs/subcontractors 47 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
48 05.k 1 x. arrangements for reporting, notification (e.g., how, when and by whom), and stating: a. the third party... including: a. the identification of each individual disclosed during such breach; b. all notifications shall be made without unreasonable delay and in no case later than 60 calendar days after the discovery of a breach if the BA is an agent of the covered entity, otherwise the timing of the notification should be explicitly addressed in the contract if the BA is not an agent of the covered entity; and HIPAA (b) Clarified differences in reporting requirements for an agent of the CE as opposed to one who is not; addressing the timing of non-agent BA breaches in the contract eliminates ambiguity and may be considered a best practice HIPAA cross reference 48 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
49 05.k 1 xi. arrangements for reporting stating: a. the third party... including: b. the identification of each individual disclosed during such breach; b. all notifications if the BA is not an agent of the covered entity; and c. evidence shall be maintained delay; and d. any other information that may be needed in the notification to individuals, either at the time notice of the breach is provided or promptly thereafter as information becomes available. HIPAA (c)(2) Added language addressing the requirement for additional information from the BA as it is discovered/developed HIPAA cross reference 05.k 1 The organization shall identify and mandate information security controls to specifically address supplier access to the organization s information and information assets. ISO/IEC 27002:2013 A Addresses information security in supplier relationships The organization shall maintain written agreements (contracts) ISO cross reference 49 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
50 05.k 1 The organization shall maintain the security of the organization s information environment. Agreements shall include requirements to address the information security risks associated with information and communications technology services (e.g., cloud computing services) and product supply chain. ISO/IEC 27002:2013 A Addresses information security in supplier relationships The agreement shall ensure the indemnity of the third party. 05.k 1 05.k 1 05.k 1 ISO cross reference ISO/IEC A ISO/IEC A ISO/IEC A DE.CM-6 ID.AM-6 Addresses monitoring requirement Addresses 3 rd party requirements, including roles & responsibilities 05.k 1 The organization shall establish personnel security requirements including security roles and responsibilities for third-party providers that are coordinated and aligned with internal security roles and responsibilities. ID.GV-2 Addresses 3 rd party requirements, including roles & responsibilities; language added for clarification 50 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
51 05.k 1 05.k 1 PR.AT-3 PR.IP-11 Specifically addresses 3 rd party requirements, including roles and responsibilities Addresses HR security-related requirements such as training and awareness 05.k 1 The organization shall maintain written agreements (contracts) that includes an acknowledgement that the third party (e.g., a service providers) is responsible for the security of the data the third party possesses or otherwise stores, processes or transmits on behalf of the organization, or to the extent that they could impact the security of the organization s information environment. PCI DSS v Although elements supporting the requirement are addressed by language in 05.k level 1, specific language was added to ensure written agreements address the full intent of the requirement 05.k 1 05.k 1 06.a 1 The agreement shall ensure that there is no misunderstanding PCI DSS v PCI DSS v ISO/IEC A New requirement in PCI DSS v3 requiring formal delineation of responsibility for PCI controls with a third party service provider Wording is identical to but intended for / directed at the service provider 51 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
52 06.a 1 06.b 2 06.b 3 ID.GV-3 ISO/IEC A DE.CM-3 Specifically addresses compliance with legal and regulatory requirements Requires automated auditing The organization shall keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all cardholder data (CHD) storage: 06.c PCI Data 06.c 1 i. Limiting data storage amount and retention time to that which is required for legal, regulatory, and business requirements ii. Processes for secure deletion of data when no longer needed iii. Specific retention requirements for cardholder data iv. A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention. PCI DSS v3 3.1 ID.GV-3 New content in 3.1 is PCI-specific Specifies retention IAW all regulatory and legislative requirements 52 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
53 06.c 1 06.c 2 PR.PT-1 ISO/IEC A Addresses maintenance/retention of all records IAW all regulatory and legislative requirements The organization shall render the PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches: 06.d PCI Data One-way hashes based on strong cryptography, (hash must be of the entire PAN) Truncation (hashing cannot be used to replace the truncated segment of the PAN) Index tokens and pads (pads must be securely stored) Strong cryptography with associated key management processes and procedures. PCI DSS v3 3.4 PCI only requirement; PCI control already mapped at level 2 53 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
54 06.d PCI Data 06.d 1 06.d 1 06.d 1 06.d 1 06.e 1 06.e 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. PCI DSS v ISO/IEC A DE.DP-2 ID.GV-3 ID.GV-3 DE.CM-3 PR.IP-11 PCI only requirement; PCI control already mapped at level 2 Specifies monitoring (detection) to protect covered information Consistent with relevant legislation policy language Specifies retention IAW all regulatory and legislative requirements Requires notice of monitoring Addresses HR security practices such as acceptable use agreements and rules of behavior 54 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
55 06.e 1 06.e 1 06.e 2 06.f 1 06.f 2 06.f 2 06.g 1 06.g 1 06.g 1 Removed: PCI DSS v PCI DSS v ISO/IEC A ID.GV-3 ISO/IEC A PR.AC-1 ISO/IEC A DE.DP-1 DE.DP-4 11.a addresses misuse of assets but does not require formally assigning responsibilities for monitoring and controlling all access to data; this will be addressed in 05.c Addresses requirement for management to approve access to information technologies Specifically addresses relevant legislation and regulations Addresses mechanisms for authentication to a cryptographic module Specifies compliance reviews will be supported by system and information owners Requires reports of non-compliance be documented and approved by management; additional requirements specified in level 2 55 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
56 06.g 1 06.g 1 Removed: ID.GV-3 ID.RA-6 Specifically addresses relevant legislation and regulations (e.g., HIPAA) 1 states corrective actions for non-compliance are identified and implemented, but level 2 specifies compliance reviews are part of a formal risk assessment process 06.g 2 Results of reviews and corrective actions carried out shall be recorded and these records shall be maintained. The security organization shall maintain records of the compliance results in order to better track security trends within the organization and to address longer term areas of concern. Administrative change Removed duplicate text 06.g 2 06.h 1 06.h 1 06.h 1 DE.CM-7 ISO/IEC A DE.CM-8 ID.RA-1 Requires the use of automated compliance tools/scans when possible; specifies continuous monitoring of security controls wrt compliance Technical compliance checks are supported by vulnerability scanning Technical non-compliance results in a potential vulnerability 56 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
57 06.h 1 06.h 1 06.h 1 06.i 1 06.i 2 06.i 2 06.i 2 06.i 2 06.j 2 ID.RA-6 PR.IP-12 RS.MI-3 DE.DP-2 ISO/IEC A DE.DP-1 DE.DP-4 PR.PT-1 DE.DP-1 Similar requirements for analysis and corrective action planning as provided in 06.g Technical compliance checks are part of a vulnerability management program Specifically addresses mitigation of technical non-compliance issues (vulnerabilities) Audit supports continuous monitoring: specifies audits should not impact business operations; level 2 specifies additional requirements Audit supports continuous monitoring: specifically addresses roles & responsibilities Audit supports continuous monitoring: specifically addresses dissemination of the audit plan Audit supports continuous monitoring: specifies limited requirements for audit processing Audit supports continuous monitoring: restricts use of audit tools to authorized individuals only 57 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
58 07.a PCI Data The inventory of system components and devices in scope for PCI DSS shall identify all personnel authorized to use the system components and devices. PCI DSS v Inventory requirement is addressed in level 1 but identification of personnel with access is more stringent and not addressed anywhere else in 07.a; PCIspecific content placed in PCI segment 07.a PCI Data 07.a PCI Data 07.a 1 07.a 1 07.a 1 The organization shall maintain an inventory of system components that are in scope for PCI DSS. The organization shall maintain an inventory of system components that are in scope for PCI DSS. Lists of payment card devices shall be kept up-to-date and include the following: i. Make, model of device ii. Location of device (for example, the address of the site or facility where the device is located) iii. Device serial number or other method of unique identification. PCI DSS v3 2.4 PCI DSS v ID.AM-1 ID.AM-2 ID.AM-5 New content in 2.4 is PCI-specific Requirement is PCI-specific and not addressed in level 2, which is required for PCI compliance. Inventory documentation requirements are addressed in level 3 but requires much more detail than PCI requires Specific to asset inventories Specific to asset inventories Requires asset inventories identify classification and business value 58 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
59 07.a 1 PR.DS-3 Addresses asset management; formal lifecycle management is specified in level 3 07.a 1 The organization shall maintain an inventory of authorized wireless access points including a documented business justification, to support unauthorized WAP identification (see 09.m) and response (see 11.c). PCI DSS v New requirement supporting PCI DSS v a 2 07.a 2 07.a 2 07.a 2 07.a 2 Updated: The organization shall maintain inventory logs of all media and conduct media inventories at least annually. ISO/IEC A PCI DSS v PCI DSS v PCI DSS v3 2.4 PCI DSS v remapped in PCI DSS v3 Previous content in 2.4 was moved to 2.6 in PCI DSS v3; new content maps to CSF control 07.a but is PCI-specific Requirement was mapped to 09.a level 2 as PCI DSS v but not specifically addressed; language added PCI DSS v3 9.9 Supports mapping of PCI DSS v This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
60 07.a 2 PCI DSS v Requirement to maintain an inventory of payment card devices is consistent with asset inventory requirements in 07.a; content is PCI-specific and added to the PCI segment 07.b 1 07.b 2 07.b 2 07.b 2 07.b 2 All information systems shall be documented including an a method to accurately and readily determine the assigned owner of responsibility, contact information, and purpose (e.g., through labeling, coding, and/or inventory). Removed: PCI DSS v ISO/IEC A ID.AM-5 ID.AM-6 PR.DS-3 Updated the language to accurately reflect the PCI requirement Requires owners to specify asset classification and business value Specifies responsibilities of asset owners Addresses asset management responsibilities of asset owners 07.c 1 The organization shall include in the rules of behavior, explicit restrictions on the use of social media and networking sites, posting information on commercial websites, and sharing information system account information. Administrative change Duplicate text in control level; artifact 60 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
61 07.c 1 07.c 1 07.c 1 07.d 1 07.d 1 07.d 2 07.d 2 07.d 2 07.e 1 07.e 1 Removed: ISO/IEC A PR.DS-5 PCI DSS v ID.AM-5 PR.DS-5 ISO/IEC A ID.RA-4 ID.RA-5 PR.DS-5 PR.PT-2 Acceptable use supports data leakage prevention Explicit approval is not addressed by 07.c, level 1; requirement is addressed by 02.d, level 2, which is already mapped to Provides classification guidelines for information assets Classification guidelines support data leakage prevention Classification requires understanding of business value and impact due to a loss of the asset Specifically addresses risk Labeling and handling requirements support data leakage prevention Addresses labeling and handling requirements for removable media 61 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
62 07.e 2 07.e 2 08.a 1 08.a 1 08.a 1 08.a 2 08.a 3 Updated: ISO/IEC A PCI DSS v PCI DSS v DE.CM-2 DE.CM-7 PR.AC-2 DE.DP-2 ISO/IEC A remapped in PCI DSS v3 Provides the use of alarms as an example of physical perimeter protection Provides the use of alarms as an example, which is meant to identify unauthorized intrusion Specifically addresses physical (perimeter) access protection Specifies compliance with regulatory requirements for fire doors 08.b PCI Data 08.b PCI Data The organization shall ensure visitors are authorized before entering, and escorted at all times within, areas where cardholder data is processed or maintained. Visitor logs shall include the name of the onsite personnel (workforce member) authorizing physical access. PCI DSS v PCI DSS v PCI requirement is more restrictive than existing language PCI DSS v is more restrictive as it requires the authorizing individual to be onsite. 62 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
63 08.b 1 08.b 1 08.b 1 08.b 1 08.b 1 Updated: Added DE.CM-2 DE.CM-7 PR.AC-2 PCI DSS v PCI DSS v PCI DSS v3 9.4 Requires visitor escort (monitoring) and monitoring of third party service personnel Requires ability to clearly distinguish between workforce members and visitors, which supports identification (monitoring) of unauthorized personnel; physical intruder detection system requirements are specified in level 3 Specifically addresses physical entry controls remapped in PCI DSS v3 Supports PCI DSS v in level 1; moved from level 2 08.b 1 All visitors shall be escorted and supervised (their activities monitored) unless their access has been previously approved. Access to areas where sensitive information (e.g., covered information, payment card data) is processed or stored shall be controlled and restricted to authorized persons only. All visitors shall be escorted and supervised (their activities monitored) unless their access has been previously approved. PCI DSS v Re-ordered and additional language added for clarity. More restrictive PCI DSS requirement placed in PCI segment 63 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
64 08.b 2 08.b 2 08.b 2 08.b 2 08.b 2 08.b 2 Removed: Updated: Updated: Updated: ISO/IEC A RS.CO-3 PCI DSS v2 9.3 PCI DSS v PCI DSS v PCI DSS v PCI DSS v PCI DSS v2 9.4 PCI DSS v Requires notification of security personnel in the event an unauthorized person is identified by a member of the workforce PCI reference (v2 9.3 / v3 9.4) moved to support PCI DSS v in level 1 remapped in PCI DSS v3 remapped in PCI DSS v3 remapped in PCI DSS v3 64 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
65 Authentication controls shall be securely maintained. 08.b 2 The organization shall ensure onsite personnel and visitors can be easily distinguished. All employees, contractors and third party users and all visitors shall be required to surrender the badge or device before leaving the facility or upon expiration. The organization shall ensure onsite personnel and visitor identification (e.g., badges) are revoked or terminated when expired or when access is no longer authorized. Identification should also be updated when access requirements change to ensure their status can be easily distinguished. PCI DSS v3 9.2 Language updated to reflect additional requirements specified in PCI DSS v3 65 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
66 Authentication controls (e.g. access control card plus PIN) shall be used to authorize and validate all access. Access must be authorized and based on individual job function. An audit trail of all access shall be securely maintained. 08.b 2 The organization shall ensure onsite personnel and visitors can be easily distinguished. All employees, contractors and third party users and all visitors shall be required when expired or when access is no longer authorized, and all physical access mechanisms, such as keys, access cards and combinations, are returned disabled or changed. Identification should also be updated when access requirements change to ensure their status can be easily distinguished. PCI DSS v3 9.3 Content for 9.3 is new for PCI DSS v3; content consistent with 08.b Removed: 08.b 3 08.b 3 08.b 3 Combinations and keys shall be changed and when keys are lost, combinations are compromised, or individuals are transferred or terminated. Administrative change DE.DP-2 DE.DP-3 Requirement addressed in level 2 with the addition of language supporting PCI DSS v3 9.3 Requires IDS installed IAW applicable standards Requires testing of IDS 66 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
67 08.b 3 The organization shall monitor and investigate notifications from real-time physical intrusion alarms and surveillance equipment. RS.AN-1 Requires monitoring of real-time physical intrusion alarms and surveillance equipment; clarification on response added. 08.c 1 08.c 2 08.c 2 08.c 2 08.c 2 08.c 2 08.d 1 08.d 1 DE.DP-2 ISO/IEC A DE.CM-2 DE.CM-3 DE.CM-7 PR.AC-2 ISO/IEC A PR.IP-5 Requires consideration of relevant health and safety regulations when security facilities Specifies video monitoring Specifies monitoring of individual access to sensitive areas Specifies use of automated mechanisms to recognize potential intrusions Addresses securing of facilities for asset protection Addresses requirements for the physical operating environment 67 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
68 08.e 1 08.e 1 08.e 1 08.e 2 08.f 1 08.f 2 ISO/IEC A DE.CM-2 PR.AC-2 RS.CO-3 PR.DS-3 ISO/IEC A Addresses requirements for locking and checking vacant secure areas Addresses requirements for locking and checking vacant secure areas Requires coordination with incident response team Addresses management of assets in public access areas, such as delivery and loading 08.g PCI Data 08.g 1 The organization shall periodically inspect payment card device surfaces to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device). PCI DSS v PR.IP-5 Requirement is PCI-specific Addresses policy requirements for equipment protection 68 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
69 08.g 1 08.g 1 08.g 2 08.h 1 08.h 1 08.h 2 08.h 3 08.i 2 The organization controls physical access to information system distribution and transmission lines within organizational facilities by disables disabling any physical ports (e.g., wiring closets, patch panels, etc.) not in use. PCI DSS v3 9.9 Supports mapping of PCI DSS v PCI DSS v ISO/IEC A ID.BE-4 PR.IP-5 PR.AC-2 ISO/IEC A CMSRs 2012v1.5 PE-4 Requirement to protect devices from tampering and substitution is consistent with equipment siting and protection in 08.g; content is PCIspecific and added to the PCI segment Dependency of critical systems on utilities (power, water) is addressed Addresses policy requirements for equipment protection Addresses physical access requirements for infrastructure assets Provided clarification of the requirement to avoid confusion with standard network ports, which will be addressed by additional language from PCI DSS v This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
70 08.i 2 08.i 2 08.i 2 08.i 3 08.j 1 08.j 1 08.j 2 08.j 2 The organization shall implement physical and/or logical controls to restrict access to publicly accessible network jacks. Removed: ISO/IEC A PR.AC-2 PCI DSS v DE.CM-7 PR.MA-1 PR.MA-2 ISO/IEC A PR.DS-1 Addresses physical access requirements for distribution and transmission lines Original language specific to CMS IS ARS 2012v1.5 PE-4 did not address the requirement specified in PCI DSS v Requires technical sweeps and physical inspections for unauthorized devices Specifically addresses security of maintenance activities Addresses remote maintenance requirements Specifically addresses clearing of data prior to maintenance activities 08.k 1 Subject to PCI Compliance, Subject to FISMA Compliance Administrative change No remaining s once PCI DSS v2 9.8 (PCI DSS v ) is removed 1 Regulatory Factor 70 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
71 08.k 1 08.k 1 08.k 1 08.l 1 08.l 1 08.l 1 08.l 1 08.l 1 08.m 1 08.m 1 Removed: Updated: Updated: ISO/IEC A PR.DS-3 PCI DSS v2 9.8 ISO/IEC A PR.DS-3 PR.IP-6 PCI DSS v PCI DSS v PCI DSS v PCI DSS v ISO/IEC A PR.DS-3 Requires management of equipment taken outside the organization s premises This control is specific to removing media from secured areas; no relevant content in 08.k level 1; specific language is addressed by 09.q level 2 Addresses security requirements for asset reuse or disposal Addresses secure disposal remapped in PCI DSS v3 remapped in PCI DSS v3 Addresses management of property taken off-site 71 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
72 The organization shall ensure operational procedures are documented, communicated (known to all parties) and in use for the following: 09.a PCI Data 09.a 1 i. managing firewalls, ii. managing vendor defaults and other security parameters, iii. protecting stored cardholder data, iv. encrypting transmissions of cardholder data, v. protecting systems against malware, vi. developing and maintaining secure systems and applications, vii. restricting access to cardholder data, viii. identification and authentication, ix. restricting physical access to cardholder data, x. monitoring access to network resources and cardholder data, and xi. security monitoring and testing. PCI DSS v3 1.5 PCI DSS v3 2.5 PCI DSS v3 3.7 PCI DSS v3 4.3 PCI DSS v3 5.4 PCI DSS v3 6.7 PCI DSS v3 7.3 PCI DSS v3 8.8 PCI DSS v PCI DSS v PCI DSS v ISO/IEC A Requirement to provide operational procedures is addressed by 05.a but documented operations procedures are specifically addressed by 09.a; cross references placed in level 1 due to PCI regulatory factor but content placed in PCI segment to ensure specific requirements are addressed in support of a PCI audit or assessment 72 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
73 09.a 1 PCI DSS v3 1.5 PCI DSS v3 2.5 PCI DSS v3 3.7 PCI DSS v3 4.3 PCI DSS v3 5.4 PCI DSS v3 6.7 PCI DSS v3 7.3 PCI DSS v3 8.8 PCI DSS v PCI DSS v PCI DSS v Requirement to provide operational procedures is addressed by 05.a but documented operations procedures are specifically addressed by 09.a; cross references placed in level 1 due to PCI regulatory factor but content placed in PCI segment to ensure specific requirements are addressed 09.aa PCI Data 09.aa 1 09.aa 1 09.aa 1 09.aa 2 A service provider shall protect each organization s hosted environment and data by ensuring logging and audit trails are enabled and unique to each organization s (customer s) cardholder data environment and consistent with PCI DSS v3 Requirement 10. PCI DSS v3 A.1.3 DE.CM-1 DE.CM-3 PR.PT-1 ISO/IEC A Specific language addressing logs and audit trails unique to each organization s cardholder data environment Specifically addresses auditing Specifically addresses auditing Specifically addresses auditing 73 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
74 09.aa 2 09.aa 2 09.aa 2 09.aa 3 09.aa 3 Removed: Removed: Removed: DE.CM-7 Addresses alarms from access control systems, AV, IDS, etc. PCI DSS v Requirement is addressed by 09.d PCI DSS v PCI DSS v PCI DSS v Specific requirements in PCI DSS v is addressed in level 3 rather than level 2 Requirement is addressed in level 2; PCI control already mapped at level 2; duplicate mapping Specific requirements in PCI DSS v is addressed in level 3 rather than level 2 09.aa 3 The following shall be logged: i. ii. the enabling, pausing or disabling of audit report generation services; and PCI DSS v Updated language to reflect PCI DSS v3 09.ab PCI Data 09.ab 1 The organization shall review, at least daily, the logs of all system components that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD). PCI DSS v DE.DP-2 Requirement specific to PCI DSS v3 Requires compliance with applicable legal requirements 74 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
75 09.ab 1 09.ab 2 09.ab 2 09.ab 2 09.ab 2 09.ab 2 09.ab 2 09.ab 3 09.ab 3 09.ab 3 Removed: Systems shall support audit reduction and report generation, and the results of monitoring activities shall be reviewed regularly. ID.GV-3 ISO/IEC A ID.RA-1 DE.AE-2 DE.AE-3 DE.CM-1 PR.PT-1 Administrative change DE.CM-4 DE.CM-7 Specifically addresses legal and regulatory requirements for monitoring Auditing supports identification and remediation of vulnerabilities Addresses detecting attacks and analyzing logs and audit trails Addresses collection and integration of data from multiple sources; correlation is specifically addressed in level 3 Specifically addresses monitoring Address audit record documentation and review Language is duplicative of other content in 09.ab, level 2; possible artifact from when additional language was added to the statement Monitors for malicious code Addresses monitoring of remote connections 75 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
76 09.ab 3 09.ab 3 09.ab 3 DE.DP-4 RS.AN-1 RS.CO-2 Requires alert notifications from automated tools; requires alerting of personnel to unauthorized modification of critical system files, etc. Requires appropriate actions be taken, e.g., when an unauthorized connection is discovered Addresses reporting 09.ab 3 The results of monitoring activities shall be reviewed daily, through the use of automated tools, forthose: i. all security events, ii. logs of all critical system components, and iii. logs of all servers that perform security functions like intrusion detection system (IDS), intrusion prevention PCI DSS v Updated language to reflect additional requirements in PCI DSS v This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
77 09.ab 3 The automated tools shall generate alert notification for technical staff review and assessment. The organization shall review logs of all other system components periodically based on its policies and risk management strategy, as determined by the organization s annual risk assessment. PCI DSS v New requirement in PCI DSS v3 09.ab 3 Suspicious activity or suspected violations on the information system identified during the review process shall be investigated, with findings reported to appropriate officials and take appropriate action. PCI DSS v Existing language modified to better reflect requirement in PCI DSS v ab 3 The organization shall deploy a change-detection mechanism (e.g., 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. PCI DSS v Updated language to reflect changes in PCI DSS v3 77 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
78 09.ab 3 09.ac 1 09.ac 1 The organization shall deploy a change-detection mechanism or content files; and configures the software to perform critical file comparisons at least weekly, and responds to any alerts generated. PCI DSS v ISO/IEC A ISO/IEC A PR.PT-1 Updated relevant language to reflect new requirement in PCI DSS v3 Protection is part of audit log implementation 09.ac 3 Write logs for external-facing technologies (wireless, firewalls, DNS, mail) onto a secure, centralized log server or media device on the internal LAN. PCI DSS v Updated language to reflect clarification provided in PCI DSS v ac 3 09.ad 1 09.ad 1 The organization shall alerts (although new data being added should not cause an alert), and responds to any alerts generated. PCI DSS v ISO/IEC A PR.PT-1 Updated relevant language to reflect new requirement in PCI DSS v3 Addresses administrator and operator logs 78 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
79 09.ad 1 09.ae 1 09.ae 1 09.af 1 09.af 1 Removed: PCI DSS v2 A.1.3 ISO/IEC A PR.PT-1 ISO/IEC A PR.PT-1 09.ad only peripherally addresses the PCI DSS v3 A.1.3 requirement; specific language addressing logs and audit trails unique to each organization s cardholder data environment will be addressed in the PCI segment for 09.aa, Audit Logging Addresses fault logging Clock synchronization is part of audit log implementation 09.af 1 The organization shall synchronize all critical system clocks and times where Where a computer or communications device has the capability to operate a real-time clock,. This this clock shall be set PCI DSS v Language updated to better reflect the PCI DSS v3 requirement 79 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
80 09.af 1 09.b 2 09.b 2 09.c 1 09.c 1 09.c 2 09.d 2 09.d 2 This clock shall be set to an agreed standard received from industry-accepted time sources, either Coordinated Universal Time (UTC) or International Atomic Time. As some clocks are known to drift with time, there shall be a procedure that checks for and corrects any significant variation. PCI DSS v ISO/IEC ISO/IEC A PR.IP-3 PR.AC-4 PR.DS-5 ISO/IEC A ISO/IEC A PR.DS-7 Language from the PCI DSS v3 requirement added for clarification Addresses change control processes Specifically addresses segregation of duties Segregation can be applied to support data leakage prevention Specifically addresses separation of development, test and production environments; level 1 addresses minimization of testing but level 2 addresses actual separation 80 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
81 The level of separation between operational, test, and development environments shall be identified and controls shall be implemented to prevent operational issues, including: 09.d 2 09.e 1 i. along with removing accounts, a review of all custom code preceding the release to production or to customers must be completed in order to identify any possible coding vulnerability, to include at least the following: a. code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices; b. code reviews ensure code is developed according to secure coding guidelines; c. appropriate corrections are implemented prior to release; and d. code-review results are reviewed and approved by management prior to release. Updated: HIPAA cross reference PCI DSS v HIPAA (b)(43) Added new language in PCI DSS v3 Prior content in (b)(3) was deleted in the Omnibus Rule; (b)(4) was subsequently renumbered 81 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
82 09.e 2 09.e 2 09.e 2 09.e 2 09.e 2 09.f 1 09.f 2 09.f 2 09.f 2 Removed: Updated: HIPAA cross reference ISO/IEC DE.CM-6 ID.AM-4 PR.AT-3 PCI DSS v HIPAA (b)(43) ISO/IEC ISO/IEC A DE.CM-6 PR.AT-3 Addresses monitoring of service levels Requires cataloguing of current service providers Requires the service provider to protect the organization s data and ensure service continuity levels are met Monitoring service delivery is a due care issue; the intent of PCI DSS v is to exercise an appropriate level of due diligence prior to establishing a relationship Prior content in (b)(3) was deleted in the Omnibus Rule; (b)(4) was subsequently renumbered Specifically addresses security incidents as part of third-party monitoring Specifies monitoring shall involve a service management relationship and process between the organization and the third party 82 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
83 09.g 1 09.g 1 09.g 2 09.h 1 09.h 1 09.h 1 09.i 2 Removed: ID.BE-1 PR.AT-3 ISO/IEC ISO/IEC A ISO/IEC A PR.DS-4 PR.PT-1 ISO/IEC A requires change management procedures for third party services and level 2 identifies specific requirements for change management 1 requires change management procedures for third party services and level 2 identifies specific requirements for change management Specifically addresses capacity requirements Addresses capacity requirements for audit logs (implementation) 09.j 1 Subject to PCI Compliance, N/A Moved from level 1 to accommodate addition of PCI requirements in level 2 09.j 1 1 Regulatory Factors DE.CM-4 Specifically addresses malicious code detection 83 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
84 09.j 2 ISO/IEC A j 2 Subject to PCI Compliance, Subject to FISMA N/A Moved from level 1 to accommodate addition of PCI requirements in level 2 1 Regulatory Factors 09.j 2 For systems considered to be not commonly affected by malicious software, the organization shall perform periodic assessments to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software. PCI DSS v Although considered a new best practice, the requirement was added to level 2 due the analysis requirement; language supporting the new PCI DSS v which also provides a more stringent requirement, was already contained in level 2 09.j 2 Malicious code protection mechanisms shall be centrally managed. Non-privileged users are prevented from circumventing malicious code protection capabilities, unless specifically authorized by management on a case-by-case basis for a limited time period. PCI DSS v3 5.3 Existing language modified to reflect new v3 requirement 09.k 1 DE.CM-5 Specifically addresses mobile code 84 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
85 09.k 2 09.l 1 09.l 1 09.l 2 09.m PCI Data Updated: The organization shall ensure network diagrams identify all cardholder data connections. ISO/IEC A PR.IP-4 PCI DSS v2 9.5 PCI DSS v ISO/IEC A PCI DSS v Specifically addresses back-up remapped in PCI DSS v3 Provides specific guidance for PCI cardholder data 09.m PCI Data The organization shall ensure network diagrams identify all cardholder data connections and cardholder data flows. PCI DSS v New requirement in PCI DSS v3 09.m PCI Data Using intrusion-detection and/or intrusionprevention techniques to detect and/or prevent intrusions into the network, monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises. PCI DSS v Requirement specific to a robust implementation of IDS/IPS in and around the cardholder data environment 85 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
86 09.m 1 09.m 1 09.m 1 09.m 1 09.m 1 09.m 1 DE.AE-1 DE.CM-1 ID.AM-3 PR.DS-5 PCI DSS v3 1.1 PCI DSS v Specifically addresses network diagrams that indicate data flows Addresses monitoring of all authorized and unauthorized wireless access Specifically addresses network diagrams that indicate data flows Specified network protections support data leakage prevention Supports sub-requirements PCI DSS v , 1.1.2, 1.1.3, 1.1.4, 1.1.5, and 1.1.7, which are mapped to the control Added to reflect renumbering from to in PCI DSS v3 09.m 1 Misconfigured wireless networks and vulnerabilities in covered information environments. The organization monitors for all authorized and unauthorized wireless access to the information system and prohibits installation PCI DSS v Requirement modified in PCI DSS v3; previous mapping at 09.m level 2 was moved to level 1 86 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
87 09.m 1 09.m 2 09.m 2 09.m 2 09.m 2 09.m 2 09.m 2 09.m 3 Deleted: v. firmware on wireless devices to support strong encryption for authentication and transmission over wireless networks vi.v other security-related Removed: Removed: PCI DSS v PR.AC-1 PR.AC-5 PR.DS-2 PCI DSS v PCI DSS v2 4.1 PCI DSS v ISO/IEC A The requirement was removed from PCI DSS v3 and incorporated into the test procedures for the control (2.1.1d). Previous language inconsistent with the rest of the list for change the following ; requirements for strong encryption for authentication and transmission over wireless networks is addressed by other language Requires identification and authentication of network devices Specifically addresses the use of firewalls to segment and protect the internal network Requires protection of information in transit Language is addressed in level 1; cross reference moved Requirement for encryption of data over public networks is not contained in 09.m; maps to content contained in 10.s New requirement related to intrusion detection addressed by 09.m 87 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
88 09.m 3 09.m 3 09.n 1 09.n 1 09.n 1 09.n 2 09.n 2 09.n 2 09.n 2 Removed: Updated: HIPAA cross reference PCI DSS v PCI DSS v HIPAA (b)(43) ISO/IEC A ID.AM-6 DE.AE-1 DE.CM-6 DE.CM-7 ID.AM-3 Removed due to renumbering of requirements in PCI DSS v3 Added to reflect renumbering in PCI DSS v3 due to the addition of a new requirement at Prior content in (b)(3) was deleted in the Omnibus Rule; (b)(4) was subsequently renumbered Specifies certain responsibilities, e.g., the right to audit; additional requirements outlined in level 2 Specifically address the information communicated for each connection, which is required to support documentation of data flows Provides for organizational monitoring of external service providers Provides for organizational monitoring of external service providers Requires identification of information communicated when authorizing system connections 88 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
89 The organization shall: 09.n 2 ii. centrally document for each connection, the interface characteristics, security requirements, and the nature of the information communicated. ID.AM-4 Requires authorization of connections to all external systems; clarification added 09.n 2 09.n 2 09.n 2 09.o 1 09.o 2 09.p 1 09.p 1 ID.GV-3 PR.AT-3 PR.PT-4 PR.PT-2 ISO/IEC A PR.DS-3 PR.DS-5 Specifies providing services IAW applicable laws & regulations Specifies requirements for third parties, including contract provisions Addresses security requirements for each connection, which would include communications and control networks Specifically addresses removable media Requires formal management of assets awaiting and during disposal Secure destruction supports data leakage prevention 89 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
90 09.p 1 09.p 1 Updated: PR.IP-6 PCI DSS v PCI DSS v3 9.8 Specifically addresses destruction remapped in PCI DSS v3 09.p 1 The organization shall destroy media when it is no longer needed for business or legal reasons. PCI DSS v3 9.8 Requirement was mapped to 09.p level 1 as PCI DSS v but not specifically addressed; language added 09.p 2 Formal procedures for the secure disposal ISO/IEC A q PCI Data The system shall not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, the system shall render all data unrecoverable upon completion of the authorization process. PCI DSS v3 3.2 PCI only requirement 09.q PCI Data The system shall not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic stripe data. PCI DSS v PCI only requirement 90 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
91 09.q PCI Data The system shall not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-no-present transactions. PCI DSS v PCI only requirement 09.q PCI Data The system shall not store the personal identification number (PIN) or the encrypted PIN block. PCI DSS v PCI only requirement 09.q PCI Data 09.q 1 09.q 1 The system shall mask the PAN when displaced (the first six and last our digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN. (Note this requirement does not supersede stricter requirements in place for displays of cardholder data for example, legal or payment card brand requirements for point-ofsale (POS) receipts.) PCI DSS v3 3.3 PR.DS-3 PR.PT-2 PCI only requirement Requires procedures for handling, processing, communication and storage of information, including media awaiting disposal Requires procedures for handling, processing, communication and storage of information, including media awaiting disposal 91 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
92 09.q 2 09.q 2 09.q 2 09.q 2 09.q 2 09.q 2 09.q 2 09.q 2 09.q 2 09.q 2 Updated: Updated: Updated: Updated: ISO/IEC A PCI DSS v2 9.6 PCI DSS v3 9.5 PCI DSS v2 9.7 PCI DSS v3 9.6 PCI DSS v2 9.8 PCI DSS v PCI DSS v2 9.9 PCI DSS v3 9.7 PCI DSS v3 3.2 PCI DSS v PCI DSS v PCI DSS v PCI DSS v3 3.3 remapped in PCI DSS v3 remapped in PCI DSS v3 remapped in PCI DSS v3 remapped in PCI DSS v3 Requirements related to handling and storage of sensitive payment card authentication data Requirements related to handling and storage of sensitive payment card authentication data Requirements related to handling and storage of sensitive payment card authentication data Requirements related to handling and storage of sensitive payment card authentication data PCI only requirement 92 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
93 09.q 2 09.r 1 09.s 1 The organization shall maintain strict control over the storage and accessibility of media. Management shall approve any and all media PCI DSS v3 9.7 ID.RA-1 ISO/IEC A Requirement was mapped to 09.q level 2 as PCI DSS v2 9.9 but not addressed; language added Protection of system documentation necessary to avoid disclosure of possible vulnerabilities 09.s 1 The organization shall ensure that communications protection requirements and compliance audits (see 06.g) consistent with relevant legislation. ID.GV-3 Consistent with relevant legislation policy language in the control objective, which was not explicitly addressed 09.s 1 PR.AC-3 Addresses requirements for remote access sessions 93 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
94 09.s 1 Formal procedures shall be defined to encrypt data in transit including use of strong cryptography protocols to safeguard covered information during transmission over open public networks. Only trusted keys and certificates shall be accepted The protocol in use shall only support secure versions or configurations The encryption strength shall be appropriate to the encryption methodology in use PCI DSS v3 4.1 Requirement is addressed in level 1 vice level 2; language updated to reflect changes in PCI DSS v3 09.s 2 09.t 1 09.t 1 09.u 1 09.u 1 Removed: PCI DSS v2 4.1 ISO/IEC A PR.AT-3 ISO/IEC A PR.DS-2 Requirement is addressed in level 1 vice level 2 Exchange agreements identify specific responsibilities for third-parties Addresses data (media) in transit 94 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
95 09.u 1 09.u 1 09.v 1 09.v 1 09.v 1 09.v 1 Updated: Updated: PR.PT-2 PCI DSS v PCI DSS v ISO/IEC A ID.GV-3 PR.DS-2 PR.DS-5 Addresses transit of all media remapped in PCI DSS v3 Addresses legal considerations, e.g., re: electronic signatures Addresses electronic messaging Security of electronic messaging supports data leakage prevention 09.v 1 The organization shall never send unencrypted covered sensitive information (e.g., covered information, PANs) by end-user messaging technologies (e.g. , instant messaging, and chat). PCI DSS v3 4.2 Requirement for covered information already addressed 09.w 1 Updated: HIPAA cross reference HIPAA (b)(43) Prior content in (b)(3) was deleted in the Omnibus Rule; (b)(4) was subsequently renumbered 95 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
96 09.w 2 09.w 2 09.w 2 09.x 1 09.x 1 09.x 1 09.x 1 09.x 2 09.y 1 09.y 1 DE.AE-1 PR.AC-5 PR.IP-1 ID.GV-3 PR.DS-1 PR.DS-2 PR.DS-5 ISO/IEC A PR.DS-1 PR.DS-2 Addresses baselines for basic security hygiene in interconnected systems Addresses segregation of untrusted and trusted networks Specifies baselines for basic security hygiene in interconnected systems Addressed legal requirements for the use of cryptographic controls Specifies data in transit protections for electronic commerce, e.g., the use of cryptographic controls to enhance security Specifies data at rest protections for electronic commerce, e.g., the loss or duplication of order information Multiple requirements support data leakage prevention Specifies data in transit protections for online transactions, e.g., the use of cryptographic controls Specifies security shall be maintained through all aspects of the transaction 96 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
97 09.y 1 09.y 2 09.z 1 09.z 1 09.z 2 09.z 2 09.z 2 09.z 2 09.z 3 10.a 1 PR.DS-5 ISO/IEC A PR.AC-4 PR.DS-6 ISO/IEC A DE.CM-6 ID.GV-3 PR.IP-1 ISO/IEC A PR.IP-2 Multiple requirements support data leakage prevention Specifies only authorized individuals may post information onto publically accessible information systems Requires protections for the integrity of the information stored, processed and transmitted Requires vulnerability testing of publically accessible systems Requires information to be obtained in compliance with any relevant legislation Requires testing to ensure security baselines and configurations are met Security requirements analysis and specification is initial part of SDLC process 97 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
98 10.a 2 ISO/IEC 27001:2013 A ISO/IEC 27002:2013 A ISO/IEC 27002:2013 A ISO/IEC 27002:2013 A ISO/IEC 27002:2013 A ISO/IEC 27002:2013 A ISO/IEC 27002:2013 A a 2 the project management methodology. Organizations shall establish and appropriately protect secure development environment for system development and integration efforts that cover the entire system development lifecycle. ISO/IEC 27002:2013 A Addresses information security in system development and acquisition ISO cross reference and evolution of requirements. 10.a 2 Organizations developing software or systems shall perform thorough testing and verification during the development process. Independent acceptance testing should then be undertaken (both for in-house and for outsourced developments) to ensure the system works as expected and only as expected. The extent of testing should be in proportion to the importance and nature of the system. ISO/IEC 27002:2013 A Addresses information security in system development and acquisition ISO cross reference 98 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
99 10.a 2 The organization shall apply information system security engineering principles in the specification, design, development, implementation, and modification of security requirements and controls in developed and acquired information systems. Organizations shall include business requirements for the availability of information systems when specifying security requirements. Where availability cannot be guaranteed using existing architectures, redundant components or architectures should be considered along with the risks associated with implementing such redundancies. ISO/IEC 27002:2013 A Incorporated new requirement to address system availability in the security engineering / SDLC process Specifications for the security control requirements ISO cross reference 10.a 2 Information security shall be addressed in all phases of the project management methodology. ISO/IEC 27002:2013 A Addresses information security in system development and acquisition 10.b 1 ISO cross reference PR.DS-5 Data input validation helps prevent certain exploits that could result in data leakage 99 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
100 10.b 1 PR.DS-6 Specific to data input integrity 10.b 2 i. improper error handling (Do not leak information via error messages) ii. broken authentication/sessions (Prevent unauthorized individuals from compromising legitimate account credentials, keys or session tokens that would otherwise enable an intruder to assume the identity of an authorized user) PCI DSS v Added new validation requirement in PCI DSS v3 For web applications and application interfaces (internal or external) this also includes but is not limited to: 10.b 2 i. cross-site scripting (XSS) (Validate all parameters before inclusion, utilize context-sensitive escaping, etc.) ii. improper Access, such as insecure direct object references, failure to restrict URL access, and directory traversal, and failure to restrict user access functions PCI DSS v Added new language in PCI DSS v3 100 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
101 10.b 2 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: i. reviewing applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes; ii. installing an automated technical solution that detects and prevents Web-based attacks (e.g., a Web-application firewall) in front of public-facing Web applications, to continually check all traffic. PCI DSS v3 6.6 Existing language was not specific to public-facing Web applications nor did it address the requirement for a technical solution; language added to reflect actual requirements 10.c 1 10.d 1 10.d 1 10.d 1 PR.DS-6 PR.DS-2 PR.DS-5 PR.DS-6 Specific to integrity of processing Specifically addresses data in transit s prevent data leakage during messaging Addresses integrity of data during messaging 101 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
102 10.f 1 10.f 1 10.f 2 10.f 2 PR.DS-1 PR.DS-2 ISO/IEC A ID.GV-3 Cryptographic control requirements support protection of data at rest Cryptographic control requirements support protection of data in transit Address legal and regulatory requirements for cryptography Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) of the following forms at all times: 10.g PCI Data 10.g 1 i. Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the dataencrypting key. ii. Within a secure cryptographic device (such as a host security module (HSM) or PTSapproved point-of-interaction device). iii. As at least two full-length key components or key shares, in accordance with an industry- accepted method. PCI DSS v PR.DS-1 New content in is PCI-specific Cryptographic control requirements support protection of data at rest 102 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
103 10.g 1 10.g 2 10.g 2 PR.DS-2 ISO/IEC A PCI DSS v3 3.4 Cryptographic control requirements support protection of data in transit General requirement to protect cryptographic keys addressed by 10.g 10.g 2 v. storing keys in the fewest possible locations, including how authorized users obtain access to keys; PCI DSS v General requirement for storing cryptographic keys addressed in 10.g 10.g 2 A key management system shall be based on a formal set of standards, procedures, and secure methods for: i. verifying identity prior to generating new keys or certificates for users; ii. PCI DSS v Added new language in that expands verification of user identity beyond passwords to other types of authenticators 10.h 1 10.h 1 ISO/IEC A PR.IP-1 Requires maintenance of current information system baselines 103 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
104 10.h 1 10.h 2 10.i 1 10.i 1 10.i 1 10.i 1 10.i 1 10.i 2 PR.IP-3 PR.DS-7 PR.AC-1 PR.AC-2 PR.AC-3 PR.AC-4 PR.AC-5 ISO/IEC A Requires maintenance of operational software IAW configuration baselines Requires testing of operational software on separate (non-production) systems States the access control procedures, which apply to operational application systems, shall also apply to test application systems States the access control procedures, which apply to operational application systems, shall also apply to test application systems States the access control procedures, which apply to operational application systems, shall also apply to test application systems States the access control procedures, which apply to operational application systems, shall also apply to test application systems States the access control procedures, which apply to operational application systems, shall also apply to test application systems 104 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
105 10.i 2 10.i 2 10.i 2 10.i 2 10.j 1 10.j 1 10.j 2 10.k 1 10.k 1 10.k 2 PR.DS-1 PR.DS-2 PR.PT-1 PR.PT-3 PR.DS-5 PR.PT-3 ISO/IEC A ISO/IEC ISO/IEC A PR.IP-3 ISO/IEC A ISO/IEC A States security controls shall be equally applied to non-production environments as production environments States security controls shall be equally applied to non-production environments as production environments Specifies audit trail for use of operational information States personnel developing & testing system code from having access to production libraries (least privilege) Safeguards against the introduction of unauthorized functionality supports data leakage prevention States access to program source code shall be restricted Requires change control; specific requirements contained in level This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
106 10.k 2 10.k 2 10.k 2 10.k 2 10.k 2 10.k 2 10.k 3 10.k 3 10.k 3 10.k 3 ID.AM-6 ID.RA-4 ID.RA-5 PR.AT-3 PR.IP-2 PR.PT-3 DE.CM-1 DE.CM-7 PR.IP-1 PR.IP-1 Addresses roles and responsibilities Specifies identification of potential impacts Requires risk assessment Specifies requirements in third party agreements / contracts States procedures must be incorporated into the SDLC process Restricts access based on least privilege / minimum necessary Requires monitoring of configuration settings Requires auditing of automated access restriction enforcement actions Specifically requires current configuration baselines for information systems Requires current baseline 106 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
107 10.l 1 10.l 1 10.l 1 10.l 1 10.l 1 10.l 1 10.l 2 10.l 2 ISO/IEC ISO/IEC A DE.CM-4 ID.BE-1 ID.RA-3 ID.RA-6 PR.AT-3 DE.CM-6 PR.IP-2 Requires testing for malicious code Role in the supply chain is communicated through contractual requirements Protection against supply chain threats requires identification of those threat Protection against supply chain threats requires identification of risk response Addresses contract requirements for outsourced software development Requires supervision and monitoring of outsourced software development Addresses security in the SDLC for outsourced software development up to implementation 10.m PCI Data Perform quarterly internal vulnerability scans and rescans as needed, until all high-risk vulnerabilities (as identified in Requirement 6.1) are resolved. Scans must be performed by qualified personnel. PCI DSS v Added content to PCI segment due to additional criteria for rescans and qualified personnel 107 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
108 10.m PCI Data 10.m PCI Data Perform quarterly external vulnerability scans, via an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). Perform rescans as needed, until passing scans are achieved. Perform internal and external scans, and rescans as needed, after any significant change. Scans must be performed by qualified personnel. PCI DSS v PCI DSS v Added content to PCI segment due to additional criteria for rescans and qualified personnel Added content to PCI segment due to additional criteria for rescans and qualified personnel 108 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
109 Implement a methodology for penetration testing that: 10.m PCI Data i. is based on industry-accepted penetration testing approaches (e.g., NIST SP ), ii. includes coverage for the entire card data environment (CDE) perimeter and critical systems, iii. includes testing from both inside and outside the network, iv. includes testing to validate any segmentation and scope-reduction controls, v. defines application-layer penetration tests to include, at a minimum, the vulnerabilities identified in 10.b, level 1 (reference PCI DSS v3 6.5), vi. defines network-layer penetration tests to include components that support network functions as well as operating systems, vii. includes review and consideration of threats and vulnerabilities experienced in the last 12 months, and viii. specifies retention of penetration testing results and remediation activities results. PCI DSS v Extensive requirements for the implementation of a penetration testing methodology is specific to PCI DSS v3 109 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
110 10.m PCI Data 10.m 1 10.m 1 10.m 1 10.m 1 10.m 1 10.m 1 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. Removed: A web-application firewall shall be placed in front of public-facing web application to detect and prevent web-based attacks. PCI DSS v2 6.6 PCI DSS v ID.RA-1 ID.RA-2 ID.RA-4 ID.RA-6 RS.MI-3 PCI DSS v3 6.6 New requirement related to pen testing addressed in 10.m, level 3; this requirement is specific to PCI Requires the organization to obtain timely information about technical vulnerabilities Requires the organization to obtain timely information about technical vulnerabilities Requires evaluation of an organization s exposure; actual risk assessment is specified in level 2 Requires remediation of identified vulnerabilities Requires remediation of identified vulnerabilities Language was changed in v3; Webapplication firewall is only an example of the type of solution that may be required; PCI DSS v2 6.6 is addressed by CSF control 10.b This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
111 10.m 2 10.m 2 10.m 2 10.m 2 10.m 2 10.m 2 10.m 2 10.m 2 Updated: ISO/IEC A DE.CM-8 ID.AM-6 ID.RA-5 PR.IP-12 PR.PT-1 RS.CO-3 PCI DSS v2 6.2 PCI DSS v3 6.1 Requires vulnerability monitoring and assessments Requires establishment of roles and responsibilities Requires assignment of a risk ranking to newly discovered vulnerabilities Requires a technical vulnerability management program Requires auditing (logging) of all procedures undertaken Requires the organization to identify any coordination responsibilities required remapped in PCI DSS v3 111 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
112 10.m 2 10.m 3 10.m 3 Internal and external vulnerability assessments of covered sensitive information systems (e.g., systems containing covered information, cardholder data) and networked environments shall be performed on a quarterly basis, and after any significant change in the network (e.g., new system component installations, changes in network topology, firewall rule modifications, product upgrades), by a qualified individual. These tests shall include both network- and application-layer tests. Updated: PCI DSS v PR.PT-3 PCI DSS v2 6.1 PCI DSS v3 6.2 Added language based on changes in PCI DSS v Specifies privileged access authorization to facilitate more thorough scanning remapped in PCI DSS v3 112 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
113 10.m 3 Perform eexternal and internal network penetration testing and an enterprise security posture review shall be performed at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a Web server added to the environment). The penetration test should also include application-layer penetration tests. PCI DSS v PCI DSS v Updated with additional language in PCI DSS v and ; enterprise security posture review addressed separately to avoid confusion with the pen test requirements. Perform an enterprise security posture review annually. 10.m 3 The penetration test should also include application-layer penetration tests. Exploitable vulnerabilities found during penetration testing are corrected and testing is repeated to verify the corrections. PCI DSS v New requirement related to pen testing addressed in 10.m, level 3 11.a PCI Data 11.a 1 The organization shall designate specific personnel to be available on a 24/7 basis to respond to alerts. PCI DSs v RS.CO-2 24/7 response exceeds requirements specified in 11.a, level 1 Requires reporting IAW specified criteria 113 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
114 11.a 1 11.a 1 11.a 2 Updated: Updated: Removed: Subject to PCI Compliance, Subject to HITECH Breach Notification Requirements, Subject to 1 Regulatory Factor PCI DSS v PCI DSS v PCI DSS v PCI DSS v Administrative change remapped in PCI DSS v3 remapped in PCI DSS v3 HITECH breach notification requirements incorporated into the HIPAA Administrative Simplification at Subpart D 11.a 2 Reports to the individuals affected by the incident shall be included in the breach. For fewer than 10 individuals, a substitute form of notice reasonably calculated to reach the individual shall be provided, except when there is insufficient or out-of-date information that precludes written notification to the next of kin or personal representative. The organization shall also notify, without HIPAA (d)(2) Added missing requirement for less than 10 individuals when substitute notice is required. 114 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
115 11.a 2 The policy shall refer to the specific... Procedures shall be developed to provide for the definition and assessment of information security incidents (e.g., an event/incident classification scale to decide whether an event classifies as an incident), roles and responsibilities, incident handling, reporting and communication processes ISO/IEC 27002:2013 A Provides additional clarification for existing requirement for the definition of information security incidents 11.a 2 11.a 2 11.a 2 11.a 2 ISO cross reference Removed: Removed: ISO/IEC A ID.GV-3 PCI DSS v PCI DSS v Outlines specific reporting requirements from the HIPAA Data Breach Notification Rule 11.a addresses reporting information security events but does not require formally assigning responsibilities for monitoring, analyzing and distributing security alerts; this will be addressed in 05.c 11.a addresses related procedures but does not require formally assigning responsibilities for establishing, documenting and distributing security incident response and escalation procedures; this will be addressed in 05.c 115 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
116 11.a 2 11.a 2 11.a 2 11.a 3 11.a 3 11.b 1 11.b 1 11.c 1 11.c 1 11.c 1 Updated: Updated: Updated: PCI DSS v PCI DSS v PCI DSS v PCI DSS v PCI DSS v PCI DSS v ISO/IEC A PR.IP-7 ISO/IEC A ID.RA-1 PR.IP-9 RS.AN-4 RS.MI-1 remapped in PCI DSS v3 remapped in PCI DSS v3 remapped in PCI DSS v3 Requires improvement of implemented controls based on analysis of prior incidents Requires reporting of potential weaknesses (vulnerabilities) Establishes incident response capability (policies, procedures) Requirement to handle different types of incidents is specified (w/ examples provided) Specifies containment 116 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
117 11.c 1 11.c 1 Updated: RS.MI-2 PCI DSS v PCI DSS v Specifies corrective actions (mitigation) remapped in PCI DSS v3 11.c 1 Procedures shall be established to handle different types of information security incidents including: viii. identity theft; and ix. unauthorized wireless access points. PCI DSS v New requirement supporting PCI DSS v3 6.1 Removed: 11.c 2 Subject to PCI Compliance, Subject to FISMA Compliance, Subject to HITECH Breach Notification Requirements, Subject to Administrative change HITECH breach notification requirements incorporated into the HIPAA Administrative Simplification at Subpart D 1 Regulatory Factor 117 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
118 The organization shall respond to incidents in accordance with the documented procedures, which should include but not be limited to the following: 11.c 2 i. collecting evidence as soon as possible after the occurrence (see 11.e); ii. conducting information security forensic analysis, as required (see 11.e); iii. escalation, as required; iv. ensuring that all involved response activities are properly logged for later analysis; v. communicating the existence of the information security incident or any relevant details thereof to other internal and external people or organizations with a need-to-know; vi. dealing with information security weakness(es) found to cause or contribute to the incident; and vii. once the incident has been successfully addressed, formally closing and recording it. ISO/IEC 27002:2013 A New ISO control is intended to ensure organizations actually implement the procedures they develop 11.c 2 11.c 2 ISO cross reference ISO/IEC A ISO/IEC A DE.AE-3 The monitoring of systems, alerts, and vulnerabilities are used to detect information security incidents 118 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
119 11.c 2 11.c 2 11.c 2 11.c 2 11.c 2 11.c 2 11.c 2 11.c 2 11.c 3 11.c 3 Updated: Updated: Updated: PR.AT-1 RS.CO-3 RS.CO-4 RS.IM-2 RS.RP-1 PCI DSS v PCI DSS v PCI DSS v PCI DSS v PCI DSS v PCI DSS v ID.GV-3 RS.CO-1 Requires training of incident response personnel Requires communication of incident response policy/procedures to appropriate parties in the organization Multiple requirements addressing communication and coordination Periodic reviews of the incident response capability, which includes recovery strategies, are required Multiple requirements imply execution of response capability remapped in PCI DSS v3 remapped in PCI DSS v3 remapped in PCI DSS v3 Requires reporting consistent with applicable laws & regulations Order of operations (roadmap, approach) is addressed in level 3; responsibilities are also addressed 119 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
120 11.c 3 11.c 3 11.c 3 11.d 1 11.d 1 11.d 1 11.d 1 11.d 1 11.d 2 11.d 2 RS.CO-5 RS.IM-1 RS-CO-2 ISO/IEC A DE.AE-1 DE.AE-4 RS.AN-2 RS.RP-1 DE.AE-2 DE.AE-3 Requires communications (voluntary sharing) with stakeholders (e.g., CERT, FedCIRC) Requires updates to policies and procedures based on lessons learned (only periodic reviews are required in level 2) Requires reporting to appropriate authorities (external, e.g., law enforcement) Requires evaluation of incidents to determine likelihood and impact; which necessarily requires threat modeling Requires identification of recurring or high impact incidents Requires identification of recurring or high impact incidents Lessons learned implies capability was implemented Requires analysis as part of the incident capability Components of the incident response capability include IPS, IDS, forensics, and vulnerability assessments 120 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
121 11.d 2 ID.AM-6 Required definition of roles and responsibilities 11.d 2 The organization shall: 1. implement an incident handling capability for security incidents that includes detection and analysis, containment, eradication, and recovery (including public relations); RC.CO-1 Lessons learned imply implementation; capability includes recovery and language added for clarification around public relations 11.d 2 The organization shall: 2. implement an incident handling capability for security incidents that includes detection and analysis, containment, eradication, and recovery (including public relations and reputation management); RC.CO-2 Lessons learned imply implementation; capability includes recovery and language added for clarification around mitigating negative impact to organizational reputation 11.d 2 11.d 2 RC.CO-3 RC.IM-1 Requires coordination of incident handling activities with contingency planning Requires incorporation of lessons learned (capability includes recovery) 121 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
122 11.d 2 11.d 2 11.d 2 11.d 2 11.d 2 11.d 2 11.d 2 11.d 2 11.d 2 11.d 2 RC.IM-2 RC.IP-1 RS.AN-1 RS.AN-2 RS.CO-3 RS.CO-4 RS.IM-1 RS.IM-2 RS.MI-1 RS.MI-2 Requires implementation of changes IAW lessons learned (capability includes recovery) Lessons learned imply implementation; capability includes recovery and language added for clarification around public relations Requires detection and analysis (investigation) Addresses forensics Requires communication Requires coordination Requires incorporation of lessons learned Requires implementation of changes IAW lessons learned Addresses containment Addresses eradication (mitigation) 122 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
123 11.d 2 Updated: PCI DSS v PCI DSS v remapped in PCI DSS v3 11.e PCI Data 11.e 1 11.e 1 11.e 1 11.e 2 11.e 2 12.a 1 A service provider shall protect each organization s hosted environment and data by enabling process to provide for timely forensic investigation in the event of a compromise to any hosted merchant or service provider. Removed: Subject to HITECH Breach Notification Requirements 1 Regulatory Factor PCI DSS v3 A.1.4 Administrative change ID.GV-3 RS.AN-2 ISO/IEC A PR.IP-11 ID.AM-5 Specific language addressing logs and audit trails unique to each organization s cardholder data environment HITECH breach notification requirements incorporated into the HIPAA Administrative Simplification at Subpart D Addresses collection of evidence IAW the laws of the relevant jurisdiction(s) Addresses collection of evidence IAW the laws of the relevant jurisdiction(s) Requires procedures for the purposes of disciplinary action (HR security) Requires identification of all critical information system assets 123 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
124 12.a 2 12.a 2 12.a 2 12.a 2 12.a 2 12.b 1 12.b 1 12.b 1 12.b 1 ISO/IEC A DE.AE-4 ID.AM-6 ID.BE-5 PR.IP-9 ID.BE-2 ID.BE-4 ID.RA-1 ID.RA-3 Requires an understanding of the risks, including likelihood and impact Requires assignment of responsibilities to an individual at an appropriate level with the organization Requires an understanding of the impact incidents have on the business to establish business objectives of the information assets Identifies key elements of the business continuity program Requires a holistic view of the organization s environment to determine potential causes of interruption Requires a plan to implement the overarching business continuity strategy; additional detail provided in level 2 Requires identification of vulnerabilities wrt identification of threats (part of risk assessment) Requires identification of internal and external threats to continuity of operations 124 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
125 12.b 1 12.b 1 12.b 2 12.b 2 12.c 1 12.c 1 12.c 1 12.c 1 12.c 1 12.c 1 ID.RA-4 ID.RA-5 ISO/IEC A ID.RM-3 ID.AM-5 ID.AM-6 ID.BE-4 ID.BE-5 PR.IP-9 RC.CO-3 Requires determination of potential impacts Requires a risk determination Requires a BIA wrt the consequences of disasters, security failures, loss of service and service availability Addresses required business objectives for restoration (priorities) Addresses roles and responsibilities in the planning process Addresses assessment of internal and external dependencies Establishes RTOs/RPOs Specifically address business continuity implementation and management; additional detail provided in levels 2 & 3 Addresses distribution to specific individuals or their functional equivalents 125 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
126 12.c 1 12.c 1 12.c 1 12.c 2 12.c 2 12.c 2 12.c 2 12.c 2 12.c 2 12.d 1 Updated: RC.RP-1 RS.CO-4 PCI DSS v PCI DSS v ISO/IEC A PR.AT-1 PR.DS-1 PR.DS-4 PR.IP-7 RS.CO-1 DE.AE-5 specification addresses implementation of the plans, which are the focus of the requirement statements throughout the control Requires coordination of contingency planning activities with incident handling activities remapped in PCI DSS v3 Addresses education of staff Requires protection of BC documentation, which could indicate vulnerabilities if disclosed inappropriately Requirements for the resumption of normal services addressed for alternate processing sites Requires plans be kept up-to-date Addresses identification and agreement of all responsibilities and procedures Requires conditions for activating the plans as well as escalation plans 126 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
127 12.d 1 12.d 1 12.d 1 12.d 1 12.d 1 Removed: ID.AM-5 ID.AM-6 ID.BE-5 PR.AT-1 RS.CO-1 Requires the framework to identify critical assets and resources needed Specifies plans shall have a specific owner Addresses procedures to move essential activities or support services to alternative temporary locations Addresses training requirements Plans must specify the individuals responsible for executing each component of the plan 12.d 2 Each plan shall have a specific owner. Emergency procedures, shall include defined responsibilities of the service providers. Removed: Administrative change Requirements are a duplicate of language contained in level 1 12.d 2 12.d 2 Each business continuity plan shall describe the approach for continuity, ensuring new requirements are identified, any existing emergency procedures (e.g. evacuation plans or fallback arrangements) shall be amended as appropriate. Administrative change ISO/IEC A Requirements are a duplicate of language contained in level This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
128 12.e 1 12.e 1 12.e 1 12.e 1 12.e 1 ID.AM-6 ID.GV-3 PR.IP-10 PR.IP-7 PR.IP-9 Requires team members to understand their roles and responsibilities Requires updates due to changes in legislation Specifically addresses testing Addresses continuous improvement (continued effectiveness) of the business continuity plans Testing is part of plan management 12.e 1 The test schedule for business continuity plan(s) shall indicate how and when each element of the plan is tested. The results of tests shall be recorded and actions taken to improve the plans, where necessary. Updates will also consider lessons learned from implementation of the business continuity plan(s). RC.IM-1 Language added as this requirement is not explicitly addressed 12.e 1 12.e 1 RC.IM-2 RS.CO-1 Requires plan updates to maintain or improve effectiveness Requires team members to understand their roles and responsibilities (specific to business continuity / recovery) 128 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
129 12.e 2 All All All All Replace: HITECH Act, Subpart D HIPAA HITECH cross reference Updated: PCI DSS v23 ISO/IEC A Administrative change Administrative change All relevant CSF mappings not otherwise addressed in this Summary of Changes is updated to reflect incorporation of HITECH data breach notification requirements into the HIPAA Administrative Simplifications at Subpart D All relevant CSF mappings not otherwise addressed in this Summary of Changes is updated to reflect new PCI-DSS release 129 This document is the PROPIETARY and CONFIDENTIAL Information It may not be used, disclosed or reproduced, in whole or in part, without the express written permission
Cybersecurity Framework Security Policy Mapping Table
Cybersecurity Framework Security Policy Mapping Table The following table illustrates how specific requirements of the US Cybersecurity Framework [1] are addressed by the ISO 27002 standard and covered
CRR-NIST CSF Crosswalk 1
IDENTIFY (ID) Asset Management (AM): The data, personnel, devices, systems, and facilities that enable the organization to achieve business purposes are identified and managed consistent with their relative
NIST CYBERSECURITY FRAMEWORK COMPLIANCE WITH OBSERVEIT
NIST CYBERSECURITY FRAMEWORK COMPLIANCE WITH OBSERVEIT OVERVIEW The National Institute of Standards of Technology Framework for Improving Critical Infrastructure Cybersecurity (The NIST Framework) is a
Automation Suite for NIST Cyber Security Framework
WHITEPAPER NIST Cyber Security Framework Automation Suite for NIST Cyber Security Framework NOVEMBER 2014 Automation Suite for NIST Cyber Security Framework The National Institute of Standards and Technology
IT ASSET MANAGEMENT Securing Assets for the Financial Services Sector
IT ASSET MANAGEMENT Securing Assets for the Financial Services Sector V.2 Final Draft May 1, 2014 [email protected] This revision incorporates comments from the public. Page Use case 1 Comments
Happy First Anniversary NIST Cybersecurity Framework:
Happy First Anniversary NIST Cybersecurity Framework: We ve Hardly Known Ya Chad Stowe, CISSP, CISA, MBA Who is your organization on Cybersecurity? Problem Statement Management has not been given the correct
ACCESS RIGHTS MANAGEMENT Securing Assets for the Financial Services Sector
ACCESS RIGHTS MANAGEMENT Securing Assets for the Financial Services Sector V.2 Final Draft May 1, 2014 [email protected] This revision incorporates comments from the public. Page Use case 1 Comments
Payment Card Industry (PCI) Data Security Standard. Summary of Changes from PCI DSS Version 2.0 to 3.0
Payment Card Industry (PCI) Data Security Standard Summary of s from Version 2.0 to 3.0 November 2013 Introduction This document provides a summary of changes from v2.0 to v3.0. Table 1 provides an overview
Critical Manufacturing Cybersecurity Framework Implementation Guidance
F Critical Manufacturing Cybersecurity Framework Implementation Guidance i Foreword The National Institute of Standards and Technology (NIST) released the 2014 Framework for Improving Critical Infrastructure
Managed Hosting & Datacentre PCI DSS v2.0 Obligations
Any physical access to devices or data held in an Melbourne datacentre that houses a customer s cardholder data must be controlled and restricted only to approved individuals. PCI DSS Requirements Version
Framework for Improving Critical Infrastructure Cybersecurity
Framework for Improving Critical Infrastructure Cybersecurity January 2016 [email protected] Improving Critical Infrastructure Cybersecurity It is the policy of the United States to enhance the security
Applying IBM Security solutions to the NIST Cybersecurity Framework
IBM Software Thought Leadership White Paper August 2014 Applying IBM Security solutions to the NIST Cybersecurity Framework Help avoid gaps in security and compliance coverage as threats and business requirements
Improving Critical Infrastructure Cybersecurity Executive Order 13636. Preliminary Cybersecurity Framework
1 Improving Critical Infrastructure Cybersecurity Executive Order 13636 Preliminary Cybersecurity Framework 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
NIST Cybersecurity Framework & A Tale of Two Criticalities
NIST Cybersecurity Framework & A Tale of Two Criticalities Vendor Management & Incident Response Presented by: John H Rogers, CISSP Advisory Services Practice Manager [email protected] Presented
Access Control BUSINESS REQUIREMENTS FOR ACCESS CONTROL
AU7087_C013.fm Page 173 Friday, April 28, 2006 9:45 AM 13 Access Control The Access Control clause is the second largest clause, containing 25 controls and 7 control objectives. This clause contains critical
Altius IT Policy Collection Compliance and Standards Matrix
Governance IT Governance Policy Mergers and Acquisitions Policy Terms and Definitions Policy 164.308 12.4 12.5 EDM01 EDM02 EDM03 Information Security Privacy Policy Securing Information Systems Policy
NIST Cybersecurity Framework Sean Sweeney, Information Security Officer 5/20/2015
NIST Cybersecurity Framework Sean Sweeney, Information Security Officer 5/20/2015 Overview The University of Pittsburgh NIST Cybersecurity Framework Pitt NIST Cybersecurity Framework Program Wrap Up Questions
PCI DSS 3.0 Changes Bill Franklin Executive IT Auditor [email protected] January 23, 2014
PCI DSS 3.0 Changes Bill Franklin Executive IT Auditor [email protected] January 23, 2014 Agenda Introduction PCI DSS 3.0 Changes What Can I Do to Prepare? When Do I Need to be Compliant? Questions
Using the HITRUST CSF to Assess Cybersecurity Preparedness 1 of 6
to Assess Cybersecurity Preparedness 1 of 6 Introduction Long before the signing in February 2013 of the White House Executive Order Improving Critical Infrastructure Cybersecurity, HITRUST recognized
Appendix B: Mapping Cybersecurity Assessment Tool to NIST
Appendix B: to NIST Cybersecurity Framework In 2014, the National Institute of Standards and Technology (NIST) released a Cybersecurity Framework for all sectors. The following provides a mapping of the
Framework for Improving Critical Infrastructure Cybersecurity
Framework for Improving Critical Infrastructure Cybersecurity Version 1.0 National Institute of Standards and Technology February 12, 2014 Table of Contents Executive Summary...1 1.0 Framework Introduction...3
Framework for Improving Critical Infrastructure Cybersecurity
Framework for Improving Critical Infrastructure Cybersecurity Version 1.0 National Institute of Standards and Technology February 12, 2014 Table of Contents Executive Summary...1 1.0 Framework Introduction...3
Looking at the SANS 20 Critical Security Controls
Looking at the SANS 20 Critical Security Controls Mapping the SANS 20 to NIST 800-53 to ISO 27002 by Brad C. Johnson The SANS 20 Overview SANS has created the 20 Critical Security Controls as a way of
Automate PCI Compliance Monitoring, Investigation & Reporting
Automate PCI Compliance Monitoring, Investigation & Reporting Reducing Business Risk Standards and compliance are all about implementing procedures and technologies that reduce business risk and efficiently
05.0 Application Development
Number 5.0 Policy Owner Information Security and Technology Policy Application Development Effective 01/01/2014 Last Revision 12/30/2013 Department of Innovation and Technology 5. Application Development
Using Automated, Detailed Configuration and Change Reporting to Achieve and Maintain PCI Compliance Part 4
WHITEPAPER Using Automated, Detailed Configuration and Change Reporting to Achieve and Maintain PCI Compliance Part 4 An in-depth look at Payment Card Industry Data Security Standard Requirements 10, 11,
Information Technology Branch Access Control Technical Standard
Information Technology Branch Access Control Technical Standard Information Management, Administrative Directive A1461 Cyber Security Technical Standard # 5 November 20, 2014 Approved: Date: November 20,
Security Control Standards Catalog
Security Control Standards Catalog Version 1.2 Texas Department of Information Resources April 3, 2015 Contents About the Security Control Standards Catalog... 1 Document Life Cycle... 1 Revision History...
Security and Privacy Controls for Federal Information Systems and Organizations
NIST Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems JOINT TASK FORCE TRANSFORMATION INITIATIVE This document contains excerpts from NIST Special Publication
Framework for Improving Critical Infrastructure Cybersecurity
Framework for Improving Critical Infrastructure Cybersecurity April 2016 [email protected] Pre-Cybersecurity Framework Threat Landscape 79% of reported victims were targets of opportunity 96% of
Logging In: Auditing Cybersecurity in an Unsecure World
About This Course Logging In: Auditing Cybersecurity in an Unsecure World Course Description $5.4 million that s the average cost of a data breach to a U.S.-based company. It s no surprise, then, that
HIPAA Security Alert
Shipman & Goodwin LLP HIPAA Security Alert July 2008 EXECUTIVE GUIDANCE HIPAA SECURITY COMPLIANCE How would your organization s senior management respond to CMS or OIG inquiries about health information
March 2012 www.tufin.com
SecureTrack Supporting Compliance with PCI DSS 2.0 March 2012 www.tufin.com Table of Contents Introduction... 3 The Importance of Network Security Operations... 3 Supporting PCI DSS with Automated Solutions...
VMware vcloud Air HIPAA Matrix
goes to great lengths to ensure the security and availability of vcloud Air services. In this effort VMware has completed an independent third party examination of vcloud Air against applicable regulatory
IT Best Practices Audit TCS offers a wide range of IT Best Practices Audit content covering 15 subjects and over 2200 topics, including:
IT Best Practices Audit TCS offers a wide range of IT Best Practices Audit content covering 15 subjects and over 2200 topics, including: 1. IT Cost Containment 84 topics 2. Cloud Computing Readiness 225
Attachment A. Identification of Risks/Cybersecurity Governance
Attachment A Identification of Risks/Cybersecurity Governance 1. For each of the following practices employed by the Firm for management of information security assets, please provide the month and year
Compliance Guide ISO 27002. Compliance Guide. September 2015. Contents. Introduction 1. Detailed Controls Mapping 2.
ISO 27002 Compliance Guide September 2015 Contents Compliance Guide 01 02 03 Introduction 1 Detailed Controls Mapping 2 About Rapid7 7 01 INTRODUCTION If you re looking for a comprehensive, global framework
This policy shall be reviewed at least annually and updated as needed to reflect changes to business objectives or the risk environment.
- 1. Policy Statement All card processing activities and related technologies must comply with the Payment Card Industry Data Security Standard (PCI-DSS) in its entirety. Card processing activities must
Miami University. Payment Card Data Security Policy
Miami University Payment Card Data Security Policy IT Policy IT Standard IT Guideline IT Procedure IT Informative Issued by: IT Services SCOPE: This policy covers all units within Miami University that
Top Ten Technology Risks Facing Colleges and Universities
Top Ten Technology Risks Facing Colleges and Universities Chris Watson, MBA, CISA, CRISC Manager, Internal Audit and Risk Advisory Services [email protected] April 23, 2012 Overview Technology
Preparing for PCI DSS 3.0 & Ensuring a Seamless Transition. November 2013
Preparing for PCI DSS 3.0 & Ensuring a Seamless Transition November 2013 Introductions Brian Serra PCI Practice Director Nick Puetz Managing Director - Strategic Services 2013 FishNet Security Inc. All
ISO 27001 Controls and Objectives
ISO 27001 s and Objectives A.5 Security policy A.5.1 Information security policy Objective: To provide management direction and support for information security in accordance with business requirements
FACT SHEET: Ransomware and HIPAA
FACT SHEET: Ransomware and HIPAA A recent U.S. Government interagency report indicates that, on average, there have been 4,000 daily ransomware attacks since early 2016 (a 300% increase over the 1,000
TASK -040. TDSP Web Portal Project Cyber Security Standards Best Practices
Page 1 of 10 TSK- 040 Determine what PCI, NERC CIP cyber security standards are, which are applicable, and what requirements are around them. Find out what TRE thinks about the NERC CIP cyber security
ISO27001 Controls and Objectives
Introduction This reference document for the University of Birmingham lists the control objectives, specific controls and background information, as given in Annex A to ISO/IEC 27001:2005. As such, the
EVALUATION REPORT. Weaknesses Identified During the FY 2014 Federal Information Security Management Act Review. March 13, 2015 REPORT NUMBER 15-07
EVALUATION REPORT Weaknesses Identified During the FY 2014 Federal Information Security Management Act Review March 13, 2015 REPORT NUMBER 15-07 EXECUTIVE SUMMARY Weaknesses Identified During the FY 2014
ISO 27002:2013 Version Change Summary
Information Shield www.informationshield.com 888.641.0500 [email protected] Information Security Policies Made Easy ISO 27002:2013 Version Change Summary This table highlights the control category
<COMPANY> P01 - Information Security Policy
P01 - Information Security Policy Document Reference P01 - Information Security Policy Date 30th September 2014 Document Status Final Version 3.0 Revision History 1.0 09 November 2009: Initial release.
CREDIT CARD SECURITY POLICY PCI DSS 2.0
Responsible University Official: University Compliance Officer Responsible Office: Business Office Reviewed Date: 10/29/2012 CREDIT CARD SECURITY POLICY PCI DSS 2.0 Introduction and Scope Introduction
How To Achieve Pca Compliance With Redhat Enterprise Linux
Achieving PCI Compliance with Red Hat Enterprise Linux June 2009 CONTENTS EXECUTIVE SUMMARY...2 OVERVIEW OF PCI...3 1.1. What is PCI DSS?... 3 1.2. Who is impacted by PCI?... 3 1.3. Requirements for achieving
PCI Compliance for Cloud Applications
What Is It? The Payment Card Industry Data Security Standard (PCIDSS), in particular v3.0, aims to reduce credit card fraud by minimizing the risks associated with the transmission, processing, and storage
INFORMATION TECHNOLOGY SECURITY STANDARDS
INFORMATION TECHNOLOGY SECURITY STANDARDS Version 2.0 December 2013 Table of Contents 1 OVERVIEW 3 2 SCOPE 4 3 STRUCTURE 5 4 ASSET MANAGEMENT 6 5 HUMAN RESOURCES SECURITY 7 6 PHYSICAL AND ENVIRONMENTAL
Achieving PCI COMPLIANCE with the 2020 Audit & Control Suite. www.lepide.com/2020-suite/
Achieving PCI COMPLIANCE with the 2020 Audit & Control Suite 7. Restrict access to cardholder data by business need to know PCI Article (PCI DSS 3) Report Mapping How we help 7.1 Limit access to system
Microsoft s Compliance Framework for Online Services
Microsoft s Compliance Framework for Online Services Online Services Security and Compliance Executive summary Contents Executive summary 1 The changing landscape for online services compliance 4 How Microsoft
74% 96 Action Items. Compliance
Compliance Report PCI DSS 2.0 Generated by Check Point Compliance Blade, on July 02, 2013 11:12 AM 1 74% Compliance 96 Action Items Upcoming 0 items About PCI DSS 2.0 PCI-DSS is a legal obligation mandated
Security Management. Keeping the IT Security Administrator Busy
Security Management Keeping the IT Security Administrator Busy Dr. Jane LeClair Chief Operating Officer National Cybersecurity Institute, Excelsior College James L. Antonakos SUNY Distinguished Teaching
Central Agency for Information Technology
Central Agency for Information Technology Kuwait National IT Governance Framework Information Security Agenda 1 Manage security policy 2 Information security management system procedure Agenda 3 Manage
Small Firm Focus: A Practical Approach to Cybersecurity Friday, May 29 9:00 a.m. 10:15 a.m.
Small Firm Focus: A Practical Approach to Cybersecurity Friday, May 29 9:00 a.m. 10:15 a.m. Topics: Explain why it is important for firms of all sizes to address cybersecurity risk. Demonstrate awareness
WRITTEN INFORMATION SECURITY PROGRAM (WISP) ACME Consulting Services, Inc.
WRITTEN INFORMATION SECURITY PROGRAM (WISP) ACME Consulting Services, Inc. Copyright 2016 Table of Contents WRITTEN INFORMATION SECURITY PROGRAM (WISP) OVERVIEW 10 INTRODUCTION 10 PURPOSE 10 SCOPE & APPLICABILITY
PCI DSS 3.0 : THE CHANGES AND HOW THEY WILL EFFECT YOUR BUSINESS
PCI DSS 3.0 : THE CHANGES AND HOW THEY WILL EFFECT YOUR BUSINESS CIVICA Conference 22 January 2015 WELCOME AND AGENDA Change is here! PCI-DSS 3.0 is mandatory starting January 1, 2015 Goals of the session
Document No.: VCSATSP 100-100 Restricted Data Access Policy Revision: 4.0. VCSATS Policy Number: VCSATSP 100-100 Restricted Data Access Policy
DOCUMENT INFORMATION VCSATS Policy Number: VCSATSP 100-100 Title: Restricted Data Access Policy Policy Owner: Director Technology Services Effective Date: 2/1/2014 Revision: 4.0 TABLE OF CONTENTS DOCUMENT
New PCI Standards Enhance Security of Cardholder Data
December 2013 New PCI Standards Enhance Security of Cardholder Data By Angela K. Hipsher, CISA, QSA, Jeff A. Palgon, CPA, CISSP, QSA, and Craig D. Sullivan, CPA, CISA, QSA Payment cards a favorite target
PCI DSS Requirements - Security Controls and Processes
1. Build and maintain a secure network 1.1 Establish firewall and router configuration standards that formalize testing whenever configurations change; that identify all connections to cardholder data
ForeScout CounterACT and Compliance June 2012 Overview Major Mandates PCI-DSS ISO 27002
ForeScout CounterACT and Compliance An independent assessment on how network access control maps to leading compliance mandates and helps automate GRC operations June 2012 Overview Information security
Supplier Information Security Addendum for GE Restricted Data
Supplier Information Security Addendum for GE Restricted Data This Supplier Information Security Addendum lists the security controls that GE Suppliers are required to adopt when accessing, processing,
Virginia Commonwealth University School of Medicine Information Security Standard
Virginia Commonwealth University School of Medicine Information Security Standard Title: Scope: Business Continuity Management Standard for IT Systems This standard is applicable to all VCU School of Medicine
Network & Information Security Policy
Policy Version: 2.1 Approved: 02/20/2015 Effective: 03/02/2015 Table of Contents I. Purpose................... 1 II. Scope.................... 1 III. Roles and Responsibilities............. 1 IV. Risk
Wireless Infusion Pumps: Securing Hospitals Most Ubiquitous Medical Device
Wireless Infusion Pumps: Securing Hospitals Most Ubiquitous Medical Device The Healthcare Sector at the NCCoE MARCH, 3 2016 THE NATIONAL CYBERSECURITY LAB HELPS SECURE HIT 1. About Us: The National Cybersecurity
University of Pittsburgh Security Assessment Questionnaire (v1.5)
Technology Help Desk 412 624-HELP [4357] technology.pitt.edu University of Pittsburgh Security Assessment Questionnaire (v1.5) Directions and Instructions for completing this assessment The answers provided
www.xceedium.com 2: Do not use vendor-supplied defaults for system passwords and other security parameters
2: Do not use vendor-supplied defaults for system passwords and other security parameters 2.1: Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing
Payment Card Industry (PCI) Data Security Standard. Summary of Changes from PCI DSS Version 1.2.1 to 2.0
Payment Card Industry (PCI) Data Security Standard Summary of s from PCI DSS Version 1.2.1 to 2.0 October 2010 General General Throughout Removed specific references to the Glossary as references are generally
Safeguards Frameworks and Controls. Security Functions Parker, D. B. (1984). The Many Faces of Data Vulnerability. IEEE Spectrum, 21(5), 46-49.
Safeguards Frameworks and Controls Theory of Secure Information Systems Features: Safeguards and Controls Richard Baskerville T 1 F 1 O 1 T 2 F 2 O 2 T 3 F 3 O 3 T 4... T n...... F l O m T F O Security
HITRUST Common Security Framework
HITRUST Common Security Framework 2014 Version 6.1 Page 1 of 470 Summary of Changes Version Description of Change Author Date Published 1.0 Final Version of Initial Release HITRUST September 11, 2009 2.0
PCI DSS Policies Outline. PCI DSS Policies. All Rights Reserved. ecfirst. 2010. Page 1 of 7 www.ecfirst.com
Policy/Procedure Description PCI DSS Policies Install and Maintain a Firewall Configuration to Protect Cardholder Data Establish Firewall and Router Configuration Standards Build a Firewall Configuration
Information Security Policy and Handbook Overview. ITSS Information Security June 2015
Information Security Policy and Handbook Overview ITSS Information Security June 2015 Information Security Policy Control Hierarchy System and Campus Information Security Policies UNT System Information
Health Insurance Portability and Accountability Act Enterprise Compliance Auditing & Reporting ECAR for HIPAA Technical Product Overview Whitepaper
Regulatory Compliance Solutions for Microsoft Windows IT Security Controls Supporting DHS HIPAA Final Security Rules Health Insurance Portability and Accountability Act Enterprise Compliance Auditing &
Montclair State University. HIPAA Security Policy
Montclair State University HIPAA Security Policy Effective: June 25, 2015 HIPAA Security Policy and Procedures Montclair State University is a hybrid entity and has designated Healthcare Components that
Information Technology Engineers Examination. Information Security Specialist Examination. (Level 4) Syllabus
Information Technology Engineers Examination Information Security Specialist Examination (Level 4) Syllabus Details of Knowledge and Skills Required for the Information Technology Engineers Examination
HITRUST Common Security Framework Summary of Changes
HITRUST Common Security Framework DRAFT Privacy s Incorporates privacy changes in NIST SP 800-53 r4. Oct-13 Fundamental to HITRUST s mission is the availability of a Common Security Framework () that provides
SUPPLIER SECURITY STANDARD
SUPPLIER SECURITY STANDARD OWNER: LEVEL 3 COMMUNICATIONS AUTHOR: LEVEL 3 GLOBAL SECURITY AUTHORIZER: DALE DREW, CSO CURRENT RELEASE: 12/09/2014 Purpose: The purpose of this Level 3 Supplier Security Standard
Administrative Improvements. Administrative Improvements. Scoping Guidance. Clarifications for Segmentation
The PCI DSS Lifecycle 1 The PCI DSS follows a three-year lifecycle PCI DSS 3.0 will be released in November 2013 Optional (but recommended) in 2014; Required in 2015 PCI SSC Community Meeting Update: PCI
Health Insurance Portability and Accountability Act (HIPAA) and Health Information Technology for Economic and Clinical Health Act (HITECH)
Health Insurance Portability and Accountability Act (HIPAA) and Health Information Technology for Economic and Clinical Health Act (HITECH) Table of Contents Introduction... 1 1. Administrative Safeguards...
INFORMATION SYSTEMS. Revised: August 2013
Revised: August 2013 INFORMATION SYSTEMS In November 2011, The University of North Carolina Information Technology Security Council [ITSC] recommended the adoption of ISO/IEC 27002 Information technology
HITRUST CSF Assurance Program You Need a HITRUST CSF Assessment Now What?
HITRUST CSF Assurance Program You Need a HITRUST CSF Assessment Now What? Introduction This material is designed to answer some of the commonly asked questions by business associates and other organizations
Kenna Platform Security. A technical overview of the comprehensive security measures Kenna uses to protect your data
Kenna Platform Security A technical overview of the comprehensive security measures Kenna uses to protect your data V2.0, JULY 2015 Multiple Layers of Protection Overview Password Salted-Hash Thank you
NETWORK AND CERTIFICATE SYSTEM SECURITY REQUIREMENTS
NETWORK AND CERTIFICATE SYSTEM SECURITY REQUIREMENTS Scope and Applicability: These Network and Certificate System Security Requirements (Requirements) apply to all publicly trusted Certification Authorities
INCIDENT RESPONSE CHECKLIST
INCIDENT RESPONSE CHECKLIST The purpose of this checklist is to provide clients of Kivu Consulting, Inc. with guidance in the initial stages of an actual or possible data breach. Clients are encouraged
Security & IT Governance: Strategies to Building a Sustainable Model for Your Organization
Security & IT Governance: Strategies to Building a Sustainable Model for Your Organization Outside View of Increased Regulatory Requirements Regulatory compliance is often seen as sand in the gears requirements
External Supplier Control Requirements
External Supplier Control s Cyber Security For Suppliers Categorised as Low Cyber Risk 1. Asset Protection and System Configuration Barclays Data and the assets or systems storing or processing it must
Function Category Subcategory Subcategory Informative References
Function Category Subcategory Subcategory Informative References ID.AM-1: Physical devices and systems within the organization are inventoried ID.AM-1.1 Ensure that physical devices and systems within
PCI-DSS: A Step-by-Step Payment Card Security Approach. Amy Mushahwar & Mason Weisz
PCI-DSS: A Step-by-Step Payment Card Security Approach Amy Mushahwar & Mason Weisz The PCI-DSS in a Nutshell It mandates security processes for handling, processing, storing and transmitting payment card
