Information Security Programs - PowerPoint PPT Presentation


Title: Information Security Programs


1
UMASS PCI DSS Compliance Training
Payment Card Industry Data Security Standard (PCI
DSS) Training Program
Version 4 Larry Wilson October, 2013
1
2
PCI DSS Training Course
Contents
  • Module 1
  • PCI DSS Introduction
  • Payment Industry Terminology
  • Payment Transaction Flow
  • Service Provider Relationships
  • Module 2
  • Payment Brand Compliance Programs
  • SAQ Overview
  • PA-DSS Overview
  • PCI Roles and Responsibilities
  • Module 3
  • Cardholder Data Discovery
  • Network Segmentation
  • Scoping the Cardholder Data Environment

3
Module 1
Module 1 Objectives
  • After completing this module you will be able to
  • Understand the importance of PCI DSS compliance
  • Describe the role of the Payment Card Industry
    Security Standards Council (PCI SSC)
  • Outline the Payment Card Industry Security
    Standards
  • Describe the benefits of PCI DSS training
  • Discuss myths of PCI DSS
  • Define Payment Card Industry Terminology
  • Define card processing Authorization, Clearing
    and Settlement
  • Define service provider relationships
  • Discuss transaction types card Not Present and
    Card Present
  • Describe credit card security
  • Compliance with PCI DSS
  • There are three things to understand about PCI
    DSS
  • Standards are not optional
  • If you accept payment cards on campus, you are
    subject to the standards
  • There are significant financial costs to
    non-compliance.
  • Failure to comply with PCI DSS can result in
    stiff contractual penalties or sanctions from
    members of the payment card industry including
  • Fines of 500,000 per data security incident
  • Fines of 50,000 per day for non-compliance with
    published standards
  • Liability for all fraud losses incurred from
    compromised account numbers
  • Liability for the cost of re-issuing cards
    associated with the compromise
  • Suspension of merchant accounts
  • Non compliance is not worth the risk.
  • It only takes one incident of data compromise to
    put the university at risk

4
Module 1
PCI DSS Introduction
  • What is PCI SSC?
  • PCI Security Standards Council (PCI SSC) was
    created in 2006 as an independent standards body
    to provide oversight f the development and
    management of payment Card Industry Security
    Standards on a global basis
  • Created to align security programs of MasterCard
    and Visa
  • Later was adopted by other major card programs
  • Founding members of the council included American
    Express, Discover, JCB, MasterCard Worldwide, and
    Visa International.
  • Resources Provided by the Council
  • PCI DSS, PCI PTS, PCI PA-DSS, P2PE, PIN Security
    and supporting documents
  • Roster of QSAs (Qualified Security Assessors),
    ASVs (Approved Scanning Vendors), validated
    payment applications, PTS Devices, and P2PE
    solutions
  • PCI Security Standards Council FAQs
  • Education and Outreach Programs
  • Participating Organization Membership, Meetings,
    Feedback
  • PCI Standards
  • PCI DSS covers security of the environments that
    store, process or transmit account data
  • PCI PTS covers tamper detection, cryptographic
    processes, and other mechanisms used to protect
    the PIN
  • PCI PA-DSS covers secure payment applications to
    support PCI DSS compliance
  • PCI PTS covers tamper detection, cryptographic
    processes, and other mechanisms used to protect
    the PIN
  • PCI P2PE covers encryption, decryption and key
    management within secure cryptographic devices
  • PCI PIN Security covers secure management,
    processing and transmission of personal
    identification number (PIN) data during online
    and offline payment card transaction processing

5
Module 1
PCI DSS Introduction
  • Who does PCI DSS apply to?
  • UMASS Merchants must be PCI DSS compliant and are
    responsible for ensuring their compliance
  • The program applies to all payment channels,
    including in person (Point of Sale), mail /
    telephone order and/or e-commerce.
  • The training is applicable to all campus
    personnel who have access to credit card
    information, as a processor of credit card
    transactions or as a reviewer of reports that
    contain credit card data
  • How does it work?
  • University Merchants and Service Providers must
    adhere to PCI DSS
  • A single approach to safeguard sensitive data for
    all card brands
  • Compliance validation ensures appropriate levels
    of cardholder data security are maintained
  • Why is this important?
  • This training provides knowledge and skills
    necessary to ensure credit card security at the
    university
  • Everyone, not just the credit card companies,
    benefits from the effective application of credit
    card security measures
  • Benefits of PCI DSS Training
  • Our Customers
  • Appreciate your ability to reduce the threat of
    identity theft
  • Trust you to complete transactions without
    duplicate or invalid charges
  • Enjoy peace of mind, knowing that their credit
    card information is in good hands
  • The University
  • Takes pride in a skilled workforce
  • Values your ability to build customer confidence
  • Needs your help in limiting potential losses,
    fines and penalties
  • and You
  • Have confidence in your ability to safely and
    efficiently do your job
  • Are alert to the warning signs of fraud
  • Know you can make informed decisions under
    pressure

6
Module 1
Myths of PCI DSS
  • Myth 6 PCI requires us to hire a Qualified
    Security Assessor
  • PCI DSS provides the option of doing an internal
    assessment with an officer sign-off if acquirer
    and/or merchant bank agree
  • Note The Commonwealth of Massachusetts
    Controllers office requires the University to
    hire a QSA to conduct an independent assessment
    on an annual basis.
  • Myth 7 We dont take enough credit cards to be
    compliant
  • PCI compliance is required for any business that
    accepts payment cards even if the quantity of
    transactions is just one
  • Myth 8 We completed a SAQ so were compliant
  • Technically, this is true for merchants who are
    not required to do on-site assessments for PCI
    DSS compliance. True security of cardholder data
    requires non-stop assessment and remediation to
    ensure that likelihood of a breach is kept as low
    as possible.
  • Myth 9 PCI makes us store cardholder data
  • Both PCI DSS and the payment card brands strongly
    discourage storage of cardholder data by
    merchants and processors
  • Myth 10 PCI is too hard
  • Understanding PCI DSS can seem daunting,
    especially for merchants without security or a
    large IT department.
  • However, PCI DSS mostly calls for good, basic
    security
  • Myth 1 One vendor and product will make us
    compliant
  • No single vendor or product fully addresses all
    12 requirements of PCI DSS.
  • Myth 2 Outsourcing card processing makes us
    compliant
  • Outsourcing simplifies but does not provide
    automatic compliance
  • We must ensure providers comply with PCI
    standards
  • Request a certificate of compliance annually from
    providers.
  • Myth 3 PCI compliance is an IT project
  • The IT staff implements technical and operational
    aspects
  • PCI compliance is an ongoing process of
    assessment, remediation, reporting
  • Myth 4 PCI will make us secure
  • Successful completion of a scan or assessment is
    a snapshot in time
  • Security exploits are non-stop and get stronger
    every day
  • PCI compliance efforts are a continuous process
    of assessment and remediation to ensure safety of
    cardholder data.
  • Myth 5 PCI is unreasonable it requires too
    much
  • Most aspects of PCI DSS are a common best
    practice for security

7
Module 1
Payment Industry Terminology
  • Payment Brand Compliance Programs
  • Tracking and enforcement
  • Penalties, fees, compliance deadlines
  • Validation process and who needs to validate
  • Approval and posting of compliant entities
  • Definition of merchants and service provider
    levels
  • Forensics and response to account data
    compromises
  • Common Acquirer Responsibilities
  • Acquirer is responsible for merchant compliance
  • Ensure that their merchants understand PCI DSS
    compliance requirements and track compliance
    efforts
  • Manage merchant communications
  • Work with merchants until full compliance has
    been validated
  • Merchants are not compliant until all
    requirements have been met and validated
  • Acquirer is responsible for providing merchant
    compliance status to payment brands
  • Incur any liability that may result from
    non-compliance with payment brand compliance
    programs
  • Cardholder
  • Customer purchasing goods as either a Card
    Present or card Not Present transaction
  • Receives the payment card and bills from the
    issuer
  • Issuer
  • Bank or other organization issuing a payment card
    on behalf of a Payment Brand (e.g. MasterCard
    Visa)
  • Payment Brand issuing a payment card directly
    (e.g. Amex, Discover, JCB)
  • Merchant
  • Organization accepting the payment card for
    payment during a purchase
  • Acquirer
  • Bank or entity the merchant uses to process their
    payment card transactions
  • Receive authorization request from merchant and
    forward to Issuer for approval
  • Provide authorization, clearing and settlement
    services to merchant
  • Payment Brand
  • Include American Express, Discover, JCB,
    MasterCard Worldwide, and Visa International
  • Each payment brand develops and maintains its own
    PCI DSS compliance program in accordance with its
    own security risk management policies

8
Module 1
Credit Card Processing
  • Authorization (time of purchase)
  • Every request receives a response that directs
    the acquirer or the merchant on how to proceed
    with the transaction (Approve or Deny)
  • Clearing (within one day)
  • Involves daily processing and routing of
    financial transactions between card brands,
    acquirers and issuers
  • Settlement (within two days)
  • Involves funds transfer for the purpose of the
    financial settlement of clearing transactions,
    fees, and other transfer of funds between card
    brands, acquirers and issuers.

9
Module 1
How Payment Processing Works (Technical Process)
10
Module 1
Service Providers
  • Service Providers
  • A service provider is a business entity directly
    involved with the processing, storage,
    transmission, or switching of transaction data
    and cardholder data.
  • Service providers include companies that provide
    services which control or could impact the
    security of cardholder data.
  • Service provider examples
  • Transaction processors
  • Payment Gateways
  • Independent sales Organizations (ISOs)
  • External Sales Organizations (ESOs)
  • Customer Service functions
  • Remittance processing companies
  • Managed firewall and Intrusion Detection Service
    (I DS) service providers
  • Web Hosting and Data Center Hosting providers

Payment Gateways This diagram illustrates how
real-time, electronic credit card processing
works using CyberSource Payment Services.
  1. Purchaser places order
  2. Merchant securely transfers order information to
    CyberSource over the Internet. CyberSource
    receives order information and performs requested
    services
  3. CyberSource formats the transaction detail
    appropriately and securely routes the transaction
    authorization request through its payment gateway
    to the processor.
  4. The transaction is then routed to the issuing
    bank (purchaser's bank) to request transaction
    authorization
  5. The transaction is authorized or declined by the
    issuing bank or card (Discover, American
    Express).
  6. CyberSource returns the message to the merchant.
  7. Issuing bank approves transfer of money to
    acquiring bank
  8. The acquiring bank credits the merchant's account

11
Module 1
Transaction Types Card Security
Credit Card Security
Merchant Configurations Card Not Present
Transactions Card Not Present Transaction
- the credit card information is keyed into a
credit card processing system (credit card
terminal, software program, or payment gateway)
without the credit card or customer present at
the time of the sale. Card Present
Transactions Card Present Transaction
(Point of Sale) - the customer and credit card
are present at the point of sale. The card is
swiped through a credit card processing system
(credit card terminal, POS system or card reader)
that obtains the card holder's information by
reading the magnetic stripe on the back of the
card.
Internet Connected Terminal
Dial-up Terminal
Wireless Terminal
Tap Go Wireless Terminal
Imprint Machine
12
Module 2
Module 2 Objectives
  • After completing this module you will be able to
  • Understand the PCI DSS Standards Framework
  • Understand Merchant Compliance Requirements
  • Describe the Self Assessment Questionnaire (SAQ)
  • Understand SAQ Instructions and Guidelines
  • Describe the three step PCI DSS Compliance
    Approach
  • Understand Merchant and Service Provider
    Compliance Levels
  • Understand Merchant and Service Provider
    Compliance Validation
  • Understand Payment Application data Security
    Standard (PA-DSS)
  • Understand PCI Roles and Responsibilities

PCI DSS Standards Framework
PCI DSS Requirements Validated by Self or Outside Assessment
Build and maintain a secure network 1.Install and maintain a firewall configuration to protect cardholder data 2.Do not use vendor-supplied defaults for system passwords and other security parameters
Protect cardholder data 3. Protect sensitive data 4. Encrypt transmission of cardholder data across open, public networks
Maintain a vulnerability management program 5 Use and regularly update anti-virus software 6. Develop and maintain secure systems and applications
Implement strong access control measures 7 Restrict access to cardholder data by business need-to-know 8. Assign a unique ID to each person with computer access 9. Restrict physical access to cardholder data
Regularly monitor and test networks 10. Track and monitor all access to network resources and cardholder data 11. Regularly test security systems and processes
Maintain an Information Security Policy 12. Maintain a policy that addresses Information security
13
Module 2
PCI DSS Standards Requirements
  • Requirement 2 Do not use vendor-supplied
    defaults for system passwords and other security
    parameters
  • Malicious individuals (external and internal to
    an entity) often use vendor default passwords and
    other vendor default settings to compromise
    systems. These passwords and settings are well
    known by hacker communities and are easily
    determined via public information.
  • Requirement 3 Protect stored cardholder data
  • Protection methods such as encryption,
    truncation, masking, and hashing are critical
    components of cardholder data protection. If an
    intruder circumvents other security controls and
    gains access to encrypted data, without the
    proper cryptographic keys, the data is unreadable
    and unusable to that person. Other effective
    methods of protecting stored data should be
    considered as potential risk mitigation
    opportunities. For example, methods for
    minimizing risk include not storing cardholder
    data unless absolutely necessary, truncating
    cardholder data if full PAN is not needed, and
    not sending unprotected PANs using end-user
    messaging technologies, such as e-mail and
    instant messaging.
  • Requirement 4 Encrypt transmission of cardholder
    data across open, public networks
  • Sensitive information must be encrypted during
    transmission over networks that are easily
    accessed by malicious individuals. Misconfigured
    wireless networks and vulnerabilities in legacy
    encryption and authentication protocols continue
    to be targets of malicious individuals who
    exploit these vulnerabilities to gain privileged
    access to cardholder data environments.
  • Requirement 1 Install and maintain a firewall
    configuration to protect cardholder data
  • Firewalls are devices that control computer
    traffic allowed between an entitys networks
    (internal) and untrusted networks (external), as
    well as traffic into and out of more sensitive
    areas within an entitys internal trusted
    networks. The cardholder data environment is an
    example of a more sensitive area within an
    entitys trusted network.
  • A firewall examines all network traffic and
    blocks those transmissions that do not meet the
    specified security criteria.
  • All systems must be protected from unauthorized
    access from untrusted networks, whether entering
    the system via the Internet as e-commerce,
    employee Internet access through desktop
    browsers, employee e-mail access, dedicated
    connections such as business-to-business
    connections, via wireless networks, or via other
    sources. Often, seemingly insignificant paths to
    and from untrusted networks can provide
    unprotected pathways into key systems. Firewalls
    are a key protection mechanism for any computer
    network.
  • Other system components may provide firewall
    functionality, provided they meet the minimum
    requirements for firewalls as provided in
    Requirement 1. Where other system components are
    used within the cardholder data environment to
    provide firewall functionality, these devices
    must be included within the scope and assessment
    of Requirement 1.


14
Module 2
PCI DSS Standards Requirements
  • Requirement 8 Assign a unique ID to each person
    with computer access
  • Assigning a unique identification (ID) to each
    person with access ensures that each individual
    is uniquely accountable for his or her actions.
    When such accountability is in place, actions
    taken on critical data and systems are performed
    by, and can be traced to, known and authorized
    users.
  • Requirement 9 Restrict physical access to
    cardholder data
  • Any physical access to data or systems that house
    cardholder data provides the opportunity for
    individuals to access devices or data and to
    remove systems or hardcopies, and should be
    appropriately restricted. For the purposes of
    Requirement 9, ?onsite personnel? refers to
    full-time and part-time employees, temporary
    employees, contractors and consultants who are
    physically present on the entitys premises. A
    ?visitor? refers to a vendor, guest of any onsite
    personnel, service workers, or anyone who needs
    to enter the facility for a short duration,
    usually not more than one day. ?Media? refers to
    all paper and electronic media containing
    cardholder data.
  • Requirement 10 Track and monitor all access to
    network resources and cardholder data
  • Logging mechanisms and the ability to track user
    activities are critical in preventing, detecting,
    or minimizing the impact of a data compromise.
    The presence of logs in all environments allows
    thorough tracking, alerting, and analysis when
    something does go wrong. Determining the cause of
    a compromise is very difficult, if not
    impossible, without system activity logs.
  • Requirement 5 Use and regularly update
    anti-virus software or programs
  • Malicious software, commonly referred to as
    ?malware?including viruses, worms, and
    Trojansenters the network during many
    business-approved activities including employee
    e-mail and use of the Internet, mobile computers,
    and storage devices, resulting in the
    exploitation of system vulnerabilities.
    Anti-virus software must be used on all systems
    commonly affected by malware to protect systems
    from current and evolving malicious software
    threats.
  • Requirement 6 Develop and maintain secure
    systems and applications
  • Unscrupulous individuals use security
    vulnerabilities to gain privileged access to
    systems. Many of these vulnerabilities are fixed
    by vendor-provided security patches, which must
    be installed by the entities that manage the
    systems. All critical systems must have the most
    recently released, appropriate software patches
    to protect against exploitation and compromise of
    cardholder data by malicious individuals and
    malicious software.
  • Requirement 7 Restrict access to cardholder data
    by business need to know
  • To ensure critical data can only be accessed by
    authorized personnel, systems and processes must
    be in place to limit access based on need to know
    and according to job responsibilities.


15
Module 2
PCI DSS Standards Requirements
  • Compliance with PCI DSS
  • Required by all entities that store, process,
    transmit cardholder information
  • PCI Compliant requires an entity to comply with
    all PCI DSS requirements
  • PCI DSS compliance is dependent on
  • Merchant or service provider level
  • Payment brand compliance validation and reporting
    requirements
  • University requirements for compliance
  • Non compliance can result in fines levied by
    credit card companies against merchants,
    processors and acquiring banks
  • Merchant Compliance Requirements
  • Understand the PCI DSS standards and compliance
    requirements
  • Sufficient technical knowledge in the security
    domains covered by PCI DSS
  • Understand credit card business processes and
    data flows
  • Identify systems and processes subject to PCI DSS
    assessments
  • Comply with requirements of the PCI DSS standards
  • Understand and comply with University e-commerce
    standards
  • Complete PCI DSS self-assessment and remediate
    gaps found
  • Acquiring Banks Compliance Requirements (Vantiv)
  • Requirement 11 Regularly test security systems
    and processes.
  • Vulnerabilities are being discovered continually
    by malicious individuals and researchers, and
    being introduced by new software. System
    components, processes, and custom software should
    be tested frequently to ensure security controls
    continue to reflect a changing environment.
  • Requirement 12 Maintain a policy that addresses
    information security for all personnel.
  • A strong security policy sets the security tone
    for the whole entity and informs personnel what
    is expected of them. All personnel should be
    aware of the sensitivity of data and their
    responsibilities for protecting it. For the
    purposes of Requirement 12, ?personnel? refers to
    full-time and part-time employees, temporary
    employees, contractors and consultants who are
    ?resident? on the entitys site or otherwise have
    access to the cardholder data environment.


16
Module 2
PCI DSS Standards Framework
SAQ A Card Not Present All Cardholder Data
Functions Outsourced
The Self-Assessment Questionnaire (SAQ) The
SAQ is a self-validation tool for merchants and
service providers who are not required to do
on-site assessments for PCI DSS compliance. The
SAQ includes a series of yes-or-no questions for
compliance. If an answer is no, the university
must state the future remediation date and
associated actions.
  • SAQ A has been developed to address requirements
    applicable to merchants who retain only paper
    reports or receipts with cardholder data, do not
    store cardholder data in electronic format and do
    not process or transmit any cardholder data on
    their systems or premises.
  • SAQ A merchants do not store cardholder data in
    electronic format, do not process or transmit any
    cardholder data on their systems or premises, and
    validate compliance by completing SAQ A and the
    associated Attestation of Compliance, confirming
    that
  • Your company accepts only card-not-present
    (e-commerce or mail/telephone-order)
    transactions
  • Your company does not store, process, or
    transmit any cardholder data on your systems or
    premises, but relies entirely on a third party(s)
    to handle all these functions
  • Your company has confirmed that the third
    party(s) handling storage, processing, and/or
    transmission of cardholder data is PCI DSS
    compliant
  • Your company retains only paper reports or
    receipts with cardholder data, and these
    documents are not received electronically and
  • Your company does not store any cardholder data
    in electronic format.
  • SAQ A includes 13 questions.

SAQ Description
A Card not present (e-commerce or mail / telephone order) merchants, all cardholder data functions outsources. This would never apply to face to face merchants.
B Imprint-only merchants with no electronic cardholder data storage, or standalone, dial out terminal merchants with no electronic cardholder data storage
C-VT Merchants using only web-based virtual terminals, no electronic cardholder data storage
C Merchants with payment application systems connected to the Internet, no electronic cardholder data storage
D All other merchants not included in descriptions for SAQ A through C above, and all service providers defined by a payment brand as eligible to complete an SAQ.
17
Module 2
Self-Assessment Questionnaire (SAQ)
  • SAQ B has been developed to address requirements
    applicable to merchants who process cardholder
    data only via imprint machines or standalone,
    dial-out terminals.
  • SAQ B merchants only process cardholder data via
    imprint machines or via standalone, dial-out
    terminals, and may be either brick-and-mortar
    (card-present) or e-commerce or mail/telephone
    order (card-not-present) merchants. Such
    merchants validate compliance by completing SAQ B
    and the associated Attestation of Compliance,
    confirming that
  • Your company uses only an imprint machine and/or
    uses only standalone, dial-out terminals
    (connected via a phone line to your processor) to
    take your customers payment card information
  • The standalone, dial-out terminals are not
    connected to any other systems within your
    environment
  • The standalone, dial-out terminals are not
    connected to the Internet
  • Your company does not transmit cardholder data
    over a network (either an internal network or the
    Internet)
  • Your company retains only paper reports or paper
    copies of receipts with cardholder data, and
    these documents are not received electronically
    and
  • Your company does not store cardholder data in
    electronic format.
  • SAQ B includes 29 questions.

SAQ B Merchants with Only Imprint Machines or
Only Standalone, Dial-Out Terminals. No
Electronic Cardholder Data Storage.
  • SAQ C-VT
  • Merchants with Web-Based Virtual Terminals, No
    Electronic Cardholder Data Storage
  • SAQ C-VT has been developed to address
    requirements applicable to merchants who process
    cardholder data only via isolated virtual
    terminals on personal computers connected to the
    Internet.
  • This SAQ option is intended to apply only to
    merchants who manually enter a single transaction
    at a time via a keyboard into an Internet-based
    virtual terminal solution. SAQ C-VT merchants
    process cardholder data via virtual terminals on
    personal computers connected to the Internet, do
    not store cardholder data on any computer system,
    and may be brick-and-mortar (card-present) or
    mail/telephone-order (card-not-present)
    merchants.
  • Such merchants validate compliance by completing
    SAQ C-VT and the associated Attestation of
    Compliance, confirming that
  • Your companys only payment processing is done
    via a virtual terminal accessed by an Internet
    connected web browser
  • Your companys virtual terminal solution is
    provided and hosted by a PCI DSS validated third
    party service provider
  • Your company accesses the PCI DSS compliant
    virtual terminal solution via a computer that is
    isolated in a single location, and is not
    connected to other locations or systems within
    your environment (this can be achieved via a
    firewall or network segmentation to isolate the
    computer from other systems)
  • Your companys computer does not have software
    installed that causes cardholder data to be
    stored (for example, there is no software for
    batch processing or store-and-forward)
  • Your companys computer does not have any
    attached hardware devices that are used to
    capture or store cardholder data (for example,
    there are no card readers attached)
  • Your company does not otherwise receive or
    transmit cardholder data electronically through
    any channels (for example, via an internal
    network or the Internet)
  • Your company retains only paper reports or paper
    copies of receipts and
  • Your company does not store cardholder data in
    electronic format.
  • SAQ C-VT includes 51 questions.

18
Module 2
Self-Assessment Questionnaire (SAQ)
  • SAQ C
  • Merchants with Payment Application Systems
    Connected to the Internet, No Electronic
    Cardholder Data Storage
  • SAQ C has been developed to address requirements
    applicable to merchants whose payment application
    systems (for example, point-of-sale systems) are
    connected to the Internet (for example, via DSL,
    cable modem, etc.) either because
  • 1. The payment application system is on a
    personal computer that is connected to the
    Internet (for example, for e-mail or web
    browsing), or
  • 2. The payment application system is connected to
    the Internet to transmit cardholder data.
  • SAQ C merchants process cardholder data via POS
    machines or other payment application systems
    connected to the Internet, do not store
    cardholder data on any computer system, and may
    be either brick-and-mortar (card-present) or
    e-commerce or mail/telephone-order
    (card-not-present) merchants.
  • SAQ C merchants validate compliance by completing
    SAQ C and the associated Attestation of
    Compliance, confirming that
  • Your company has a payment application system and
    an Internet connection on the same device and/or
    same local area network (LAN)
  • The payment application system/Internet device is
    not connected to any other systems within your
    environment (this can be achieved via network
    segmentation to isolate payment application
    system/Internet device from all other systems)
  • Your company store is not connected to other
    store locations, and any LAN is for a single
    store only
  • Your company retains only paper reports or paper
    copies of receipts
  • Your company does not store cardholder data in
    electronic format and
  • Your companys payment application software
    vendor uses secure techniques to provide remote
    support to your payment application system.
  • SAQ C includes 40 questions.

SAQ D All Other Merchants and All Service
Providers Defined by a Payment Brand as Eligible
to Complete an SAQ SAQ D has been developed for
all service providers defined by a payment brand
as eligible to complete an SAQ, as well as
SAQ-eligible merchants who do not meet the
descriptions of SAQ types A through C,
above. SAQ D service providers and merchants
validate compliance by completing SAQ D and the
associated Attestation of Compliance. While many
of the organizations completing SAQ D will need
to validate compliance with every PCI DSS
requirement, some organizations with very
specific business models may find that some
requirements do not apply. For example, a
company that does not use wireless technology in
any capacity would not be expected to validate
compliance with the sections of the PCI DSS that
are specific to managing wireless technology.
SAQ D includes 288 questions.
19
Module 2
SAQ Instructions and Guidelines
20
Module 2
PCI DSS Compliance Approach
  • Step 1 Assess
  • Goal Identify technology and process
    vulnerabilities posing a security risk of
    cardholder data transmitted, processed or stored
    by the university.
  • Step 1.1 - Study PCI DSS Standard - Learn what
    the standard requires of the business
  • Step 1.2 - Inventory IT Assets and Processes
  • Identify systems, personnel, processes involved
    in transmission, processing, storing cardholder
    data.
  • Determine how cardholder data flows from
    beginning to end of the transaction process.
  • Check versions of personal identification number
    (PIN) entry terminals and software to ensure they
    are PCI compliant.
  • Step 1.3 - Find Vulnerabilities - Use the
    appropriate SAQ to guide the assessment, and
    technologies to locate insecure systems
  • Step 1.4 - Validate with Third-Party Experts -
    May require a Qualified Security Assessor (QSA)
    and/or Approved Scanning Vendor (ASV) to execute
    proper assessment.
  • Note Liability for PCI compliance extends to
    third parties involved with the process flow, so
    we must confirm that they are compliant.
  • Step 2 Remediate
  • Goal Remediation is the process of fixing
    vulnerabilities including technical flaws in
    software code or unsafe practices in how the
    university processes or stores cardholder data.
  • Step 2.1 - Scan your network with software tools
    that analyze infrastructure and spot known
    vulnerabilities
  • Step 2.2 - Review and remediate vulnerabilities
    found during on-site assessment (if applicable)
    or through the Self-Assessment Questionnaire
    (SAQ) process
  • Step 2.3 - Classify and rank the vulnerabilities
    to help prioritize the order of remediation, from
    most serious to least serious
  • Step 2.4 - Apply patches, fixes, and changes to
    unsafe processes and workflow
  • Step 2.5 - Re-scan to verify that remediation
    actually occurred
  • Note Remediation should occur as soon as
    practical when a vulnerability is discovered via
    the Assessment process (Step 1).
  • Step 3 Report
  • Regular reports are required for PCI compliance
    these are submitted to the acquiring bank and
    card payment brands that you do business with.
  • PCI SSC is not responsible for PCI compliance.
  • All qualifying merchants and processors must
    submit a quarterly scan report, which must be
    completed by a PCI approved ASV.
  • Businesses must submit an annual Attestation
    within the Self-Assessment Questionnaire (SAQ).

21
Module 2
Merchant Levels and Compliance Validation
Service Provider Levels and Compliance Validation

Level Merchant Criteria Validation Requirements
1 Merchants processing over 6 million Visa transactions annually Annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA) or internal auditor if signed by officer of the company Quarterly network scan by Approved Scanning Vendor (ASV) Attestation of Compliance Form
2 Merchants processing 1 million to 6 million Visa transactions annually Annual Self-Assessment Questionnaire (SAQ) Quarterly network scan by ASV Attestation of Compliance Form
3 Merchants processing 20,000 to 1 million visa e-commerce transactions annually Annual SAQ Quarterly network scan by ASV if applicable Attestation of Compliance Form
4 Merchants processing less than 20,000 Visa e-commerce transactions annually Annual SAQ recommended Quarterly network scan by ASV if applicable Compliance validation requirements set by acquirer
Level Validation Action Validated By
1 Annual On-site PCI Data Security Assessment Quarterly Network Scan Qualified Security Assessor (QSA) Approved Scanning Vendor (ASV)
2 Annual PCI Self-Assessment Questionnaire Quarterly Network Scan Service Provider Approved Scanning Vendor (ASV)
  • Level 1
  • All Third Party Processors (TPPs) and Data
    Storage Entities (DSEs) that store, transmit or
    process less than 1,000,000 combined MasterCard
    and Maestro transactions annually.
  • Additionally, All compromised TPPs and DSEs
  • Level 2
  • All DSEs that store, transmit or process less
    than 1,000,000 combined MasterCard and Maestro
    transactions annually

Note UMASS is designated as a Level 3 Merchant
but we report as a Level 2 Merchant
22
Module 2
Payment Application Data Security Standard
(PA-DSS)

Assessing Environments with PA-DSS Applications

PA -DSS Overview
  • PA-DSS is a comprehensive set of requirements
    designed for payment application software vendors
    to facilitate their customers PCI DSS
    compliance.
  • Distinct but aligned with OPCI-DSS
  • PA-DSS applies to third party applications that
    perform authorization and/or settlement.
  • PA-DSS does not apply to payment applications
    that are typically sold and installed off the
    shelf without much customization by software
    vendors.
  • PA-DSS does not apply to payment applications
    provided in modules, which typically includes a
    baseline module and other modules specific to
    customer types or functions, or customized per
    customer request.
  • PA-DSS does not apply to a payment application
    developed and sold to only one customer since
    this application will be covered a part of the
    customers PCI DSS compliance review.
  • PCI-DSS does not apply to payment applications
    developed by merchants and service providers if
    used only in-house (not sold to a third party).
  • PA-DSS does not apply to operating systems onto
    which a payment application is installed,
    database systems that store cardholder data or
    back-office systems that source cardholder data.
  • Use of PA-DSS compliant application by itself
    does not make an entity PCI-DSS compliant
  • PA-DSS validated payment applications are
    included in the scope of a PCI-DSS assessment
  • The assessor should not challenge the PA-DSS
    validation
  • PCI-DSS assessment of validated payment
    applications should verify the payment
    application is implemented into a PCI-DSS
    compliant environment and the payment application
    is implemented according to the PA-DSS
    Implementation Guide
  • All other system components in scope for PCI DSS
    must still be assessed
  • The assessor should focus their assessment on the
    applications implementation in accordance with
    the vendors implementation guide.

23
Module 2
Roles Responsibilities

  • Merchant Service Providers
  • Review and understand the PCI Security Standards
  • Understand the compliance validation and
    reporting requirements defined by the payment
    card brands
  • Validate and report compliance to acquirer or
    payment card brand
  • Maintain ongoing compliance, not just during
    assessment
  • Read and incorporate communications from the
    payment brands, acquirers, and the PCI SSC
  • Internal Security Assessors
  • Validate the scope of the assessment
  • Verify all technical information given by
    stakeholders using independent judgment to
    confirm requirements have been met
  • Provide support and guidance during the
    compliance process
  • Be on-site for the duration of any relevant
    assessment procedure
  • Review the work that supports the assessment
    procedures
  • Ensure adherence to PCI-DSS Requirements
  • Select business facilities and system components
    for sampling
  • Evaluate compensating controls and produce final
    report
  • Approved Scanning Vendor (ASV)
  • Perform external vulnerability scans via PCI-DSS
    Requirement 11.2
  • PCI Security Standards Council
  • Maintain PCI-DSS, PA-DSS, PTS, P2PE, and PIN
    Security standards and supporting documentation
  • Define, implement validation requirements for
    QSAs, PA-QSAs, ASVs, ISAs
  • Approve companies and their employees to perform
    PCI DSS Assessments, Payment Application
    Assessments, ASV Scanning
  • Maintain list of validated payment applications,
    P2PE solutions, PIN transaction security devices,
    QSA, PA-QSA, ASV companies
  • Offer training for the QSAs, PA-QSAs, ASVs, and
    ISAs
  • Promote PCI security on a global basis
  • Payment Card Brands
  • Development and enforcement of compliance
    programs
  • Fines or penalties for non-compliance
  • Endorse QSA, PA-QSA and ASV company qualification
    criteria
  • Accept validation documentation from approved
    QSA, PA-QSA, and ASV companies and their
    employees
  • Provide feedback to council on QSA, PA-QSA and
    ASV performance
  • Forensic investigation and account data
    compromise
  • Qualified Security Assessor (QSA)
  • Validate the scope of the assessment
  • Conduct PCI-DSS assessments

24
Module 3
UMASS e-Commerce Committee Security Council
  • Roles and Responsibilities
  • UMASS Campus / Presidents Office e-Commerce and
    Information Security Representative
  • Roles and Responsibilities Merchant Compliance
    (Campus and Presidents Office)
  • Manage campus merchants inventory spreadsheet
    and compliance WorkShare site
  • Manage campus merchants annual Self Assessments
    Questionnaires (SAQs)
  • Manage campus merchants QSA Security Assessments
    (new implementations)
  • Manage campus merchants Quarterly Scans (if
    applicable)
  • Manage campus merchants annual PCI DSS training
  • Manage campus merchants ongoing communications
    and updates (as needed)
  • UMASS Presidents Office e-Commerce and
    Information Security Representative
  • Roles and Responsibilities QSA Contracts and
    Statement of Work (SOW)
  • Manage QSA (Lighthouse, DRG) Statement of Work
  • Manage QSA and ongoing communications and updates
    (as needed)
  • UMASS Presidents Office e-Commerce and
    Information Security Representative

25
Module 3
UMASS Merchant and Service Provider Compliance
Checklist
  • Merchants Compliance Checklist
  • New install requirements
  • All new Merchant Installs must include a
    documented PCI Security Assessment completed by a
    Qualified Security Assessor (QSA) either
    Lighthouse or DRG.
  • This requirements is for new on-line
    installations that are using software in lieu of
    or in addition to CyberSource or Commerce Manager
    (non-traditional configurations)
  • Annual re-certification requirements
  • The campus representatives are responsible for
    maintaining the Merchant inventory (with the
    cooperation of the Merchants)
  • All Merchants must attest by completing the
    appropriate SAQ, with University of
    Massachusetts Treasurers Office - Treasurers
    Fiscal Procedure No. 08-01 including all
    requirements of Section A Operational, Section
    B Inventory, Section C PCI Compliance, and
    Section D Online Third Party Requirements.
  • All Merchants must attest and provide evidence of
    compliance with PCI Self-Assessment Questionnaire
    (SAQ) Type A, B, C-VT, C, or D as appropriate.
    The Treasurers office will distribute a
    university developed questionnaire to be
    completed and returned by the merchants.
  • All Merchants (as required) must complete and
    provide Quarterly Vulnerability Scan results.
  • All Merchants must complete and provide evidence
    of completion the University of Massachusetts PCI
    training (see note).
  • Note This is a new requirement starting April,
    2012.
  • Service Providers Compliance Checklist
  • Annual re-certification requirements
  • All Service Providers must complete and sign the
    necessary contracts to attest that they are
    authorized Third Party Service Providers for the
    University of Massachusetts before services are
    engaged. Annually, they must provide evidence of
    their PCI compliance to the University of
    Massachusetts.

26
Appendix
UMASS Self Assessment Questionnaire Type A (SAQ
A) Card Not Present All Cardholder Data
Functions Outsourced
  • SAQ A Merchants Requirements
  • Such merchants validate compliance by completing
    SAQ A and the associated Attestation of
    Compliance, confirming that
  • Handles only card-not-present (e-commerce or
    mail/telephone-order) transactions
  • Does not store, process, or transmit any
    cardholder data on your systems or premises, but
    relies entirely on third party service
    provider(s) to handle all these functions
  • Has confirmed that the third party(s) handling
    storage, processing, and/or transmission of
    cardholder data is PCI DSS compliant
  • Retains only paper reports or receipts with
    cardholder data, and these documents are not
    received electronically and
  • Does not store any cardholder data in electronic
    format.
  • Treasurers Fiscal Procedure No. 08-01
  • Section A A.1, A.2, A.5, A.6, A.8
  • Section B B.1, B.2, B.3
  • Section C C.1, C.6, C.7, C.8, C.9

27
Appendix
UMASS Self Assessment Questionnaire Type B (SAQ
B) Merchants with Only Imprint Machines or Only
Standalone, Dial-Out Terminals. No Electronic
Cardholder Data Storage.
  • SAQ B Merchants Requirements
  • Such merchants validate compliance by completing
    SAQ B and the associated Attestation of
    Compliance, confirming that
  • Use only imprint machines and/or uses only
    standalone, dial-out terminals (connected via a
    phone line to your processor) to take your
    customers payment card information
  • The standalone, dial-out terminals are not
    connected to any other systems within your
    environment
  • The standalone, dial-out terminals are not
    connected to the Internet
  • Do not transmit cardholder data over a network
    (either an internal network or the Internet)
  • Retains only paper reports or paper copies of
    receipts with cardholder data, and these
    documents are not received electronically and
  • Does not store cardholder data in electronic
    format.
  • Treasurers Fiscal Procedure No. 08-01
  • Section A A.1, A.2, A.5, A.6, A.8
  • Section B B.1, B.2, B.3

28
Appendix
UMASS Self Assessment Questionnaire Type B (SAQ
B) Merchants with Only Imprint Machines or Only
Standalone, Dial-Out Terminals. No Electronic
Cardholder Data Storage.
29
Appendix
UNIVERSITY OF MASSACHUSETTS TREASURERS
OFFICE Treasurers Fiscal Procedure No.
08-01 Effective Date March 1, 2012 Fiscal
Standard and Procedure E-Commerce and PCI
  • Section A Operational
  • Overall
  • Campus merchants (departments) may not store in
    any manner full 16 digit credit card numbers
    (PAN).
  • Unprotected PAN (Primary Account Number) should
    not be sent via end-user messaging technologies
    including but not limited to email, instant
    messaging, text message, or social media.
  • All requests for credit card receipt copies and
    chargebacks must be processed immediately.
    Failure to respond before the deadline will
    result in the chargeback being processed by the
    card company. Credit card copies must mask all
    but the first six and last four digits of the
    account number (PAN) prior to transmission.
  • Point of Sale
  • Credit card terminals must be batched out daily.
  • Campus merchants (departments) may not store in
    any form the magnetic strip, which consists of
    track data, CVV2 data or PIN data.
  • University Records Retention Policy states that
    we must retain all credit card receipts for three
    years. PCI Standards also require that these
    records be classified by labeling as
    Confidential and stored securely. These
    receipts should not contain the full PAN (Primary
    Account Number). At the end of three years they
    must be properly disposed of by being cross-cut
    shredded, incinerated, or pulped. Containers
    storing documents to be destroyed should have a
    lock preventing access to its contents.
  • To process a credit for a point-of-sale terminal,
    ideally you should have the card present and
    swipe it through the terminal.  If the card is
    not present then there should be communication
    with the cardholder to get the full number to be
    used to enter into the terminal.  There should
    not be storage of full card numbers in any
    format.
  • Online
  • Electronic records containing cardholder data
    should not contain the full PAN. If you receive
    a report containing the full PAN please contact
    your campus eCommerce representative immediately
    for instructions on permanently deleting the
    file.
  • All credits specific to CyberSource applications
    must be processed online through the University
    Treasurers Office within 60 days of the original
    transaction and are based on a transaction
    reference number. Card number is not required.
    Beyond 60 days, credits can be processed manually
    by the receiving site or as a stand-alone credit
    through the Treasurers Office.
  • Section B Inventory
  • Each campus must maintain a complete and accurate
    inventory of all credit card processing locations
    including point of sale and online merchants.
    The campus is also responsible for maintaining an
    inventory of documentation regarding third party
    vendors contracted to process credit cards.
    Process flows and technology configuration should
    be documented and updated as needed.
  • Campus E-commerce representatives must be
    involved in and approve any decisions to accept
    credit cards or other electronic form of cash
    receipts.
  • It is recommended that each campus maintain an
    inventory of all outsourced vendors that process
    credit card payments. Proof of their PCI
    compliance should be provided no less than
    annually.
  • Section C PCI Compliance
  • Administrative
  • Campus E-commerce representatives and Campus
    Bursars will work with departments to provide the
    necessary guidance in the areas of PCI
    Compliance, internal controls (including
    restricting access to cardholder data), deposit
    techniques and reconciliation.
  • E-commerce representatives have the authority to
    suspend the account of a merchant who is not in
    compliance with the University of Massachusetts
    Fiscal Standard and Procedure E-Commerce and
    PCI.
  • Failure to follow the PCI DSS standards for
    credit card merchants subjects the University to
    fines and penalties. Any fines will be the
    responsibility of the campus.
  • Use of any unauthorized or non-compliant third
    party credit card processing vendors must be
    immediately terminated.
  • Any department accepting credit card payments in
    any format is required to complete the
    appropriate PCI SAQ (Self-Assessment
    Questionnaire) annually.
  • Transmission of quarterly scan results and the
    annual SAQ will be sent and tracked by the
    Treasurers Office to the acquiring bank.
  •  

30
Appendix
UNIVERSITY OF MASSACHUSETTS TREASURERS
OFFICE Treasurers Fiscal Procedure No.
08-01 Effective Date March 1, 2008 Fiscal
Standard and Procedure E-Commerce and PCI
  • Section C PCI Compliance
  • Point of Sale
  • All broken and discontinued POS terminals must be
    returned in a secure manner to the University
    Treasurers Office for disposal.
  • Departments are responsible for ensuring they
    only use PCI compliant POS terminals and must
    replace any non-compliant or obsolete terminals
    at their own expense.
  • POS terminals should only be used on campus. If
    a business need arises to take the terminal off
    campus departments must obtain approval from
    their campus eCommerce Representative prior to
    taking a terminal off campus. The requesting
    department must be able to confirm the connection
    type that will be used at the outside venue and
    agree to monitor the terminal at all times and
    keep it securely locked when not in use.
  • Online
  • CyberSource and NelNet have been identified as
    the third party vendors of choice for all online
    activity. Any deviation from the use of
    CyberSource or NelNet must be approved by your
    campus Vice Chancellor for AF as well as the
    E-commerce Committee. All third party vendors are
    subject to the same standards for data compliance
    and security. Proof of PCI compliance must be
    provided on an ongoing basis. Proof will be
    provided no less than annually.
  • Third party installations other than CyberSource
    or NelNet must be reviewed by a QSA (Qualified
    Security Assessor) prior to accepting payments.
    The QSA deliverable should be a written report
    stating that the installation was installed in a
    PCI compliant manner. Additionally, campuses
    should periodically review these installations to
    confirm ongoing compliance.
  • All new payment applications must be listed on
    the PCI list of Validated Payment Applications.
    If the application is not listed the campus must
    provide the University Treasurers Office with a
    PABP Implementation Guide to help ensure that
    once the application is implemented it is in
    compliance. This will demonstrate that the
    application was developed under PABP guidelines
    and that their environment is PCI compliant.
  • All charge card applications written in-house
    must be developed using VISAs PABP, Payment
    Application Best Practices and validated to be
    PCI compliant before going live.
  • Any department processing online credit card
    payments must work with their campus IT Security
    Department to determine if they will need to
    complete and submit quarterly scans.
  • Section D Online Third Party Applications
  • All third party credit card processing vendors
    are subject to PCI DSS Standards. In addition
    they may be subject to quarterly network scans
    that must be performed by an Approved Scanning
    Vendor (ASV). The completion of annual
    self-assessment questionnaires is required. It is
    the responsibility of the campus to monitor and
    maintain current documentation.
  • Outside (third party) vendors must be listed on
    the PCI list of Validated Payment Applications or
    if not listed, they need to submit documentation
    from their QSA to the campus stating that they
    are PCI compliant and the date specific to that
    compliance. This document must be updated
    annually.
  • All new contracts with third party or outside
    vendors must contain language requiring that the
    vendor be PCI compliant and they will remain PCI
    compliant throughout the term of the contract.
    If the third party vendor is not the payment
    processor, their contract language must state
    that they will only use a PCI compliant payment
    processor throughout the term of the contract.
    Failure to do so gives the University the right
    to terminate the contract at no penalty to the
    University of Massachusetts.
  • All new contracts with third party or outside
    vendors must contain language that the vendor
    acknowledges that they are responsible for the
    security of cardholder data that they possess.
  • Campuses are responsible for ensuring that third
    party vendors remain PCI compliant throughout the
    term of the contract.

31
Appendix
PCI DSS Terminology
Approved Scanning Vendor (ASV) - is a
vulnerability assessment provider who provides
automated software tools for scanning for
vulnerabilities. Cardholder - Non-consumer or
consumer customer to whom a payment card is
issued to or any individual authorized to use the
payment card. Cardholder Data - At a minimum,
cardholder data consists of the full PAN.
Cardholder data may also appear in the form of
the full PAN plus any of the following
cardholder name, expiration date and/or service
code. Internal Security Assessor (ISA) - The
ISA Program provides eligible internal security
audit professionals PCI DSS training and
certification that will improve the
organizations understanding of the PCI DSS,
facilitate interactions with QSAs, enhance the
quality, reliability, and consistency of PCI DSS
self-assessments, and support consistent and
proper application of PCI DSS measures and
controls. The Payment Application-Data Security
Standard (PA-DSS) - A global security standard
created by the Payment Card Industry Security
Standards Council, or PCI SSC, formed by the
major credit-issuing companies with the goal of
delivering an effective and useful data security
standard to vendors of payment application
systems. The intent of this standard is to
effectively prohibit secure data from being
illegally accessed by unauthorized
parties. Payment processor - An organization
that processes payment requests, such as credit
card authorizations and settlements, to the
appropriate card associations per their
guidelines. Your merchant banks processor
relationship determines which payment processor
you will use. Payment gateway - An organization,
such as CyberSource, that enables merchants to
securely send and receive order information to
and from payment processors in the appropriate
format. PCI Compliant - refers to an
organization that has become compliant with the
PCI DSS and has demonstrated this either through
a Self Assessment Questionnaire or through formal
validation (audit) by a QSA firm. PCI DSS - Data
Security Standard a document consisting of 12
requirements and various principles all designed
to provide a framework to protect payment card
data and systems.
PCI SSC Security Standards Council - the global
governing body for payment card security
standards. Responsible for developing, managing,
education, and awareness of the PCI Security
Standards including Data Security Standard (PCI
DSS), Payment Application Data Security Standard
(PA-DSS), and PIN Transaction Security (PTS)
Requirements. Primary Account Number (PAN) -
is essentially a payment card number (16 19
digit) which is generated according to the LUHNS
algorithm). Qualified Security Assessor (QSA)
is a Information Security and PCI expert who
works for a QSA firm and who has been certified
by the PCI SSC to be fit and proper to validate
whether a company / environment is PCI
compliance Report on Compliance (ROC) - the
report on compliance refers to a report that
shows that an environment has been validated by a
QSA in accordance with the PCI DSS. The outcome
of the validation assessment may result in a
Report of Compliance opinion of Compliant or Not
Compliant depending the evidence provided to
support the compliance assertions provided by the
merchant or service provider to the QSA
Self-Assessment Questionnaire (SAQ) A
validation tool for merchants and service
providers that are not required to undergo an
on-site data security assessment per the PCI DSS
Security Assessment Procedures. The purpose of
the SAQ is to assist organizations in
self-evaluating compliance with the PCI DSS, and
you may be required to share it with your
acquiring bank. There are multiple versions of
the PCI DSS SAQ to meet various business
scenarios. Service Provider - An entity that
stores, processes or transmits cardholder data on
behalf of merchants. Examples of service
providers include hosting and payment services
for merchants. Such providers do not have direct
service provider contractual relationships with
acquiring institutions, other than for their own
merchant activities, but nonetheless still fall
into scope for the PCI DSS where they store,
process or transmit payment cards on behalf of
merchants. It is the merchant responsibility to
ensure the service providers operate in a way
that is complaint with the PCI DSS. Validation /
Audit - refers to the final stage of PCI
compliance whereby a Qualified Security Assessor
(QSA) will validate and attest the compliance
status of the environment under assessment for
compliance with the PCI DSS. Vulnerability
Assessment is a technical security audit that
uses automated tools to test for security flaws,
mis-configurations and weaknesses in
infrastructure and applications (to a relatively
limited extent).
32
Appendix
Useful PCI DSS References
PCI DSS Overview video http//abcnews.go.com/Vi
deo/playerIndex?id4769169 (How Thieves Are
'Stealing You) Treasurers office e-commerce
standards http//media.umassp.edu/massedu/treasu
rer/Principles20--02272008final20on20letterhead
1.pdf PCI Security Standards Council
https//www.pcisecuritystandards.org/ PCI Quick
Reference Guide https//www.pcisecuritystandards.
org/pdfs/pci_ssc_quick_guide.pdf Documents
Library https//www.pcisecuritystandards.org/sec
urity_standards/documents.php?document2.02.0 Cer
t
View by Category
About This Presentation
Title:

Information Security Programs

Description:

UMASS PCI DSS Compliance Training Payment Card Industry Data Security Standard (PCI DSS) Training Program Version 4 Larry Wilson October, 2013 * * Appendix ... – PowerPoint PPT presentation

Number of Views:486
Avg rating:3.0/5.0
Slides: 36
Provided by: UITS72
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Information Security Programs


1
UMASS PCI DSS Compliance Training
Payment Card Industry Data Security Standard (PCI
DSS) Training Program
Version 4 Larry Wilson October, 2013
1
2
PCI DSS Training Course
Contents
  • Module 1
  • PCI DSS Introduction
  • Payment Industry Terminology
  • Payment Transaction Flow
  • Service Provider Relationships
  • Module 2
  • Payment Brand Compliance Programs
  • SAQ Overview
  • PA-DSS Overview
  • PCI Roles and Responsibilities
  • Module 3
  • Cardholder Data Discovery
  • Network Segmentation
  • Scoping the Cardholder Data Environment

3
Module 1
Module 1 Objectives
  • After completing this module you will be able to
  • Understand the importance of PCI DSS compliance
  • Describe the role of the Payment Card Industry
    Security Standards Council (PCI SSC)
  • Outline the Payment Card Industry Security
    Standards
  • Describe the benefits of PCI DSS training
  • Discuss myths of PCI DSS
  • Define Payment Card Industry Terminology
  • Define card processing Authorization, Clearing
    and Settlement
  • Define service provider relationships
  • Discuss transaction types card Not Present and
    Card Present
  • Describe credit card security
  • Compliance with PCI DSS
  • There are three things to understand about PCI
    DSS
  • Standards are not optional
  • If you accept payment cards on campus, you are
    subject to the standards
  • There are significant financial costs to
    non-compliance.
  • Failure to comply with PCI DSS can result in
    stiff contractual penalties or sanctions from
    members of the payment card industry including
  • Fines of 500,000 per data security incident
  • Fines of 50,000 per day for non-compliance with
    published standards
  • Liability for all fraud losses incurred from
    compromised account numbers
  • Liability for the cost of re-issuing cards
    associated with the compromise
  • Suspension of merchant accounts
  • Non compliance is not worth the risk.
  • It only takes one incident of data compromise to
    put the university at risk

4
Module 1
PCI DSS Introduction
  • What is PCI SSC?
  • PCI Security Standards Council (PCI SSC) was
    created in 2006 as an independent standards body
    to provide oversight f the development and
    management of payment Card Industry Security
    Standards on a global basis
  • Created to align security programs of MasterCard
    and Visa
  • Later was adopted by other major card programs
  • Founding members of the council included American
    Express, Discover, JCB, MasterCard Worldwide, and
    Visa International.
  • Resources Provided by the Council
  • PCI DSS, PCI PTS, PCI PA-DSS, P2PE, PIN Security
    and supporting documents
  • Roster of QSAs (Qualified Security Assessors),
    ASVs (Approved Scanning Vendors), validated
    payment applications, PTS Devices, and P2PE
    solutions
  • PCI Security Standards Council FAQs
  • Education and Outreach Programs
  • Participating Organization Membership, Meetings,
    Feedback
  • PCI Standards
  • PCI DSS covers security of the environments that
    store, process or transmit account data
  • PCI PTS covers tamper detection, cryptographic
    processes, and other mechanisms used to protect
    the PIN
  • PCI PA-DSS covers secure payment applications to
    support PCI DSS compliance
  • PCI PTS covers tamper detection, cryptographic
    processes, and other mechanisms used to protect
    the PIN
  • PCI P2PE covers encryption, decryption and key
    management within secure cryptographic devices
  • PCI PIN Security covers secure management,
    processing and transmission of personal
    identification number (PIN) data during online
    and offline payment card transaction processing

5
Module 1
PCI DSS Introduction
  • Who does PCI DSS apply to?
  • UMASS Merchants must be PCI DSS compliant and are
    responsible for ensuring their compliance
  • The program applies to all payment channels,
    including in person (Point of Sale), mail /
    telephone order and/or e-commerce.
  • The training is applicable to all campus
    personnel who have access to credit card
    information, as a processor of credit card
    transactions or as a reviewer of reports that
    contain credit card data
  • How does it work?
  • University Merchants and Service Providers must
    adhere to PCI DSS
  • A single approach to safeguard sensitive data for
    all card brands
  • Compliance validation ensures appropriate levels
    of cardholder data security are maintained
  • Why is this important?
  • This training provides knowledge and skills
    necessary to ensure credit card security at the
    university
  • Everyone, not just the credit card companies,
    benefits from the effective application of credit
    card security measures
  • Benefits of PCI DSS Training
  • Our Customers
  • Appreciate your ability to reduce the threat of
    identity theft
  • Trust you to complete transactions without
    duplicate or invalid charges
  • Enjoy peace of mind, knowing that their credit
    card information is in good hands
  • The University
  • Takes pride in a skilled workforce
  • Values your ability to build customer confidence
  • Needs your help in limiting potential losses,
    fines and penalties
  • and You
  • Have confidence in your ability to safely and
    efficiently do your job
  • Are alert to the warning signs of fraud
  • Know you can make informed decisions under
    pressure

6
Module 1
Myths of PCI DSS
  • Myth 6 PCI requires us to hire a Qualified
    Security Assessor
  • PCI DSS provides the option of doing an internal
    assessment with an officer sign-off if acquirer
    and/or merchant bank agree
  • Note The Commonwealth of Massachusetts
    Controllers office requires the University to
    hire a QSA to conduct an independent assessment
    on an annual basis.
  • Myth 7 We dont take enough credit cards to be
    compliant
  • PCI compliance is required for any business that
    accepts payment cards even if the quantity of
    transactions is just one
  • Myth 8 We completed a SAQ so were compliant
  • Technically, this is true for merchants who are
    not required to do on-site assessments for PCI
    DSS compliance. True security of cardholder data
    requires non-stop assessment and remediation to
    ensure that likelihood of a breach is kept as low
    as possible.
  • Myth 9 PCI makes us store cardholder data
  • Both PCI DSS and the payment card brands strongly
    discourage storage of cardholder data by
    merchants and processors
  • Myth 10 PCI is too hard
  • Understanding PCI DSS can seem daunting,
    especially for merchants without security or a
    large IT department.
  • However, PCI DSS mostly calls for good, basic
    security
  • Myth 1 One vendor and product will make us
    compliant
  • No single vendor or product fully addresses all
    12 requirements of PCI DSS.
  • Myth 2 Outsourcing card processing makes us
    compliant
  • Outsourcing simplifies but does not provide
    automatic compliance
  • We must ensure providers comply with PCI
    standards
  • Request a certificate of compliance annually from
    providers.
  • Myth 3 PCI compliance is an IT project
  • The IT staff implements technical and operational
    aspects
  • PCI compliance is an ongoing process of
    assessment, remediation, reporting
  • Myth 4 PCI will make us secure
  • Successful completion of a scan or assessment is
    a snapshot in time
  • Security exploits are non-stop and get stronger
    every day
  • PCI compliance efforts are a continuous process
    of assessment and remediation to ensure safety of
    cardholder data.
  • Myth 5 PCI is unreasonable it requires too
    much
  • Most aspects of PCI DSS are a common best
    practice for security

7
Module 1
Payment Industry Terminology
  • Payment Brand Compliance Programs
  • Tracking and enforcement
  • Penalties, fees, compliance deadlines
  • Validation process and who needs to validate
  • Approval and posting of compliant entities
  • Definition of merchants and service provider
    levels
  • Forensics and response to account data
    compromises
  • Common Acquirer Responsibilities
  • Acquirer is responsible for merchant compliance
  • Ensure that their merchants understand PCI DSS
    compliance requirements and track compliance
    efforts
  • Manage merchant communications
  • Work with merchants until full compliance has
    been validated
  • Merchants are not compliant until all
    requirements have been met and validated
  • Acquirer is responsible for providing merchant
    compliance status to payment brands
  • Incur any liability that may result from
    non-compliance with payment brand compliance
    programs
  • Cardholder
  • Customer purchasing goods as either a Card
    Present or card Not Present transaction
  • Receives the payment card and bills from the
    issuer
  • Issuer
  • Bank or other organization issuing a payment card
    on behalf of a Payment Brand (e.g. MasterCard
    Visa)
  • Payment Brand issuing a payment card directly
    (e.g. Amex, Discover, JCB)
  • Merchant
  • Organization accepting the payment card for
    payment during a purchase
  • Acquirer
  • Bank or entity the merchant uses to process their
    payment card transactions
  • Receive authorization request from merchant and
    forward to Issuer for approval
  • Provide authorization, clearing and settlement
    services to merchant
  • Payment Brand
  • Include American Express, Discover, JCB,
    MasterCard Worldwide, and Visa International
  • Each payment brand develops and maintains its own
    PCI DSS compliance program in accordance with its
    own security risk management policies

8
Module 1
Credit Card Processing
  • Authorization (time of purchase)
  • Every request receives a response that directs
    the acquirer or the merchant on how to proceed
    with the transaction (Approve or Deny)
  • Clearing (within one day)
  • Involves daily processing and routing of
    financial transactions between card brands,
    acquirers and issuers
  • Settlement (within two days)
  • Involves funds transfer for the purpose of the
    financial settlement of clearing transactions,
    fees, and other transfer of funds between card
    brands, acquirers and issuers.

9
Module 1
How Payment Processing Works (Technical Process)
10
Module 1
Service Providers
  • Service Providers
  • A service provider is a business entity directly
    involved with the processing, storage,
    transmission, or switching of transaction data
    and cardholder data.
  • Service providers include companies that provide
    services which control or could impact the
    security of cardholder data.
  • Service provider examples
  • Transaction processors
  • Payment Gateways
  • Independent sales Organizations (ISOs)
  • External Sales Organizations (ESOs)
  • Customer Service functions
  • Remittance processing companies
  • Managed firewall and Intrusion Detection Service
    (I DS) service providers
  • Web Hosting and Data Center Hosting providers

Payment Gateways This diagram illustrates how
real-time, electronic credit card processing
works using CyberSource Payment Services.
  1. Purchaser places order
  2. Merchant securely transfers order information to
    CyberSource over the Internet. CyberSource
    receives order information and performs requested
    services
  3. CyberSource formats the transaction detail
    appropriately and securely routes the transaction
    authorization request through its payment gateway
    to the processor.
  4. The transaction is then routed to the issuing
    bank (purchaser's bank) to request transaction
    authorization
  5. The transaction is authorized or declined by the
    issuing bank or card (Discover, American
    Express).
  6. CyberSource returns the message to the merchant.
  7. Issuing bank approves transfer of money to
    acquiring bank
  8. The acquiring bank credits the merchant's account

11
Module 1
Transaction Types Card Security
Credit Card Security
Merchant Configurations Card Not Present
Transactions Card Not Present Transaction
- the credit card information is keyed into a
credit card processing system (credit card
terminal, software program, or payment gateway)
without the credit card or customer present at
the time of the sale. Card Present
Transactions Card Present Transaction
(Point of Sale) - the customer and credit card
are present at the point of sale. The card is
swiped through a credit card processing system
(credit card terminal, POS system or card reader)
that obtains the card holder's information by
reading the magnetic stripe on the back of the
card.
Internet Connected Terminal
Dial-up Terminal
Wireless Terminal
Tap Go Wireless Terminal
Imprint Machine
12
Module 2
Module 2 Objectives
  • After completing this module you will be able to
  • Understand the PCI DSS Standards Framework
  • Understand Merchant Compliance Requirements
  • Describe the Self Assessment Questionnaire (SAQ)
  • Understand SAQ Instructions and Guidelines
  • Describe the three step PCI DSS Compliance
    Approach
  • Understand Merchant and Service Provider
    Compliance Levels
  • Understand Merchant and Service Provider
    Compliance Validation
  • Understand Payment Application data Security
    Standard (PA-DSS)
  • Understand PCI Roles and Responsibilities

PCI DSS Standards Framework
PCI DSS Requirements Validated by Self or Outside Assessment
Build and maintain a secure network 1.Install and maintain a firewall configuration to protect cardholder data 2.Do not use vendor-supplied defaults for system passwords and other security parameters
Protect cardholder data 3. Protect sensitive data 4. Encrypt transmission of cardholder data across open, public networks
Maintain a vulnerability management program 5 Use and regularly update anti-virus software 6. Develop and maintain secure systems and applications
Implement strong access control measures 7 Restrict access to cardholder data by business need-to-know 8. Assign a unique ID to each person with computer access 9. Restrict physical access to cardholder data
Regularly monitor and test networks 10. Track and monitor all access to network resources and cardholder data 11. Regularly test security systems and processes
Maintain an Information Security Policy 12. Maintain a policy that addresses Information security
13
Module 2
PCI DSS Standards Requirements
  • Requirement 2 Do not use vendor-supplied
    defaults for system passwords and other security
    parameters
  • Malicious individuals (external and internal to
    an entity) often use vendor default passwords and
    other vendor default settings to compromise
    systems. These passwords and settings are well
    known by hacker communities and are easily
    determined via public information.
  • Requirement 3 Protect stored cardholder data
  • Protection methods such as encryption,
    truncation, masking, and hashing are critical
    components of cardholder data protection. If an
    intruder circumvents other security controls and
    gains access to encrypted data, without the
    proper cryptographic keys, the data is unreadable
    and unusable to that person. Other effective
    methods of protecting stored data should be
    considered as potential risk mitigation
    opportunities. For example, methods for
    minimizing risk include not storing cardholder
    data unless absolutely necessary, truncating
    cardholder data if full PAN is not needed, and
    not sending unprotected PANs using end-user
    messaging technologies, such as e-mail and
    instant messaging.
  • Requirement 4 Encrypt transmission of cardholder
    data across open, public networks
  • Sensitive information must be encrypted during
    transmission over networks that are easily
    accessed by malicious individuals. Misconfigured
    wireless networks and vulnerabilities in legacy
    encryption and authentication protocols continue
    to be targets of malicious individuals who
    exploit these vulnerabilities to gain privileged
    access to cardholder data environments.
  • Requirement 1 Install and maintain a firewall
    configuration to protect cardholder data
  • Firewalls are devices that control computer
    traffic allowed between an entitys networks
    (internal) and untrusted networks (external), as
    well as traffic into and out of more sensitive
    areas within an entitys internal trusted
    networks. The cardholder data environment is an
    example of a more sensitive area within an
    entitys trusted network.
  • A firewall examines all network traffic and
    blocks those transmissions that do not meet the
    specified security criteria.
  • All systems must be protected from unauthorized
    access from untrusted networks, whether entering
    the system via the Internet as e-commerce,
    employee Internet access through desktop
    browsers, employee e-mail access, dedicated
    connections such as business-to-business
    connections, via wireless networks, or via other
    sources. Often, seemingly insignificant paths to
    and from untrusted networks can provide
    unprotected pathways into key systems. Firewalls
    are a key protection mechanism for any computer
    network.
  • Other system components may provide firewall
    functionality, provided they meet the minimum
    requirements for firewalls as provided in
    Requirement 1. Where other system components are
    used within the cardholder data environment to
    provide firewall functionality, these devices
    must be included within the scope and assessment
    of Requirement 1.


14
Module 2
PCI DSS Standards Requirements
  • Requirement 8 Assign a unique ID to each person
    with computer access
  • Assigning a unique identification (ID) to each
    person with access ensures that each individual
    is uniquely accountable for his or her actions.
    When such accountability is in place, actions
    taken on critical data and systems are performed
    by, and can be traced to, known and authorized
    users.
  • Requirement 9 Restrict physical access to
    cardholder data
  • Any physical access to data or systems that house
    cardholder data provides the opportunity for
    individuals to access devices or data and to
    remove systems or hardcopies, and should be
    appropriately restricted. For the purposes of
    Requirement 9, ?onsite personnel? refers to
    full-time and part-time employees, temporary
    employees, contractors and consultants who are
    physically present on the entitys premises. A
    ?visitor? refers to a vendor, guest of any onsite
    personnel, service workers, or anyone who needs
    to enter the facility for a short duration,
    usually not more than one day. ?Media? refers to
    all paper and electronic media containing
    cardholder data.
  • Requirement 10 Track and monitor all access to
    network resources and cardholder data
  • Logging mechanisms and the ability to track user
    activities are critical in preventing, detecting,
    or minimizing the impact of a data compromise.
    The presence of logs in all environments allows
    thorough tracking, alerting, and analysis when
    something does go wrong. Determining the cause of
    a compromise is very difficult, if not
    impossible, without system activity logs.
  • Requirement 5 Use and regularly update
    anti-virus software or programs
  • Malicious software, commonly referred to as
    ?malware?including viruses, worms, and
    Trojansenters the network during many
    business-approved activities including employee
    e-mail and use of the Internet, mobile computers,
    and storage devices, resulting in the
    exploitation of system vulnerabilities.
    Anti-virus software must be used on all systems
    commonly affected by malware to protect systems
    from current and evolving malicious software
    threats.
  • Requirement 6 Develop and maintain secure
    systems and applications
  • Unscrupulous individuals use security
    vulnerabilities to gain privileged access to
    systems. Many of these vulnerabilities are fixed
    by vendor-provided security patches, which must
    be installed by the entities that manage the
    systems. All critical systems must have the most
    recently released, appropriate software patches
    to protect against exploitation and compromise of
    cardholder data by malicious individuals and
    malicious software.
  • Requirement 7 Restrict access to cardholder data
    by business need to know
  • To ensure critical data can only be accessed by
    authorized personnel, systems and processes must
    be in place to limit access based on need to know
    and according to job responsibilities.


15
Module 2
PCI DSS Standards Requirements
  • Compliance with PCI DSS
  • Required by all entities that store, process,
    transmit cardholder information
  • PCI Compliant requires an entity to comply with
    all PCI DSS requirements
  • PCI DSS compliance is dependent on
  • Merchant or service provider level
  • Payment brand compliance validation and reporting
    requirements
  • University requirements for compliance
  • Non compliance can result in fines levied by
    credit card companies against merchants,
    processors and acquiring banks
  • Merchant Compliance Requirements
  • Understand the PCI DSS standards and compliance
    requirements
  • Sufficient technical knowledge in the security
    domains covered by PCI DSS
  • Understand credit card business processes and
    data flows
  • Identify systems and processes subject to PCI DSS
    assessments
  • Comply with requirements of the PCI DSS standards
  • Understand and comply with University e-commerce
    standards
  • Complete PCI DSS self-assessment and remediate
    gaps found
  • Acquiring Banks Compliance Requirements (Vantiv)
  • Requirement 11 Regularly test security systems
    and processes.
  • Vulnerabilities are being discovered continually
    by malicious individuals and researchers, and
    being introduced by new software. System
    components, processes, and custom software should
    be tested frequently to ensure security controls
    continue to reflect a changing environment.
  • Requirement 12 Maintain a policy that addresses
    information security for all personnel.
  • A strong security policy sets the security tone
    for the whole entity and informs personnel what
    is expected of them. All personnel should be
    aware of the sensitivity of data and their
    responsibilities for protecting it. For the
    purposes of Requirement 12, ?personnel? refers to
    full-time and part-time employees, temporary
    employees, contractors and consultants who are
    ?resident? on the entitys site or otherwise have
    access to the cardholder data environment.


16
Module 2
PCI DSS Standards Framework
SAQ A Card Not Present All Cardholder Data
Functions Outsourced
The Self-Assessment Questionnaire (SAQ) The
SAQ is a self-validation tool for merchants and
service providers who are not required to do
on-site assessments for PCI DSS compliance. The
SAQ includes a series of yes-or-no questions for
compliance. If an answer is no, the university
must state the future remediation date and
associated actions.
  • SAQ A has been developed to address requirements
    applicable to merchants who retain only paper
    reports or receipts with cardholder data, do not
    store cardholder data in electronic format and do
    not process or transmit any cardholder data on
    their systems or premises.
  • SAQ A merchants do not store cardholder data in
    electronic format, do not process or transmit any
    cardholder data on their systems or premises, and
    validate compliance by completing SAQ A and the
    associated Attestation of Compliance, confirming
    that
  • Your company accepts only card-not-present
    (e-commerce or mail/telephone-order)
    transactions
  • Your company does not store, process, or
    transmit any cardholder data on your systems or
    premises, but relies entirely on a third party(s)
    to handle all these functions
  • Your company has confirmed that the third
    party(s) handling storage, processing, and/or
    transmission of cardholder data is PCI DSS
    compliant
  • Your company retains only paper reports or
    receipts with cardholder data, and these
    documents are not received electronically and
  • Your company does not store any cardholder data
    in electronic format.
  • SAQ A includes 13 questions.

SAQ Description
A Card not present (e-commerce or mail / telephone order) merchants, all cardholder data functions outsources. This would never apply to face to face merchants.
B Imprint-only merchants with no electronic cardholder data storage, or standalone, dial out terminal merchants with no electronic cardholder data storage
C-VT Merchants using only web-based virtual terminals, no electronic cardholder data storage
C Merchants with payment application systems connected to the Internet, no electronic cardholder data storage
D All other merchants not included in descriptions for SAQ A through C above, and all service providers defined by a payment brand as eligible to complete an SAQ.
17
Module 2
Self-Assessment Questionnaire (SAQ)
  • SAQ B has been developed to address requirements
    applicable to merchants who process cardholder
    data only via imprint machines or standalone,
    dial-out terminals.
  • SAQ B merchants only process cardholder data via
    imprint machines or via standalone, dial-out
    terminals, and may be either brick-and-mortar
    (card-present) or e-commerce or mail/telephone
    order (card-not-present) merchants. Such
    merchants validate compliance by completing SAQ B
    and the associated Attestation of Compliance,
    confirming that
  • Your company uses only an imprint machine and/or
    uses only standalone, dial-out terminals
    (connected via a phone line to your processor) to
    take your customers payment card information
  • The standalone, dial-out terminals are not
    connected to any other systems within your
    environment
  • The standalone, dial-out terminals are not
    connected to the Internet
  • Your company does not transmit cardholder data
    over a network (either an internal network or the
    Internet)
  • Your company retains only paper reports or paper
    copies of receipts with cardholder data, and
    these documents are not received electronically
    and
  • Your company does not store cardholder data in
    electronic format.
  • SAQ B includes 29 questions.

SAQ B Merchants with Only Imprint Machines or
Only Standalone, Dial-Out Terminals. No
Electronic Cardholder Data Storage.
  • SAQ C-VT
  • Merchants with Web-Based Virtual Terminals, No
    Electronic Cardholder Data Storage
  • SAQ C-VT has been developed to address
    requirements applicable to merchants who process
    cardholder data only via isolated virtual
    terminals on personal computers connected to the
    Internet.
  • This SAQ option is intended to apply only to
    merchants who manually enter a single transaction
    at a time via a keyboard into an Internet-based
    virtual terminal solution. SAQ C-VT merchants
    process cardholder data via virtual terminals on
    personal computers connected to the Internet, do
    not store cardholder data on any computer system,
    and may be brick-and-mortar (card-present) or
    mail/telephone-order (card-not-present)
    merchants.
  • Such merchants validate compliance by completing
    SAQ C-VT and the associated Attestation of
    Compliance, confirming that
  • Your companys only payment processing is done
    via a virtual terminal accessed by an Internet
    connected web browser
  • Your companys virtual terminal solution is
    provided and hosted by a PCI DSS validated third
    party service provider
  • Your company accesses the PCI DSS compliant
    virtual terminal solution via a computer that is
    isolated in a single location, and is not
    connected to other locations or systems within
    your environment (this can be achieved via a
    firewall or network segmentation to isolate the
    computer from other systems)
  • Your companys computer does not have software
    installed that causes cardholder data to be
    stored (for example, there is no software for
    batch processing or store-and-forward)
  • Your companys computer does not have any
    attached hardware devices that are used to
    capture or store cardholder data (for example,
    there are no card readers attached)
  • Your company does not otherwise receive or
    transmit cardholder data electronically through
    any channels (for example, via an internal
    network or the Internet)
  • Your company retains only paper reports or paper
    copies of receipts and
  • Your company does not store cardholder data in
    electronic format.
  • SAQ C-VT includes 51 questions.

18
Module 2
Self-Assessment Questionnaire (SAQ)
  • SAQ C
  • Merchants with Payment Application Systems
    Connected to the Internet, No Electronic
    Cardholder Data Storage
  • SAQ C has been developed to address requirements
    applicable to merchants whose payment application
    systems (for example, point-of-sale systems) are
    connected to the Internet (for example, via DSL,
    cable modem, etc.) either because
  • 1. The payment application system is on a
    personal computer that is connected to the
    Internet (for example, for e-mail or web
    browsing), or
  • 2. The payment application system is connected to
    the Internet to transmit cardholder data.
  • SAQ C merchants process cardholder data via POS
    machines or other payment application systems
    connected to the Internet, do not store
    cardholder data on any computer system, and may
    be either brick-and-mortar (card-present) or
    e-commerce or mail/telephone-order
    (card-not-present) merchants.
  • SAQ C merchants validate compliance by completing
    SAQ C and the associated Attestation of
    Compliance, confirming that
  • Your company has a payment application system and
    an Internet connection on the same device and/or
    same local area network (LAN)
  • The payment application system/Internet device is
    not connected to any other systems within your
    environment (this can be achieved via network
    segmentation to isolate payment application
    system/Internet device from all other systems)
  • Your company store is not connected to other
    store locations, and any LAN is for a single
    store only
  • Your company retains only paper reports or paper
    copies of receipts
  • Your company does not store cardholder data in
    electronic format and
  • Your companys payment application software
    vendor uses secure techniques to provide remote
    support to your payment application system.
  • SAQ C includes 40 questions.

SAQ D All Other Merchants and All Service
Providers Defined by a Payment Brand as Eligible
to Complete an SAQ SAQ D has been developed for
all service providers defined by a payment brand
as eligible to complete an SAQ, as well as
SAQ-eligible merchants who do not meet the
descriptions of SAQ types A through C,
above. SAQ D service providers and merchants
validate compliance by completing SAQ D and the
associated Attestation of Compliance. While many
of the organizations completing SAQ D will need
to validate compliance with every PCI DSS
requirement, some organizations with very
specific business models may find that some
requirements do not apply. For example, a
company that does not use wireless technology in
any capacity would not be expected to validate
compliance with the sections of the PCI DSS that
are specific to managing wireless technology.
SAQ D includes 288 questions.
19
Module 2
SAQ Instructions and Guidelines
20
Module 2
PCI DSS Compliance Approach
  • Step 1 Assess
  • Goal Identify technology and process
    vulnerabilities posing a security risk of
    cardholder data transmitted, processed or stored
    by the university.
  • Step 1.1 - Study PCI DSS Standard - Learn what
    the standard requires of the business
  • Step 1.2 - Inventory IT Assets and Processes
  • Identify systems, personnel, processes involved
    in transmission, processing, storing cardholder
    data.
  • Determine how cardholder data flows from
    beginning to end of the transaction process.
  • Check versions of personal identification number
    (PIN) entry terminals and software to ensure they
    are PCI compliant.
  • Step 1.3 - Find Vulnerabilities - Use the
    appropriate SAQ to guide the assessment, and
    technologies to locate insecure systems
  • Step 1.4 - Validate with Third-Party Experts -
    May require a Qualified Security Assessor (QSA)
    and/or Approved Scanning Vendor (ASV) to execute
    proper assessment.
  • Note Liability for PCI compliance extends to
    third parties involved with the process flow, so
    we must confirm that they are compliant.
  • Step 2 Remediate
  • Goal Remediation is the process of fixing
    vulnerabilities including technical flaws in
    software code or unsafe practices in how the
    university processes or stores cardholder data.
  • Step 2.1 - Scan your network with software tools
    that analyze infrastructure and spot known
    vulnerabilities
  • Step 2.2 - Review and remediate vulnerabilities
    found during on-site assessment (if applicable)
    or through the Self-Assessment Questionnaire
    (SAQ) process
  • Step 2.3 - Classify and rank the vulnerabilities
    to help prioritize the order of remediation, from
    most serious to least serious
  • Step 2.4 - Apply patches, fixes, and changes to
    unsafe processes and workflow
  • Step 2.5 - Re-scan to verify that remediation
    actually occurred
  • Note Remediation should occur as soon as
    practical when a vulnerability is discovered via
    the Assessment process (Step 1).
  • Step 3 Report
  • Regular reports are required for PCI compliance
    these are submitted to the acquiring bank and
    card payment brands that you do business with.
  • PCI SSC is not responsible for PCI compliance.
  • All qualifying merchants and processors must
    submit a quarterly scan report, which must be
    completed by a PCI approved ASV.
  • Businesses must submit an annual Attestation
    within the Self-Assessment Questionnaire (SAQ).

21
Module 2
Merchant Levels and Compliance Validation
Service Provider Levels and Compliance Validation

Level Merchant Criteria Validation Requirements
1 Merchants processing over 6 million Visa transactions annually Annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA) or internal auditor if signed by officer of the company Quarterly network scan by Approved Scanning Vendor (ASV) Attestation of Compliance Form
2 Merchants processing 1 million to 6 million Visa transactions annually Annual Self-Assessment Questionnaire (SAQ) Quarterly network scan by ASV Attestation of Compliance Form
3 Merchants processing 20,000 to 1 million visa e-commerce transactions annually Annual SAQ Quarterly network scan by ASV if applicable Attestation of Compliance Form
4 Merchants processing less than 20,000 Visa e-commerce transactions annually Annual SAQ recommended Quarterly network scan by ASV if applicable Compliance validation requirements set by acquirer
Level Validation Action Validated By
1 Annual On-site PCI Data Security Assessment Quarterly Network Scan Qualified Security Assessor (QSA) Approved Scanning Vendor (ASV)
2 Annual PCI Self-Assessment Questionnaire Quarterly Network Scan Service Provider Approved Scanning Vendor (ASV)
  • Level 1
  • All Third Party Processors (TPPs) and Data
    Storage Entities (DSEs) that store, transmit or
    process less than 1,000,000 combined MasterCard
    and Maestro transactions annually.
  • Additionally, All compromised TPPs and DSEs
  • Level 2
  • All DSEs that store, transmit or process less
    than 1,000,000 combined MasterCard and Maestro
    transactions annually

Note UMASS is designated as a Level 3 Merchant
but we report as a Level 2 Merchant
22
Module 2
Payment Application Data Security Standard
(PA-DSS)

Assessing Environments with PA-DSS Applications

PA -DSS Overview
  • PA-DSS is a comprehensive set of requirements
    designed for payment application software vendors
    to facilitate their customers PCI DSS
    compliance.
  • Distinct but aligned with OPCI-DSS
  • PA-DSS applies to third party applications that
    perform authorization and/or settlement.
  • PA-DSS does not apply to payment applications
    that are typically sold and installed off the
    shelf without much customization by software
    vendors.
  • PA-DSS does not apply to payment applications
    provided in modules, which typically includes a
    baseline module and other modules specific to
    customer types or functions, or customized per
    customer request.
  • PA-DSS does not apply to a payment application
    developed and sold to only one customer since
    this application will be covered a part of the
    customers PCI DSS compliance review.
  • PCI-DSS does not apply to payment applications
    developed by merchants and service providers if
    used only in-house (not sold to a third party).
  • PA-DSS does not apply to operating systems onto
    which a payment application is installed,
    database systems that store cardholder data or
    back-office systems that source cardholder data.
  • Use of PA-DSS compliant application by itself
    does not make an entity PCI-DSS compliant
  • PA-DSS validated payment applications are
    included in the scope of a PCI-DSS assessment
  • The assessor should not challenge the PA-DSS
    validation
  • PCI-DSS assessment of validated payment
    applications should verify the payment
    application is implemented into a PCI-DSS
    compliant environment and the payment application
    is implemented according to the PA-DSS
    Implementation Guide
  • All other system components in scope for PCI DSS
    must still be assessed
  • The assessor should focus their assessment on the
    applications implementation in accordance with
    the vendors implementation guide.

23
Module 2
Roles Responsibilities

  • Merchant Service Providers
  • Review and understand the PCI Security Standards
  • Understand the compliance validation and
    reporting requirements defined by the payment
    card brands
  • Validate and report compliance to acquirer or
    payment card brand
  • Maintain ongoing compliance, not just during
    assessment
  • Read and incorporate communications from the
    payment brands, acquirers, and the PCI SSC
  • Internal Security Assessors
  • Validate the scope of the assessment
  • Verify all technical information given by
    stakeholders using independent judgment to
    confirm requirements have been met
  • Provide support and guidance during the
    compliance process
  • Be on-site for the duration of any relevant
    assessment procedure
  • Review the work that supports the assessment
    procedures
  • Ensure adherence to PCI-DSS Requirements
  • Select business facilities and system components
    for sampling
  • Evaluate compensating controls and produce final
    report
  • Approved Scanning Vendor (ASV)
  • Perform external vulnerability scans via PCI-DSS
    Requirement 11.2
  • PCI Security Standards Council
  • Maintain PCI-DSS, PA-DSS, PTS, P2PE, and PIN
    Security standards and supporting documentation
  • Define, implement validation requirements for
    QSAs, PA-QSAs, ASVs, ISAs
  • Approve companies and their employees to perform
    PCI DSS Assessments, Payment Application
    Assessments, ASV Scanning
  • Maintain list of validated payment applications,
    P2PE solutions, PIN transaction security devices,
    QSA, PA-QSA, ASV companies
  • Offer training for the QSAs, PA-QSAs, ASVs, and
    ISAs
  • Promote PCI security on a global basis
  • Payment Card Brands
  • Development and enforcement of compliance
    programs
  • Fines or penalties for non-compliance
  • Endorse QSA, PA-QSA and ASV company qualification
    criteria
  • Accept validation documentation from approved
    QSA, PA-QSA, and ASV companies and their
    employees
  • Provide feedback to council on QSA, PA-QSA and
    ASV performance
  • Forensic investigation and account data
    compromise
  • Qualified Security Assessor (QSA)
  • Validate the scope of the assessment
  • Conduct PCI-DSS assessments

24
Module 3
UMASS e-Commerce Committee Security Council
  • Roles and Responsibilities
  • UMASS Campus / Presidents Office e-Commerce and
    Information Security Representative
  • Roles and Responsibilities Merchant Compliance
    (Campus and Presidents Office)
  • Manage campus merchants inventory spreadsheet
    and compliance WorkShare site
  • Manage campus merchants annual Self Assessments
    Questionnaires (SAQs)
  • Manage campus merchants QSA Security Assessments
    (new implementations)
  • Manage campus merchants Quarterly Scans (if
    applicable)
  • Manage campus merchants annual PCI DSS training
  • Manage campus merchants ongoing communications
    and updates (as needed)
  • UMASS Presidents Office e-Commerce and
    Information Security Representative
  • Roles and Responsibilities QSA Contracts and
    Statement of Work (SOW)
  • Manage QSA (Lighthouse, DRG) Statement of Work
  • Manage QSA and ongoing communications and updates
    (as needed)
  • UMASS Presidents Office e-Commerce and
    Information Security Representative

25
Module 3
UMASS Merchant and Service Provider Compliance
Checklist
  • Merchants Compliance Checklist
  • New install requirements
  • All new Merchant Installs must include a
    documented PCI Security Assessment completed by a
    Qualified Security Assessor (QSA) either
    Lighthouse or DRG.
  • This requirements is for new on-line
    installations that are using software in lieu of
    or in addition to CyberSource or Commerce Manager
    (non-traditional configurations)
  • Annual re-certification requirements
  • The campus representatives are responsible for
    maintaining the Merchant inventory (with the
    cooperation of the Merchants)
  • All Merchants must attest by completing the
    appropriate SAQ, with University of
    Massachusetts Treasurers Office - Treasurers
    Fiscal Procedure No. 08-01 including all
    requirements of Section A Operational, Section
    B Inventory, Section C PCI Compliance, and
    Section D Online Third Party Requirements.
  • All Merchants must attest and provide evidence of
    compliance with PCI Self-Assessment Questionnaire
    (SAQ) Type A, B, C-VT, C, or D as appropriate.
    The Treasurers office will distribute a
    university developed questionnaire to be
    completed and returned by the merchants.
  • All Merchants (as required) must complete and
    provide Quarterly Vulnerability Scan results.
  • All Merchants must complete and provide evidence
    of completion the University of Massachusetts PCI
    training (see note).
  • Note This is a new requirement starting April,
    2012.
  • Service Providers Compliance Checklist
  • Annual re-certification requirements
  • All Service Providers must complete and sign the
    necessary contracts to attest that they are
    authorized Third Party Service Providers for the
    University of Massachusetts before services are
    engaged. Annually, they must provide evidence of
    their PCI compliance to the University of
    Massachusetts.

26
Appendix
UMASS Self Assessment Questionnaire Type A (SAQ
A) Card Not Present All Cardholder Data
Functions Outsourced
  • SAQ A Merchants Requirements
  • Such merchants validate compliance by completing
    SAQ A and the associated Attestation of
    Compliance, confirming that
  • Handles only card-not-present (e-commerce or
    mail/telephone-order) transactions
  • Does not store, process, or transmit any
    cardholder data on your systems or premises, but
    relies entirely on third party service
    provider(s) to handle all these functions
  • Has confirmed that the third party(s) handling
    storage, processing, and/or transmission of
    cardholder data is PCI DSS compliant
  • Retains only paper reports or receipts with
    cardholder data, and these documents are not
    received electronically and
  • Does not store any cardholder data in electronic
    format.
  • Treasurers Fiscal Procedure No. 08-01
  • Section A A.1, A.2, A.5, A.6, A.8
  • Section B B.1, B.2, B.3
  • Section C C.1, C.6, C.7, C.8, C.9

27
Appendix
UMASS Self Assessment Questionnaire Type B (SAQ
B) Merchants with Only Imprint Machines or Only
Standalone, Dial-Out Terminals. No Electronic
Cardholder Data Storage.
  • SAQ B Merchants Requirements
  • Such merchants validate compliance by completing
    SAQ B and the associated Attestation of
    Compliance, confirming that
  • Use only imprint machines and/or uses only
    standalone, dial-out terminals (connected via a
    phone line to your processor) to take your
    customers payment card information
  • The standalone, dial-out terminals are not
    connected to any other systems within your
    environment
  • The standalone, dial-out terminals are not
    connected to the Internet
  • Do not transmit cardholder data over a network
    (either an internal network or the Internet)
  • Retains only paper reports or paper copies of
    receipts with cardholder data, and these
    documents are not received electronically and
  • Does not store cardholder data in electronic
    format.
  • Treasurers Fiscal Procedure No. 08-01
  • Section A A.1, A.2, A.5, A.6, A.8
  • Section B B.1, B.2, B.3

28
Appendix
UMASS Self Assessment Questionnaire Type B (SAQ
B) Merchants with Only Imprint Machines or Only
Standalone, Dial-Out Terminals. No Electronic
Cardholder Data Storage.
29
Appendix
UNIVERSITY OF MASSACHUSETTS TREASURERS
OFFICE Treasurers Fiscal Procedure No.
08-01 Effective Date March 1, 2012 Fiscal
Standard and Procedure E-Commerce and PCI
  • Section A Operational
  • Overall
  • Campus merchants (departments) may not store in
    any manner full 16 digit credit card numbers
    (PAN).
  • Unprotected PAN (Primary Account Number) should
    not be sent via end-user messaging technologies
    including but not limited to email, instant
    messaging, text message, or social media.
  • All requests for credit card receipt copies and
    chargebacks must be processed immediately.
    Failure to respond before the deadline will
    result in the chargeback being processed by the
    card company. Credit card copies must mask all
    but the first six and last four digits of the
    account number (PAN) prior to transmission.
  • Point of Sale
  • Credit card terminals must be batched out daily.
  • Campus merchants (departments) may not store in
    any form the magnetic strip, which consists of
    track data, CVV2 data or PIN data.
  • University Records Retention Policy states that
    we must retain all credit card receipts for three
    years. PCI Standards also require that these
    records be classified by labeling as
    Confidential and stored securely. These
    receipts should not contain the full PAN (Primary
    Account Number). At the end of three years they
    must be properly disposed of by being cross-cut
    shredded, incinerated, or pulped. Containers
    storing documents to be destroyed should have a
    lock preventing access to its contents.
  • To process a credit for a point-of-sale terminal,
    ideally you should have the card present and
    swipe it through the terminal.  If the card is
    not present then there should be communication
    with the cardholder to get the full number to be
    used to enter into the terminal.  There should
    not be storage of full card numbers in any
    format.
  • Online
  • Electronic records containing cardholder data
    should not contain the full PAN. If you receive
    a report containing the full PAN please contact
    your campus eCommerce representative immediately
    for instructions on permanently deleting the
    file.
  • All credits specific to CyberSource applications
    must be processed online through the University
    Treasurers Office within 60 days of the original
    transaction and are based on a transaction
    reference number. Card number is not required.
    Beyond 60 days, credits can be processed manually
    by the receiving site or as a stand-alone credit
    through the Treasurers Office.
  • Section B Inventory
  • Each campus must maintain a complete and accurate
    inventory of all credit card processing locations
    including point of sale and online merchants.
    The campus is also responsible for maintaining an
    inventory of documentation regarding third party
    vendors contracted to process credit cards.
    Process flows and technology configuration should
    be documented and updated as needed.
  • Campus E-commerce representatives must be
    involved in and approve any decisions to accept
    credit cards or other electronic form of cash
    receipts.
  • It is recommended that each campus maintain an
    inventory of all outsourced vendors that process
    credit card payments. Proof of their PCI
    compliance should be provided no less than
    annually.
  • Section C PCI Compliance
  • Administrative
  • Campus E-commerce representatives and Campus
    Bursars will work with departments to provide the
    necessary guidance in the areas of PCI
    Compliance, internal controls (including
    restricting access to cardholder data), deposit
    techniques and reconciliation.
  • E-commerce representatives have the authority to
    suspend the account of a merchant who is not in
    compliance with the University of Massachusetts
    Fiscal Standard and Procedure E-Commerce and
    PCI.
  • Failure to follow the PCI DSS standards for
    credit card merchants subjects the University to
    fines and penalties. Any fines will be the
    responsibility of the campus.
  • Use of any unauthorized or non-compliant third
    party credit card processing vendors must be
    immediately terminated.
  • Any department accepting credit card payments in
    any format is required to complete the
    appropriate PCI SAQ (Self-Assessment
    Questionnaire) annually.
  • Transmission of quarterly scan results and the
    annual SAQ will be sent and tracked by the
    Treasurers Office to the acquiring bank.
  •  

30
Appendix
UNIVERSITY OF MASSACHUSETTS TREASURERS
OFFICE Treasurers Fiscal Procedure No.
08-01 Effective Date March 1, 2008 Fiscal
Standard and Procedure E-Commerce and PCI
  • Section C PCI Compliance
  • Point of Sale
  • All broken and discontinued POS terminals must be
    returned in a secure manner to the University
    Treasurers Office for disposal.
  • Departments are responsible for ensuring they
    only use PCI compliant POS terminals and must
    replace any non-compliant or obsolete terminals
    at their own expense.
  • POS terminals should only be used on campus. If
    a business need arises to take the terminal off
    campus departments must obtain approval from
    their campus eCommerce Representative prior to
    taking a terminal off campus. The requesting
    department must be able to confirm the connection
    type that will be used at the outside venue and
    agree to monitor the terminal at all times and
    keep it securely locked when not in use.
  • Online
  • CyberSource and NelNet have been identified as
    the third party vendors of choice for all online
    activity. Any deviation from the use of
    CyberSource or NelNet must be approved by your
    campus Vice Chancellor for AF as well as the
    E-commerce Committee. All third party vendors are
    subject to the same standards for data compliance
    and security. Proof of PCI compliance must be
    provided on an ongoing basis. Proof will be
    provided no less than annually.
  • Third party installations other than CyberSource
    or NelNet must be reviewed by a QSA (Qualified
    Security Assessor) prior to accepting payments.
    The QSA deliverable should be a written report
    stating that the installation was installed in a
    PCI compliant manner. Additionally, campuses
    should periodically review these installations to
    confirm ongoing compliance.
  • All new payment applications must be listed on
    the PCI list of Validated Payment Applications.
    If the application is not listed the campus must
    provide the University Treasurers Office with a
    PABP Implementation Guide to help ensure that
    once the application is implemented it is in
    compliance. This will demonstrate that the
    application was developed under PABP guidelines
    and that their environment is PCI compliant.
  • All charge card applications written in-house
    must be developed using VISAs PABP, Payment
    Application Best Practices and validated to be
    PCI compliant before going live.
  • Any department processing online credit card
    payments must work with their campus IT Security
    Department to determine if they will need to
    complete and submit quarterly scans.
  • Section D Online Third Party Applications
  • All third party credit card processing vendors
    are subject to PCI DSS Standards. In addition
    they may be subject to quarterly network scans
    that must be performed by an Approved Scanning
    Vendor (ASV). The completion of annual
    self-assessment questionnaires is required. It is
    the responsibility of the campus to monitor and
    maintain current documentation.
  • Outside (third party) vendors must be listed on
    the PCI list of Validated Payment Applications or
    if not listed, they need to submit documentation
    from their QSA to the campus stating that they
    are PCI compliant and the date specific to that
    compliance. This document must be updated
    annually.
  • All new contracts with third party or outside
    vendors must contain language requiring that the
    vendor be PCI compliant and they will remain PCI
    compliant throughout the term of the contract.
    If the third party vendor is not the payment
    processor, their contract language must state
    that they will only use a PCI compliant payment
    processor throughout the term of the contract.
    Failure to do so gives the University the right
    to terminate the contract at no penalty to the
    University of Massachusetts.
  • All new contracts with third party or outside
    vendors must contain language that the vendor
    acknowledges that they are responsible for the
    security of cardholder data that they possess.
  • Campuses are responsible for ensuring that third
    party vendors remain PCI compliant throughout the
    term of the contract.

31
Appendix
PCI DSS Terminology
Approved Scanning Vendor (ASV) - is a
vulnerability assessment provider who provides
automated software tools for scanning for
vulnerabilities. Cardholder - Non-consumer or
consumer customer to whom a payment card is
issued to or any individual authorized to use the
payment card. Cardholder Data - At a minimum,
cardholder data consists of the full PAN.
Cardholder data may also appear in the form of
the full PAN plus any of the following
cardholder name, expiration date and/or service
code. Internal Security Assessor (ISA) - The
ISA Program provides eligible internal security
audit professionals PCI DSS training and
certification that will improve the
organizations understanding of the PCI DSS,
facilitate interactions with QSAs, enhance the
quality, reliability, and consistency of PCI DSS
self-assessments, and support consistent and
proper application of PCI DSS measures and
controls. The Payment Application-Data Security
Standard (PA-DSS) - A global security standard
created by the Payment Card Industry Security
Standards Council, or PCI SSC, formed by the
major credit-issuing companies with the goal of
delivering an effective and useful data security
standard to vendors of payment application
systems. The intent of this standard is to
effectively prohibit secure data from being
illegally accessed by unauthorized
parties. Payment processor - An organization
that processes payment requests, such as credit
card authorizations and settlements, to the
appropriate card associations per their
guidelines. Your merchant banks processor
relationship determines which payment processor
you will use. Payment gateway - An organization,
such as CyberSource, that enables merchants to
securely send and receive order information to
and from payment processors in the appropriate
format. PCI Compliant - refers to an
organization that has become compliant with the
PCI DSS and has demonstrated this either through
a Self Assessment Questionnaire or through formal
validation (audit) by a QSA firm. PCI DSS - Data
Security Standard a document consisting of 12
requirements and various principles all designed
to provide a framework to protect payment card
data and systems.
PCI SSC Security Standards Council - the global
governing body for payment card security
standards. Responsible for developing, managing,
education, and awareness of the PCI Security
Standards including Data Security Standard (PCI
DSS), Payment Application Data Security Standard
(PA-DSS), and PIN Transaction Security (PTS)
Requirements. Primary Account Number (PAN) -
is essentially a payment card number (16 19
digit) which is generated according to the LUHNS
algorithm). Qualified Security Assessor (QSA)
is a Information Security and PCI expert who
works for a QSA firm and who has been certified
by the PCI SSC to be fit and proper to validate
whether a company / environment is PCI
compliance Report on Compliance (ROC) - the
report on compliance refers to a report that
shows that an environment has been validated by a
QSA in accordance with the PCI DSS. The outcome
of the validation assessment may result in a
Report of Compliance opinion of Compliant or Not
Compliant depending the evidence provided to
support the compliance assertions provided by the
merchant or service provider to the QSA
Self-Assessment Questionnaire (SAQ) A
validation tool for merchants and service
providers that are not required to undergo an
on-site data security assessment per the PCI DSS
Security Assessment Procedures. The purpose of
the SAQ is to assist organizations in
self-evaluating compliance with the PCI DSS, and
you may be required to share it with your
acquiring bank. There are multiple versions of
the PCI DSS SAQ to meet various business
scenarios. Service Provider - An entity that
stores, processes or transmits cardholder data on
behalf of merchants. Examples of service
providers include hosting and payment services
for merchants. Such providers do not have direct
service provider contractual relationships with
acquiring institutions, other than for their own
merchant activities, but nonetheless still fall
into scope for the PCI DSS where they store,
process or transmit payment cards on behalf of
merchants. It is the merchant responsibility to
ensure the service providers operate in a way
that is complaint with the PCI DSS. Validation /
Audit - refers to the final stage of PCI
compliance whereby a Qualified Security Assessor
(QSA) will validate and attest the compliance
status of the environment under assessment for
compliance with the PCI DSS. Vulnerability
Assessment is a technical security audit that
uses automated tools to test for security flaws,
mis-configurations and weaknesses in
infrastructure and applications (to a relatively
limited extent).
32
Appendix
Useful PCI DSS References
PCI DSS Overview video http//abcnews.go.com/Vi
deo/playerIndex?id4769169 (How Thieves Are
'Stealing You) Treasurers office e-commerce
standards http//media.umassp.edu/massedu/treasu
rer/Principles20--02272008final20on20letterhead
1.pdf PCI Security Standards Council
https//www.pcisecuritystandards.org/ PCI Quick
Reference Guide https//www.pcisecuritystandards.
org/pdfs/pci_ssc_quick_guide.pdf Documents
Library https//www.pcisecuritystandards.org/sec
urity_standards/documents.php?document2.02.0 Cer
t
About PowerShow.com