OpAuditTM from is the first compliance management product on the market to successfully track manual controls and technical controls in the same workflow-based system. This ingenious solution gathers & manages all evidence of compliance in a single system so you can successfully track attestations, evidence and technical audit data across all policies Users can answer questions, make attestations and upload evidence to gather all of the information needed to prove an organization s compliance with policies, best practice frameworks and service level agreements, all through the intuitive web-based user interface. Key Benefits Attestations Enables contributors to answer questions and upload evidence. Assessments Lets staff and suppliers answer questionnaires as evidence. Technical Auditing Enables technical data to be gathered as compliance evidence. Policy Builder Enables users to build their own standards and assessments. Unified Controls Means users only answer any question once. Custom Fields Turns compliance tracking into business intelligence. Users can also deploy the ubiquitous Pervade Data Collector to run technical queries, using a vast array of data types, into devices, databases, files and other sources to answer compliance related questions automatically. PCI- DSS Requirements The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. PCI-DSS applies to all entities involved in payment card processing as well as all other entities that store, process or transmit cardholder data. PCI-DSS provides a baseline of technical and operational requirements designed to protect cardholder data and the latest version (v2.0 issued in October 2010) details 62 requirements that are grouped into 12 high level areas of security. The requirements are broken down into 200 controls, or Testing Procedures, which organizations are audited against to prove their compliance. Of these 200 Controls between 75 and 85 of them (depending on the organization s infrastructure) can be checked using technical data gathering techniques, as opposed to having to manually check devices and systems for the answers, saving huge amounts of time and effort and removing the element of human error from the monitoring process. OpAuditTM is the only monitoring solu5on on the market able to gather all of the data types needed to automate every possible control tes5ng procedure. To automate, without using OpAuditTM, would require at least 3 separate monitoring systems, to gather:- Key Features Onsite or Secure Hosting Log Data Configura7on Data Asset Data Encrypted Browser Access Application Layer Protection Data 256-bit AES Encrypted Object Persistent Database Multiple Language Support Multi-tenant Segregation Add your own Audits Completely Customizable This document describes how to configure OpAuditTM to automatically gather the sort of technical data required by the PCI-DSS Requirements. The specific queries needed by an organization will obviously depend on the specific devices in that organization s infrastructure. Therefore, some of the examples provided might not be appropriate for every organization and the information might not be accurate for every infrastructure. This information should be considered guidance about the sort of data collection that is possible and is intended to prompt ideas about to how to automate as many of the testing procedures as possible. For more detailed explanations about how to automate the testing procedures in your specific infrastructure, please contact the Support Team.
Use Case PCI Technical Controls PCI Requirements that can be technically monitored Requirement 1: Install and Maintain a Firewall R.1.2.0: Firewall and Router Configura5on R.1.2.1: Restrict Inbound and Outbound Traffic R.1.2.2: Secure Router Configura5on Files R.1.2.3: Install Firewalls on Wireless Networks R.1.3.0: Prohibit Direct Public Access R.1.3.2: Limit Inbound Internet Traffic to DMZ R.1.3.3: Do Not Allow Direct Connec5ons R.1.3.4: Don t Allow Internal Addresses into DMZ R.1.3.5: Authorize All Outbound Traffic R.1.3.6: Implement Stateful Inspec5on R.1.3.8: Do Not Disclose Rou5ng Informa5on R.1.4.0: Install Personal Firewalls Requirement 2: Change Vendor- Supplied Defaults R.2.1.0: Acempt Vendor- supplied Logon R.2.1.1: Change Wireless Vendor Defaults R.2.3.0: Encrypt Administra5ve Access R.2.4.0: Tes5ng Shared Hos5ng Providers Requirement 3: Protect Stored Cardholder Data R.3.2.0: Data Reten5on and Disposal for Issuers R.3.2.1: Do Not Store All Track Data R.3.2.2: Do Not Store Card Verifica5on Code R.3.2.3: Do Not Store PIN Data R.3.4.0: PAN Protec5on Systems R.3.5.2: Cryptographic Key Storage Requirement 4: Encrypt transmission of cardholder data across open, public networks R.4.1.0: Transmiced Data Security Protocols Requirement 5: Use and regularly update an7- virus sopware or programs R.5.1.0: An5- Virus So<ware R.5.2.0: An5- Virus Mechanisms Requirement 7: Restrict access to cardholder data by business need to know R.7.2.3: Default Deny- all Sefng Requirement 8: Assign a unique ID to each person with computer access R.8.1.0: Assign Unique User ID R.8.4.0: Render Passwords Unreadable R.8.5.4: Revoke access for Terminated Users R.8.5.5: Remove Inac5ve Accounts R.8.5.6: Enable and Monitor Vendor Accounts R.8.5.8: Group, Shared, or Generic Accounts R.8.5.9: Change passwords Periodically R.8.5.10: Minimum Password Length R.8.5.11: Passwords Alpha Numeric R.8.5.12: Password Repe55on R.8.5.13: Limit Repeated Access Acempts R.8.5.16: Database & Applica5on Access Requirement 9: Restrict physical access to cardholder data R.9.1.0: Physical Security Controls R.9.1.1: Monitor Entry/Exit Points R.9.2.0: Processing for Assigning Badges Requirement 10: Track and monitor all access to network resources and cardholder data R.10.1.0: Audit Trails for System Components R.10.2.1: Access to Cardholder Data R.10.2.2: Administra5ve/Root Ac5ons R.10.2.3: Access to all Audit Trails R.10.2.4: Invalid Access Acempts R.10.2.5: Iden5fica5on Mechanisms R.10.2.6: Audit Log Ini5aliza5on R.10.2.7: Object Crea5on and Dele5on R.10.3.1: User Iden5fica5on R.10.3.2: Type of Event R.10.3.3: Date and Time R.10.3.4: Success or failure Indica5on R.10.3.5: Origina5on of event R.10.3.6: Name of Affected Data R.10.4.0: Time- synchroniza5on Technology R.10.4.1: Cri5cal Systems have Correct Time R.10.4.2: Time data is protected R.10.4.3: Time Sefngs from Accepted Sources R.10.5.1: Limit Viewing of Audit Trails R.10.5.2: Protect Audit Trail Files R.10.5.3: Back up Audit Trail Files R.10.5.4: Offload Logs for External- facing R.10.5.5: Use change- detec5on So<ware on Logs R.10.7.0: Audit Log Reten5on Requirement 11: Regularly test security systems and processes R.11.1.a: Detect Unauthorized Wireless Points R.11.2.1: Quarterly Internal Vulnerability Scans R.11.4.a: Use of IDS/IPS Systems R.11.5.0: File- integrity Monitoring Tools PCI-DSS Requirements that can be supported by technical evidence R.1.2.1: Restrict Inbound and Outbound Traffic R.6.1.0: Vendor Patches Current R.7.2.2: Access Privileges based on Job Func5on R.12.3.3: Compile List of Devices and Users R.12.3.8: Disconnect Inac5ve Sessions R.12.5.4: Administer User Accounts R.12.6.2: Personnel read Policy Regularly R.12.8.4: Monitoring Service Providers R.12.9.5: Alerts Trigger Plan Informa5on provided by Pervade So<ware Ltd, of Castle Court, 6 Cathedral Road, Cardiff, UK CF11 9LJ Tel: 02920 647632 Email: info@pervade- so<ware.com
This is how Requirement 1.2.0 looks in OpAuditTM Users can see the full text, as it appears in the PCI Security Standards Council documentation. There are no summaries or interpretations just the actual wording that an auditor will refer to when assessing you. Being able to read the Section, Objective and Requirement statements helps to put the Question itself into it s proper context thus making it easier to answer. By default, all Questions in the system are configured as Yes/No Questions, they look like this You can configure addi.onal op.ons to help clarify the organiza.on s compliance posture (e.g. Risk Weigh.ng) You can allocate each Ques.on to the person in the organiza.on who is best able to answer it If you discover that you are not yet compliant and must answer NO to a Ques.on, you are given the opportunity to add addi.onal informa.on about how you are going to remediate your posi.on, about how much it is likely to cost and also how long it is likely to take. This helps you to build your organiza.on s Ac.on Plan to Compliance If you have documentary evidence to show an auditor to prove your compliance, then you can manage those documents through the system. You can upload into the secure, tamper- proof document store or add a link to a document that is in a system, or a file store, elsewhere on your network. The majority of the questions an Auditor will ask will require answers, attestations and evidence. It is possible to use the Yes/No Question functionality to address all Requirements manually. However, having the ability to automatically answer a Question saves time and helps to minimize human error. So, the more answers that can be gathered automatically the better.
This is how Technical Questions are configured STEP ONE: Devices in Scope The first step, is to identify the specific devices that you will need to run Queries into in order to get the data needed to prove compliance with the Requirement. In this example (Requirement 1.2.0), you need to look at a network diagram of the cardholder data environment to identify connections to untrusted networks. Check whether there are firewalls at each of these connections, or if they are restricted in some other way. If you identify a connection that is not restricted in any way, you could manually answer No to this Question and document the remediation activity needed to secure the connections and become compliant. If there are Devices at each connection point, then gather details of IP addresses and login credentials. You can add these Devices into the software, one at a time, or using the Bulk Add facility. Once a Device has been set up in the system, it is possible to monitor it, as an Asset, for Performance, Availability, Vulnerability, Security, Configuration, Log, Flow, File etc. And, you are also able to track it s compliance status! STEP TWO: Queries & Collec5on Policies The next step, is to decide the best way to collect data from the firewalls to prove that the connections are "restricted". With 20 times more Query Types than any other product, OpAuditTM provides you with an incredible range of options. For example, you could run an Availability Query into each firewall, the fact that a firewall exists implies access is restricted. Or, you could run a Config Query to check for an "Any-Any Allow Rule", if one doesn't exist then the firewall is restricting access. With so much flexibility, you will be able to use the best possible methodology to get the right data in the right way using the simple and intui.ve controls in the user interface. The Queries can be run into the appropriate Devices at the appropriate time intervals. The results of the Queries will be sent back to the Central Server by the Data Collector and will be available for you to use in correlations, aggregations, charts, tables, reports and of course, as evidence of compliance.
This is how Requirement 1.2.0 can be answered automatically STEP THREE: Technical Ques5ons Having determined that a question can be answered using Queries, you can replace the Yes/No Question in the software with a Technical Question. A Technical Question is a question which references a Query that has been created in the system and asks whether the data returned by that Query contains data that will prove compliance with a particular Requirement or Control. All Questions in the software can be edited, deleted and replaced. So, once you have created the Technical Question, use it to replace the preexisting Yes/No Question and it will automatically answer the policy question based on the data returned by the Query. STEP FOUR: Display the Answers The Question will answer automatically and a real-time compliance scoring mechanism will kick in. The accordion bars will change from Red to either Amber or Green. Fully answered Questions will score 100% and will turn Green while the Objective or Section will turn Amber (until all its Questions are answered). Depending on the number of Questions in a Objective or Section, the compliance score of each will alter to show how much progress has been made and how much work is left. If a Query (which is constantly running in the background) suddenly returns a negative answer, the corresponding accordion bar will immediately turn Red (and can trigger alerts) to warn of non-compliance. In addition to the compliance tracking on the Policy accordion bars, all of the information will be detailed in any Compliance Reports you produce. It is also possible to create a wide range of graphs, charts, tables and displays which can be organized on customizable tabs and dashboards. So, you can demonstrate your compliance posture in the best way for you, for your teams, for your management and, of course, for the auditor.