How do PCI DSS Requirements 2 and 8 apply to SAQ A merchants?

PCI SSC has clarified new requirements 2.x and 8.x included in the SAQ A v3.2. According to the FAQ 1439 these new requirements apply to all redirection servers in Ecommerce and MOTO payment channels.

“E-commerce merchants that redirect customers from their website to a third party for payment processing will need to validate these requirements for the webserver upon which the redirection mechanism is located.”

This may cause some issues, especially if User Management processes for web servers have been outsourced to a Third Party Service Provider.


PCI SSC: Bulletin on Migrating from SSL and Early TLS

Download the Bulletin. Key points and deadlines:

  • All processing and third party entities ? including Acquirers, Processors, Gateways and Service Providers must provide a TLS 1.1 or greater service offering by June 2016
  • Consistent with the existing language in the DSS v3.1, all new implementations must be enabled with TLS 1.1 or greater
  • All processing and third party entities must cutover to a secure version of TLS (as defined by NIST) effective June 2018
  • The use of SSL/TLS 1.0 within a POI terminal that can be verified as not being susceptible to all known exploits for SSL and early TLS, with no demonstrative risk can be used beyond June 2018 consistent with the existing language in the DSS v3.1 for such an exception

ISACA releases – A Practical Guide to the Payment Card Industry Data Security Standard (PCI DSS)

Download: ISACA Member $35 | Non-Member $60

The guide provides a comprehensive overview of the PCI DSS and explains how to implement its demanding security requirements. The guide also contains a wealth of background information about payment cards and the nature of payment card fraud. The content in this guide goes beyond other sources of information about the PCI DSS by providing the following valued information::

Concise summaries of PCI DSS requirements (published in the Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures, Version 3.1)
Consolidated information from numerous PCI DSS publications
Background advice on challenging requirements
Techniques that are required to scope and implement the requirements
PCI DSS requirements mapped to COBIT 5 processes and International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 27001/2 controls
Detailed explanation of how to design a professional audit/assurance plan
The guide has been written in plain language to enable non-technical directors, managers and staff in retail enterprises, financial organizations and IT service functions to easily find, understand and use the information.


QSA Experience

PCI SSC has announced changes to the QSA Qualification Requirements lately. The supplementary document dated June 2015 reads:
“The requirement to possess at least one industry-recognized certification is effective as of January 1, 2016 for new QSA Employees. For QSA Employees qualified and added to the search tool prior to January 1, 2016, this requirement is effective July 1, 2016 (for example, upon annual requalification after June 30, 2016).”

What industry-recognized certification are acceptable?

There are two lists published by the SSC: A and B (see below).

Currently, you can pick one certification from either List A OR List B. Although, the SSC recommends to have one from each list, which at some point may turn into the requirement.

Personally, I think the SSC tries to raise the bar, who conducts PCI DSS assessments and performs QA. It may be also an effective technique to filter out non-technical individuals, which in result may improve the quality of Report on Compliance and recommendations provided to merchants and service providers. Where, previously the SSC relied on quite ambiguous “5 years IT Security experience”; it has effectively outsourced the background check processes to ISC2, ISACA and other certification bodies, which already perform thorough background checks on all candidates.

Note. In order to obtain CISSP, CISM or CISA, you need to present a minimum of five years of direct full-time security work experience, which is vetted upon completion of the exam.

List A – Information Security

  • Certified Information System Security Professional (CISSP)
  • Certified Information Security Manager (CISM)

List B – Audit

  • Certified Information Systems Auditor (CISA)
  • GIAC Systems and Network Auditor (GSNA)
  • Certified ISO 27001, Lead Auditor, Internal Auditor
  • International Register of Certificated Auditors (IRCA)
  • Information Security Management System (ISMS) Auditor
  • Certified Internal Auditor (CIA)

Overview: SABSA vs TOGAF vs CobIT vs ITIL

Have you ever wondered the difference between the above frameworks? I’ve put together a quick cheat sheet explaining the basics of:

SABSA – Sherwood Applied Business Security Architecture

TOGAF – The Open Group Architecture Framework

COBIT – Control Objectives for Information and Related Technology

ITIL – Information Technology Infrastructure Library

Download PDF from: HERE


*Source: https://www.vanharen.net/blog/


CISSP & SSCP Updates Announced

ISC2 announced updates to its CISSP and SSCP certifications. There are no information about CISSP Concentrations: ISSAP, ISSEP, ISSMP updates. An official email stated:

“What does this mean for (ISC)2 members?  Beginning April 15, 2015, all CISSPs and SSCPs will be required to submit their continuing professional education (CPE) credits in accordance with the refreshed eight domains of the CISSP and seven domains of the SSCP.  This process ensures that the examinations and continuing professional education requirements encompass the topic areas relevant to the roles and responsibilities of today?s information security professionals.

Refreshed technical content has been added to the official (ISC)? CISSP Common Book of Knowledge (CBK) to reflect the most current topics in the information security industry today. The content of the SSCP has also been refreshed to reflect the most pertinent issues that security practitioners currently face, along with the best practices for mitigating those issues.  For both the CISSP and the SSCP, some topics have been expanded, while others have been realigned under different domains. Both credentials reflect knowledge of information security best practices, but from different facets. “

CISSP Domains, Effective April 15, 2015

  • NEW Security and Risk Management (Security, Risk, Compliance, Law, Regulations, Business Continuity)
  • NEW Asset Security (Protecting Security of Assets)
  • NEW Security Engineering (Engineering and Management of Security)
  • NEW Communications and Network Security (Designing and Protecting Network Security)
  • NEW Identity and Access Management (Controlling Access and Managing Identity)
  • NEW Security Assessment and Testing (Designing, Performing, and Analyzing Security Testing)
  • NEW Security Operations (Foundational Concepts, Investigations, Incident Management, Disaster Recovery)
  • NEW Software Development Security (Understanding, Applying, and Enforcing Software Security)

SSCP Domains, Effective April 15, 2015

  • Access Controls
  • Security Operations and Administration
  • Risk Identification, Monitoring, and Analysis
  • Incident Response and Recovery
  • Cryptography
  • Networks and Communications Security
  • Systems and Application Security

(ISC)2 2014 CISSP JTA Survey – 5 FREE CPEs

Calling all CISSP in good standing. Take the survey and claim 5 CPEs.

A Job Task Analysis (JTA) workshop for the CISSP was recently completed.  The workshop participants produced an updated draft content outline upon which the new CISSP examination will be based.  It is now up to all (ISC)2 members who hold the CISSP credential to take the next step in the process.  We are therefore asking that all CISSPs complete a JTA Survey based on this new content outline.  Respondents will have an opportunity to rate the importance of and comment on the tasks defined within it, to suggest new tasks, and to make any other comments related to the CISSP credential program in general.  This information, along with some demographic data that is collected, will be used to finalize a new content outline and exam blueprint that will be used for the next three (3) years.  The survey should take approximately 30 minutes to complete.



Part 1: Audit Trails in PCI DSS v3.0 – Logging in Windows

What should I be logging in Windows to pass PCI DSS assessment v3.0? – this and similar questions come up rather often when it comes to fulfilling Section 10 of PCI DSS v3.0.

In Part 1, we are looking at Microsoft Windows  and in Part 2 we will investigate CentOS. Note. This article is describing local logs configuration settings. If you are interested in the centralized logging and PCI DSS, please read the following article: Free Log Management and PCI DSS 3.0. 

Microsoft Windows comes with very detail and comprehensive logging mechanism. Get it right and you will end up with very useful information, not only helping you to secure the environment but also to achieve high availability and spot things before the real disaster happens. In opposite, enable every possible auditing option and you will end up with thousands records per second, which may hinder the real attack.

The key is to optimize the settings and tweak the system, so it’s compliant with PCI DSS but also provides useful information to the staff involved in monitoring of such logs.

Lets have a look at what events must be logged to satisfy PCI DSS v3.0:

10.2 Implement automated audit trails for all system components to reconstruct the following events:
10.2.1 All individual user accesses to cardholder data
10.2.2 All actions taken by any individual with root or administrative privileges
10.2.3 Access to all audit trails
10.2.4 Invalid logical access attempts
10.2 5 Use of and changes to identification and authentication mechanisms?including but not limited to creation of new accounts and elevation of privileges?and all changes, additions, or deletions to accounts with root or administrative privileges
10.2.6 Initialization, stopping, or pausing of the audit logs
10.2.7 Creation and deletion of system-level objects

The screenshot below presents what Audit Policy Settings must be configured in the Group Policy Object to achieve the above PCI DSS requirements. In the example below it is configured on the Local GPO,  but the same settings apply to the Domain Level GPOs.

Note. Windows offers much more granular auditing configuration settings, which can be found in Computer Configuration -> Windows Settings – > Security Settings -> Advanced Audit Policy Configuration. The advanced settings are beyond the scope of PCI DSS v3.0. As always, PCI DSS is a bare minimum, if you wish to log more, please investigate the advanced logging further.

2014-04-03 15_20_18-Console1 - [Console Root_Local Computer Policy_Computer Configuration_Windows Se







The second part is to enable the above settings on the right directories. The screenshot below presents how to enable the Audit Policy (Object Access) on chosen directories:

2014-04-03 15_41_28-Program Manager






The level of logging for each directory /file (screenshots below) will vary, depending on what directory/user the settings are applied to. For example:

For 10.2.2 all actions on all directories / files must be logged for Administrators. In such case all boxes would be ticked:

2014-04-04 15_17_02-Auditing Entry for GLOBAL

For 10.2.7 only creation and deletion of system-level objects would be ticked:

2014-04-04 15_17_41-Auditing Entry for GLOBAL


At minimum the following Windows directories should have the  ‘Auditing’ settings enabled:

– [PCI DSS 10.2.1] Any directories/files, which store cardholder data – for Everyone

– [PCI DSS 10.2.2] All directories/files – for Domain Administrators, Enterprise Administrators, Local Administrators

– [PCI DSS 10.2.3 and 10.2.6] All directories/files, which store Windows event files (Default – %SystemRoot%\System32\Winevt\Logs\) – for Everyone

– [PCI DSS 10.2.7] All system directories (example: %SystemRoot%\System32\) – for Everyone. Note. System-level object: Anything on a system component that is required for its operation, including but not limited to database tables, stored procedures, application executables and configuration files, system configuration files, static and shared libraries and DLLs, system executables, device drivers and device configuration files,and third-party components.


Lastly, PCI DSS lists what entry should be logged for each event:

10.3.1 User identification
10.3.2 Type of event
10.3.3 Date and time
10.3.4 Success or failure indication
10.3.5 Origination of event
10.3.6 Identity or name of affected data, system component, or resource.

The screenshot below presents an example of event with highlighted fields after the Audit Policy Settings have been enabled. As you can see, there is no need to configure any additional settings in order to fulfill PCI DSS Req. 10.3.x.

2014-04-03 16_12_35-Event Properties - Event 4663, Microsoft Windows security auditing.



Part 2: Audit Trails in PCI DSS v3.0 – Logging in Linux -> Coming soon.