SAQ 101: A final look at the series

by Dave Gavic
June 11, 2013 10:00AM

Now that we have touched on all 12 PCI DSS requirements, let’s have a final look at what this means for merchants in the ever changing world of information security.  No matter how long a merchant has been in business I would be shocked if they have never heard of PCI compliance. However, after speaking with so many merchants I understand why so many want to run for the hills when they hear those words.  I think the biggest fears today with merchants in regards to PCI compliance are time and money.  Implementing a compliance effort, especially on your own, will increase overhead and take up a considerable amount of time with zero revenue generated.  This can be true in the beginning, but once you get into the behavior of network security, physical security and critical data handling PCI will blend into your everyday business operations and not be so daunting.  By choosing to not meet PCI compliance requirements you are leaving your business vulnerable to a possible compromise which would likely end up costing much more than an initial PCI program, or even worse, costing you your business.

Technology is constantly evolving.  As a business owner you need to have a serious focus on keeping your customers’ critical information secure, not only to satisfy PCI requirements, but also to keep your business protected.  At the end of the day, it is ultimately the merchant’s sole responsibility to adhere to the PCI DSS.  Acquiring banks and processors have started to levy fines on merchants who are not PCI compliant and have even been known to take away the ability for some to accept credit/debit cards as a form of payment until the merchant can validate compliance.

We started this blog series well over a year ago.  We covered many aspects of PCI starting with basic terms, going all the way through processes and procedures in hopes of better informing merchants of network security and PCI compliance.  In my opinion, a merchant should strive to make PCI a regular part of their business operations instead of looking at it as a minimum requirement that must be checked off a list.  Just as technology is advancing, so are the malicious individuals that would like to gain access to your network and make off with your customers’ cardholder data.  (more…)

SAQ 101: Requirement 12

by Dave Gavic
May 22, 2013 1:00PM

Maintain an Information Security Policy

Requirement 12 of the PCI DSS: Maintain a policy that addresses information security for all personnel

Here we are at the 12th and final requirement of the PCI DSS. What a journey this has been.  Looking back, we discussed creating a secure network starting with a firewall at the perimeter, all the way down to limiting users’ access and having unique usernames and passwords for your staff.  The final step is to create an information security policy that will guide you and your staff through all of the processes and procedures of your business with security in mind.  Think of the information security policy as your rules and expectations of your staff. It is pertinent that everyone in the company, from top to bottom, understands the guidelines spelled out in the information security policy.  Let’s take a look at a few of the requirements in the PCI DSS that your information security policy needs to cover.

The very first point specified in requirement 12.1 is to establish, publish, maintain and disseminate an information security policy that addresses all PCI DSS requirements.  I believe that if this requirement is followed properly you will be setting yourself up to have true, consistent behavior in regards to security and not just a check box approach.

This brings me to the most important part of an information security policy: Training.  Requirement 12.6 reads:

Implement a formal security awareness program to make all personnel aware of the importance of cardholder data security.

I feel that having a proper training program set up for your employees is one of the biggest factors in successfully implementing a security policy.  If personnel are not educated about their security responsibilities, the security guidelines you have established may become ineffective through errors or unintentional actions.  The weakest point of an organization’s security is the end user.  If the end user is not trained or educated on security best practices, then critical data will be much harder to protect.  (more…)

PCI SSC Video – 3 Best Practices for Your Card Reader

by Kristyan Mjolsnes
May 10, 2013 4:20PM

The PCI SSC is determined to make certain all merchants are educated on the importance of credit card security and their series of short, entertaining videos may just be the trick. In previous blogs we highlighted their videos which introduced PCI compliance and discussed password protection. The third PCI SSC video in the series is on three security best practices in regards to card readers.

The three best practices involve:

  • The location of a card reader
  • Examining the card reader and connecting cords
  • Access to the card reader

Check out this third video in the PCI SSC’s Protecting Cardholder Data Is Good For Your Business video series:

(more…)

SAQ 101: Requirement 11

by Dave Gavic
April 25, 2013 10:00AM

Regularly Monitor and Test Networks

Requirement 11 of the PCI DSS: Regularly test security systems and processes

Requirement 11 is one of the more technical requirements of the PCI DSS that focuses on testing the Cardholder Data Environment (CDE) for vulnerabilities.  Some of the steps in this requirement will not be able to be completed by the merchant without some outside assistance.

To help you to better understand this requirement, I am going to first explain Requirement 11.2.2, which reads:

Perform quarterly external vulnerability scans via an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC). 

An Approved Scanning Vendor (ASV) is an organization approved by the PCI SSC which performs vulnerability scans on merchants’ CDEs.  External vulnerability scanning is a specific test that looks for weaknesses in a network’s perimeter that can be exposed or exploited by malicious individuals looking to gain unauthorized access into the network.  The PCI SSC has a specific list of rules and guidelines that an ASV must comply with in order to be certified by the PCI SSC to perform external vulnerability scanning for merchants in the pursuit of PCI compliance.  Currently the PCI SSC has a list of over 130 certified Approved Scanning Vendors that can be found at the PCI SSC’s website.  Having these external vulnerability scans run each quarter is only the beginning of what a merchant will need to do to meet requirement 11.

Now that you understand what external vulnerability scanning is, let’s go back to Requirement 11.2.1 which talks about internal vulnerability scanning.  (more…)

SAQ 101: Requirement 10

by Dave Gavic
March 20, 2013 2:15PM

Regularly Monitor and Test Networks

Requirement 10 of the PCI DSS: Track and monitor all access to network resources and cardholder data

Requirement 10 sounds like a daunting task and at times it can definitely feel that way if you do not have the necessary logging mechanisms in place.  In this installment of the SAQ 101 blog series we will go over what a log is, what needs to be logged and how logging can help to determine the cause of a possible network breach.  Without proper logging data, determining if, how and when your network has been compromised can be next to impossible.

The first base we need to cover is what logging is in a network security sense.  Logging is essentially a form of monitoring.  It is important that you have the ability to see all activity that occurs within your network and who is in your network at all times.  For example, if someone unsuccessfully tries to login to your workstation by guessing your password, that will create a log as a failed login attempt.  Merchants are required to keep track of all logs as well as check logs on a daily basis in order to maintain PCI compliance.  Regularly monitoring your logs is crucial and can be the difference between a breach lasting just a couple hours or a couple days, weeks or even months.

Requirement 10.1 states, “Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.”

It is critical to have a system that links users to the system components they access, especially for those with administrative privileges.  This system generates audit logs specific to each user and provides the ability to trace any suspicious activity back to the user that was involved.  This information is invaluable for post-incident forensics investigations.  (more…)

Learn More
Case Studies
Packages
PCI Compliance
PCI Questions
SecureConnect Blog
Webinars
Why SecureConnect
SecureConnect Scoop
About Us
Approved Scanning Vendor
Careers
Press Releases
Privacy Policy
Site Map
Terms of Use
Next Steps
Call Direct: 888.949.7328
Email Us
mySecureConnect Login
Receive Communications from us
Request a Free PCI Consultation
Send Informational Packet
Sign Up
Follow SecureConnect
Follow us with RSS feed RSS feed
Follow us on Twitter Follow Us
Follow us on Facebook Like us
Follow us on Facebook Company Photos
Visit our profile on Linkedin Follow us on LinkedIn