“Compliance is not something that’s bought; it’s a process. It never ends, and it needs to stay in lock step with the changes happening in a dynamic business. Understanding direct costs will probably require additional headcount to pull proper reports and document the program. It also may require investment in some software tools to mine through all the data that is generated by systems, networks and applications.”

One goal of this article series was to provide a reliable “bottom line” financial investment in becoming and maintaining PCI compliance. The more I learned about the industry that specializes in compliance the more difficult it was to find solid, or even estimated, pricing. What I found easliy matched the research that was released by Gartner and reported in the PCI DSS Compliance Blog.

“Level 3 merchants, those processing between 20,000 and one million transactions per year, spent an average of $155,000, excluding security assessment.”

In doing this article series, I gained a better understanding for both our internal security procedures (electronic keyed entry, guests signed in, frequent password changes, etc.) as well as the job that Warner and his team does to make sure that every transaction that passes through our network is as secure as current technology allows. Warner was an amazing resource for this series. When I came to the point where the PCI regulations seems beyond comprehension, or a solution was difficult to find, they were able to clarify the instructions or give direction to products or services that would help. I likely would have given up the series at the 3rd article if I didn’t have access to a group that manages these details daily.

Even though I am finished with this series, and will not have to actually become PCI compliant personally, PCI compliance doesn’t actually ever end. If we were really starting a business with a traditional merchant account, we would just be getting started at this point. As the PCI DSS Compliance Blog perfectly states :

“PCI compliance is dynamic, requiring ongoing adaptation.  PCI compliance starts with a set of 12 basic requirements, it continues with vigilance and adaptation, and it ends with….well, it doesn’t end.”

Further Reading:

Clearing the Mystery of PCI Compliance (Part 1)
Clearing the Mystery of PCI Compliance (Part 2)
Clearing the Mystery of PCI Compliance (Part 3)
Clearing the Mystery of PCI Compliance (Part 4)
Clearing the Mystery of PCI Compliance (Part 5)
Clearing the Mystery of PCI Compliance (Part 6)
Clearing the Mystery of PCI Compliance (Part 7)

Requirement 12: Maintain a policy that addresses information security

This part of the standard lists more policies we have to implement and more procedural documentation to write. A complete list of specific policies and documentation we need is here. Given the scope of this requirement, I can give some general information about complying with this standard, but I cannot cover every portion of the requirements. Some examples of policies that require documentation are:

• Formal Risk Assessment and Risk Management Program
• Security Awareness Program
• Usage Policies for all end-user technologies and company resources
• Incident Response Plan

This standard, more than any other forces us to think about what we will do in the event of an attack on our network, or when our security is compromised either externally or internally. We need to know what to do in the event an attack is identified. How do we respond? Who is in charge of our response? What response capabilities do we have internally? Do we need to involve outside experts?

This also includes company directives such as the establishment of a security team, security education for all employees, and pre-employment screening. At this point in our small company of one, we still need to have these policies and procedeures in place and documented. As we grow we can spend more time revising them in the future(since we already have to review and update our policies regularly).

Reading the PCI DSS requirements, we see many areas calling for documentation for various systems and procedures relating to the use and storage of our customers’ information.  Among the requirements are the following:

• Data Retention and Disposal Policy
• Anti-Virus Policies and Procedures
• Password Management rules
• Firewall Policies and Procedures
• Change Management Guidelines

The documentation directly above will be useful in complying with this final PCI requirement, but they do not replace it. This is, in essence, the culmination of the previous eleven standards. Requirement 12 establishes how all of the above work together to create our over-arching security policy. In addition to formalizing established policies and their interaction, we need to establish daily, quarterly and annual audits of our users, our system updates, and a formal risk assessment. For example, checking our logs for potential employee security violations and purging users/employees who no longer require access.

In a few weeks I will recap what I learned during this exercise in meeting PCI DSS compliance. I will be extending this article series to provide more details on just how much time is involved in meeting the PCI standards. While there are significant hardware and software investments in meeting the requirements, time, I found, was my greatest investment.

Further Reading:

Clearing the Mystery of PCI Compliance (Part 1)
Clearing the Mystery of PCI Compliance (Part 2)
Clearing the Mystery of PCI Compliance (Part 3)
Clearing the Mystery of PCI Compliance (Part 4)
Clearing the Mystery of PCI Compliance (Part 5)
Clearing the Mystery of PCI Compliance (Part 6)

Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes

The reason we need to have individual logins mentioned in last week’s article is so that we can limit, monitor, and track access to network resources and cardholder data. In the event of a security breach, these records allow us to find whose account was used to compromise the data and mitigate the damage done to our customers. We need to audit all accesses to customer data, review audit logs each day, and be able to reconstruct events that touch cardholder information. We also need to be able to provide detailed audit trails for all administrative events. An attempt to change system configuration for malicious purposes will be captured and can be traced back to the user. A central logging solution along with the policies we developed previously will allow us to track internal access to our network and record actions that take place.

Auditing of network access attempts and tracking of access logs is a critical aspect of this requirement. Most operating systems have very basic utilities that monitor and record events. For the most part, the event browsing and filtering capabilities provided by these utilities are restricted and will not meet PCI standards. For instance, unauthorized access to a customer’s information will not, by default, alert anyone that the event has been logged, it will only be discovered later when someone does an audit. Because of these limitations, we will need to look for some companies to provide us with some assistance.

Thankfully, we can find a number of Security Information Management (SIM) products that maintain comprehensive log management. These tools can automate collecting data, issue needed alerts, and give very detailed reports. SIMs will will also help give us a baseline of normal network activity. We can use this information to establish rules to categorise events. When an event happens that falls outside of these rules a SIM can trigger an alert letting us know of potential security violations. Many security information management products also provide default rule sets that classify events according to PCI requirements.

Now we need to plan to test our network and security measures at least once each year. It is important to note that we cannot use actual customer data for these tests. While your computer may be safe now, new ways to compromise your computer and new vulnerabilities are constantly being developed or discovered. It is important to test your systems and your network to make sure your customers’ information is as safe as it can be. This is not the same as testing new applications as discussed previously.

When it comes to scanning our systems for vulnerabilities, we need to use the right tools and techniques to expose vulnerabilities in devices on both wired and wireless networks. There are a number of security risks linked to wireless devices, weak encryption methods, and the lack of employee security awareness. Therefore, we need to test everything that touches customer information – from how easily our network can be compromised to how we access the data. The Payment Card Industry requires that we have a “PCI approved” company perform an external scan of our system to determine our general safety.

It is important that our software and hardware gets regularly patched with the latest security updates. In addition to the regular patching process, our network and applications can be protected from security threats by the consistent use of vulnerability scanners that can see all of the applications and devices on the network, identify vulnerabilities, and supply information to resolve these vulnerabilities. However, scanning our network will not reveal every potential vulnerability. To be aware of our ability to detect and counter any unwanted access to our systems, we need to perform a penetration test that measures how well we can respond to and withstand an attack. This test exploits vulnerabilities so we can determine the actual risk to our specific system of any particular vulnerabilities. PCI requires an annual external penetration test. This test is in addition our regular scanning and audits of our security logs.

To comply with these particular PCI requirements, we will need to provide some financial investment in a Security Management System and a vulnerability scanner. We will also need to invest time finding a specialist to perform a penetration test correctly. Thankfully, we decided to  have our firewall and software applications automatically update with security fixes. This lets us be sure that what we are testing is the most up-to-date security for our particular system.

Costs:

Central Logging Solution – Starts $5,000
Security Information Management – I found many companies willing to offer quotes, but no baseline costs.
Quarterly external scan – As above, due to the complexity and variety of networks, pricing will be highly varied
Vulnerability Scanner – Roughly $1,200 per year
External penetration tests minimum $10,000 per year, likely much more than that

Further Reading:

Clearing the Mystery of PCI Compliance (Part 1)
Clearing the Mystery of PCI Compliance (Part 2)
Clearing the Mystery of PCI Compliance (Part 3)
Clearing the Mystery of PCI Compliance (Part 4)
Clearing the Mystery of PCI Compliance (Part 5)
Clearing the Mystery of PCI Compliance (Part 7)

First, we need to make sure that our computers, firewall, and any other devices we have are all updated with vendor-supplied security patches. We also need to make sure that we install any future updates within one month of release. In our example, we have agreed to a contract with our firewall  and anti-virus manufacturers for a years worth of free updates. Our web browser and operating systems will also provide us with security updates. So this is already covered. Good thing we think ahead! It is our responsibility to make sure we are aware of new security threats and take steps to counter them. It isn’t a good idea to rely on one source of information, one example of a free threat alert is from Bugtraq. Your anti-virus vendor should also provide you with updated threat reports. There are others, and I recommend checking at least two alerts every day.

Now, we need to make sure that our new updates, or any other new applications for that matter, will work on our network. Unless you are comfortable working on your network alone, you will need to hire a system admin for this. We need to have a completely separate environment to develop and test all security patches and system and software configuration changes before deployment. We need this separation because we cannot use or endanger our customers’ information. If a new piece of code for our shopping cart ends up being a security risk, it’s best to find that out before our customers use it. So, separate environments for all development, new programs, everything except processing the live sales.

After testing the updates, creating a back out plan and verification process (assuming they all work with no security risks) we are ready to move them over into the “live” environment. While you have your network admin available you will want to establish a variety of procedures for when you need to make changes using your new development environment. Essentially, you need documentation stating what is being developed/tested, who recommended the development, and what testing is being done to make sure it’s safe.

If we develop or use web software and applications we need to make sure they are based on secure coding guidelines such as the Open Web Application Security Project guidelines. We have to review custom application code to identify coding vulnerabilities for each new piece of code or application we use/update. This requirement also covers the prevention of common coding vulnerabilities in software development such as buffer overflows, improper error handling, insecure storage, and the dread denial of service. This is by no means a complete list of what we need to cover, but it gives a good place to start.

I have already established my limited knowledge regarding networking, so I looked for estimates on how long it will take for a network admin to complete this project. Unfortunately, different networks and needs make estimating this job particularly difficult. The minimum estimation I have is roughly 60 hours, but they can easily go as high as 300 – 500 hours.

Now that we have our network protected with AV software and a testing/development environment to make sure that everything is secure for our customers, we should be just about finished meeting the PCI standards. Well, we are half way through – the end is in sight.

Bottom Line for Steps 5 and 6:

Time:
Networking – 100 – 500 hours

Cost:
Business level Anti-Virus Software: $500-$700 (Includes one year’s worth of updates)
Network Admin $1,000 – $5,000 minimum. People who specialize in PCI Compliance often charge $250+ each hour of work.

Further Reading:

Clearing the Mystery of PCI Compliance (Part 1)
Clearing the Mystery of PCI Compliance (Part 2)
Clearing the Mystery of PCI Compliance (Part 3)
Clearing the Mystery of PCI Compliance (Part 5)
Clearing the Mystery of PCI Compliance (Part 6)
Clearing the Mystery of PCI Compliance (Part 7)

Requirement 3: Protect stored cardholder data
Requirement 4: Encrypt transmission of cardholder data across open, public networks

We have provided a secure network to collect and store our customer’s information. Now, we need to turn our attention to the data itself. To fulfill requirement 3, we need to come up with a policy detailing how we will store card holder data. This sounds easy enough, just make a few decisions and stick with them. However, this is actually a bit more complicated as the PCI-DSS FAQ explains. There are 20 different criteria to meet. While I suggest reading the linked FAQ some highlights are:

• 3.1 Keep cardholder data storage to a minimum.
• 3.2 Do not store sensitive authentication data after authorization (even if encrypted).
• 3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block.
• 3.3 Mask PAN (Personal Account Number) when displayed (the first six and last four digits are the maximum number of digits to be displayed).

I have to admit, after reading what is involved with this portion of PCI compliance, I nearly gave up. This part of PCI compliance doesn’t really have a cost that can easily be measured in money. The cost is in time – hours and hours of time spent looking over what information is stored, where it is stored, how long it should be stored, what systems are used to backup that data, etc. it gets exhausting.

As you become familiar with the standard, you will need to figure out what data you must keep on hand and how long would be a reasonable amount of time to keep that data. The longer you keep the data, the more risky and potentially costly it becomes in the unfortunate event the data becomes compromised. Generally, to comply with requirement 3, you need to understand that all information you collect from your customers must be protected. This means that you can only store a limited amount of the data, and the data you do store must be encrypted (see below).  A simple overview of the requirements for card data storage encryption can be found here.

Requirement 4 is a little more straightforward. While most people recognize the need to encrypt sensitive information during transmission over networks that are easily accessed by malicious individuals, few recognize the importance of encrypting information sent between back-end systems. This also means that stored information needs to also be encrypted.

Encryption is the most effective way to achieve data security by translating data into a secret code. Essentially, both stored and transmitted data must be made unreadable. The most common method used by credit card processors to protect high speed transactions is a network security protocol called Secure Socket Layer(SSL).

To get an SSL certificate you will first need to choose a certificate that matches your specific needs. Then you need to generate a Certificate Signing Request (CSR) for the site. For example, I found a site selling a certificate for a single domain for $600.00/year. This is on the low end for SSL pricing considering that it comes with a warranty, re-issuance, and provides features I like (priority phone support and regular security audits). I should also note this is a 2Checkout supplier.

If someone were to access our network from the previous article, we want to have protections in place that both limit their access to our customer’s information and makes any information they may access unreadable. Complying with the second set of requirements provides another layer of security for our customers.

Bottom Line for Step 2

Time:
Hours and hours – Literally HOURS and HOURS

Cost:
SSL Certificate: $250-$700+/ year

Further Reading:

Clearing the Mystery of PCI Compliance (Part 1)
Clearing the Mystery of PCI Compliance (Part 3)
Clearing the Mystery of PCI Compliance (Part 4)
Clearing the Mystery of PCI Compliance (Part 5)
Clearing the Mystery of PCI Compliance (Part 6)
Clearing the Mystery of PCI Compliance (Part 7)