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! VICS uses AIX login security as the primary basis of all of our security. We actually extend the security, but it all starts with an AIX login and password, which is something you know, and hence meets PA-DSS requirements for the software. You, however, to be PCI compliant must set the AIX users up with rules that force the correct behavior. As usual, VICS can set this up for you at your request.

Specific recommendations:

1) Make passwords expire no less often than 90 days

2) Use 3-6 user id lengths

3) Use passwords of 7 or more characters

4) Complex passwords mean mix letters and numbers and punctuation in a meaningless manner. For example if your name is Torris then T0rr1s! is NOT a good password as it has an easily guessed meaning and some bad person could guess it easily enough.

5) Make sure you set it so that old passwords cannot recycle such that they cannot reuse a password for at least four changes. AIX keeps a history of passwords to do this.

6) Set up the system to limit repeated login attempts that fail. This is to keep someone from repeatedly hacking the account. The recommendation is that the account lock out after no more than 6 failures.

7) You can set the lockout to be permanent until root resets it, or you can set a "time out." In AIX this is in seconds and PCI requires 30 minutes which is 1800 seconds. NOTE: this is the only place where IBM's "high level" security is not more than sufficient for PCI Compliance. They recommend 300 seconds or 5 minutes. Go with the stricter PCI requirements. Or just lock it until root clears it, which I prefer. 8) Do not set AIX to end your session if you are idle. This could kill programs while running and is not good. For example if you where archiving A/R which can take 8 hours, and AIX logged you out after 15 minutes, the archiving would stop. Instead, in the Metropolis Data Base user setup where we extend the O/S security, enter a "lockout" time of 15 minutes or less (this number is in minutes). The lockout allows the program to continue but forces you to re-enter your password to actually use the screen again. Set the timeout option to lockout only. Note that if you plan to leave your desk you can manually lock it with Alt-. (the Alt key and then the period symbol).

This should all be done under the AIX login management, and Metropolis login management. The easiest way in AIX being under "smit" and in Metropolis under "User Maintenance". Good documents from IBM are listed below. If you use the "high level" security and follow the rules above you should easily be able to obtain PCI compliance (except see #7 above). If in doubt, ask VICS and defer to IBM's recommendations.

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/security_standards/documents.php

Please note -- nothing in our software requires root access or any specific group nor any generic or shared accounts. And we strongly advise against using them. Do not configure in such a way.


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 XML Commander 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, and our preference, is that you should be using two-factor authentication. Using a VPN is one way, and you will need to provide us with unique certificates. We also have the ability to setup telnet of SSL and give access only to the server we manage, and then use AIX security for the second factor (login/password). We have our own self-signed certificate for this purpose, we prefer you send us a unique one from your system. Please section 8 of the PC standards in detail.

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/security_standards/documents.php

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. Here is the standard:
4.1.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices (for example, IEEE 802.11i) to implement strong encryption for authentication and transmission. Note: The use of WEP as a security control was prohibited as of 30 June 2010.

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.

In addition to the direct logging of the actual credit card server, the CV objects log activity. This includes logging of changes or deletions or other access to sensative data. These are largely not possible to disable on some level, a few are optional. Please discuss with VICS which activity logging you are interested in.

All logging may be centralized by turning on a feature of Metropolis that allows all Metropolis log entries of all types to be routed to the syslog daemon. This daemon can route the logging to another machine, it can put the logging in various different files by the level and facility, and a lot of other fancy AIX stuff. We suggest you get some generic software (which can be found on PCs) to analyze the syslog logs and look for unusual activity.

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/security_standards/documents.php

      • 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://www.pcisecuritystandards.org/security_standards/documents.php. 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