Navigation

 ·   Wiki Home
 ·   Wiki Help
 ·   Categories
 ·   Title List
 ·   Uncategorized Pages
 ·   Random Page
 ·   Recent Changes
 ·   RSS
 ·   Atom
 ·   What Links Here

Active Members:

Search:

 

Create or Find Page:

 

View PCI - 12 Required Items for Hudson Clients

Category:Security
Category:Credit Card Processing

The 12 Required Items on the PCI SAQ

*****THIS ARTICLE IS STILL BEING GENERATED AND EDITED AND IS NOT COMPLETE*****


Each Hudson client that processes credit cards in their business, will likely have to complete a PCI Self Assessment Questionnaire (SAQ) at some point. In its simplest overview, Merchants have to address and comply with 12 different elements. Only a couple of these specifically involve the actual credit card application that you are using. Before we get ahead of ourselves, lets review the list of required elements in the SAQ.

There are 12 elements that you will be required to address. These elements are:

  • Install and maintain a firewall configuration to protect cardholder data
  • Do not use vendor-supplied defaults for system passwords and other security parameters
  • Protect stored cardholder data
  • Encrypt transmission of cardholder data across open, public networks
  • Use and regularly update anti-virus software or programs
  • Develop and maintain secure systems and applications
  • Restrict access to cardholder data by business need to know
  • Assign a unique ID to each person with computer access
  • Restrict physical access to cardholder data
  • Track and monitor all access to network resources and cardholder data
  • Regularly test security systems and processes
  • Maintain a policy that addresses information security for all personnel

  • While the list above seems pretty simple and straight forward, when you actually start answering the questions in the 12 sections of the SAQ, you will find that there are a great number of subsections and questions on each subsection as well. The answers will be anything but obvious or easy to arrive at.  For this reason, Hudson has prepared the following overview that should help you answer some of these questions if you process credit cards using the HGTS system and / or you are using Hudson’s cloud hosting option.  If you are not processing credit cards using Hudson technology or are running the Hudson system on your own network (premise-based), then the answers below will be of little value to you.  This list will be updated and maintained often, so feel free to return and look for new or updated information. NOTE: The numbering scheme used below conforms to the SAQ-D template. If you are completing a different SAQ, the information should be the same but the numbering scheme may be different!

    DISCLAIMER:  The Hudson Group is neither authorized nor approved to help clients complete their own SAQ. Hudson is not suggesting that these answers will apply to your specific operation or business. The information contained here should serve primarily as an example of how questions might be answered. If you are unclear on the intent or content of any question on the SAQ, you should not use the example answer provided here.  Do not answer any question on your SAQ until you have a clear understanding of its meaning and intent! Following Hudson’s example answers in no way ensures that your business will be found to be PCI Compliant.

    Section 1 - Firewall, etc.

    Section 2 - System Passwords & Defaults, etc.

    Section 3 - Protecting Stored Cardholder Data

    3.1.1 a)
    3.1.1 b)
    3.1.1 c)
    3.1.1 d)
    3.1.1 e)
    3.2 a) N/A
    3.2 b) For all other entities, if sensitive authentication data is received and deleted, are processes in place to securely delete the data to verify that the data is unrecoverable?  YES
    3.2.1 ) Full contents of any track / magnetic data are not stored: YES
    3.2.2 ) Card Verification Value (CVV) is not stored under any circumstance: YES
    3.2.3 ) The personal identification number (PIN) are not stored under any circumstance:  YES
    3.3 ) Personal Account Number (PAN) is masked when displayed: YES
    3.4 ) PAN rendered unreadable anywhere it is stored: YES
    3.4.1 a) N/A - Disk encryption is not used
    3.4.1 b) N/A - Disk encryption is not used
    3.4.1 c) N/A - Disk encryption is not used
    3.5.1 ) Access to cryptographic keys restricted: YES
    3.5.2 a) Keys stored in encrypted format: YES
    3.5.2 b) Cryptographic keys stored in the fewest locations and forms: YES
    3.6 a) Are key management processes fully documented:  YES
    3.6 b)
    3.6.1 ) Cryptographic key procedure include generation of strong keys: YES
    3.6.2 ) Cryptographic key procedure include secure distribution: YES
    3.6.3 ) Cryptographic key procedure include secure key storage: YES
    3.6.4 )
    3.6.5 a)
    3.6.5 b)
    3.6.5 c)
    3.6.6 )
    3.6.7 ) Procedures prevent unauthorized substitution of cryptographic keys: YES
    3.6.8 )

    Section 4 - Encrypted Transmission of Data

    4.1 a) Strong cryptography and security in place to protect cardholder data over public networks: YES
    4.1 b) Are only trusted keys / certificates accepted: YES
    4.1 c) Security protocols implemented to only support secure configurations: YES
    4.1 d) Proper encryption strength implemented: YES
    4.1 e) SSL/TLS - HTTPS appears in URL on browser: YES
    4.1.1 ) Industry best practices used for strong encryption of authentication & transmission: YES
    4.2 a) Personal Account Numbers (PAN) rendered unreadable / secured: YES
    4.2 b) Policies in place state that unprotected PAN’s are not to be sent via end user messaging: YES

    Section 5 - Use of AntiVirus Software

    The information in Section 5 addresses the use of AntiVirus applications to secure the host network. In this instance, the questions apply to clients using Hudson’s managed hosting service: INetU. Hudson’s hosting service and environment is PCI Compliant.  Hudson works in tandem with INetU to ensure that the following items are all addressed. 
    5.1 ) Antivirus deployed on all systems: YES
    5.1.1 ) AV programs capable of detecting / removing all malicious software: YES
    5.2 a) AV policy requires updating of AV software and definitions: YES
    5.2 b) Master installation of AV software enabled for automatic updates and scans: YES
    5.2 c) Automatic updates and periodic scans are enabled: YES
    5.2 d) AV mechanisms generate audit logs and are retained for at least one year (10.7 a): YES

    Section 6 - Secure Systems and Applications

    This section addresses the software system used to process reservations and process / store credit card data. For most clients this will be the Hudson HGTS suite / system. The items in this section were all addressed by The Hudson Group during its PA-DSS evaluation and review process. All items were required to be compliant before Hudson applications can be determined to be PA-DSS accepted. Background information and documentation is available from Hudson if needed and required. This includes the following documents that might be requested by an authorized Quality Security Assessor (QSA):
    The Hudson Group - Secure Troubleshooting Procedures
    The Hudson Group - Data Encryption Procedures
    The Hudson Group - Vulnerability Management Process
    The Hudson Group - Software Development Procedures
    The Hudson Group - Change Control Procedures
    The Hudson Group - PA-DSS Client Implementation Guide
    Trustwave - The Hudson Group: Report on Validation

    6.1 a) System components and software receive latest vendor-supplied security patches: YES
    6.1 b) Critical security patches are installed within one month of release: YES
    6.2 a) Process in place to identify new security vulnerabilities: YES
    6.3 a) (Hudson) Software practices based on industry standards / best practices: YES
    6.3 b) Information security included throughout the Software Development Life Cycle: YES
    6.3 c) (Hudson) Applications developed in accordance with PCI DSS: YES
    6.3.1) Custom application accounts, ID’s, passwords removed before released to customer: YES
    6.3.2) All custom application code changes reviewed prior to release into production environment: YES
    6.4.1) (Hudson) Development/test environments separate from production environment: YES
    6.4.2) Separation of duties between development staff and production (deployment/Support) staff: YES
    6.4.3) Production data (live PAN’s) NOT used for testing or development: YES
    6.4.4) Test data and accounts removed before production system becomes active: YES
    6.4.5 a) Change control procedures are documented: YES
    6.4.5.1) Documentation of impact: YES
    6.4.5.2) Documnted approval by authorized parties: YES
    6.4.5.3 a) Function tested to verify change does not adversely impact security: YES
    6.4.5.3 b) Code changes / updates tested for PCI compliance before deployed: YES
    6.4.5.4) Back-out procedures available for each change: YES
    6.5 a) (Hudson) Applications developed based on secure coding guidelines: YES
    6.5 b) (Hudson) Developers knowledgeable in secure coding techniques: YES
    6.5.1) Validate input to verify user data cannot modify meaning of commands, queries, etc: YES
    6.5.2) Validate buffer boundaries and truncate input strings: YES
    6.5.3) Prevent cryptographic flaws: YES
    6.5.4) Properly encrypt all authenticated and sensitive communications: YES
    6.5.5) Do not leak information via error messages: YES
    6.5.6) All “High” vulnerabilities identified in the Vulnerability Identification Process (6.2 above): YES
    6.5.7) Validate all parameters before inclusion, utilize context-sensitive escaping, etc: YES
    6.5.8) Properly authenticate users and sanitize input. Do not expose internal object references to users: YES
    6.5.9) Do not reply on authorization credentials and tokens automatically submitted by browsers: YES
    6.6 ) For public facing web applications, new threats addressed on an on-going basis: YES

    Section 7 - Restrict Access

    This section specifically asks Hudson clients to confirm or affirm that they adhere to at least the MINIMUM PCI standards regarding login procedures when using the HGTS suite. Before answering these questions, and assuming that your procedures meet the minimum PCI standards, you should review the appropriate section(s) of the Hudson PA-DSS Client Implementation Guide.

    7.1.1) Access rights to cardholder data restricted to those whose job function requires: YES
    7.1.2) Privileges assigned to individuals are based on job classification and function: YES
    7.1.3) Documented approval by authorized parties is required for access to cardholder data: YES
    7.1.4) Access controls are implemented via an automated access control system (Hudson application): YES
    7.2.1) Access control systems are in place on all system components (Agent, Dispatcher, Admin): YES
    7.2.2) Access control systems configured to enforce privileges based on job classification and function: YES
    7.2.3) Do access control systems have a default “deny-all” setting: YES

    Section 8 - Unique ID’s

    You should have a data security and retention policy in place in your business. As requested in other parts of the SAQ, this policy should also address user logins and restricted access. While Hudson deploys new clients (Spring 2012 forward) with minimum PCI standards configured and in place, it is still incumbent upon you and your internal system administrator to ensure that the following items are all addressed.  Just because you use the Hudson HGTS PA-DSS accepted version of the system does not necessarily mean that all of these items are addressed. You must be vigilant in maintaining user accounts and access to cardholder data.  If you do these items, then most of the example answers below will apply to your organization as well.

    8.1 ) All users assigned a unique ID before allowing them access to HGTS and cardholder data: YES
    8.2 ) In addition to a unique ID, you also use: password, token or biometric: YES
    8.3 )
    8.4 a) All passwords rendered unreadable during transmission and storage: YES
    8.4 b) For Service Providers: Are customer passwords encrypted: YES
    8.5.1) Additions, deletion, and modification of ID’s is controlled: YES
    8.5.2) User identity verified before performing password resets via non, face-to-face requests: YES
    8.5.3) First time and password reset requests are set to immediately expire on first use: YES
    8.5.4) Access for any terminated users is immediately deactivated or removed: YES
    8.5.5) Inactive user accounts over 90 days old removed or disabled: YES
    8.5.6 a)
    8.5.6 b)
    8.5.7) Authentication procedures and policies communicated to users with access to cardholder data: YES
    8.5.8) Group, shared or generic accounts and passwords are prohibited: YES
    8.5.9 a) User passwords are changed at least every 90 days: YES
    8.5.9 b)
    8.5.10 a) Minimum password length of at least seven characters is required: YES
    8.5.10 b)
    8.5.11 a) Passwords must contain both numeric and alphabetic characters: YES
    8.5.11 b)
    8.5.12 a) New passwords must be different from any of the last four passwords used: YES
    8.5.12 b)
    8.5.13 a) Repeated access attempts result in locking of account after max of 6 failures: YES
    8.5.13 b)
    8.5.14) Locked accounts remain locked for minimum of 30 minutes or until administrator unlocks: YES
    8.5.15) Session is idle for more than 15 minutes forces users to re-authenticate: YES (NOTE: Hudson hosted Windows RDP terminal sessions time-out after a period of 15 minutes of activity. User must reauthenticate in order to be connected to their Hudson application session.)
    8.5.16 a) All access to any database containing cardholder data is authenticated: YES
    8.5.16 b) User access to actions and queries on the database is only through the (HGTS) application: YES
    8.5.16 c) User direct access to database restricted to database administrators: YES
    8.5.16 d) Application ID’s with database access only able to be used by the application: YES

    Section 9 - Physical Access to Cardholder Data

    This section addresses physical access to the server hardware and infrastructure where cardholder data is stored. PCI compliance requires this access to be limited and strictly monitored. If you host the HGTS system in your own facility, then you should not use the sample answers provided here. You need to review these questions against your current networking infrastructure. The sample answers to the questions below would be appropriate for Hudson clients using the managed hosting services (cloud computing) options offered by Hudson. INetU is Hudson’s managed hosting provider and is responsible for administering most of these items on behalf of Hudson and Hudson hosted clients.  NOTE: Hudson staff do not have any physical access to client server infrastructure where cardholder data is stored.

    9.1 ) Facility entry controls to limit and monitor physical access to the cardholder data environment: YES
    9.1.1 a) Video cameras and / or access control systems to monitor physical access: YES
    9.1.1 b) Video cameras and / or control mechanisms protected from tampering or disabling: YES
    9.1.1 c) Data collected from video, etc. reviewed and stored for at least 3 months: YES
    9.1.2) Physical access to public network jacks restricted: YES
    9.1.3) Physical access to wireless access, gateways, etc. restricted: YES
    9.2 a) Processes for assigning badges to onsite personnel: YES
    9.2 b) Access to badge system limited to authorized personnel: YES
    9.2 c) Badges clearly identify visitors vs onsite personnel: YES
    9.3.1) Visitors authorized before entering where cardholder data processed / maintained: YES
    9.3.2 a) Visitors given a physical token that identifies them as NOT onsite personnel: YES
    9.3.2 b) Visitor badges expire: YES
    9.3.3) Visitors asked to surrender token before leaving / upon expiration: YES
    9.4 a) Visitor log used to record physical access where cardholder data stored / transmitted: YES
    9.4 b) Visitor log contains: name, firm, onsite host, and log retained for at least 3 months: YES
    9.5 a) Media backups stored in secure location - preferably off-site: YES
    9.5 b) Location’s security reviewed at least annually: YES
    9.6 ) All media physically secured: YES
    9.7 a) Strict control maintained over internal / external distribution of any media: YES
    9.7.1) Media is classified so sensitivity can be determined: YES
    9.7.2) Media sent by secured courier or other method can be tracked: YES
    9.8 ) Logs maintained to track all media moved from secured area showing management approval: YES
    9.9 ) Is strict control maintained over the storage and accessibility of media: YES
    9.9.1) Inventory logs of all media properly maintained and inventories conducted at least annually: YES
    9.10 ) Media destroyed when no longer needed for business / legal reasons: YES
    9.10.1 a) Hardcopy media cross-cut shredded, incinerated, or pulped so cardholder data is destroyed: YES
    9.10.1 b) Containers holding data to be destroyed are secured to prevent access: YES
    9.10.2) Cardholder data on electronic media rendered unrecoverable via secure wipe or physical destruction: YES

     

    Section 10 - Tracking and Monitoring Access to Cardholder Data

    This section applies to the Hudson managed hosting environment and addresses access to system components and resources.  Any clients that are using their own premise-based installations of the HGTS system should not use these example replies as they may not apply to their system access controls, logging, etc.

    10.1 ) Process in place to link all access to system components to each individual user: YES
    10.2.1) All individual user access to cardholder data: YES
    10.2.2) All action taken by any individual with root or administrative privileges: YES
    10.2.3) Access to all audit trails: YES
    10.2.4) Invalid logical access attempts: YES
    10.2.5) Use of identification and authentication mechanisms: YES
    10.2.6) Initialization of audit logs: YES
    10.2.7) Creation and deletion of system-level object: YES
    10.3.1) User Identification: YES
    10.3.2) Type of event: YES
    10.3.3) Date and Time: YES
    10.3.4) Success or failure: YES
    10.3.5) Origination of event: YES
    10.3.6) Identify or name of affected data, system component or resource: YES
    10.4 a) Critical system clocks synchronized via time synchronization technology: YES
    10.4.1 a) Designated central time servers receive time signals and all maintain correct time: YES
    10.4.1 b) Central time servers peer with each other: YES
    10.4.2 a) Access to time data restricted to personnel with a business need: YES
    10.4.2 b) Changes to time settings on critical systems logged and reviewed: YES
    10.4.3) Time settings received from specific industry accepted sources: YES
    10.5.1) Viewing of audit trails limited to those with job-related need: YES
    10.5.2) Audit trail files protected from unauthorized modifications: YES
    10.5.3) Audit trail files backed up to centralized log server or other media: YES
    10.5.4) External facing logs offloaded / copied to centralized log server or LAN media: YES
    10.5.5) File integrity monitoring or change-detection used: YES
    10.6 ) Logs for all system components reviewed at least daily: YES
    10.7 a) Audit log retention policy and procedures in place, retained for at least one year: YES
    10.7 b) Audit logs available for at least 1 year and can restore last 3 months immediately: YES

    Section 11 - Regular Testing of Security Systems and Processes

    11.1 a) Documented process in place to detect and identify wireless access points quarterly: YES
    11.1 b) Methodology identifies unauthorized wireless access points: YES
    11.1 c) Process of identifying performed at least quarterly: YES
    11.1 d) If automated monitoring in place, will generate alerts: YES
    11.1 e) Incident Response Plan (12.9) includes response for unauthorized wireless devices detected: YES
    11.2.1 a) Quarterly internal vulnerability scans performed: YES
    11.2.1 b) Quarterly internal scan process continues until passing results obtained: YES
    11.2.1 c) Quarterly internal scans performed by qualified individual or 3rd party: YES
    11.2.2 a) Quarterly external vulnerability scans performed: YES
    11.2.2 b) Quarterly external scans results satisfy teh ASV Program Guide requirements: YES
    11.2.2 c) Quarterly external scans performed by Approved Scanning Vendor: YES
    11.2.3 a) Internal & External scans performed after any significant network change: YES
    11.2.3 b) Internal & external scans completed until passing results obtained: YES
    11.2.3 c) Scans performed by a qualified individual or 3rd party: YES
    11.3 a) External & internal penetration testing performed at least once per year / after changes: YES
    11.3 b) Noted exploitable vulnerabilities corrected and testing repeated: YES
    11.3 c) Tests performed by a qualified individual or 3rd party: YES
    11.3.1) Network-layer penetration tests performed: YES
    11.3.2) Application-layer penetration tests performed (includes items in 6.5): YES
    11.4 a) Intrusion detection/prevention systems monitor traffic at / inside cardholder data environment: Yes
    11.4 b) ID’s and/or IPS configured to alert personnel of suspected compromises: YES
    11.4 c) Intrusion detection / prevention engines and signatures kept up to date: YES
    11.5 a) File integrity monitoring deployed within cardholder data environment: YES
    11.5 b) Tools configured to alert personnel, and perform critical comparisons at least weekly: YES

    Section 12 - Information Security Policy

    Attestation of Compliance, SAQ-D, Service Provider Version

    Once you have answered all the SAQ questions, you will need to complete and attach or submit an Attestation of Compliance.  This section should help you select the most appropriate answers on this form:

    Part 2:  PCI DSS Assessment Information
    Part 2a: Services Provided that were included in the scope:  Merchant Services
    Part 2d: How does your business process and or transmit cardholder data:
      Payment Application:  HGTS by The Hudson Group\
      Version Number:  (Current Version)
      Last Validated according to PA-DSS: HGTS v 1.94: December 2012

    Categories: