Once you have all of your controls in place and running smoothly, you can think about auditing them. A successful audit is the closest thing you‘ll get to proof that your organization is secure. Which audit should you consider? You probably won’t get to choose as most audits are thrust upon us. If you’re lucky, you’ll only have to deal with one audit instead of several overlapping ones. All of the processes and controls discussed in this book are applicable to SSAE 16, ISO 27001, PCI DSS, and other major audit requirements. So where do you begin?
Getting Ready for Audit
The first thing to do is review everything you’ve done, with a careful eye toward how you‘ve defined scope . Remember that an auditor may challenge the decisions you’ve made regarding scope, so be prepared to defend your choices. Concerning process and controls, how much has been documented? Not just policies, standards, and procedures but do you have records based on these processes running? To an auditor, if an activity wasn’t documented with a paper trail then the activity may not have been done. It’s also important that all of your processes are being followed by everyone who is supposed to be following them. Publishing documents is insufficient. The controls must be used.
You need to make sure that everything was completed, from start to finish, and been running for a while. This book presented things in conceptual order, not necessarily chronological. Read, understand, and implement the whole thing before paying money for an audit. Here is a checklist for implementing a security program :
Analyses
Asset analysis
Risk analysis
Impact analysis
Threat analysis
Natural threats
Adversarial threats
Control analysis (Existing controls)
Compliance analysis
Identify specific required controls and assets per compliance regime.
Define scope.
Build Governance model
Obtain management endorsement.
Set up ISMS Steering committee.
Select members.
Create charter.
Review analyses.
Perform risk management.
Define risk acceptance criteria.
Accept risks.
Eliminate risks.
Transfer risks.
Mitigate risks.
Control risks.
Develop risk treatment list.
If pursuing ISO 27001, write SoA matching controls to risks and compliance requirements.
Write key security policies.
Organizational security policy
Acceptable usage policy
Design controls.
Design controls based on risk treatment list.
Develop control policy, standards, and procedures.
Develop tools to monitor control effectiveness and coverage.
Develop control implementation projects.
User training
Security awareness training
Policy roll out and training
Control process training
Roll out controls.
Implement control projects.
Collect records of controls in action.
Monitor control effectiveness.
Assess program for audit.
Review all work so far against specific compliance requirements.
Select and hire audit firm.
Begin audit.
The first eight steps have been covered so far. Now you need to assess your security program against the audit requirements you’re going to face. This means you need to obtain the latest guide for the audits you need to pass. Here is where you can find some of them:
SSAE 16 SOC 1,2,3
http://www.aicpa.org/Publications/AccountingAuditing/KeyTopics/Pages/ServiceOrganizations.aspx
PCI DSS
ISO 27001
http://shop.bsigroup.com/ProductDetail/?pid=000000000030282638
These URLS may have moved around a bit between the writing of this book and when you’re reading it. However, it should be easy to find audit guides to any major audit program directly from the certifying body. Be aware that some of audit guides cost money, but definitely worth the investment before your spend thousands of dollars and hours of work on auditors and consultants. These guides are designed to help you map your processes and controls to the requirements. This is where you roll up your sleeves and do a gap analysis. Some organizations hire a consultant to do this work for them as well. This is an option, but it still is a good idea for the security team to have a clear idea of the audit criteria they are expected to meet.
After this review, you may need to go back and tweak some processes and add a few controls. Once you are satisfied that you are doing what is described in the audit guide, you can move on to hiring an auditor.
Picking an Auditor
Most of the time, but not always, you can choose your own auditor. Audits and auditors are supposed to be standardized and interchangeable. When you get into the details, this is not really the case. Sometimes this means that the quality of that testing varies. Since quality is a relative term, it can mean speed of testing, cost of testing, depth of testing, thoroughness of testing, or appropriateness of testing. There are a few things to look for in an auditor to make sure that they’re a good fit for your organization’s needs.
The first big factor is experience with testing in your industry or vertical. If your organization is a string of boutique retail stores, you may not want a PCI DSS auditor from the e-commerce world. You want someone familiar with the processes, threats, and issues that are prevalent in your industry. You don’t want to have to explain business processes and unique regulatory pressures either. In fact, you’d want the auditor to have a good idea of what is common practice for you organization and the common pitfalls. Since we are talking about IT security, what kind of technical expertise do they have in the areas of technology your organization uses? When choosing, you want to make sure that the audit engagement team has at least a dozen or so audits worth of experience in a business sector like yours. Ask them for references from other organizations.
Another major factor is how they perform the audit. While their certifying body dictates the audit workflow, each firm has its own particular methods that may or may not work well for your organization. Are they local to your region or will they fly folks in? Will they have dedicated technical experts in your office doing the testing (expensive but quick) or will there be junior team members doing the legwork supervised by the experts (cheaper but slower). Will they gather and analyze data on site or will it be shipped off to the auditor’s offices for analysis? Do they offer additional complimentary audit services, like can they do both PCI DSS and SSAE 16? Do they offer vulnerability and penetration testing services? How fast can they turn around a report? All of these may mean something to you or not, it depends on your needs and resources.
One factor that may be important is the auditor’s reputation and name recognition. Organizations who want prestige from their completed audits want an auditor with a strong reputation. Big names from trusted firms can look good with customers, partners, and regulators. Would you rather hand a customer a report from a large internationally recognized audit firm or Jasper’s Audit Emporium? However, the big names are not the cheapest, fastest, or most flexible either. It’s a good example of defensive decision making,1 but it can be worth it. If you just need to check a box and get off the hook for compliance reasons, then maybe a smaller relatively unknown firm is the way to go.
We’re All on the Same Side
When you’re hiring an audit firm, it’s in everyone’s best interest for you to pass. The firm doesn’t want to issue a report full of so many findings that your organization is shown to be non-compliant and they never get hired again. This may be a different story with regulators or externally hired auditors, but in general, hired audit firms want to pass you. This doesn’t mean they’ll overlook things on purpose or bend the rules. These auditors can be sued or decertified for not upholding the standard they’re charged with testing. In general, I’ve seen that the larger firms with big name recognition are stricter than the smaller ones. Larger firms have more cut and dried audit methodologies and less time on engagements to be flexible on the interpretations of the rules. They also may have a larger chain of experts needed to sign off on understand an audit finding.
I say all of this because I actually prefer the more strict and formal audit firms. It’s not because I enjoy torturing my organization and myself. I want the most exacting and demanding audit possible. Remember the goal of the audit is to expose through transparency any potential problem with a security program. Anything less than thorough sets you up for failure with another auditor or an attacker. Assume breach can apply to many things and you never know who will audit you after this firm leaves. I want to set a high bar on my program in case there’s future trouble involving regulators, customers, business partners, or even the courts. I want my organization to be as compliant as possible because it means we have a better reputation and are carrying less liability. Lastly, a good tough audit keeps everyone inside my organization honest. It supports my efforts to reduce risk to have solid controls and fewer mistakes in processes. All things being equal, if you have to choose between an easy audit or a tough one, I say aim high.
What Happens During Audit
In general, audits all follow the same workflow . After engaging with an auditor, they discuss your compliance requirements and work to ensure your business objectives are met as well. They may even suggest a different audit or audit approach based on your needs and the regulatory environment. They dive deep into how your organization functions, both in process and in technology. For this, you should be providing them with high-level network diagrams, physical locations, organization charts, business process service models, and a list of the major technologies in use. Even though they are evaluating you for an audit, any audit firm you hire is still there to make sure that your needs are served. So do you best to be open and clear on how your organization functions and what you hope to get out of the audit.
The auditor should then do a high-level review of your scope, security program, and controls. This is not an audit but just a quick skim of the project so they can gauge how much time and effort are required to complete the audit. Based on this, the auditor may suggest doing a pre-assessment . A pre-assessment is a light version of the audit that doesn’t count. It’s a gap assessment that can uncover design or operational problems that you don’t want coming up later during the real audit. These do take time and effort to complete, so pre-assessments aren’t usually offered for free and can delay the start of the audit. However, if this is your first real audit, I recommend doing it. Once the actual audit begins, any problem that the auditor uncovers is written up as findings in the final report. Pre-assessments are also useful as an independent expert opinion can demonstrate to upper management the need for more time or resources to mature the security program without the impact of an audit finding.
Once the audit is ready to begin, the last thing to finalize is the audit period . Some audits, like SSAE 16 Type 1, are just a single point in time, so this isn’t a concern. For most others, there is a defined range of time being reviewed. For example, if your audit period is January 1st until December 31st, then any control activity during that time is fair game for auditor review. This is true even if the auditors haven’t shown up until March or April. The auditors review your records going all the way back to the beginning of the period to confirm that controls were running at that time. For this reason, there can be some wiggle room on the start period of the audit. If the pre-assessment turned up numerous problems, then an audit period may be pushed to start later, after all things are corrected. You may not have the flexibility to do this for contractually mandated audits, like PCI DSS, but for SSAE 16 and ISO 27001k, you can.
Scope Review
As you’ve seen earlier, scope establishes the context for the entire audit. Therefore, the audit team begins by examining your scope in meticulous detail. They need information on the relevant scoped physical locations, networks, servers, and personnel defined by the scope. This review may include investigating the following:
Detailed network diagrams, perhaps even down to the cable and individual IP address level.
Inventory and configuration of critical systems that store, process, receive, and transmit scoped data.
Scoped data record format.
How scoped data is identified and tracked within the environment, in and out of scope
All the people involved in scoped data and systems, including engineers, support technicians, developers, and managers.
All of the relevant processes that interact with scoped data, systems, and data flows.
Lastly, the auditors look carefully at where and how the scope barriers operate. Warning, the auditor may change your scope if the integrity and effectiveness of your boundaries is insufficient.
Control Review
After confirming your scope, the auditors now dive through all the control objectives and the controls supporting them. For each control, they need to verify it’s in place and designed adequately. Depending on the type of audit, they then check that the control is functioning as designed over the period of time being audited.
Auditors usually do their request for evidence with a formal checklist or pull list based on their earlier discussions and analysis. This checklist includes requests for the following:
Documents, which are numbered and tracked by the auditor, including:
Policies, standards, checklists, procedures
Logs, meeting minutes, system records, e-mails, helpdesk tickets
Reports and output from systems and third parties
Requests for meetings with individuals, usually identified by role. The individual sessions consist of the following:
Walk-throughs in which the audit team asks an individual to describe how specific controls and processes are performed. During the walk-through, the auditors likely ask the individual to provide follow-up evidence such as screen-shots, configuration dumps, help desk tickets, or completed checklists . The auditor may even shadow people as they run procedures to get a hands-on idea on how something functions.
Interviews in which the auditors ask questions about how processes, controls, or risks are done. The answers are compared to your policies and standards to see how things match. Auditors may also ask individuals to explain how certain processes or technical function to get a better idea on the details.
Follow up discussions with managers or security personnel regarding questions or discrepancies uncovered so far.
Audit Evidence Gathering
As you can see, auditors rely on a variety of methods to gather evidence. Not just individual attestations, but records and configuration snapshots. The variety and diversity of evidence helps solidify their assurance that you are doing what you claim. When there are large bodies of records and controls to examine, the auditor may use sampling to select a percentage of the records for examination.
The selection is based on statistical sampling methods, the criticality of control, and ease of collection. There are many methods for the auditor to select samples, from random selection designed to statistically ensure significant coverage. There may even be some variation in sampling methods from audit type and audit firm, but their chosen methods need to be approved by the certifying body. When sampling, if the auditor uncovers evidence of control failures, they may request additional records to give them a better idea of the size of the problem. This is where you hope the failures turn out to be a one-time failure (but still be noted as a finding) and not an endemic design weakness.
How does the audit evidence-gathering process actually look? Next are some examples for various control audit scenarios.
Control Being Audited Is Background Checks
Auditor asks HR for a list of all employees hired during the audit period so far.
HR produces a list.
Auditor randomly selects a percentage of new hires from the list.
Auditor then submits the selected names to HR with a request for background check records for those individuals.
HR either produces the records or schedules a walk-through session in the HR offices to review the records with the auditor.
Control Being Audited Is Scope Control Barriers
Auditor asks for detailed network diagram of scoped environment.
Network engineer provides diagram.
Auditor reviews diagram and notes the use of a firewall and several network switches used to manage the scoped environment.
Auditor requests a full configuration report from the firewall and switches.
Auditor brings in experts to parse these reports and verifies they match diagram description.
Auditor requests a walk-through with a network engineer to explain configuration on firewall and shows live settings.
Auditor requests a walk-through with a system administrator to demonstrate functionality of scope barrier by trying to make an authorized connection from an out-scope-machine to a scoped machine.
Control Being Audited Is Antivirus Software
Auditor has a walk-through with a system administrator on the antivirus console.
Auditor asks for screenshots of system inventory and antivirus settings.
Auditor selects a percentage of hosts from the system inventory.
Auditor asks for a walk-through for each of these hosts and review local host antivirus settings to check version and signature settings.
Control Being Audited Is Change Control
Auditor asks for a list of all authorized changes since the period began.
Auditor asks for a list of all authorized change approvers during the period.
Auditor randomly selects a list of authorized changes and requests the records associated with those changes.
Auditor compares change records and lists them against change control procedures and standards.
If this is a key control (like for SSAE 16 SOC 2), then auditor also requests a walk-through of an active change being performed by a system administrator.
Roles During an Audit
During the audit process, it’s a good idea to have a clear idea of the roles and responsibilities of each party. Sometimes the audit firm spells this out for you at the start of the engagement, other times it’s not so clear. Therefore, so you know, next we’ll go over everyone’s general roles.
The Auditor’s Role
The auditor’s duty is to evaluate your scoped assets against the compliance standard for the agreed upon period. Anything else is extraneous. Things you did before the period or after don’t count. Things out of the scope aren’t part of the audit either.
Auditors are almost always restricted from auditing their own work, depending on the certifying body. This means that the auditor can’t design controls or provide security advice regarding what they’re auditing. Some audit firms spin off separate consulting divisions with different management structures in order to provide additional services. In general, the consulting advice you may get from an auditor is during the pre-assessment regarding how other audited customers may have solved your particular problem.
Auditors are responsible for keeping you informed on their progress. They publish a project schedule and give you updates as they progress. They report findings and observations in a timely manner, so that you don’t get a huge wave of information at the end. If it is a short or small audit, you may not get much until the end. In general, they let you know if they find something as soon as they’ve confirmed it.
Auditors can also pass on observations, which are like light findings that don’t show up in the actual audit report. They are more suggestions and potential problems that the auditor feels you should be aware of, so that you can nip an issue in the bud.
Auditors are also bound to keep everything confidential except the contents of the final report. Sometimes even the audit report has access restrictions baked into it. For example, SSAE 16 SOC 1 and SOC 2 audit reports state that the contents of the report are solely for the use by the audited organization and organizations that rely on the scoped services. Only SSAE 16 SOC 3 reports are designed to be posted on the Internet for anyone to see. SOC 1 reports are designed for use as part of financial audits. Auditors looking at financial reporting integrity for Sarbanes-Oxley compliance are not allowed to rely on SSAE 16 SOC 2 or SOC 3 reports for their assurance work.
The Audited Organization’s Role
The audited organization has many responsibilities as well. An important one is designating a primary contact to coordinate all the audit activity. This person, perhaps you, is responsible for scheduling the auditor’s visits, arranging office space, scheduling interviews, and procuring documents for the auditors. It is also the audited organization’s responsibility to be open and forthcoming about their environment and controls. Not only should you be transparent and honest when answering questions, but you should also keep the auditor up to date about major changes or problems in the organization that could affect the audit.
As part of the audit contract, you may be required to disclose any suspected deception by staff that could affect the audit. If you lie during an audit, the least bad thing that could happen is that the entire audit is invalidated with the audit firm getting to keep the audit fees.
Third-Party Roles
If part of your scope or controls extend to a third party outside of your organization, they too need to be covered in the audit. The best solution is for the third party to have already undergone an audit against the same compliance requirements as you. This way your auditor can simply review the third party’s report and check off the coverage for the outsourced pieces. Many service providers obtain audits for a variety of compliance regimes for this reason. If they haven’t had an audit, then they too need to be audited. You, your auditor, or another audit firm needs to provide assurance that the security at that third party is adequately addressed. This topic is covered in more detail in Chapter 23, which focuses on third-party security.
Specific Audits
Moving beyond the general audit overview, let’s explore the specific audits covered in this book.
SSAE 16 Audits
SSAE 16 audits are certified by the AICPA and must be done by CPA firms. This can make them a little more expensive and formal than other audits, but they are also more recognized in mature industries.
Remember that there are six different permutations of SSAE 16 audits, but regarding the workflow of the audit, the biggest difference is between the Type 1 and Type 2 audits. The Type 1 audit is a design audit. Type 2 is an operational effectiveness audit and it includes the Type 1 activities. The Type 1 audit involves a review of the controls and scope, but no examination of the operation of the controls. This the auditors focus on document gathering and design walk-throughs. There is no pulling of records of control operation or checks of running processes. It is just a snapshot of the control architecture. You usually see type 1 reports in the first year of an organization’s SSAE 16 audit experience. After that, organizations do Type 2 audits.
Type 1
Where Type 1 audits can get interesting is for SOC 1 engagements. For SOC 2 and SOC 3, the control objectives and controls are supplied from the AICPA based on the service principles chosen. However, with SSAE 16 SOC 1 audits, the audited organization is responsible for designing their own control objectives and control stack. The design of the control objectives must effectively mitigate the risk of unauthorized changes affecting the integrity of the organization’s financial reporting system. Usually the control objectives are straightforward, covering the major types of security like logical, physical, operational, and so forth. The auditors can easily check the objectives and may even have wording changes to meet up closer to generally accepted standards in the SSAE 16 world. The second piece of design the audited organization must do is select the controls to support the control objective. Chapter 12, which was on control design, is a big help here. The controls need to cover risk and should include defense in depth in case a key control fails. The auditors go over these controls and your scoped processes to make sure that the design is adequate.
Type 2
Type 2 audits usually cover a period of six to twelve months, although three-month periods are not impossible. The auditor visits several times during the period to examine running controls and do their testing. They may also spread out their visits between physical locations, based on their sampling methods, to make sure that they have a good handle of what’s going on with the scoped systems. The overall goal is to look at the operational effectiveness of the running controls. It won’t matter if the controls are inefficient, costly, or laborious. All they care about is how well they mitigate the risk to the control objectives. Their findings and feedback is in the context of the control objectives.
SOC 1
For SOC 1, the scope of the audit is focused on the one or more products and services used by a customer and their reliance on the control design and operation. The customer in this case can be internal or external; it really depends on how they rely on these controls to ensure accurate financial reporting and disclosure. As stated by the AICPA: “These reports are important components of user entities’ evaluation of their internal controls over financial reporting for purposes of comply with laws and regulations such as the Sarbanes-Oxley Act and the user entities’ auditors as they plan and perform audits of the user entities’ financial statements.”2
SOC 2/3
You do not design control objectives for SOC 2 or SOC 3 audits, you select from up to five service principles. Each principle has its own control objectives and associated controls. In summary, they are as follows:
Security Service Principle: Controls covering governance, security awareness, risk management, control monitoring, operations and change management.
Availability Service Principle: Controls covering capacity management, data backup, and system recovery.
Confidentiality Service Principle: Controls covering system acquisition, system disposal, system boundary protection, third-party confidentiality, service providers, and user awareness of confidentiality.
Processing Integrity Principle: Controls covering management of processing errors, system input integrity, data processing accuracy, data storage, output accuracy, and modification protection.
Privacy Principle: Privacy policies, privacy notices, privacy consent processes, data collection processes, data usage and storage limitations, internal access controls, third-party disclosures, IT security controls, data quality, compliance monitoring. These controls go beyond IT security and are not covered in this book.
SSAE 16 Reports
SSAE 16 reports are structured into five major sections, as follows:
Section 1
This is the description of scope and the auditor’s opinion. Unqualified means the control objectives were met. Qualified means everything is good except certain named control objectives were not achieved. A qualified report is not good, but not the end of the world. This is the first section of the audit report.
Section 2
This is the audited organization’s formal assertion that they didn’t lie or withhold information to the auditors, that their controls were designed to meet the risks, and their controls were consistently used throughout the period.
Section 3
The audited organization’s description of the control environment. This is a large narrative describing the organization, the scoped environment, and how all the controls function. The fun part is that the auditors don’t write this section, you do. The auditors review it for accuracy and completeness, but the audited organization needs to draft it.
Section 4
After the auditor’s opinion, this section is the second most important. This section is a big matrix detailing the actual audit tests performed and the results. Findings and control failures are detailed here. Forget a background check for a new hire? It is noted here. The audited organization can include a management response providing explanation or remediation descriptions regarding the finding. For example, the response may say, “New hire background check was missed because of an HR transition to a new system. Management added a new second review process to ensure that future checks are always performed.” Some of the recipients of your audit report will dissect this part of the report and ask you to further explain things. In a Type 1 report, this section would just be a listing of the controls and control principles/objectives.
Section 5
This is an optional section where an audited organization can include a few pages to clarify the report. This section usually includes descriptions of other controls and services outside the scope (which means they aren’t verified by audit), descriptions of future plans (next year, we’ll be adding new controls), or even descriptions of services that customers may want to purchase. The auditor officially expresses no opinion on this section, so when reading someone else’s report, you can view this section as non-essential.
ISO 27001 Audits
ISO 27001 audits can only be done by companies certified to perform them. They are not as expensive as SSAE 16 audits, but the supply of ISO auditors is somewhat smaller than other auditors, especially within the United States.
The ISO 27001 audit is against an ISO management standard that encompasses how an organization has designed and runs its security program. It looks at the IT security governance structure, including the leadership, policy, and roles. It also delves into the processes, ensuring they properly align to the Plan-Do-Check-Act methodology. The review of planning phase involves the processes around risk, compliance, and asset assessment, as well as the risk treatment process. The review of the Do phase incorporates the specific control testing. The review of the Check phase is around control monitoring and internal audit processes. Lastly, the Act review looks at how the security governance team works to improve and update the security program to meet changing needs and ineffective controls. Chapter 7, on governance, covers the ISO 27001 standard for security governance—the ISMS, or information security management system.
The controls used in an ISO 27001 audit are based on the defined risk treatment plan and the statement of applicability (SoA ). If you remember, the SoA is a document that shows the link between the chosen controls and the risks and compliance requirements. The SoA also must include a review of all 114 controls detailed in ISO 27002, which break down into the major areas of security policy, security governance, remote access, human resource security, asset management, data classification, access control, cryptography, physical security, operational security, communication security, system acquisition and development, third party supplier security, incident management, business continuity security, and compliance.
An ISO 27001 audit consists of two major phases, an offsite document review, and the onsite process review.
Document Review
This is the first stage of an ISO 27001 audit. It is done off site, as it is easy to review documents without incurring travel and lodging expenses. The audited organization provides the auditor all the relevant documentation related to the ISMS, including the risk assessment, the risk treatment plan, the SoA and all the documentation regarding IT security governance. Much like the SSAE 16 Type-1 design review, the auditor looks at the coverage and completeness of the security program. Does the risk assessment look reasonable and does it adequately cover the scope? Is the risk treatment plan acceptable and the chosen controls appropriate for the risks and assets involved? Are all the controls in ISO 27002 adequately addressed in the SoA? Does the governance model align with ISO standards?
Governance is a big focus of this review, as it is the heart of ISO 27001. The auditor is looking for policies, standards, procedures, and records for scope, policy objectives, asset inventories, risk assessment standards, risk treatment planning, security roles and job descriptions, and reviews of control operations.
Once the auditor feels the documents represent a satisfactory IT security program design, they inform their customer and proceed to scheduling an onsite visit.
Onsite Review
Like the SSAE 16 Type 2 audit, this inspection is about making sure all the documentation you supplied is being used. The auditor examines process and control activity with walk-throughs and interviews. They also look at records and configuration details for technical controls. Sites are visited as well, to examine physical security and the processes in action. Systems can be selected and reviewed against published standards. The auditor can also use logs and help desk tickets to track adherence to procedures.
The ISO 27001 auditor also focuses on the monitoring and correction (check/act) phases of IT security governance. This means the auditor looks at the internal auditor function, making sure they are independent and have been reviewing the security program. The auditor will want assurance that the internal auditor’s reports are being reviewed and acted upon by the ISMS committee. This means that a brand new security program cannot be submitted for ISO 27001 audit. The program has to be running for at least a few months, so that controls and processes can go into operation, be internally audited, and management can respond to that feedback. Internal audit is covered more in Chapter 22.
Findings in the ISO 27001 world are called non-conformities, and they always include a direct reference to the specific section of the ISO 27001 standard documentation. This makes remediation and analysis easier, as you can go right to the standard and see what is needed.
Surveillance Audits
After passing your ISO 27001 audit, the certification is good for three years. During that three-year period, the auditors return each year for a surveillance audit, which is a smaller version of the first audit. This is to ensure that your practices and controls are still in place.
PCI DSS Audit
The PCI DSS audit is the most constrained and because of that, the most simple (but not easy) of these audits. Per the Payment Card Industry Security Standards Council: “PCI DSS applies to all entities involved in payment card processing-including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) .”3
If you store or process more than six million payment card transactions per year, you are considered a Level 1 merchant. For Level 1 merchants and anyone who has experienced a PCI DSS breach, these audits must be done by certified qualified security assessors (QSA ); visit the PCI DSS web site at https://www.pcisecuritystandards.org/assessors_and_solutions/qualified_security_assessors .
Organizations with lower annual payment card transaction counts can submit their Self-Assessment Questionnaire (SAQ). There are many different types of SAQs broken out by type of organization and their role in the payment card transaction. The PCI standards organization has a good document called “Understanding the SAQs for PCI DSS,” which is available at https://www.pcisecuritystandards.org/ document_library?category=saqs#results.
The PCI DSS is one of the most technically prescriptive of all the audit compliance regimes. The audit therefore focuses a lot on technical controls, especially the vulnerability scanning and penetration testing. These scans must be done by an approved scanning vendor (ASV ), listed online at https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors .
Vulnerabilities found during scanning or penetration testing must be remediated if rated higher than medium, or 4.0 on the CVSS score range.
The QSA also looks very closely at the technical controls segregating the scoped environment from the rest of the world. PCI DSS refers to the scoped environment as the cardholder data environment (CDE ). As for the controls themselves, the PCI DSS includes the testing procedures directly in the standard, so you know exactly what should be done.
After the review of controls, the QSA produces an Initial Report on Compliance, or IROC . If there are gaps, your organization has a few months to fix things before the auditor returns for retesting. When everything is clean, you receive a final Report on Compliance (ROC) , which is your audit report. It contains an executive summary, a scope description, details on the CDE and organization, quarterly ASV scan results, and findings and observations by the QSA. Details on the format of this report are available right on the PCI DSS web site as the Report on Compliance (ROC ) Reporting Template for auditors at https://www.pcisecuritystandards.org/document_library .
Disagreeing with Auditors
There may be times when you disagree with an auditor’s findings . Changing an auditor’s mind can be tough and you will often lose. The real trick is to politely disagree and explain your perspective on the finding without antagonizing the auditor. I like to see my role as a defense attorney trying to make sure that I receive justice for my client. I need to be firm with my client’s case, but I do not want to usurp the judge’s authority and sink my entire case. It takes a gentle but firm touch to voice a dissenting opinion with an auditor. This can be especially difficult since the auditor expects push back and likely hears complaints all the time. Stick to the facts, the audit standard, and use logic. Let’s break down some types of findings in Table 21-1.
Table 21-1. Audit Findings and Responses
Finding | Likely Reason | Your Response |
|---|---|---|
This control was excluded and therefore there is a finding | Some controls are always applicable in some audit requirements, some are not | If the control is not required by the audit, explain how the risk it mitigates is negligible or covered by another control elsewhere. |
This automated control failed and that’s a finding | Control did not function as described | Although it is still our fault that this control failed because of a manufacturer‘s bug, we have other controls that address this risk (defense in depth). Although these controls aren’t as fast or robust as the automated control, they still address the risk during the short duration of this failure. |
As you can see, the strategy is to focus not on the control but on the risk. Some auditors focus too much on controls and don’t consider risk in their evaluations. Your response is to drive the conversation to the heart of the problem and go over the specific risks, matching them to the control and the potential impacts. When discussing risk, make sure that you discuss both likelihood and business impact.