Requires Free Membership to View
SearchSecurity.com members gain immediate and unlimited access to breaking industry news, virus alerts, new hacker threats, highly focused security newsletters, and more -- all at no cost. Join me on SearchSecurity.com today!
Michael S. Mimoso, Editorial Director
 |
||||
|
|
|||
|
||||
The most important thing to remember about an IT auditor is that he or she focuses on a few simple questions:
- For each area of risk, has the organization either accepted the risk or identified an appropriate control?
- For each control, where is the evidence that it works as intended?
- Is there documentation that all actions were carried out in the intended manner with required oversight and approval?
Therefore, there are a few simple things security leaders can do to streamline the interactions between the security team and the auditors:
- Document not only measures to reduce risks, but also those cases where the organization decides to accept risks, in return for greater flexibility or potential benefits.
- Embed the idea of "controls" and "control objectives" in the security architecture. Controls are the specific measures put in place to ensure compliance or security, and control objectives are the metrics or evidence that the control is working as intended. For example, a control might be procedures for disabling the IDs of terminated staff, and the control objective would then be that all access is removed within two business days of termination.
- These are key concepts everyone needs to use, and they will improve security by taking hazy best practices and turning them into measurable performance metrics.
- Never overstate or underestimate the degree of confidence you have in your controls and mitigations. If you can't prove that, for instance, access rights are being removed in a timely way and in practical terms, your credibility will be reduced for this and other controls. In simple terms, if the auditor finds an exaggeration in the effectiveness of one area, all the other areas will be called into question.
In my experience, auditors appreciate it when their jobs are made easier. One helpful approach is to fully document the mapping of the security policy and architecture to a standard framework, such as COBIT or the ISO 27000 series. When the auditor walks in and says, "How are you dealing with encryption key management issues?," it will be invaluable to know that the criteria he will use are described in COBIT "Deliver and Support" section 5.8; it will be evident what the auditor is likely to assess.
Talk to the internal audit team during the company's annual security policy and status review and get a feel for where they see deficiencies or unknowns. Be sure to do this outside the audit report and response process. Invite them to review policies and standards, and enlist them to ensure that future controls have strong record-keeping and validation.
The special nature of the QSA
Although security professionals often think of the QSA as an auditor, there are important differences. As defined by the Payment Card Industry Data Security Standard (PCI DSS), a QSA is a specialist who assists a body subject to PCI DSS in being compliant with the standard's requirements, and who can provide an acceptable assessment of whether the organization has been successful in establishing and maintaining compliance.
PCI DSS is different from the gray and ambiguous nature of other compliance objectives such as Sarbanes-Oxley; it is a mixture of principles and specifics, which can be frustrating for security professionals. In some areas, it supports strong measures for protecting cardholder data; in others, it seems surprisingly lax. For example, PCI recommends against Wired Equivalent Privacy (WEP), a known flawed protocol, but still allows it to be used until June 2010.
|
||||
|
|
|||
|
||||
Any firm large enough to have a dedicated security staff is likely to be what PCI defines as a Level 1, 2 or 3 merchant or service provider. The scale is loosely based on the company's number of annual credit card transactions, or the nature of the business. Regardless of the particular firm's classification, it's possible to make a great start on QSA relations in the same way as with any other auditor: by knowing what questions he or she will ask before they're asked.
Fortunately, by downloading the Security Audit Procedures from the PCI Security Standards Council website, you can review the framework that QSAs use to conduct onsite reviews and validate PCI compliance. Level 2, 3 and 4 merchants are required to perform self-assessments using the documents published on that website, whereas Level 1 merchants must have an assessment performed by a qualified third-party QSA. The full effect of this document is reserved for Level 1 merchants, but anybody that handles credit card information will benefit from basing their PCI compliance on a documented target such as this.
Finally, remember that PCI DSS compliance reaches far beyond encryption, storage or protecting transactions. If the information security team is tasked with all PCI compliance activities, it's important to be much more involved with business processes and record-keeping. Build a strong relationship with the CFO, controllers and operational managers, and you can present a single voice to the QSA -- everyone involved will be better for it.
About the author:
Tony Higgins, CISSP-ISSMP, CISA, CIPP, is a consultant specializing in information security, privacy, and compliance, who has recently worked in the resort, gaming, and financial sectors.
This was first published in December 2008