The first subrequirement is 1.1 defined as establishing firewalls and routers configuration standards based on Subrequirement 1.1’s subrequirements.  Firewalls and routers control outside access into the network and what information goes out of the network.  They also control access privileges allows to groups of users.  To better understand how networks work, watch the following 3d videos. While the movies are somewhat old, they give a basic understanding of network routers/switches and firewalls. Pay particular attention to the section on routers and firewalls at the top of the TCP/IP stack.

www.youtube.com/watch?v=x9XWxD6cJuY

You’ll note in the above video that the router and switches movie the informational packets around on the internal company network. These routers and switches must be correctly configured to grant or deny access to certain portions of the network. They can be located inside the network and just outside the network.

You should also note the Network Interface or Proxy (also known as a Proxy Server). The packet content is inspected as it goes into and out of the internal network. If you saw the unacceptable address which is “summarily” dealt with, the information regarding unacceptable addresses must be configured by a systems administrator for the proxy server. This would fall under this subrequirement 1.1.

The firewall is another layer that looks at the IP (information) packets to examine the content. Towards the end of the presentation, the firewall is configured for ports 80 and 25. The ports are similar to doors. Some doors are open and other doors are closed.  Configuring which doors are open and closed is up to a systems administrator or network administrator. The same goes for the internal firewall policeman.

Firewalls and routers can either be software based and/or hardware based. This simply means that they are either physical plugged in hardware which probably requries some configuration and/or software based or both. While this is all very well, configuring them is the core of Requirement 1.1.  The requirement clearly states a “standard” or basically a policy for configuring the firewalls and routers within a secure network. A company needs policies and procedures in place to have staff correctly configure the routers and firewalls to work as a cohesive unit in a network. It also supplies documentation that substantiates a company’s procedures.

It’s important to note that a QSA (Qualified Security Assessor) will ask for documentation and diagrams of the firewall/router and network configurations. This helps them determine the scope of the network that must be compliant and what policies and procedures are being followed. The documentation itself is a requirement as well as the network configuration. The QSA will test the network against the documentation as well as security scans and tests.

In my next post, I’ll begin detailing the rest of Subrequirement 1.1.

PA DSS stands for Payment Applicatin Data Security Standard. In July 2010 all merchants using a third party payment application must be using a PA DSS certified application. Be aware that all merchants must currently be PCI Compliant which includes other methods and procedures to attain. Simply using a PA DSS certified application does not make a merchant PCI compliant.

Any application licensed for use by a third party that collects , processes or stores card data is in scope of PA DSS. Getting compliant with PA DSS means that application vendor has followed standard security implementations outlined by OWASP. It also means the specific version has been tested in a “laboratory” by a PA DSS QSA certified by the PCI Security Standards Council. 

There is confusion about what organizations must certify their applications, particularly open source vendors. The key is in the wording; Software vendors and others that develop secure payment applications that are sold, distributed, or licensed to third parties. While open source vendors do not sell their applications, they are distributed and licensed to third parties. Quite often the application is also drastically altered by third part developers for their clients.

The first key component is to not store sensitive information after authorization. While some applications might store the data then delete it after authorization, the QSA testing procedure centers around determining if that data has been deleted and is unrecoverable either through debug or log files.  A QSA might try to generate error conditions that cause error logs to be saved on a server where they can be extracted by other means.  Any and all historical data that may retain the credit card data must be deleted.  If credit card data is stored, it must be protected. Expired data must be securely purged from the system. 

The point being that even if an application does not store credit card data inside a database, it does not mean that the data is not stored somewhere. There are other requirements for PA DSS and we will cover them in future installments herre on PCI Guard Dog.

As mentioned in my previous post, the PCI Security Standards Council was founded by 5 major card brands: Visa, MasterCard, JCP, Discover and American Express. It was based on their separate programs as I mentioned.  The PCI SSC was founded to develop the standards by which everyone would measure how securely they would be keeping credit card holder data. Card Holder Data (chd) as it is known in the industry consists not only of the credit card number but the magnetic stripe data held on the card and the code on the back of the card. 

Part One: Determine Your Organization’s Role 

The first part is to understand your organization’s role within PCI. Since most organizations can become members of the PCI SSC, they can participate in developing the standards by which compliancy is measured.

 The Credit Card Brands determine the level of requirements for compliance under their own individual companies. Currently merchants are divided into 4 groups, Levels 1-4. However, each of the Credit Card Brands use different numbers to determine which level a merchant or service provider may fall within those levels.  All service providers and merchants should be sure to read over the individual Credit Card Brand company programs to understand which level they fall under.

Acquiring Banks are tasked with ensuring that their merchants are compliant with the credit card brand program requirements. They can be stringent or not depending on the bank. Some banks even have stricter requirements.

Service Providers fall in the same area as merchants as both must be compliant.  Service Providers offer services to help the merchant through collecting, storing, processing, and transmitting card holder data.

Merchants are those organizations offering goods and services for cash or credit. They hold merchant accounts at Acquiring Banks. When a data breech occurs, the merchant is the first one responsible.

Part Two: Determine Your Organization’s Scope

If your organization stores, processes and/or transmit card holder data on any of it’s computers, equipment or people, your organization is within scope. Just because card data is not processed on a computer does not mean it is not in scope. If a person writes down a card number, that process falls within PCI Compliance and requires training and policies in place to handle that data. Writing a card number on a piece of paper constitutes storage.

Some organizations would argue that they are not storing any data in a database, just sending the data forward to a payment gateway. However, if the data passes through a computer program, it is vulnerable. The reason is that error and debug log files are prone to saving that data into a flat file which is a target by hackers. If the software handles the card holder data, it’s in scope.

Many of the companies working towards compliancy focus first on narrowing the scope by isolating networks handling card holder data from other networks. They also limit the number of people allowed to handled card holder data.

Part Three: Separating Development Roles Between People

This part of developing a pci compliant environment isn’t mentioned much around the internet. It’s still important. It’s also why the single web developer will not be developing pci compliant ecommerce websites.  The development requirements for networks and software require multiple people. The person who develops the software must be using a development network while the testers and the deployment developers must also use separate networks and machines. The key is to have different people double checking the work.

Part Four: Monitoring Continuancy

Once everything is done, people are of the mindset that they are compliant and do not have to do anything else. This is not the case. PCI Compliance is an ongoing process requiring monitoring and fixing of systems as soon as a problem occurs. It requires servers being patched on a timely basis, and software to be continually tested and upgraded as needed. The consequences are harsh. If a company is out of compliance at the time of a breech, fines, forensic costs and legal fees go into the 10s of thousands of dollars monthly. Compliance is an ongoing process not a once a year event.

I hope this brief overview helps everyone out. It’s a start towards understanding your responsibilities under PCI Compliance.

Visa’s program, Card Information Security Program or CISP was mandated by Visa in 2001. The program now centers around PCI DSS Compliance and compliance validation based on their own set of criteria. Members include financial institutions, merchants and service providers participating in the Visa payment system. Fines are levied against members who are found to be non-compliant at the time of data breach.  Wording on the website vaguely implies that that Visa may waive the fines if they are compliant at the time of breech but also further stipulates that members can prevent fines by staying compliant at all times.

The MasterCard SDP Program (Site Data Protection) was announced in 2001 with the goal of helping acquiring banks and merchants with their online systems.  SDP was a service offered by MasterCard rather than referring other companies to supply the service. Currently the program focuses on PCI DSS Compliance.  Acquiring banks verify PCI Compliance with each merchant depending on their level.

American Express Data Security Operating Policy was first implemented in 2002. American Express supports PCI DSS Compliance as a measure of minimum security. Note that upon perusing documenation, American Express indicates that a Level 4 merchant with another card logo acquirer may have a different level with American Express. Each company payment solution is separate from every other payment card.

The Discover Information Security & Compliance (DISC) program was developed prior to PCI Security Standards Council of which Discover is a founding member. The program designates Discover’s roles and responsibilities in regards to PCI DSS Compliance. Again, the company determines which members must be PCI compliant, determines validation and reporting requirements, enforces compliance and responds to data compromises.  This sums up what each company is doing in regards to PCI DSS Compliance.

The JCB Data Security Program was started at the JCB International, a company based in Asian countries. The documentation on their website is slight. It focuses on “recommending” that a company use their program and become PCI DSS Compliant. The wording might be reflective of a different culture from European and American cultures but the intent is the same. They develop requirements for compliance with the PCI DSS. And again. the acquiring banks where merchant accounts are established are in charge of enforcing the requirements on the merchants. 

These 5 major card brands started the PCI Security Standards Council which develops the standards of card holder data security. While the standards council develops the standards to which they all agree, each company has somewhat different requirements for compliance to the standards. Levels 1-4 merchants are defined somewhat differently by each company and require careful review. If a merchant accepts more than one brand, each brand’s compliancy requirements must be met to continue accepting that brand of credit card.

We’re getting ready to bring the information you need to get your clients PCI Compliant within their budget and within your abilities. We’ll review shopping carts, payment gateways, servers and provide you with news, events and updates under the PCI Compliance race.