Shearwater’s PCI DSS Compliance insights help you keep up with the Payment Card Industry Data Security Standard’s changes and updates.

PCI DSS Update: Version 3.2.1

SAQ-A 6.2 – This one inclusion has changed the way we need to look at web servers.

PCI DSS version 3.2.1 was introduced earlier this year. Until the end of the year you can still assess against the previous version, but time is soon running out. 

One of the changes introduced isn’t in the standard itself but in the Self Assessment Questionnaire (SAQ), specifically SAQ-A, which is used by many people who only use PCI Compliant third parties for their ecommerce sites and use one of the following three methods to reduce their scope.

  • Method 1 – Outsource everything, website, payments etc.
  • Method 2 – URL redirect. When the customer has to pay, they are redirected to a third party payment platform and the payment is processed there.
  • Method 3 – iframe. The website provides a link to an iframe which embeds the payment page from the provider in the page of the merchant website. When submitted the card information goes directly from the client’s browser to the payment provider.

Using any of these three methods meant that the company had very few requirements to meet, and originally none on the web server that was doing the redirecting or providing the iframe link. Using any of these three methods meant that the web server hosting the links was considered out of scope. 

The Payment Brands (Visa, Mastercard, AMEX Discovery and JBC brands still expected you to take reasonable measures to secure it but, from a PCI DSS perspective, the server was considered out of scope and therefore did not need to be managed in a PCI DSS compliant manner. From a security perspective this was, to be honest, a weird position because we all know that if you control the server that provides the links, you control the payment flow and bad things can happen. However, remember, PCI DSS is not really there for you and me, it exists to reduce the risk to the card brands. Some worked under the assumption that if you were no longer receiving funds, you’d probably figure out, fairly quickly, that there was an issue, therefore, there was no real need to protect the web server.

That was a long introduction to say this: It is no longer the case. The Web server is now in scope for PCI DSS for at least one requirement.

In SAQ-A, an additional requirement has appeared, Requirement 6.2, that applies to the web server you are using to redirect to the payment page.


PCI DSS Question Expected Testing
6.2 (a) Are all system components and software protected from known vulnerabilities by installing applicable vendor-supplied security patches?
  • Review policies and procedures
(b) Are critical security patches installed within one month of release?
  • Review policies and procedures
  • Examine system components
  • Compare list of security patches installed to recent vendor patch lists


If you are using method 1, everything is hosted elsewhere and you have no responsibilities for managing it, then you can answer ‘Not Applicable’.

If you are using method 2 or 3, then you will have to get a patching process in place and patch the server in a reasonable amount of time. And if you do not answer ‘yes’ you will not be compliant.

This change of view also has some implications for the other requirements in SAQ-A. The other requirements that are applicable for this SAQ now also should be evaluated on the web server used to provide the redirects.

If you are unsure whether an SAQ-A could apply to you, have a look at the guidance published in the PCI Security Standards Council’s document Best practice for Securing E-Commerce.

If you need help or have any questions, ask your QSA, or ask ours using the contact form.

IRAP Frequently Asked Questions

RECENT UPDATES (March 2020):

The Australian Signals Directorate (ASD) and the Digital Transformation Agency (DTA) announced changes affecting cloud service providers. Those wishing to provide cloud services to Australian Government departments and agencies are no longer required to pass the Cloud Services Certification Program (CSCP) assessment. Furthermore, they will no longer be listed on the Certified Cloud Services List (CCSL).

These changes mean that cloud providers will be treated in the same way as other ICT providers. It is still recommended to undergo an IRAP assessment, as once you achieve certification with one Government department or agency, it can be leveraged to open the way for you to work with other departments and agencies.

For ICT or cloud providers considering undergoing IRAP assessment, the Government has announced extra resources to boost the number of IRAP assessors. This should facilitate a more efficient IRAP assessment process.

Contact us for further information on the IRAP assessment process and how Shearwater can guide you through the process.


What is IRAP?

The Information Security Registered Assessors Program (IRAP) is an initiative of the Australian Signals Directorate (ASD) through the Australian Cyber Security Centre (ACSC) to ensure the standard of cybersecurity and information security assessments for Information and Communications Technology (ICT) systems that process or store government information. A certified IRAP Assessor’s role is to conduct independent assessments of any system, network or gateway, for compliance with the Australian Government Information Security Manual (ISM), the Protective Security Policy Framework (PSPF) and other Australian Government guidance, to ensure the safety of government information. An assessment is the first stage in the process towards achieving Australian Government security accreditation for suitability to process, store or communicate government or sensitive information.


Why conduct an IRAP Assessment?

Cybersecurity and information security are a top national security priority for government, to prevent cyberintrusions on government systems, critical infrastructure and other information networks that could threaten Australia’s national security and national interests.

An Information Security Registered Assessors Program (IRAP) assessment is the first stage in the process towards achieving accreditation for suitability to process, store or communicate government or sensitive information. Government agencies and commercial Information and Communications Technology (ICT) systems, Cloud providers, Networks and Gateways that process or store government information (or wish to do so) are required to achieve and maintain Australian Government security accreditation by demonstrating compliance with the Australian Government Information Security Manual (ISM) and the Protective Security Policy Framework (PSPF) and other Australian Government guidance.


Who is responsible for IRAP?

The Information Security Registered Assessors Program (IRAP) is an initiative of the Australian Signals Directorate (ASD) through the Australian Cyber Security Centre (ACSC).


Who are IRAP Assessors?

Information Security Registered Assessors Program (IRAP) Assessors are Australian Signals Directorate (ASD)-certified Information and Communications Technology (ICT) professionals from across Australia who have:

  • the necessary experience and qualifications in ICT, security assessment and risk management, and
  • a detailed knowledge of Australian Government information security compliance requirements.*

Becoming a certified IRAP assessor requires extensive, prerequisite qualifications and experience and the completion of IRAP training and examinations. Thereafter, IRAP assessors are required to maintain these prerequisite qualifications and complete annual training.

Shearwater has several Security Consultants who are certified IRAP Assessors.

* ACSC, Who are IRAP Assessors?, accessed 9 October 2018, <>.


What can an IRAP Assessor assess?

Assessments of up to SECRET classified systems can be undertaken by agency Information Technology Security Managers (ITSMs) and Information Security Registered Assessors Program (IRAP) Assessors. Assessments of TOP SECRET systems can only be undertaken by the Australian Signals Directorate (ASD) and IRAP Assessors with appropriate clearance.

IRAP Assessors may provide assessment for:

  • Cloud services
  • Gateways
  • Information systems
  • Gatekeeper
  • FedLink


What is the Australian Government security accreditation process?

The accreditation process is as follows:

  1. Assessment
    • Audit stage 1 –Assessor provides a Findings Report to the system owner
    • System owner implements controls
    • Audit stage 2 – When controls have been met, an Audit Report is sent to the Certification Authority
  2. Certification Authority Assessment of Audit Report and residual risk. If successful;
  3. Certification awarded. Certification Report is then sent to the Accreditation Authority.
  4. Assessment of Certification Report, residual risk and other factors. If successful;
  5. Accreditation awarded.*

In most cases, reaccreditation is generally required every 2-3 years. For Australian Signals Directorate (ASD) Certified Cloud Services, ASD recertification is required every 2 years for UNCLASSIFIED DLM services and every 1 year for PROTECTED services.

* Abbreviation of process described by ACSC, Accreditation, accessed 9 October 2018, <>.


What is the IRAP Assessment process?

An Information Security Registered Assessors Program (IRAP) assessment has two stages:

  • Audit Stage 1 – Security deficiencies are identified and a Findings Report is provided to the System Owner.
  • Audit Stage 2 – Remediated security deficiencies are audited and an Audit Report is sent to the Certification Authority.

During Audit Stage 1, the IRAP Assessor:

  • defines the statement of applicability in consultation with the system owner
  • gains an understanding of the system
  • reviews the system architecture and the suite of system security documentation, including:
  • seeks evidence of compliance with Australian Government Information and Communications Technology (ICT) requirements and recommendations, and
  • highlights effectiveness of ICT controls and recommends actions to address or mitigate non-compliance.

The outcome of a Stage 1 Security Assessment is a Findings Report, given to the System Owner.

During Audit Stage 2, the IRAP Assessor looks deeper into the system’s operation, focusing on seeking evidence of compliance with, and the effectiveness of, security controls. The IRAP Assessor will conduct a site visit where they will:

  • conduct interviews with key personnel
  • investigate the implementation and effectiveness of security controls in reference to the security documentation suite, and
  • sight all physical security and information system certifications and any related waivers.

The outcome of a Stage 2 Security Assessment is an Audit Report, given to the Certification Authority that:

  • describes areas of compliance and non-compliance
  • suggests remediation actions, and
  • makes a certification recommendation.

The Certification Authority uses the report to:

  • assess the residual risk relating to the operation of the system
  • assess any remediation activities the system owner has undertaken, and
  • make a decision on whether to grant certification.

* ACSC, What is an IRAP Assessment?, accessed 9 October 2018, <>.


Who is the Certifying Authority and what is their role?

The certification authority for government systems is generally the owning agency’s Information Technology Security Advisor (ITSA). The Australian Signals Directorate (ASD) is the certification authority for all TOP SECRET systems and for gateways and cloud services hosting multiple government agencies. The certifying authority is responsible for reviewing the Audit Report provided by the Information Security Registered Assessors Program (IRAP) Assessor. Certification will be awarded if the Certification Authority is satisfied that:

  • The system has been appropriately audited, and
  • Associated security controls have been implemented and are operating effectively.

The Certification Authority will then make a recommendation to the Accreditation Authority based on any identified non-compliance and mitigation strategies.*

* ACSC, Accreditation, accessed 9 October 2018, <>.


Who is the Accreditation Authority and what is their role?

The Accreditation Authority is typically the agency head or a senior executive who has an appropriate level of understanding of the risks they are accepting on behalf of the agency. The Accreditation Authority:

  • Accepts any residual risks that were identified during the audit and certification process, and
  • Awards accreditation.

Accreditation of a system ensures that either sufficient security issue remediation has been achieved or that deficiencies have been accepted by an appropriate authority.*

*ACSC, Accreditation, accessed 9 October 2018, <>.


What is the Protective Security Policy Framework (PSPF)

The Protective Security Policy Framework (PSPF) is the responsibility of the Attorney-General’s Department. Its purpose is to provide policy, guidance and best practice advice for security governance, personnel security, physical security and information security for government agencies or commercial Information and Communications Technology (ICT) systems, Cloud providers, Networks and Gateways that process or store government information.*

*Australian Government Attorney-General’s Department, The Protective Security Policy Framework, accessed 9 October 2018, <>


What is the Australian Government Information Security Manual (ISM)?

The Australian Government Information Security Manual (ISM) is the responsibility of the Australian Signals Directorate (ASD), through the Australian Cyber Security Centre (ACSC). It is the standard which governs the security of government Information and Communications Technology (ICT) systems. All government agencies and commercial ICT systems, Cloud providers, Networks and Gateways that process or store government information are required to comply with the ISM.


How often is reaccreditation required?

In most cases, reaccreditation is generally required every 2-3 years. For Australian Signals Directorate (ASD) Certified Cloud Services, ASD recertification is required every 2 years for UNCLASSIFIED DLM services and every 1 year for PROTECTED services.


How long does an IRAP Assessment take?

The length of time for an Information Security Registered Assessors Program (IRAP) Assessment can vary depending on the complexity of the system being assessed. Typically, this could range from 1-3 months.


What is an organisation expected to do during an IRAP Assessment?

Your organisation will be expected to participate in several activities throughout the Information Security Registered Assessors Program (IRAP) assessment, including:

  • Scheduling and participating in interviews with key stakeholders
  • Organising the IRAP assessors’ access to all system documentation
  • With the guidance of the IRAP Assessor, schedule meetings with system administrators, engineers, and/or security operations personnel to validate the implementation of security controls
  • Outline and demonstrate any additional security controls implemented.


Useful Links

Ten things you should know about ISO/IEC 27001

1.    What is ISO 27001?

ISO 27001 is an international standard for information security management.

2.    Why is ISO 27001 important to me?

Information is the lifeblood of most contemporary organisations’. It provides intelligence, commercial advantage and future plans that drive success. Most Organisation store these highly prized information assets  electronically. Therefore, protection of these assets from either deliberate or accidental loss, compromise or destruction is increasingly important. ISO 27001 is a risk-based compliance framework designed to help organisations effectively manage information security.

3.    Why are international standards like ISO 27001 important?

Many Industries and many Governments have adopted ISO 27001 as the de facto standard for information security management practices. ISO is particularly popular at the State Government level within Australia where it is often mandated, and in industries such as ICT and data centre hosting. International Standards provide significant benefits overall to the domestic and global economy.

For Consumers
Proof of conformity to International Standards helps reassure consumers that products, systems and organisations are safe, reliable and good for the environment.

For Business
International Standards can be a strategic tool to help businesses tackle challenges and compete on a global stage.
Adoption can: open up new markets, improve competitiveness through greater customer satisfaction, reduce costs, streamline systems and processes, and increase productivity.

For Society
Standards improve safety, quality and environmental outcomes as well as encouraging international trade.

4.    Why is ISO 27001 important?

Having an international standard for information security allows a common framework for managing security across business and across borders. With an ever more connected world, the security of information is increasing in importance.

Data and information needs to be safe, secure, and accessible. The security of information is important for personal privacy, confidentiality of financial and health information and the smooth functioning of systems and supply chains that we rely on in today’s interconnected world.

ISO 27001 provides the framework for you to effectively manage risk, select security controls and most importantly, a process to achieve, maintain and prove compliance with the standard.
Adoption of ISO 27001 provides real credibility that you understand security and take security seriously.

5.    What are the elements of ISO 27001?

ISO 27001 is made up of a number of short clauses, and a much longer annex listing 14 security domains and 114 controls. The most important of the short clauses relate to:

  • The organisational context and stakeholders
  • Information security leadership and high-level support
  • Planning of an Information Security Management System (ISMS), including risk assessment; risk treatment
  • Supporting an ISMS
  • Making an ISMS operational
  • Reviewing the system’s performance
  • Adopting an approach for corrective actions

Based on the risk profile of the organisation, controls may be selected to manage identified risks. Within the Annex, the 114 listed controls are broken down into 14 key domains which are listed below:

  • Information security policies
  • Organisation of information security
  • Human resource security
  • Asset management
  • Access control
  • Cryptography
  • Physical and environmental security
  • Operations security
  • Communications security
  • System acquisition, development and maintenance
  • Supplier relationships
  • Information security incident management
  • Information security aspects of business continuity management
  • Compliance

6.    How does it work? – What is a Risk-Based Approach to Compliance?

Unlike other security standards, for example, the Payment Card Industry – Data Security Standard (PCI-DSS) and Sarbanes-Oxley (SOX), which are highly prescriptive and control driven, ISO takes a risk-based approach to security compliance. In other words, there are no defined set of security controls that must be implemented regardless of the type of business operation, as is the case with PCI-DSS. Controls are selected based on their ability to mitigate risks to the organisation

ISO 27001 is concerned with the process of continual improvement and a demonstrated commitment to managing information security based on risks to the organisation’s information assets.
A risk-based approach to managing information security ensures that security risks are appropriately prioritised, cost effectively managed as well as ensuring that only those controls that are necessary to manage these risks are implemented. It is a comply or explain approach. Based on your organisations’ risk, you can comply with the controls that help manage risk, or simply explain why they aren’t relevant and why you don’t need them. There is no compliance for the sake of compliance with ISO.

7.    Where should I start?

Before starting out on the path to certification, it may be worthwhile understanding if certification is required, or if compliance will suffice. For many organisations, certification is not a requirement.

For those industries where certification is a requirement, the path to achieving certification should not be treated as a one-off project. Firms that successfully maintain certification over multiple years, treat information security as a critical business process and invest time, resources and effort into ongoing compliance. Certification is the logical consequence of compliance, and should be relatively easy if a solid compliance regime is established and maintained.

For most organisations, the logical place to start is to conduct a gap analysis against the requirements of ISO 27001.

8.    The Audit Process

External certification can only be conducted by an Accredited Certification Body (CB). In Australia, Shearwater recommends certification services from reputable CB’s only, such as BSI and SAI Global.

The initial audit process is undertaken in two stages:

  • Stage 1 – A Documentation Review that focuses on a desktop review of available ISMS documentation and processes. Sufficient evidence of a functioning ISMS is required in order to progress to the Stage 2 audit.
  • Stage 2 – Focuses on evaluating the implementation and effectiveness of the management system. The audit will assess evidence and will typically require the ISMS to have been running for a period of at least three months.

The certification cycle also requires regular external surveillance audits to be performed and evidence that the management system is being actively maintained. Surveillance audits for ISO 27001 are typically performed every six months, however, mature systems in low-risk industries can be extended to an annual audit cycle in consultation with the certification body. ISMS re-certification occurs every 3 years.

9.    Who wrote ISO 27001? – History

ISO (International Organization for Standardization) is the world’s largest developer of voluntary International Standards. Many Countries have their own national standards governing everything from railway gauges, electrical power point specifications, building materials, personal protective equipment and children’s toys, to name just a few. When a standard reaches maturity and has widespread application in more than one jurisdiction, ISO forms a working group and works towards publishing an International Standard.
The original forerunner of ISO 27001 was written by the UK Government’s Department of Trade and Industry (DTI), and then published by the British Standards Institute (BSI) as BS 7799 in 1995.

10.    Tips, trick and pitfall avoidance

Before Certification
Don’t underestimate the number of stakeholders you will need to consult. In large organisations, stakeholder management can be a large undertaking and key requirement for a successful compliance activity.

Partner with experienced information security providers who know the implication of advice, in particular with respect to the selection of information security controls. Many controls sound like a good idea, but the implementation can be much more challenging.
Start with an understanding of risks and development of a management system before jumping into controls and technology. Investing time up front to understand your risk posture will pay long-term benefits.

During Certification

Avoid anybody who guarantees certification within 1 month. They can’t! Certification Bodies generally like to see at least 3 months of evidence at the stage 2 Audit to make a recommendation for certification to the Accreditation Body. For smaller scopes, this timeframe may be less, but it is best to plan on at least 3 months.

Certification Bodies are prevented under another ISO standard (19011) and scheme rules from performing certification and consulting/advisory services due to conflict of interest issues. Some get around this by offering extended pre-assessments of gap analysis. Whilst these may appear cheap, there are limits to the amount of actionable recommendations that can be provided.

After Certification
You will be entitled to display an ISO 27001 certification mark. The certification mark is tangible proof that you take care of information, are committed to protecting data entrusted to you, and are fulfilling your commercial, contractual and legal responsibilities with respect to information security. A great idea would be to promote this certification on your marketing collateral and website as a source of differentiation from your competitors.

Need assistance with ISO 27001? Get advice from one of our experienced consultants! We’ll arrange a scoping call, and offer you tips and suggestions for a clear roadmap to achieving and maintaining compliance. Talk to us today!

ASD Essential 8 Summary

So you have mastered the ASD Top 4? What do you need to tame the Essential 8? 

In this ASD Essential 8 Summary, we will answer:

  • What has stayed the same?
  • What has changed?
  • What that means?
  • What do I need to do to achieve this baseline standard?
  • When do I need to complete it by?


What has stayed the same?

The key thing that has remained constant from the ASD Top 4 to the Essential 8, is the pragmatic, good advice provided by ASD. The focus is still on making systems and information secure, in order to safeguard organisational reputations and save time and money. However, unlike a great number of global compliance regimes such as SOX, JSOX, PCI, SSAE, etc, the Essential 8:

  • Helps organisations manage risks that are relevant to their specific context
  • Provides prioritised steps to address relevant threats
  • Represents a baseline for organisations to achieve

The risk-based approach and the prioritised controls are world class and equate to a cost effective and intelligent use of security budgets.

The evolution of the Top 4 to the Essential 8 quite firmly underlines the core message that good security is a process and not a project. Organisations that have conducted a ‘Top 4 project’ and not implemented an ongoing security process, may in fact have missed the point. The Essential 8 is ASD’s reminder to keep improving.

What has changed?

There is one large change and a number of smaller changes. The large change shifts focus from the Top 4 being Strategies to Mitigate Targeted Cyber Intrusions, to being an essential 8 Strategies to Mitigate Cyber Security Incidents. Top 4 was designed to keep the malicious out. Essential 8 recognises that whilst a lot can be done to keep people out, the reality is that you need to plan and design for when eventually they do get in.

The smaller changes add 4 more controls and shift the initial Top 4 around. You now have two columns:

Prevent Malware from running
Keep ‘em Out
Limit the extent of incidents and recover data
Plan for when they get in and respond
Application Whitelisting (Top 4 original) Restrict administrative privileges (Top 4 original)
Patch Application (Top 4 original) Patch Operating Systems (Top 4 original)
Disable untrusted Microsoft Office macros (New) Multi-factor authentication (New)
User application hardening (New) Daily backup of important data (New)

What this means?

The ASD has reinforced that good security is a journey that never ends. In other words, you should expect the Essential 8 to continually change over time. ASD’s subliminal challenge is to think about what will provide you with the best returns for your effort and investment across both prevention and response. ASD wants organisations and security leaders to answer 4 searching questions:

  1. Do I know what my mission critical assets are and what needs protecting?
  2. Who are my adversaries, or who do I need to guard against?
  3. What is the gap between my current security controls and those outlined in the Essential 8? In other words, what other strategies do I need to implement based on my risks?

If your security posture is risk based, pragmatic and process rather than project driven, adding a few more tasks or re-ordering a few initiatives within your work programme should be straight forward.

When do I need to have done it?

With respect, you are asking the wrong question! The goal of establishing a layered defence to protect against and respond to threats does not have an end date. But if you want to know where to start, Shearwater are the experts who can help you avoid wastage of time, effort and money. Engaging our expert team of advisors will allow you to plan at the strategic level whilst executing at the tactical.

If you don’t know where or how to start with the Essential 8, Shearwater can assist. For expert help, please contact us.

PCI DSS v3.2 Changes

As you may be aware the security issues relating to SSL and early TLS prompted the Payment Card Industry Security Standards Council (PCI SSC) to issue a new version of the Payment Card Industry Data Security Standard (PCI DSS) and supporting documents.  This release v3.1 (April 2015) included a deadline for moving away from SSL and early TLS by June 30, 2016.  

After the release of version 3.1 of the standard, the industry as a whole provided feedback to the council regarding the deadline of this particular requirement and late 2015 the deadline for removal of these protocols was extended to June 2018.  The council has now formalised this in a new version of the standard. There are however a number of other changes that have been introduced in this new version that you should be aware of and that will affect your compliance requirements, especially for service providers.  
The new release of the standard is effective immediately, version 3.1 will be retired October 31, 2016. This means that your next assessment will likely be against the new version of the standard.

The new version of the standard has a number of new requirements.  These are considered best practice until 1 February 2018, which means that you are encouraged to implement them as soon as possible, but they must be in place by the deadline.  For those of you still using SSL or early TLS, there are a number of new requirements outlined in appendix 2 of the standard that must be in place, effective by June 30, 2016. Most of you will already have these, with the possible exception the requirement to have “All service providers must provide a secure service offering by June 30, 2016”.  This particular requirement recognises that many service providers have customers that may not be able to change their systems to remove the weak protocols by June 30, but ensures that service providers have the capability to accept the stronger protocols. This should only affect you if you have systems that cannot communicate using TLS v1.1 or preferably TLS v1.2.

The highlights of the changes are as follows:

  • 3.5.1 – Maintain a documented description of the cryptographic architecture.
    This applies to service providers only and is something Shearwater has been encouraging clients to do for a while now.  The requirement outlines what information is required.
  • 6.4.6 – Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable.
    Whilst this was always implied in the standard this version calls it out as a specific activity and is designed to ensure PCI DSS compliance is part of BAU rather than an annual activity. For the majority of you this will be an additional step in the change control process, however it will now be an auditable event. The guidance for the requirement provides information on what is expected for this control.
  • 10.8 – Implement a process for the timely detection and reporting of failures of critical security control systems
    This relates to reporting of failures within the organisation. There must be processes place to detect failures with security controls and processes to address them. Similar to an incident response plan.  
  • – Additional requirement for service providers only: If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods.
    This testing can be done by qualified internal resources or a qualified third party.
  • 12.4 – Additional requirement for service providers only: Executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program.
    Most will already have this, but the standard is now enforcing it.  PCI compliance must now be assigned to a specific role.  
  • 12.11 – Additional requirement for service providers only: Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures.  
    This requirement again goes towards ensuring PCI DSS compliance is an ongoing process rather than a once per year activity.  Many of you will have this already.  It basically requires you to have processes in place that once per quarter validates that daily tasks etc. are being performed.  

Two new appendices are in place. Appendix 2 as mentioned previously outlines the SSL and weak TLS requirements.  The final appendix addresses requirements for those that are explicitly told they must do this. This is based on volume and other criteria.  
A few requirements have been removed as the item was generally already covered by another requirement.  

The only other requirement that could have a significant impact is the changes to requirement 8.3.  this requirement currently requires two-factor (now changed to multi-factor) authentication when administering the Cardholder Data Environment (CDE) remotely.  This has now been changed that ALL administrative access must be multifactor authentication.  This could be any form of multifactor authentication, but potentially this will have an impact on how you manage the CDE and CDE components.  

Other changes in the standard are cosmetic. Clarifications for a number of requirements are provided, some dated examples are removed. The council’s “Summary of changes document from PCI DSS version 3.1 to 3.2” ( outlines all of the changes.  

It is recommended that you have a read of the summary of changes document.  As always should you have any further questions feel free to reach out to your Shearwater contact, or directly to myself.  We can certainly help you navigate the requirements.  

I Think I Need to Be PCI Compliant… Now What??

By Heather Robins

Sometimes, coming to grips with your company’s need to be compliant with the Payment Card Industry Data Security Standards (PCI DSS) feels a bit more like going through the Five Stages of Grief than tackling a standard issue business problem. I’ve been in the Information Security industry for a little over 5 years, and I’ve heard just about every justification and excuse about why (insert excuse here) means your business doesn’t need to comply with the standard… but if your organisation processes, stores or transmits credit card data (yes, any one of those things!), then yes, you DO need to comply with the PCI standards.

If you’ve arrived at this page, the good news is it’s likely that you’ve finally reached the ‘Acceptance’ phase of your journey. The bad news is that this is where the work begins!

The steps outlined below are just that – an outline. This may or may not apply precisely to your business, but it should start you on the right path. Your acquiring bank should be able to provide additional assistance and if you want additional assistance, reach out to a Qualified Security Assessor in your region (Shearwater can help in Australia).

Step #1:

Define your Cardholder Data Environment and Document Your Card Flows. In simple terms: how do you accept credit cards, what do you do with them and how.  

Step #2:

Look at that scope you just defined… is there any way to limit it? Can you eliminate a business process that currently requires you to store credit card numbers in Manny from Finance’s bottom drawer? Can you segment your environment at this point? A limited scope and limited number of card flows will save your sanity.

Step #3:

Understand if you’re a Merchant or Service Provider and What “Level” you’re at. This is a question of how your business interacts with cards and how many interactions it has with cards. PCI DSS doesn’t care if you take one credit card number and process it 6 million times or take 6 million cards and process them one time, if you’re over 6 Million transactions per year, you are a PCI DSS Level 1 Merchant.   The Level 1 barrier for Service Providers is at 300,000 transactions per year. Level 1 (for either Merchant or Service Provider) means you’ll need to engage a Qualified Security Assessor (QSA) organisation… the silver lining is you won’t have to fill in a Self Assessment Questionnaire because your QSA will do that for you, in the form of a Report on Compliance (RoC) and an Attestation of Compliance (AoC).

Step #4:

Find Your Self-Assessment Questionnaire (SAQ). If you are not a level 1 Merchant or Service provider you will need to complete an SAQ. While I’ll be looking to write a bit more extensively on picking your SAQ, the best first step is to look at the PCI Council’s Website. There are specific SAQ’s to fit specific business models (ecommerce only, virtual terminals only, etc.) The short story is SAQ D covers just about everything so, if you know you take cards through a lot of different channels or you don’t seem to fit in any particular bucket, this is your SAQ. Remember you have to meet all the requirements for the SAQ, if not your SAQ will be SAQ-D.

Step #5:

Identify your gaps. SAQ D has 288 individual requirements, so this can feel very daunting. The PCI Council’s Prioritized Approach can provide a good jumping off point if you’re looking to do all of this on your own. If you do decide as a company to take this project on internally, make sure you assign someone (or several someones!) who understand the business, are well connected and are well respected. You’ll need the project leader on this to feel confident engaging with technical and business staff and have the resourcefulness to know where to go to get answers.  

Step #6:

Put together your remediation roadmap. What were your major findings from the gap discovery/gap analysis phase? How do you plan to fix them? Almost every organisation will have policy and procedure work to do that can provide ‘quick wins’ on improving their posture versus PCI compliance at a relatively low price point. Big infrastructure undertakings will obviously take considerably more resources and planning. Where possible, try to understand what you have currently that can be leveraged more powerfully for compliance initiatives.

Step #7:

Fill in and submit your SAQ or RoC (depending on your level) and Attestation of Compliance. While everyone wants to be PCI Compliant, the simple fact of the matter is that almost every organisation does not start off that way! Don’t continually put off this step in the process because you’re waiting for your dream state of affairs to be willed into reality. If you’re not compliant, you’re not compliant. Submit your required documents and your plan – every acquiring bank I’ve ever worked with has been willing to work with their vendors who are proactive on PCI compliance. It’s better to take control before your bank comes to you about PCI because something bad has happened!

You can do as little or as much of this ‘on your own’ as you care to (except for Level 1 Merchants and Service Providers, who do need to engage a QSA!). It will require a lot of internal manpower if you have a complex organisation, complex payment processes, poor documentation, poor segmentation or some combination of all the above. You can bring in a PCI Consultant at pretty much any stage in this process. In my experience, bringing in a QSA at the scoping/de-scoping stage and at the gap analysis stage is good bang for buck compared to doing it all yourself, but again, it will really depend on your business and your specific situation.

If you do have any comments, concerns or clarifications, or if you need assistance on your PCI journey, feel free to reach out to the Shearwater QSA team or to me directly ( We’d love to hear your thoughts and take on any feedback you might have.


PCI-DSS & PA-DSS Changes to REQ 4.1

1- Background

The Payment Card Industry Security Standards Council (PCI SSC) has issued a bulletin flagging a change in the Payment Card Industry Data Security Standard (PCI DSS) and the Payment Application Data Security Standard (PA DSS). This change will affect all those that are required to implement either standard.

As you may be aware over the past twelve months there have been a number of very serious vulnerabilities relating to Secure Sockets Layer (SSL), one of the key protocols used in e-commerce. The nature of the vulnerabilities has resulted in the decision that no version of SSL meets the requirement of “Strong cryptography” and as such can no longer be used.

The standards, PCI DSS and PA-DSS will be updated and reissued as version 3.1. The council has currently not provided a date as to when this will be. However they do state that once issued the standards will be effective immediately.

2- How does this affect you

The change in the standard means that web sites and other communications currently using SSL must be changed to utilise TLS instead of SSL. For many this will be a relatively innocuous change, however there may be customer impact and it is therefore recommended that efforts to remove SSL start sooner rather than later.

In addition to web servers there are other devices and applications within your environment that will be utilising SSL. If they are in scope these should also be addressed. For example firewalls, SSL VPN services, Citrix and so on. In short anything accessed using HTTPS:// will need to be checked and if using SSL, remediated.

At this moment there are no known compensating controls that can be implemented.

What if we don’t change?

If you continue to utilise SSL you will be non compliant with the standard. The quarterly ASV scans will flag that SSL is accepted and the ASV vendor will issue a FAILED report. This in turn will result in a non-compliance for PCI DSS.

Likewise in an on-site assessment or breach investigation

3- How can you remediate

You will need to reconfigure web servers to only accept TLS traffic and disable SSL.


1 – Check if server accepts SSL connections

This can be done utilising the online service from vendors such as Qualys. (please ensure you tick the “Do not show the results on the boards” option).

an alternate is to use the nmap tool to scan server utilising the following command:

nmap yourserveripornamehere -p 443 –script ssl-enum-ciphers

2 – Once identified remove the server’s ability to communicate using SSL

For windows servers this will mean registry changes.

For linux servers you will need to modify the relevant files for the web server being used. For example the mod_SSL configuration file.

For appliances such as firewalls, load balancers, switches, routers, remote access solutions, you will need to approach the vendor and request the relevant update.

5- How can we help

If required there are several ways in which we can assist. These include:

  • Identifying servers devices and applications that allow SSL connections 

  • Assisting with remediation 

Shearwater is dedicated to its customers’ security, and are always happy to provide advice. If any assistance is required please contact us.

What is Payment Card Industry Data Security Standard?

Today I’ll provide an overview of what is often the elephant in the room: What is Payment Card Industry Data Security Standard?

Unlike ISO 27001 where shades of grey are acceptable, in PCI DSS things are very much black and white, with some wiggle room  although limited and realistically only if you can convince the QSA (Qualified Security Assessor) that what you are doing is ok.  It boils down to you either be compliant or not. There is no “kind of”.


Each of the payment brands has a set of information security requirements that must be met by its merchants. This meant that in order to process VISA transactions you needed to comply with Visa’s Cardholder Information Security Program (CISP).  When dealing with MasterCard you needed to comply with MasterCard’s Site Data Protection (SDP) and so on for American express, Discover and JCB issued cards. In order to simplify the requirements on merchants and to align the different programs the founding members developed PCI DSS and the PCI Security Standards Council was created to manage the various different standards.

Founding members and their various compliance requirements:

The main standard most people will need to comply with is PCI DSS. The other standards have a specific scope.

  • PA-DSS applies to those that are selling an application that accepts, processes, stores or transmits credit card information.
  • PCI PTS applies to the actual pin pad devices many of us are familiar with and
  • PCI P2PE (Point-to-Point Encryption) which deals with encryption in point to point solutions.

PCI DSS applies to any organisation that  accepts, process, store or transmit credit card information (or more correctly payment branded cards). It unfortunately does not matter how small or large you are, you have to meet all the requirements of PCI DSS, although there are some small differences in the standard depending on whether you are a merchant or a service provider. If you accept credit cards, you have to comply.

Depending on the number of transaction you may be considered a level 1, 2, 3, or for some payment brands even a level 4 merchant or service provider.  In a nutshell if you are a level 1 merchant or service provider, you will need to have an on-site assessment annually and Quarterly Authorised Scanning Vendor (ASV) scans. Lower levels may only require you to validate using a self assessment questionnaire (SAQ) and have quarterly ASV scans. The main thing to remember though is that the number of transactions you do only determines the validation requirements, not the compliance requirements.  You will always have to comply withall requirements outlined in the standard, unless they are really not applicable to your situation.

Just to make it slightly more complicated the number of transactions that determines what level you are depends on each payment brand.  You can be a level 1 merchant for Visa, Level 2 for MasterCard and level 3 for Amex. The best place to find the specific levels is via one of the links above. To make it even more complicated your acquirer or the payment brand themselves may specify that you have to validate as a level 1 merchant or service provider. Some service providers will always have to validate as a level 1 regardless of the number of transactions processed, depending on the type of service being provided.   So life can get confusing

What happens if you don’t comply, well that depends on the acquiring bank that you deal with as a merchant or service provider. Ultimately the Acquirer caries the risk, they are the ones that get yelled at and have to provide evidence of their merchants’ compliance (i.e you) with the standard. When you are not compliant they may impose additional fees on your organisation until you are compliant, they may refuse services. I have see both happen in the past twelve months. Should there be a breach you may also be held liable for the costs associated with the breach.  Typically the acquirer or payment brand will bring in their own investigative team and perform an analysis as to how the breach occurred. If, at the time, of a breach you are not compliant with PCI DSS they may try and recover their costs. It is therefore important that once you are compliant you make sure you are able to maintain it.

A longish background I know, but it is important to get these things straight before you try and tackle the rest of the standard. 

Scope and scope reduction
Possibly the most difficult thing to do is scoping of the PCI environment and the one area where the as a QSA you get the most questions from people.  Scoping can be a pain, but there are a few rules of thumb you can work with that might make it easier for you.

  • Electronic world
    • If the system accepts, stores, processes or transmits credit card information it is in scope.
    • If you use tokenization the systems interacting with the tokenization services are in scope.
    • If you can access systems that process card information you are in scope. For example if I have a web server that shows some static pages (nothing to do with buying anything or processing cards), but it is in the same network segment (i.e. it has access to the other web server) as those web servers dealing with credit card information, then it is in scope.
  • Paper world
    • If it has a credit card written on it, it is in scope

If you are slightly freaked out by those broad rules and you are thinking OMG that means my entire worldwide network is potentially in scope, then you are starting to get it. PCI DSS is the elephant in the room or bigger than Ben Hur is quite appropriate as well. Which is where scope reduction comes into play. 

PCI DSS is concerned with specific pieces of information, the cardholder data.  Credit card number, Name, expiry date, CVV/C2V, and authentication data. Some of which you are allowed to store and use prior to authorisation of a transaction and not after. Some of it must never be stored (e.g. authentication data, unless you are an issuer of course). So by reducing the information kept, you may be reducing the impact of PCI DSS on the organisation.   
The main mechanisms for reducing scope are:

  • don’t store card details. If you do not need the card number for anything, get rid of it once the transaction is complete.  Keep enough info so you can do your settlements and chargebacks if needed;
  • Truncate, only store the first 6 and last 4 digits of the card number;
  • Tokenize – Use an internal or third party tokenization service which takes a credit card and provides a non identifiable result back which is used in your transactions (i.e if you lose the token, the actual credit card number cannot be discerned);
  • Network segmentation is also a common method for reducing the scope.  Basically those servers and other devices that accept store and process card details are segmented off from the main network and has very limited interaction between the cardholder environment and the rest of the network.  If done correctly the scope for PCI may be reduced and finally,
  • get someone else to do it. Many organisations reduce scope by getting a service provider to certain tasks for them, such as store credit card details. Third party tokenization services are quite common. Likewise having a third party scan forms, redact the credit card number prior to it being sent to your organisation is very common.  Depending on how it is implemented having someone else do the work may reduce your scope.

The how and why is a bit beyond this intro to the standard. Either way if doing scope reduction exercises keep your QSA briefed and they can provide advice as to what you are doing will help your situation or not. 

There are twelve requirements in the standard. A number of them have been introduced as a result of breach investigations, the remainder are fairly typical security practices that hopefully you are already doing anyway. Following are brief explanations of the requirements and some general observations regarding the requirement based on PCI based engagements over the years.

  • Requirement 1: Install and maintain a firewall configuration to protect cardholder data

This requirement outlines the processes that need to be in place with regards to the management of firewalls and routers used in the Cardholder Data Environment.

Most organisations have this reasonably under control. There are however documentation requirements that are not often met and there are those pesky ANY rules (you can have them, but it typically increases the scope).

  • Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Systems are often compromised through the use of default passwords and other default configuration items.  This section addresses requirements such as default passwords, but also security/hardening configuration of devices used, such as server configuration standards for servers and network devices.

This varies from organisation to organisation. Basic build documents are usually available, but they do not often address the requirements of the standard. Default passwords are usually changed, but the simple ones are not (public, private ring a bell?).

  • Requirement 3: Protect stored cardholder data

This requirement addresses the storage requirements for cardholder information and what can be stored and what cannot be stored.   It also addresses encryption requirements and outlines the related documentation requirements.

This is probably the most difficult requirement for most organisations.  Encrypting and managing the keys can be a big challenge.

  • Requirement 4: Encrypt transmission of cardholder data across open, public networks

This requirement addresses the interaction between the organisation and third parties as well as donors/customers.

Usually easily met by most organisations as they often already have VPNs or SSL based applications.

  • Requirement 5: Use and regularly update anti-virus software or programs

This requirement addresses the malware management of the environment and helps ensure that malicious software does not adversely affect the environment.

If you don’t have this sorted, PCI will be the least of your problems.  Most organisations do OK with this, just read the requirement for regular scanning carefully.

  • Requirement 6: Develop and maintain secure systems and applications

This requirement addresses patching and change control as well as the development and testing of applications used to accept and process cardholder information.

The main issues we find relate to the lack of security training or awareness for developers as well as a deficiency in security related testing of internal and external facing applications.  On the patching side, if it has a CVSS score of 4 or higher, you must patch.

  • Requirement 7: Restrict access to cardholder data by business need to know

Requirement 7 relates to access and privilege management and the processes involved for providing access the cardholder data.  This includes the authorisation process and documentation, typically role based.

Most of the time the deficiencies relate to documentation.

  • Requirement 8: Assign a unique ID to each person with computer access.

Users have individual accounts on the various systems and password controls are applied, but not documented.

Userid and password management is often fine, however privileged accounts management and the use of root in some organisations can be challenge.

  • Requirement 9: Restrict physical access to cardholder data.

In order to protect the cardholder information physical security must be considered.

Usually OK, the most problems we come across relate to dealing with visitors.

  • Requirement 10: Track and monitor all access to network resources and cardholder data.

As part of management of cardholder data it is important to have visibility in the environment and have the ability to track activities.

The daily review of logs and file integrity monitoring is where most people struggle

  • Requirement 11: Regularly test security systems and processes.

Under PCI DSS it is expected that the security of systems and applications be tested regularly to ensure that cardholder information is safe.

The quarterly wireless checks for rogue devices is usually the main stumbling block as all sites have to be done. Likewise the difference between a penetration test and a vulnerability scan is sometimes confused and causes issues.

  • Requirement 12: Maintain a policy that addresses information security for employees and contractors.

Policies are the cornerstone of compliance as they outline the requirements to be followed within the organisation.

Usually policies are OK, however monitoring of the PCI status of your service providers is often not well developed.

Becoming compliant

If you are in the process of becoming compliant, then the first step should really be to see where you are at.  So perform a gap analysis, have a look at all the of the requirements and see how your organisation stacks up against these.  The council has two documents available here that will help.  Firstly there is the “navigating the PCI DSS v2.0” document.  It provides guidance on the requirements. Secondly there is the “prioritised approach for PCI DSS Version 2.0” document and spreadsheet that will help with remediation by assisting in prioritising your efforts.  Acquirers have been know to ask for completion of this spreadsheet so they can track your compliance efforts.

Be aware of the self assessment trap that people tend to fall into. Remember all those quizzes in magazines. Can you run 100m in 12 seconds?, sure.  Can you bench press your own weight at least ten times?  no problem.  We tend to over estimate our abilities. So when doing the gap analysis, for each requirement you look at, add the following “how can I prove it?” That should bring answers back into reality. For example requirement 1.1.1 Verify that there is a formal process for testing and approval of all network connections and changes to firewall and router configurations “how can I prove it?”.  What the QSA will be looking for is a document that states “must be approved, must be tested, etc” then typically they’ll ask to see the approval for a particular change to a network device.  Who approved it, who executed it, etc. If that is not possible, then you are not compliant.

After the gap analysis and the remediation you are ready for either the on-site assessment, if needed, or the self assessment. There are a number of different self assessment questionnaires that can be completed depending on your situation.  Usually the acquirer stipulates which SAQ needs to the be completed. Just remember the magazine quiz trap when completing the SAQ, it is easy to say yes when the answer is really no.

A bit longer than I had initially intended, so that’s where we’ll leave it for today. Comments always welcome I would suggest that for specific questions you use the contact form.

co-published at SANS ISC InfoSec Forums