V . I . C . S ., LLC
HomeNew Features Contact Us LinksSecurity Recommendations

Also see:

  PCI Standards - The Scoop

  Software Security Changes

  Official Certification for VICS


Security Recommendations

The purpose of this disclosure is to inform you of minimum security recommendations.

Documentation on the PCI Data Security Standard has been sent to you previously, of which you must comply with in order to gain "safe harbor" (limit of liability) should your system be compromised and credit card data stolen. This disclosure has been broken down into several sections:

General Recommendations

  • Think about security.
  • Develop a written policy.
  • Follow that policy.

Security is not just in the VICS software, it is also in how you implement it, how you secure your network, and how you physically handle data such as backups and reports.

VICS is not going to make any recommendations for physical security beyond asking you to read, understand, and follow the PCI standards. This includes building access, backup control, report control, and more.

A NOTE on BACKUP SECURITY:

You are advised to be aware that backups of data (stored on tape or other media) from older versions of VICS products may contain unencrypted card data. For more information, please see section 1.1.5 of the PABP Implementation Guide.


Login & Password

Each user should have a unique user id and password (no sharing) and no one should use the "root" account unless doing system admin work. You should use complex passwords and have it periodically expire. You should administer your users and delete terminated employees. This is all especially true of the root user - use every trick in the book! This should all be done under the AIX login management, the easiest way being under "smit". A good document from IBM on what to do and how is:

http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.ai
x.security/doc/security/aix_sec_expert_login_policy_settings.htm

Make sure and follow the requirements of section 8 of the PCI requirements

https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf


Network Security

As usual, we continue to recommend that you keep your network secure by going through your network provider. Our general recommendations are to have a firewall that is well maintained, restrict access as much as possible with the firewall and logins, and use some sort of secure connection for anyone accessing sensitive data such as credit card data (such as using SSL or SSH or Secure VPN or two-factor authentication). You should restrict access to the main AIX server even further, including only allowing the Integrator access from your web server and from no place else. Be especially careful of any always-on services allowed on your AIX server. Also be especially careful of any remote access - try and use all the cool new technology that is now available to secure this access (such as VPN, SSH, and SSL mentioned above). Note that for proper PCI compliance you should be using two-factor authentication.

Use the operating features to harden security. Here is the IBM document on things you can do to harden security under AIX:

IBM: AIX Security Expert:
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.
security/doc/security/aix_sec_expert.htm

SecurityDocs.com: Implementing & Maintaining AIX Security Policies: http://www.securitydocs.com/library/3136/5

Auditnet.org: AIX Security Issues: http://www.auditnet.org/docs/AIXSecurityIssues.doc
PCI Security Standards: https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf

Use the application security features. Restrict access to credit card data severely. We still recommend that only the A/R Manager or equivalent be the only person allowed to enter new credit cards. Do not allow anyone root access. Do not allow anyone to run the one report that prints the full credit card number. Do not allow access except for the A/R Manager to programs to authorize A/R, settle batches, re-authorize, and so forth. Keep your exposure to a minimum.

Make sure you are running the soon-to-be-available validated version of our credit card application and MBA. Be aware that our software alone gets you no where near compliance - you must read and follow the standards.

Implement and use the AIX logs to determine who is accessing the system, or trying to access the system. In addition, please read the syserr.log and ablogfile logs - we do write them for a reason. These logs should all be enabled and saved, even if you chose not to read them, in case an audit of problems is required.

If you do ANYTHING wireless - make sure it is triple secure.

Please don't do anything to bypass our security design within our application. There is a reason we have your customers call with their credit card number and a reason we don't allow you to accept credit card numbers on your web pages. Do NOT move the credit card data off of your server for any reason. Do not allow the web server access. This is very important because design and practices are more likely to affect security than encryption and other software tricks.

Make sure your modems are disabled and that nobody can connect TO the system remotely. They are really for outgoing traffic only. If you ever need it for incoming, change the setting temporarily while it is in use, then disable it again. Please read the PCI standard for further details.

The default encryption for the credit card software is AES-128-CBC. This is the minimum level of encryption you should use. Unless you have a good reason, do not override this value in the visanet.ini file. If you want stronger encryption you may use AES-256-CBC but there are many other encryption algorithms that are not PCI compliant. If you insist on using another, please check for PCI compliance.

Do NOT allow card holder data to be sent by email. Tell your customers you do not want to receive card holder data in emails. Stick to our design, and make the customers call you with their credit card information. If you really insist on using email for this, you MUST use strong encryption. We do not recommend this.

Do not under any circumstance install our server software in the DMZ or anywhere else outside of your secure network. Access to the server software should only occur in a secure environment in order to be PCI compliant.

Logging Features

The debug logging features of the credit card application should be left turned off unless active debugging is occurring in conjunction with VICS. This is the "seebuf" log, and it should always be off as it would contain extremely sensitive data. Whenever this log is enabled the software will be operating in a non-PCI compliant mode.

The "event" logs should only be turned on if needed. The "authlog" contains only 4 digits of the card number and the "caplog" contains no card information and is less sensitive, but we still recommend leaving these logs off as well, even though it is likely PCI compliant with them on.

The "error" log should remain on. This is the visanet log and it contains only the error code from visanet. All logs are encrypted, but even as such, that does not make them 100% safe. Enabling the debug log would make the application not PCI compliant and should only be done when working directly with VICS.

Important Reminder!

VICS truly appreciates your cooperation in upholding these security recommendations. However, please remember that it is your own responsibility to follow the PCI standards and to ensure the safety of your data. Thank you.




PCI Standards - The Scoop!

Thanks to Lee Pierce at Security Metrics for the information provided below.


First..

..it's always good to ascertain your merchant/service provider/gateway status. Look at our http://www.securitymetrics.com/pci_intro.adp general page regarding services. You are probably only going to need our Quarterly External Vulnerability Assessment (VA) Scanning Site Certification, but you want to make sure and verify your status.

    Please read over these VISA web pages regarding:

If you have further questions regarding service providers and gateways, I can help you with that. Lee Pierce - lpierce@securitymetrics.com

    You may also want to look at the following from, the general PCI web page:

Second..

..let's look at what all merchants will need.

    Quarterly External Vulnerability Assessment (VA) Scanning

  • Security Metrics "Quarterly" Site Certification
    • 12-month service
    • PCI approved external vulnerability scanning
    • Online PCI self-assessment questionnaire
    • Scans performed automatically each quarter
    • Unlimited rescanning (by merchant; run the scan every day if you wish!
    • Unlimited calls to customer/technical support
    • User Control Panel to view test results, take questionnaire, initiate scanning and send compliance reports
    • Use of Site Certified logo on any website scanned
    • Acquirer reporting

You and your IT staff (as well as web host) should familiarize yourselves with the PCI Scanning Procedures Document. It can be downloaded from PCI's website:

    • PCI DSS Security Scanning Procedures
      https://www.pcisecuritystandards.org/pdfs/pci_scanning_procedures_v1-1.pdf

      • This document explains the purpose and scope of the Payment Card Industry (PCI) Security Scan for merchants and service providers who undergo PCI Security Scans to help validate compliance with the PCI Data Security Standard (DSS). Approved Scanning Vendors (ASVs) also use this document to assist merchants and service providers in determining the scope of the PCI Security Scan.

Our IP address, from which the vulnerability assessment will be running, is: 204.238.82.4

This should be communicated to the person(s) responsible for the web-server hosting your domain names, or for any Network IP addresses over which they administer. They may need to accommodate our IP address in their IDS/IPS system when external VA is running.

    Here are some specifics regarding our vulnerability assessment:

    Here is the link to our general information:

    And here is an overview of our "Site Certification" program:

    You can also download a Site Certification Report:


Six PCI Compliance Standards
  1. Build and Maintain a Secure Network
    • Requirement 1: Install and maintain a firewall configuration to protect cardholder data
    • Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

  2. Protect Cardholder Data
    • Requirement 3: Protect stored cardholder data
    • Requirement 4: Encrypt transmission of cardholder data across open, public networks

  3. Maintain a Vulnerability Management Program
    • Requirement 5: Use and regularly update anti-virus software
    • Requirement 6: Develop and maintain secure systems and applications

  4. Implement Strong Access Control Measures
    • Requirement 7: Restrict access to cardholder data by business need-to-know
    • Requirement 8: Assign a unique ID to each person with computer access
    • Requirement 9: Restrict physical access to cardholder data

  5. Regularly Monitor and Test Networks
    • Requirement 10: Track and monitor all access to network resources and cardholder data
    • Requirement 11: Regularly test security systems and processes

  6. Maintain an Information Security Policy
    • Requirement 12: Maintain a policy that addresses information security

While non-compliance penalties vary among major credit card networks, they can be substantial. Participating companies can be barred from processing credit card transactions, higher processing fees can be applied; and in the event of a serious security breach, fines of up to $500,000 can be levied for each instance of non-compliance.


PCI Requirements vs. "Taking your chances"

The risk is that a hacker can alter a NON-ecommerce website, making it appear that a purchase can be made by using methods such as Cross Site Scripting. An example might be that a hacker could place a link on one of your sites that invites the customer to "Buy Now". The link takes the customer to the hacker's domain, cleverly designed to look like your website. The customer then gives the hacker his/her credit card info. Phishing can also occur, where some social engineering can lead to the theft of cardholder data.

We have heard of instances where the Card Brands have chosen to fine a merchant who was compromised because they had not followed the rules of scanning EVERY active, public-facing IP address; EVEN when the portion NOT in compliance had nothing to do with the actual compromise.

On Visa's website they describe "Safe Harbor".
http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp.html#anch
or_9http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp.html#
anchor_9


Safe Harbor

Safe harbor provides members protection from Visa fines and compliance exposure in the event that its merchant or service provider experiences a data compromise. To attain safe harbor status:

  1. A member, merchant, or service provider must maintain full compliance at all times, including at the time of breach as demonstrated during a forensic investigation.
  2. A member must demonstrate that prior to the compromise their merchant had already met the compliance validation requirements, demonstrating full compliance.
  3. It is important to note that the submission of compliance validation documentation, in and of itself, does not provide the member safe harbor status. The entity must have adhered to all the requirements at the time of the compromise.
We have been told in the past that "full compliance" means EVERY active, public-facing IP address. Choosing not to have External VA running on information-only websites appears to be a risk you will have weigh. If you perceive that risk to be minimal, that's your call.

Here's some wording from the Security Scanning Procedures document (download from https://pcisecuritystandards.org/tech/supporting_documents.htm. It tells you to make the call, but again, I will state that there can be some risk of fines in the right circumstances, should there be a compromise ("Safe Harbor" wording).

PCI Security Scans may apply to all merchants and service providers with Internet-facing IP addresses. Even if an entity does not offer Internet-based transactions, other services may make systems Internet accessible. Basic functions such as e-mail and employee Internet access will result in the Internet-accessibility of a company's network. Such seemingly insignificant paths to and from the Internet can provide unprotected pathways into merchant and service provider systems and potentially expose cardholder data if not properly controlled.

Scope of PCI Security Scanning

The PCI requires all Internet-facing IP addresses to be scanned for vulnerabilities. If active IP addresses are found that were not originally provided by the customer, the ASV must consult with the customer to determine if these IP addresses should be in scope. In some instances, companies may have a large number of IP addresses available while only using a small number for card acceptance or processing. In these cases, scan vendors can help merchants and service providers define the appropriate scope of the scan required to comply with the PCI. In general, the following segmentation methods can be used to reduce the scope of the PCI Security Scan.

  • Providing physical segmentation between the segment handling cardholder data and other segments.
  • Employing appropriate logical segmentation where traffic is prohibited between the segment or network handling cardholder data and other networks or segments.

Merchants and service providers have the ultimate responsibility for defining the scope of their PCI Security Scan, though they may seek expertise from ASVs for help. If an account data compromise occurs via an IP address or component not included in the scan, the merchant or service provider is responsible.


"The premier operational and financial system for the sportswear distribution industry"
logo
MBA Applications
VICS, LLC © 2007  |  Terms Of Use  |  Updated on: Feb 6, 2007