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.
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.
This document describes how to configure OpAuditTMto 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 Pervade Software Support Team.
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 t o b e g a t h e r e d a s compliance evidence. Policy Builder Enables users to build their own standards and assessments.
Unified Controls M e a n s u s e r s o n l y answer any question once.
Custom Fields T u r n s c o m p l i a n c e tracking into business intelligence.
Key Features Onsite or Secure Hosting 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
OpAudit
TMfrom Pervade Software 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…
OpAudit
TMis 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
OpAudit
TM, would
require at least 3 separate monitoring systems, to gather:-‐
•
Log Data
•
Configura7on Data
PCI-DSS Requirements that can be supported by technical evidence…
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
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
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…
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.
You can allocate each Ques.on to the person in the organiza.on
who is best able to answer it
You can configure addi.onal op.ons to
help clarify the organiza.on’s compliance posture (e.g. Risk Weigh.ng)
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
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.
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.
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!
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.
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
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.
STEP FOUR: Display the Answers
The Question will answer automatically and a real-time compliance scoring mechanism will kick in. 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 pre-existing ‘Yes/No’ Question and it will automatically answer the policy question based on the data returned by the Query.
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.
