Holiday Security Tips

holiday security, data security, data breach

How to protect your business from data breach and theft. 

data breach, security tips
Michael Simpson
(QSA, CISSP, CCNP)

Most wonderful time of year for criminals?

Winter holidays are synonymous with shopping. Black Friday, Cyber Monday, last minute Christmas gifts, and the like mean more transactions and more credit card spending. In fact, the Winter holiday months account for %19.7 of annual retail spending in the United States.

While the busyness and bedlam of the holidays can provide cover for cybercriminal activity, there are a few things your business can do to protect against data breaches this holiday season.

Bad security habits plus chaos equals crimes of opportunity. Because cybercriminals continually scan for the “lowest hanging fruit” in terms of exploitable security weaknesses, you can prevent a majority of successful breaches simply by practicing good data security habits:

holiday security, data security, data breach Follow the most current NIST password recommendations.


The organization recently overhauled its guidelines for password creation. They now advocate using easy-to-recall-but-lengthy “pass phrases,” in place of the traditional minimum-length, randomly generated passwords. Long passwords/pass phrases (at least 10 characters) made of common, memorable words are mathematically harder to crack than short passwords with added symbols and numbers. More tips for creating strong pass phrases.

Update software and systems. 


Many successful exploits are against unpatched systems or computers. After a vulnerability is known, and a corresponding patch is released, it’s critical that you update your systems. Typically, a critical patch should be updated on your systems within 30 days, but we recommend as soon as possible. Hackers will quickly craft exploits to match the vulnerability, because they know that most businesses won’t install patches in a timely manner—and for those that do, the patch may not reach all computers and devices. It’s good practice to have a member of your IT team assigned to stay on top of updates.

Review security procedures with staff. 


Phishing campaigns spike during the holidays because the transaction volumes create an environment of increased susceptibility to being deceived into opening an email and clicking on a link. Employees will likely receive emails (and increasingly, SMS texts) with fake coupons, malicious attachments, even spoofed shipping notifications and party invites. The aim of these schemes is to collect sensitive personal or corporate information or serve malicious malware. Make sure to review email and website security policies, guidelines, and procedures with employees, in addition to your regular security training.

Check for card data with discovery tools. 


Storing unencrypted cardholder data on a server poses a risk for the company. Once a hacker gets access to a system, stored unencrypted payment data makes it it’s easier for them to export and sell your customers’ credit card numbers and sensitive information. If you must store cardholder data, it is best practice to encrypt it while it is stored or transmitted. You should use a trusted card data discovery tool to find out if you are inadvertently storing plain text cardholder data anywhere on your systems or devices. 

If your company takes orders over the phone or mail, you should be sure that if cardholder data is written down, it is properly destroyed in a timely manner.

data security, holiday security Test website and network with vulnerability scanning. 


Companies don’t want to be inconvenienced in the middle of the busy holiday season with an emergency maintenance window in order to fix misconfigured firewalls, remove malware hazards or remote access vulnerabilities. A company should be proactive rather than waiting for a data breach to clue them in. Regular vulnerability scanning is an essential procedure that checks for vulnerabilities and security holes that could enable backdoors, buffer overflows, denial of service, and other types of malicious attacks which ultimately could cause downtime and prevent potential orders from taking place.

Avoid problems—prepare now


Transaction volumes during the holidays add complexity to the task of protecting corporate, customer, and personal data. Even so, industry-wide education and implementation of best practice security measures will go a long way toward minimizing the effectiveness of attacks and preventing data breaches. Sound security principles and proactive best practice implementation, policy and procedures will serve as the foundation for your business’s cybersecurity this holiday season. Avoid snags, upsets, delays—or a devastating breach—by getting into good security habits now.

Michael Simpson (QSA, CISSP, CCNP) is a Principal Security Analyst at SecurityMetrics and has been in the IT Security industry for 15 years. He has a Bachelor of Science in Computer Science and a Masters in Business Administration.




5 Security Best Practices for Protecting Your HIPAA-Compliant Data

hipaa, hipaa security, data security

What do these situations have in common?

  • April 2017: Augusta University Medical Center reported that it had become a victim of phishing for the second time within a twelve-month period. 
  • From December 2016 through early 2017, a trio of cybercrime rings took over 26,000 open MongoDB servers and demanded ransom
  • July 2017: A successful intrusion of Medical Oncology Hematology Consultants was detected, a breach which compromised 19,203 patient records
  • June 2017: Ransomware brought down Pacific Alliance Medical Center. Two months later, the firm said the attack impacted 266,123 patients.

Adnan Raja
These are all examples of HIPAA violations that took place in 2017. And each is a nightmare scenario healthcare organizations should hope to avoid. Forget the threat to credibility—including the much-dreaded Wall of Shame—the sheer expense of such a breach is overwhelming. The average drop in revenue at a healthcare firm after a data breach is $3.7 million.

Since these data breaches are more common and costly than many would like to think, this post will go over some HIPAA fundamentals and review security best practices for protecting HIPAA-compliant data. Here are a few tips and best practices your organization can integrate into your environment to help secure protected health information (PHI) that is under your watch:

1. Encrypt everything.

Encryption is critical. A study published in Perspectives in Health Information Management in 2014 examined all HIPAA breaches on file with the HHS Department. At the time of the report (which used all events through September 22, 2013), 27 million records had been compromised via successful attacks of 674 covered entities and 153 business associates. These breaches included intrusions related to hacking, improper disposal, loss, theft, and unauthorized access. They occurred in various digital environments—devices and back end systems—as well as physical documents.

The study provided data about types of breaches, and it reveals how rampant data theft is. Here are the top five types of breach in descending order of volume, with the number of individuals, covered entities, and business associates affected in each case—numbers that in the last few years have grown even more:

  1. Theft: 12,785,150 people (via 344 CEs and 52 BAs)
  2. Loss: 7,359,407 people (via 74 CEs and 23 BAs)
  3. Hacking or IT event: 1,901,111 people (via 59 CEs and 20 BAs) 
  4. Unauthorized access: 1,334,118 people (via 136 CEs and 44 BAs) 
  5. Improper disposal: 649,294 people (via 32 CEs and 5 BAs)

A major concern with “data breach by theft” isn’t the theft itself. In each of those cases, unencrypted information was left on the devices. Encrypting information means that even if bad actors steal digital information, encryption makes that information unusable. When encrypted correctly, ePHI may not fall under the Breach Notification rule, even when the system storing it is physically stolen.

2. Assess your risk.

hipaa, hipaa security, data securityConduct a complete risk assessment of all the elements of your ecosystem that store, process, or transfer electronic PHI (ePHI). Make sure to evaluate the ways in which your information could be exposed. If your environment includes a data center, you should ask these questions:

  • Are natural disasters common in the location of the data center? 
  • Is there a responsible party associated with all hardware components? 
  • Have you assessed the security mechanisms that are now in place and any risks that are present? 
  • Have you taken into account all ways in which ePHI is accessed or manipulated within your system? (Consider the creation, receipt, maintenance, and transfer of ePHI).

3. Training is fundamental.

You must properly train your staff, especially since the cybersecurity threat landscape is evolving, and comes with an increasingly sophisticated toolset for accessing your data. Phishing campaigns were created to elicit simple yet devastating mistakes from employees. If a staff member clicks on a link or submits data—like a username or a social security number—they essentially hand over the keys to your organization’s data environment. It’s scary but true that something as simple as a fake email could create a point of entry for attackers to exploit.

Keep in mind that no matter how extensive your training program is, people make mistakes. Back up your training program with technical security controls that prevent employees from installing malware or visiting spoofed websites.

4. Be vigilant and ready to act.

Although not fun to think about, it's critical to be prepared for the possibility of a breach. You need a planned response that is easy to execute, but thoroughly designed. The Office for Civil Rights’ checklist lists the steps of a proper response after a breach of HIPAA-protected material:

  1. Carry out your response and mitigation steps. 
  2. Stop the attack and contain the threat to privacy and security. 
  3. Report the incident to law enforcement. 
  4. Submit the relevant cyber threat indicators to federal and information sharing and analysis organizations (ISAOs).
  5. Notify the Office for Civil Rights quickly, within 60 days following the detection of a breach that compromised at least 500 people.

5. Read business associate agreements and find partnerships you trust. 

Due diligence will help you avoid making decisions that might leave you vulnerable. Whether your organization is a covered entity or business associate, you need to be certain that any vendor relationships related to PHI or ePHI are designed to protect the data as defined within HIPAA. Whenever you look at a new potential agreement, it’s important to check that the outside entity regularly scans its system for security risks. You also want to know that their staff has been properly trained, and that they have designated security and privacy officers.

While a business associate agreement is necessary from a legal standpoint, it won't protect you at a technological level. To make sure the systems themselves are properly secured and controlled, look to see if the provider has been validated for HIPAA compliance by a qualified, third-party assessor.
Do you need to secure your HIPAA data systems? It may help to put things into perspective to look at the experience of a single organization. See how Complete HealthCare Solutions followed the above best practices to secure their PHI and ePHI.

Author Bio: Adnan Raja has been the Vice President of Marketing at atlantic.net for 14 years. During Raja’s tenure, the Orlando-based, privately held hosting company has grown from having a primarily regional presence to garnering and developing attention nationwide and internationally. In collaboration with a skilled and dedicated team, Raja has successfully led a full spectrum of marketing campaigns, as well as handling PR work with major news outlets and the formation of key strategic alliances.



Network Penetration Testing 101

pen test, penetration test

Learn about Network Penetration Testing. 

pen test, penetration test
George Mateaki
QSA, PA-QSA,
CISSP, CISA
PCI DSS Requirement 11 calls for regular vulnerability scanning and penetration testing. Naturally, vulnerability scans and pen tests are sound security practices for any business—whether in the PCI/HIPPA realm or not. Regular scans will proactively identify vulnerabilities, and annual penetration tests will dive into the complexities of your network to find root causes and prescribe solutions.

The PCI SCC requires penetration tests whenever a business makes significant changes in their IT environment. For example, if you change from SSL to IPsec, or you introduce new network zones (new departments).

Whether you're building a network, or you're in your tenth year of PCI DSS certification, you'll need to pen test your network. Here's the info you need to get started:

What is a Network Penetration Test? 

pen test, penetration testPenetration testing in general is a type of "ethical certified hacking" during which a pen tester will attempt to enter and exploit your IT environments. There are a few types: Segmentation Checks, Application Penetration Tests, Wireless Penetration Tests, and Network Penetration Tests.

Segmentation Checks look for misconfigured firewalls. Application Penetration Tests find security issues that are due to application coding flaws. But when we pen test a network, we look for security issues in the design, implementation, and maintenance of servers, workstations, and network services.

SEE ALSO: Types of Penetration Testing; The What, The Why, and The How

Hackers will target anything that stores, processes or transmits credit card information or personal identifying information (PII). And if you're in the HIPAA realm, that includes protected health information (PHI). The location(s) at which you store this information are collectively known as the Cardholder Data Environment (CDE).

So, a Network Pen Test is mainly concerned with three areas:

  • The Cardholder Data Environment (CDE): servers.
  • The Corporate Zone: all employee devices. 
  • The Shared Services Area: supporting servers (logging, directory), IT admin.


What Will the Pen Tester Look For?

Network Penetration Tests commonly find the following security issues: misconfigured software, firewalls, and operating systems; outdated software and operating systems; Insecure protocols; unnecessary exposures.

To discover these problems, a professional penetration tester will first scour and test the perimeters of all the zones and areas, look at access points between them, and try to travel between zones that are not meant to connect. Then, they’ll test critical systems. This includes any technology that is not directly connected to the CDE but, if compromised, could give access to an attacker.

SEE ALSO: Network Penetration Testing Webinar

A pen tester looks for potential stepping stones. For example, they might look into the shared services zone, which includes employee devices. If a hacker compromised an employee device, could they then pivot and access the CDE? Could they "up" their privileges?

There are five stages of a professional pen test:

    pen test, pen tester, penetration testing, network penetration testing
  • High-level overview: understand the environment to be tested
  • Validate automated scans: look for indications of scan interference + eliminate false positives
  • Identify Issues: Is the protocol secure? And, on a given service:
    • Is the service still maintained?
    • What are the recommended steps for securing the service? 
    • What are security issues that have been recently identified and patched?
    • Are there common trends for how the service can be misconfigured?
    • Are there service-specific scanners or scripts? 
  • Exploitation: Determine actual impact of an issue. Attempt to pivot and exploit the trust relationship between the compromised and other servers. Attempt to escalate privileges.
  • Documentation: Record the results of the test in a deliverable. Include description of issues, targets affected and how exploiting the issues may affect the security of the organization. Provide risk rating and references for removing those risks.   

How Long Does a Network Pen Test Take?

It depends on your organization and its scope. For an average level 4 merchant, a network pen test should take 2-3 days. But for level 1 merchant who are processing millions of credit cards annually, could be a week or 2.

SEE ALSO: PCI Penetration Testing Data Sheet

Choosing a Penetration Test Provider

Not all pen testers are created equal. Some may advertise as professional pen tests but are basically glorified vulnerability scans. If you blindly trust, there’s a chance you’ll get shortchanged. So, it’s extremely important to engage with potential providers; talk to them and keep the dialogue honest. Pay attention to the questions they ask before quoting you. Do they understand--and can they cover--the scope and complexity of your IT environment? Find out whether they have specific experience or specialty in your type of network. Other questions to ask:

  • Do they have certifications? And not only are they certified, can they translate the theory behind certifications into application? 
  • How long have they been pen testing? Look for a seasoned vet. 
  • What reports will the penetration tester provide? If you’re seeking PCI compliance, make sure you talk to your QSA to understand what reports they need and will accept. 

Can I Do My Own Penetration Test?

It's possible, but not recommended. A penetration tester should be an outside, neutral party. The person finding the issues should not be the person responsible for fixing them. Naturally, there can be blind spots and assumptions.

SEE ALSO: BambooHR Annual Penetration Test Case Study

Why Network Penetration Tests are So Important

A pen test will give you a holistic view of what your security system truly looks like. Companies and merchants with poor security practices across their environment leave themselves vulnerable. If a company has an immature network with un-patched systems, it’s likely that the desktop systems are probably in a similar state.

Network pen tests are a necessary part of a healthy security culture. And, don’t forget other types of pen tests like segmentation checks, application penetration tests and wireless penetration tests. It helps to think of your pen tests and vulnerability scans as a way to cover as much of your environment as possible. Diversify your tests and scans for a more robust security practice. Repeating tests is okay, but trying a new type of test will add even more security.

At the end of the day, it’s not just cardholder information that a company needs to protect. It’s the company’s reputation. Whether it’s a small business or large corporation, hackers can deface websites, publicize sensitive info, or hold data ransom if and when they find an opportunity.

Schedule a penetration test here. 

George Mateaki (CISSP, CISA, QSA, PA-QSA) is a Security Analyst at SecurityMetrics with an extensive background in Information Security and 20+ years in IT.

Understanding the PCI SSC Multi-Factor Authentication Supplement

An in-depth look at the PCI Security Standard Council’s recent MFA guidance supplement and what it means for your organization.  


QSA, MFA, multi-factor authentication
George Mateaki
Security Analyst
QSA, CISSP

Moving toward true security 

In the wake of recent massive data breaches, foundational data security principles—like network segmentationstrong passwords, and multi-factor authentication (MFA)—are getting more attention from organizations, consumers and security experts.

The Deloitte data breach of September 2017 was recently tied to a lack of multi-factor authentication on an admin account. Aetna and Airbnb have announced they are shifting away from single-password authentication and towards strong, multi-factor authentication access for users of their apps.

MFA is also an important principle for any business’s internal operations, especially when it comes to remote access into a company’s cardholder data environment (CDE). There has been some confusion within the QSA community, the payments industry, and the data security/PCI compliance realm. In order to clear up confusion and offer help, the PCI Security Standard Council released a supplement in February of 2017 with additional guidance and clarification about MFA.

Even with the additional supplement, it can be confusing to keep all of the principles, terms, and definitions related to MFA straight. This post is intended to help our readers understand Multi-Factor Authentication, and the associated PCI SSC guidance, at both practical and conceptual levels.

Purpose of the MFA Supplement 

The bottom line? The PCI SSC wants to help secure remote user access. Remote access is still the biggest vector for an attack into sensitive data systems. But, strong MFA can keep criminals and hackers away from your systems.

This new supplement does not create any new requirements. Its intent is to provide further guidance and help people understand the underlying principles of security, so they can go the extra mile to truly protect their network. The overall security goal is clean, multi-factor authentication into a critical network/CDE, from anywhere outside of that network.

The supplement also does a great job of getting down to the details of MFA; it defines terms and compares authentication principles. It clears up some previous points of confusion, like what is really meant by “independence of factors,” “multi-step,” and “multi-factor.”

It’s important to note that MFA is not currently a requirement for PCI compliance. But, according to the supplement, “While PCI DSS 8.3 does not currently require organizations to validate their MFA implementation to all the principles described in this guidance document, these principles may be incorporated into a future version or future revision of the standard.” Work with your QSA now to look closely at your current MFA system, even though it may not be a requirement yet.

SEE ALSO: New Multi-Factor Authentication Clarification & Supplement: Principles You Should Know

MFA Basics

PCI DSS 3.2 requirement 8.3 says, “Multi-factor authentication requires an individual to present a minimum of two separate forms of authentication before access is granted.” In this case “two” is the minimum—not the maximum—number of factors required. For true MFA, you need at least two factors from at least two of these three categories:

Something only you know (password)
Something only you have (smart card, token)
Something only you are (fingerprint, ocular scan, face scan)

While you can add other types of factors to your MFA solution—like geolocation, time, IP address, or MAC address—they don’t count towards the two-factor minimum.

“Factor Independence”

To maintain factor independence:

  • Access to one of the factors can’t automatically enable access to an additional factor. For instance, if you want to use a laptop login as one factor, and an open SSH key certificate file stored on the same laptop (used to gain access to a remote server), that won’t work. You would need more server-side validated factors—like a google authentication. 
  • It’s best to physically separate your factors. Good example: a password is in your head, and a token is sent to a device. Bad example: you log in to your laptop, click on a link for remote access, and a password is added automatically from a password vault or single sign-in system. In that case, you wouldn’t maintain factor independence. 


The PCI Security Standard Council reiterates that factor independence is not a PCI DSS requirement at this time, but that we should be focused on increasing security, not just compliance. The guidance supplement can help us all move up to a higher level of security.

Out-of-Band Authentication

Factors communicated through separate, protected channels and are known as “out-of-band authentication,” e.g., through a cell phone, FOB, etc. Examples:

  • A remote user enters username and password, plus a one-time password sent to them on their smart phone. 
  • A remote user enters username and password, and then must use a unique dynamic number found on an RSA SecurID™ token 


Be mindful when using a smart phone or another device to make a remote connection on VPN or SSH. If you use the same device to login and receive a one-time password or google authorization, this negates your factor independence.

Also, be aware of who has possession of such a device. If your text message notifications pop up and display automatically on your phone screen, you could inadvertently show someone your second-factor token. It might just be a quick SMS text message with the token, but if not secured behind a lock or pin, it would invalidate the true principles of MFA.

Cryptographic Tokens

If you’re authenticating from a single device or channel, you can enforce independence of factors by using cryptographic tokens. Here are a few examples:


  • Store a token on a secure cryptographic environment like a SIM card, chip or USB, that could then be embedded directly into a device (like a laptop or cell phone, or tablet).
  • Sometimes a hidden SMS text message called over-the-air programming can be sent directly to a SIM card (if the SIM card has a secure element on it). This is not something the user would be interacting with, but it would be used to run an application that would ask for a pin or fingerprint, then send you a more complex token as a second factor. In that case, you would preserve the factor independence. 


There aren’t a lot of these solutions available currently, but we keep a look out for “secure environment” methodologies. And, there will be more coming in the future.

Protect Your Factors

Whatever your factor is, you have to protect it. If it’s “something you know,” you have to use strong password principles. If it’s biometric data or “something you are,” you have to make sure it can’t be replicated. And if it’s “something you have,” make sure you’re not sharing that data with someone else, for instance with coworkers.

Understanding Multi-Step vs. Multi-Factor

The principle that has caused the most discussion and confusion for QSAs is “multi-step vs. multi-factor” authentication. We want to make sure our readers understand this principle.

The PCI DSS itself has always stated that all factors have to be verified before full access to the network or an asset is granted. It is well-understood that if any of the factors fail, no access is granted. But, the MFA supplement goes on to say that your MFA solution cannot provide any clues as to which, if any, of the factors was a failure. This additional guidance is based on strong security principles, but it is not well-understood by the community. The misunderstanding has resulted in many MFA solutions that use the following pattern:

  1. Ask for a user name and password 
  2. If those work, enter a second factor (like a code sent through SMS text, google authorization number, or a fingerprint.)

If you type in a wrong password and then you’re not asked for the second factor (usually with an accompanying “sorry, that didn’t work” message), then the PCI Security Standards Council—as well as the National Institute of Standards and Technology (NIST) would consider that to be a multi-step, not multi-factor authentication. This is because all factors weren’t presented at the same time and before access was or wasn’t granted, so the user can surmise which of the two tokens failed.

For true multi-factor authentication, the pattern would need to ask you to submit the username/password and the second token at the same time. Then it could subsequently grant (or not grant) access. That way the user can’t know which of the two factors failed—the password or the token.

Many of you may be using a method similar to the first example. Our advice? Move away from that. Whether you’re a merchant, vendor, QSA—find a way to achieve true multi-factor authentication. It may be difficult to hear, but the truth is that large data compromises happen through insecure remote access every day.

SEE ALSO: 2 Things You Should Know about PCI 3.2 Multi-Factor Authentication Updates 

Examples of MFA 

The PCI SSC guidance document gives examples of some commonly used MFA solutions. Some are better than others. But, there are many more methods and configurations. You can work with your QSA to find the best solution for your organization.

Example 1:

  • An individual logs in to workstation/device, and accesses a software token stored on that device, with one set of credentials (password A). 
  • The individual then connects to the CDE/corporate network by using a different set of credentials (password B) and a “one-time password” generated by the software token as authentication.
  • If both factors are valid—something you know (password B) and something you have (software token)—the authentication system will grant access.


If you use this method: make sure the software token is embedded carefully. It can’t be moved to another physical device. Protect that physical device and maintain proof of possession by the user.

Example 2: 

  • An individual uses a set of credentials (password A) to log in to a workstation, and those credentials also provide access to a software token stored on the device. 
  • Then the individual launches a browser window that automatically prepopulates password B (either from a cache or a password vault). Password B is then used in conjunction with the one-time password to connect to the CDE/corporate network.


This is an example of a poor MFA solution, because it does not provide independence between the two authentication factors. Password B came from a password vault stored on the device, not from memory. So, password A provides access to two factors.

Example 3:

  • An individual uses one set of credentials (password A) to log in to a workstation
  • The individual then uses that same password (A) and a one-time password generated by a software token on their mobile device to connect to the CDE/corporate network. 


Even though the individual used the same password (A) to authenticate the workstation and the CDE/corporate network, the one-time password from the phone provided a second, physically separate factor. Note that if you use a mobile device to get a second factor; you shouldn’t use that same device to log in to the remote system. That would negate factor independence. In this case, the phone is the device used to receive the second factor, not the device used for login authentication.

Example 4: 

  • An individual uses multi-factor authentication (e.g., password and biometric) to log in to a smart phone or laptop.
  • The individual then provides a single authentication factor (e.g., another password, digital certificate, signed challenge response) to connect to the CDE/corporate network.


This is a good example, although likely uncommon. The individual enters two factors right when getting into the system, and then uses a signature or client certificate stored on the device to request access to the CDE/corporate network.

If you use this method: be sure there are always two factors required to log in to the device, and that there is no way to circumvent authentication of those two factors for login. This solution could be difficult in a “bring your own device” environment; if used in such an environment, the individual user-devices should maintain a robust isolated execution environment that can’t be adversely impacted or bypassed by the user.

SEE ALSO: PCI Requirement 8: Combatting Weak Passwords & Usernames

We’re all in this together

The main thing to remember about the PCI SSC’s MFA guidance document: it’s not changing the PCI DSS. However, we in the data security realm need to learn the attributes of our current solutions and think about security, not just compliance. Are you practicing the bare minimum to achieve PCI compliance? Or have you achieved true MFA? Evaluate your solution using the principles we’ve discussed here.

Remember that we’re all in this together. We need to be ready for future changes both to the standard and to the security environment as a whole. The PCI standard helps and guides us in our quest for security. As always, it represents the “floor” of data security, not the ceiling.

More questions about multi-factor authentication? Contact us.

George Mateaki (CISSP, CISA, QSA, PA-QSA) is a Security Analyst at SecurityMetrics with an extensive background in Information Security and 20+ years in IT.



PCI Requirement 11: Vulnerability Scans and Penetration Tests

Learn why you should include scans and pen tests in your info security program. 

By: Michael Simpson
Security Analyst
QSA, CISSP, CCNP
Whether you’re aware of it or not, your network likely has vulnerabilities hackers could exploit.

Defects in web servers, web browsers, email clients, POS software, operating systems, and server interfaces can allow attackers to gain access to an environment. Installing security updates and patches for systems in the cardholder or sensitive data environments can help correct many of the newly found defects and vulnerabilities before attackers have the opportunity to leverage them.

But in order to patch these vulnerabilities, you need to find them first. For that you need to implement vulnerability scanning and penetration testing.

The basics of vulnerability scanning

A vulnerability scan is an automated, high-level test that looks for and reports potential vulnerabilities. All external IPs and domains exposed in the CDE are required to be scanned by a PCI Approved Scanning Vendor (ASV) at least quarterly.

PCI DSS requires two independent methods of PCI scanning: internal and external scanning. An external vulnerability scan is performed outside of your network, and it identifies known weaknesses in network structures. An internal vulnerability scan is performed within your network, behind the firewall and other perimeter security devices in place, to search for vulnerabilities on internal hosts that could be exploited in a pivot attack.

Typically, these vulnerability scans generate an extensive report of vulnerabilities found and provides references for further research on the vulnerability. Some even offer directions to fix the problem.

Remember, regular scanning is just the first step. Act quickly on any vulnerabilities discovered to ensure security holes are plugged and then re-scan to validate that the vulnerabilities have been successfully addressed. Often times organizations that have the best process have the best security.

SEE ALSO: Vulnerability Scans 101: What, Why and How to Comply

The basics of penetration testing

Just like a hacker, penetration testers analyze network environments, identify potential vulnerabilities, and try to exploit those vulnerabilities (or coding errors). In simple terms, analysts attempt to break into your company’s network to find security holes.

PCI DSS Requirement 11.3 (applicable to SAQ C and SAQ D) requires internal and external penetration testing of both the network and application layers of the CDE. But penetration testing isn’t limited to the PCI DSS. Any company that would like an unbiased look at their information security posture, should consider having a penetration test performed.

The time it takes to conduct a penetration test varies based on network size, network complexity, and the number of penetration test staff members assigned. A small environment can be completed in a few days, but a large environment can take several weeks.

Typically, penetration test reports contain a long, detailed description of attacks used, testing methodologies, and suggestions for remediation.

SEE ALSO: How Much Does a Pentest Cost?

Defining a significant change

In addition to annual penetration tests and quarterly vulnerability scans, you’ll want to perform these vulnerability assessments whenever significant infrastructure or application changes occur to determine if the changes made introduced any new vulnerabilities in the environment.

PCI DSS Requirement 11.3 requires that penetration testing be performed after any ‘significant change’ to the CDE. Due to the cost and time required to perform a penetration test, organizations often claim no significant changes have been made to their PCI environment.

How do you know when a change to the CDE is considered significant? What might be considered a major change to a smaller organization may only be a minor change in a large environment. While this should be an internal risk-based decision, here are some examples of changes that would be considered significant: OS upgrade for CDE system, replacing firewall or critical security device, adding a new payment acceptance process, moving portions or all of the environment to a cloud-hosted environment. The process your organization follows to determine if a change to the CDE is significant should be documented in internal policy and procedure documents

Penetration testing can be performed internally, if an organization has staff who are qualified to perform penetration tests and who are also independent from the systems being tested.  Someone who is actively involved in the management and configuration of systems in the CDE shouldn’t also perform the penetration test, as they would not be considered independent.  If a company lacks either the skills necessary to perform a test or the organizational independence, tests should be performed by a third-party penetration tester.

SEE ALSO: Different Types of Penetration Tests for Your Business Needs

Difference between penetration tests and vulnerability scans

As a review, vulnerability scanning, whether internal or external, is not the same as penetration testing. 


Here are two big differences:
  1. A vulnerability scan is automated, while a penetration test includes a live person actually digging into the complexities of your network. 

  2. A vulnerability scan only identifies potential vulnerabilities.  During a penetration test the tester will verify the exploitability of the vulnerability and look to identify the root cause of the vulnerability that allows access to secure systems or stored sensitive data. 


Vulnerability scans and penetration tests work together to encourage optimal network security. Vulnerability scans are great weekly, monthly, or quarterly insight into your network security, while penetration tests are a more thorough assessment of your overall information security posture. 


Need help with finding vulnerabilities? Talk to us about vulnerability scanning and penetration testing!

Michael Simpson (QSA, CISSP, CCNP) is a Principal Security Analyst at SecurityMetrics and has been in the IT Security industry for 15 years. He has a Bachelor of Science in Computer Science and a Masters in Business Administration.