Preparing for a PCI DSS compliance audit doesn't have to be complicated if you take five simple key measures before the assessment is required. This technical tip is written from the approach that your organization has never undergone a PCI DSS audit.
STAKEHOLDER ENGAGEMENT STRATEGY: RECRUIT PHYSICAL SECURITY, LEGAL
Managing an audit requires the cooperation of others inside and outside the IT department. Reference your company's org-chart and determine staff that will provide evidentiary data. Once identified, notify their upstream manager to set expectations. You will likely require the support of one of the two following non-IT departments: legal and physical security. Legal must be engaged because they will set the direction for current policies and any new policies that may be required to support PCI DSS compliance. Legal can direct you toward streamlining your policies. Physical security should be engaged to support providing physical evidentiary data.
CHOOSE YOUR PCI SELF ASSESSMENT QUESTIONNAIRE WISELY
The PCI Security Standards Council has provided a self-assessment tool free of charge; PCI DSS v1.2 should be used. There are five categories of self-assessment you may choose from. Verify which self assessment questionnaire (SAQ) is appropriate for your organization. Complexity of compliance can be reduced by selecting a SAQ that will not impose unnecessary requirements.
SETTING MINIMUM, MAXIMUM POLICY REQUIREMENTS
Compare policies against the pre-assessment findings. Why? Policies are legal documents that set the floor as to how your organization operates. They will tell the auditor: "This is the legal minimum or maximum we require of our organization." You may find after reviewing your policies that you've set the ceiling on policies that really only require the floor. For instance, PCI DSS Requirement 1 references firewall configuration. If you have a firewall policy that states your organization must use application layer firewalls only, you will have set the ceiling and eliminated routers and any other technology that can examine all network traffic and block transmissions as a firewall. The requirement sets the expectation that routers are considered firewalls based on ACLs. It is better to identify such policy issues before the audit as they can be easily corrected prior to the audit.
ESTABLISH A BASELINE FOR YOUR INFORMATION ARTIFACTS
Setting the floor is declaring where your baselines begin. You want to set the floor as to information artifacts (policies, standards and procedures that support an audit and compliance), identities and document management for starters. Information artifacts are the documents your organization executes its operations against. The authoritative identity source for your organization should be set as it can mitigate against rogue accounts or help identify the lack of naming standards. Finally, communicate, require and enforce where electronic content is stored based on content. This can help reduce the scope of a PCI DSS audit.
USE TAXONOMY-BASED INFORMATION ARTIFACTS
Using a taxonomy-based approach, information artifacts are aggregated under a classification system rather than an individualistic approach. The result is fewer artifacts to maintain and consume. I use the approach below:
- Does the artifact cover a particular segment only? If yes then it = P(oint).
- Does the artifact cover a whole which consists of disparate points? If yes then it = E(nterprise).
- Does the artifact need to cover P and E? If yes then it = H(ybrid).
For example, an acceptable use policy is an artifact written as a hybrid to address the enterprise and point segments it covers. Set the floor by writing basic policies you'd expect. Next, add policies related to technology your organization has currently invested in, and finally, write exceptions to address future technologies they are considering but have yet to implement. That is how you make information artifacts extensible and you have only the artifacts required by the organization. Finally, updates are rare, which means lower cost of ownership. Regarding the firewall policy, approach it as a classification and it becomes firewalling. You may now set the floor on what that means for your organization from a functionality perspective, which allows for extensibility of firewall types and can include routers.
(The information in this article is agnostic and may be applied to any compliance requirement you may face.)
Ravila Helen White is currently an enterprise security architect on assignment at an invention company in Seattle. Prior to that, she was the head of information security at The Bill & Melinda Gates Foundation and drugstore.com.
Send comments on this technical tip to editor@searchmidmarketsecurity.com
Join our IT Knowledge Exchange discussion forum; please use the midmarket security tag.
