A Resource for Merchants and Service Providers to Become Compliant
This post contains part of the text from the SecurityMetrics Guide to PCI Compliance. To view the full text, download the PDF below.
No matter the advances in cyber security technology and despite government initiatives and regulations, attackers will continue to work to steal unprotected payment card data.
SecurityMetrics Audit Director
QSA (P2PE) | PA-QSA (P2PE) | CISA | CISSP
The information described in this guide is presented as a reference and is not intended to replace security assessments, tests, and services performed by qualified security professionals. Users are encouraged to consult with their companies’ IT professionals to determine their needs to procure security services tailored to those needs.
TABLE OF CONTENTS
- How to Read This Guide
- PCI DSS Compliance Overview
- Understanding Your PCI DSS Responsibility
- SAQ Overview
- PCI DSS 3.2 and 3.2.1: Key Changes and Updates
- Forensic Perspective
PCI DSS REQUIREMENTS
- REQUIREMENT 1: Protect Your System with Firewalls
- REQUIREMENT 2: Use Adequate Configuration Standards
- REQUIREMENT 3: Secure Cardholder Data
- REQUIREMENT 4: Secure Data Over Open and Public Networks
- REQUIREMENT 5: Protect Systems with Anti-Virus
- REQUIREMENT 6: Update Your Systems
- REQUIREMENT 7: Restrict Access
- REQUIREMENT 8: Use Unique ID Credentials
- REQUIREMENT 9: Ensure Physical Security
- REQUIREMENT 10: Implement Logging and Log Monitoring
- REQUIREMENT 11: Conduct Vulnerability Scans and Penetration Tests
- REQUIREMENT 12: Start Documentation and Risk Assessments
HOW TO READ THIS GUIDE
Whether you’re a new employee with limited PCI knowledge or an experienced system administrator, our guide aims to help you secure your environment and for your organization to become compliant with PCI DSS requirements. We specifically designed this document as a reference guide to address the most challenging aspects of PCI DSS compliance.
Depending on your background, job role, and your organization’s needs, some sections may be more useful than others. Rather than reading our guide cover to cover, we recommend using it as a resource for your PCI compliance efforts.
The chart below displays an overview of the PCI Security Standards Council’s Prioritized Approach. The Prioritized Approach offers organizations a risk-based roadmap to address issues on a priority basis, while also supporting organizational financial and operational planning.
The Prioritized Approach is broken down into the following six milestones (based on high-level compliance and security goals):
|1||Remove sensitive authentication data and limit data retention|
|2||Protect systems and networks, and be prepared to respond to a system breach|
|3||Secure payment card applications|
|4||Monitor and control access to your systems|
|5||Protect stored cardholder data|
|6||Finalize compliance efforts, and ensure all controls are in place|
PCI DSS COMPLIANCE OVERVIEW
93.3% of SecurityMetrics customers that started their SAQ have achieved passing status
PCI DSS REQUIREMENTS OVERVIEW
TOP 10 FAILING SELF-ASSESSMENT QUESTIONNAIRE (SAQ) SECTIONS
In 2021, it took the average SecurityMetrics customer 20.33 days to reach PCI DSS compliance with an average number of 0.98 support calls.
UNDERSTANDING YOUR PCI DSS RESPONSIBILITY
In recent years, the PCI DSS introduced several changes, including changes to PCI scope definitions and SAQ categories. PCI scope deals with the people, processes, and technologies that must be tested and protected to become PCI compliant. An SAQ is simply a validation tool for merchants and service providers to self-evaluate their PCI DSS compliance.
93.6% of SecurityMetrics customers who started their SAQ went on to complete it in 2021.
PCI DSS SCOPING AND NETWORK SEGMENTATION SUPPLEMENT
In May 2017, the PCI Security Standards Council (SSC) released a supplemental guide for scoping and network segmentation. The purpose of this guidance was to help organizations identify the systems that need to be considered in scope for PCI DSS compliance and clarify how segmentation can reduce the number of in-scope systems.
SCOPE YOUR ENVIRONMENT
When scoping your environment, start with the assumption that everything is in scope until it is verified that all necessary controls are in place and actually provide effective segmentation.
Make sure any changes to your environment are reflected in your annual scope assessment.
Without adequate network segmentation, your entire network is in scope of the PCI DSS assessment and applicable PCI requirements.
While not required, best practice is for you to implement PCI DSS controls on out-of-scope systems to prevent them from being used for malicious purposes.
TIPS FROM AN AUDITOR
PCI DSS SCOPE
To discover your PCI scope and what must be included for your PCI compliance, you need to identify anything that processes, stores, or transmits cardholder data, and then evaluate what people and systems are communicating with your systems. In May 2017, the council released an informational supplement regarding PCI scoping. The document helps reinforce and clarify scoping points that have always been part of PCI scoping. The document can help you work through your annual scoping exercise and can lead you to discover card flows and in-scope systems that you may have previously ignored.
Do not panic if you find data where it does not belong.
Usually organizations can find ways to fix processes and delete this sensitive data, rather than add servers to their scope. A simple way to find unencrypted card data is by running a card discovery tool, such as SecurityMetrics PANscan®.
CISSP | CISA | QSA (P2PE) | PA-QSA (P2PE)
DETERMINE YOUR SAQ TYPE
How you process credit cards and handle cardholder data determines which of the 9 Self-Assessment Questionnaire (SAQ) types your business needs to fill out. Here are the different SAQ type requirements:
SAQ D FOR MERCHANTS
SAQ D applies to merchants who don’t meet the criteria for any other SAQ type. This SAQ type handles merchants who store card information electronically and do not use a P2PE certified POS system. Here’s what qualifies you for SAQ D:
SAQ D FOR SERVICE PROVIDERS
A service provider is a business entity that isn’t a payment brand, but is directly involved in the processing, storage, or transmission of cardholder data on behalf of another organization. Service providers can also provide services that control or could impact the security of cardholder data. Here’s what qualifies you for SAQ D:
COMBINING MULTIPLE SAQS
PCI DATA SECURITY ESSENTIALS EVALUATION TOOL FOR SMALL MERCHANTS
PCI DSS 4.0
THE GOAL OF PCI DSS 4.0
2. PROMOTE SECURITY AS A CONTINUOUS PROCESS
3. ENHANCE VALIDATION METHODS AND PROCEDURES
Relying on a security implementation you already have in place may save on new capital expenses, but it will require more work on your part. You will need to thoroughly document, test, and conduct risk analysis efforts to present to your QSA. The QSA then has to review your information to develop custom testing procedures–a process that will require more reporting from the entity.
PCI DSS 4.0 SUMMARY
IMPLEMENTING A PCI COMPLIANT REMOTEWORKFORCE SETUP
2022 FORENSIC PREDICTIONS
PAYMENT IFRAME BREACH VIA BROWSER VULNERABILITY OR ZERO-DAY ATTACK
SecurityMetrics forensic investigators have continued to see a surge iniFrame compromises.
In a typical iFrame compromise, we often see where a customer attempts to make a purchase on an e-commerce website and an error message indicates that they need to re-enter their card information. In fact, there was no error.In the first form submission, the credit card data goes to the attacker; the second submission goes to the processor.
By utilizing some of these zero-day attacks, the customer only needs to enter their information once. The attacker would then be able to collect their payment information and send it to the processor without the customer or merchant being aware that anything was amiss.
MOBILE DEVICES WILL BECOME A PRIMARY TARGET OF CREDIT CARD SKIMMERS
While never completely immune, mobile device processing (e.g., tablet, cell phone) to accept credit card transactions has been an area where we typically have not seen a lot of skimming.
However, as more and more e-commerce is happening on mobile devices, we expect mobile device processing will soon become card skimmers’ new playground, both on the merchant side and customer side.
In the past we’ve seen a hacker tool (i.e., Inter) that was designed to insert skimmers on the checkout page inside of a desktop browser. Recently, this tool has been reconfigured (and renamed as MobileInter) to inject skimmers that run on your phone’s browser instead of a desktop browser.
INCREASE IN USE OF ANTI-FORENSIC TECHNIQUES OF CREDIT CARD SKIMMERS
The harder it is for a forensic analyst to detect an attack, the longer that attack goes on, with even more cardholder data being lost.
The range of tools being used covers data hiding (e.g., root kits, encryption, steganography), artifact wiping (e.g., disk cleaner, free space and memory cleaners, prophylactic), trail obfuscation (e.g., log cleaners, spoofing, misinformation, zombied accounts, Trojan commands), and attacks against cyber forensics processes/tools (e.g., file signature altering, hash fooling, nested directories).
We’re going to see more of this occurring on the mobile platform.
This is even more reason to regularly update your defensive tools (e.g.,antivirus), since these tools will try to identify some of these attacks to the best of their ability.
RISE OF RANSOMWARE WITHOUT ENCRYPTION
Ransomware traditionally will lock a computer and encrypt its files. If you want to access your files again, you have to pay the ransom.
However, there will be a shift from solely encrypting files to collecting and holding onto the confidentiality of your files, which are put at ransom.
Hackers will disclose that they’ve captured your data, and if you don’t want your competitors to receive this information, have your information publicly disclosed, or for the sensitive information to be sold on the dark web, you will need to pay the ransom.
This shift is because more businesses have been following cyber security best practices, ensuring that they have backups that are current and disconnected from their network.
Because many organizations are better prepared to deal with the consequences of a traditional ransomware attack, the attackers were receiving fewer large ransoms, so cyber criminals are moving onto extortion.
In one case, we saw that a company paid to have their data unlocked, then had to pay to have the attackers not publish the data. The attackers then came back six months later saying, “We still have your data. We’re going to need another payment in order to keep this information confidential.” The bad thing is that they still have your data, and there could essentially be no end to them coming back for more money.
PCI DSS REQUIREMENTS
PROTECT YOUR SYSTEM WITH FIREWALLS
Network firewalls are vital for your security. A firewall’s purpose is to filter potentially harmful Internet traffic to protect valuable sensitive data. Simply installing a firewall on your organization’s network perimeter doesn’t make you secure.
A hardware firewall–or perimeter firewall–is typically installed at the perimeter of an organization’s network to protect the internal networks from the Internet. Hardware firewalls are also used inside an environment to create isolated network segments. Higher security internal network segments would be created to limit access to sensitive data from networks that don’t need that access.
In summary, a properly configured hardware firewall protects environments from the outside world. For example, if attackers try to access your network from the outside, your hardware firewall would act as the first line of defense and should block them.
You also need a firewall between the systems that store sensitive data and other systems on your network. Typically, this is a second hardware firewall installed inside your corporate network to create a secure zone to further protect sensitive data.
If your firewall is not configured and maintained properly, your network is not secure.
HARDWARE FIREWALL PROS
HARDWARE FIREWALL CONS
Most robust security option
Rules need to be carefully documented
|Protects an entire network||Difficult to configure properly|
Can segment internal parts of a network
Needs to be maintained and reviewed regularly
Many personal computers come with pre-installed software firewalls. This feature should be enabled and configured for any laptop computers thatcommonly connect to sensitive data networks.
For example, if a sales manager accidentally clicks on a phishing email scam, their computer’s software firewall should stop the malware from propagating throughout the corporate network.
SOFTWARE FIREWALL PROS
SOFTWARE FIREWALL CONS
Fewer security options
|Protects mobile workers when outside the corporate network||Should not replace hardware firewalls for network segmentation|
|Easier to maintain and control||Doesn’t protect an entire network|
PROPERLY CONFIGURE FIREWALLS
A common mistake regarding firewalls is assuming they are a plug-and-play technology. After initial installation, additional effort is almost alwaysnecessary to restrict access and protect the CDE.
The end goal of firewall implementation is to filter potentially harmfulInternet traffic and other untrusted networks to protect valuable confidential data. In e-commerce applications, a firewall should be used to limit traffic to only essential services needed for a functioning CDE. By identifying sensitive systems and isolating them through the proper use of firewalls (e.g., network segmentation), merchants can more precisely control what type of access is allowed in and out of these zones and more easily protect payment data.
In a recent data breach investigation conducted by SecurityMetricsForensic Investigators, an organization had a sophisticated security andIT system. However, amongst 300 pages of firewall rules (with about 100rules on every page), two incorrectly written firewall rules essentially negated the whole firewall, leaving the entire network exposed. It was through this vulnerability that the attacker accessed their network and stole sensitive data
FIVE BASIC FIREWALL CONFIGURATION BEST PRACTICES
CREATE FIREWALL CONFIGURATION STANDARDS: Before implementing firewall settings and rules on the hardware, carefully document settings and procedures such as: hardware security settings, port/service rules needed for business, justify the need for rules, consider both inbound and out bound traffic, etc.
TRUST BUT VERIFY: After implementing firewall rules/settings, test the firewall appropriately externally and internally to confirm settings are correct (e.g., pen test, scans).
LIMIT OUTBOUND TRAFFIC: Often, we worry too much about blocking inbound ports/services and forget that outbound traffic from inside the network should be limited to just what is needed.This limits hackers’ paths for exfiltrating data.
PERSONAL FIREWALLS: Configure personal firewalls on mobile computing platforms to limit attack surfaces and minimize the propagation of malware when on unsecured networks.
MANAGEMENT: Only manage the firewall itself from within your network. Disable external management services unless they're part of a secure managed firewall infrastructure.
Merchants often set up flat networks, meaning everything inside the network can connect to everything else. They may have one firewall at the edge of their network, but that’s it. There’s no internal segmentation, making it a “flat network.”
Flat networks make security difficult because if an attacker gets inside, they have access to everything.
Initial intrusion of many recent investigated data breaches began in areas of an organization’s network that shouldn’t have given the attacker access to the CDE. For example, since an organization’s network was configured as a flat network, it was not difficult for the attacker(s) to migrate from the point of entry (e.g., employee laptop, work station) to the CDE or other sensitive systems.
Firewalls can be used to segment an organization’s network. When businesses create a secure payment zone–firewal led off from the rest of the day-to-day business traffic–they can better ensure their CDE only communicates with known and trusted sources. This limits the size of the CDE and potentially lowers your PCI scope.
For example, you install and configure a multi-interface firewall at the edge of your network. From there, you create one interface on the firewall dedicated just to the systems that store, process, and transmit cardholder data. If that interface doesn’t allow any other traffic in or out of any other zones, this is proper network segmentation.
Segmentation is not necessarily required in order to be compliant withPCI DSS. However, if you’re looking for one of the easiest ways to reduce cost, effort, and time getting in-scope systems compliant, you may want to consider segmentation.
Segmentation can be tricky, especially for those without a technical security background. Consider having a security professional double-check all your segmentation work by performing regular segmentation checks.
SEGMENTED NETWORK EXAMPLE
TEST AND MONITOR CONFIGURATION
Rules and environments change over time, no matter the size of your organization. Firewall rules should be reviewed (and revised when necessary) over the course of a few months or at least every six months.
TIPS FROM AN AUDITOR
REQUIREMENT 1: ESTABLISH THOROUGH FIREWALL ARCHITECTURE
Large environments typically have firewalls in place, at least at the network’s perimeter. Make sure to choose firewalls that support the necessary configuration options to protect critical systems and provide segmentation between the CDE and other internal and external networks.
Smaller organizations sometimes struggle to understand firewalls, not having the necessary in-house expertise to configure and manage them correctly and securely. If this is the case, contract a PCI-validated third party service provider to provide assistance, rather than simply deploying a firewall’s default configuration and hoping for the best.
It’s best to start by having a “block everything” mentality, and then add exceptions as needed. PCI DSS requires you to document a valid business justification for any communication allowed to or from the CDE.Spend the time to identify the specific source and destination addresses your systems need to communicate with for a given service or protocol.
It may seem obvious, but leave as few holes as possible in your firewall.
Don’t just allow all access to the Internet because it’s easier. Along the same line, if you or any third parties remotely support your environment, limit that inbound access to specific sources and protocols.
Often, the volume of log data can be overwhelming, so some merchants turn logging off or send alert messages directly to the junk bin. It’s important(and required) to review firewall logs daily to identify patterns and activity that indicate attempts to breach your security. There are many good software packages available to help you deal with the volume of log data and automate alerts. This will help you pick out the important data that requires action.
For requirement 1, remember the following:
- Start with a “block everything” mentality, thenwork backward.
- Pay attention to what logs tell you.
- Review firewall configurations frequently and adjust as necessary.
SecurityMetrics Principal Security Analyst | CISSP | CISA | QSA | CCSFP |CHQP
USE ADEQUATE CONFIGURATION STANDARDS
DEFAULT PASSWORD WEAKNESSES
Out-of-the-box devices, such as routers or POS systems, come with factory settings like default usernames and passwords. Defaults make device installation and support easier, but also mean every model originates with the same username and password. Default passwords are easy to guess, especially since most are published online.
Businesses are often unaware that default settings are used in their environment, due to third-party installation.
In one SecurityMetrics forensic investigation, it was discovered that a third-party IT vendor purposely left POS system default passwords in place to facilitate easier future system maintenance. Default passwords might make it easier for IT vendors to support a system without learning new passwords each time; however, convenience is never a valid reason to forego security, nor will it reduce liability.
When defaults aren’t changed, it provides attackers an easy gateway into a system, which is why changing vendor defaults on every system with exposure to your CDE is so vital.
Passwords must be changed every 90 days and contain at least seven characters – including both numbers and letters.
Passwords that fall short of these criteria can usually be broken using a password-cracking tool.
Any system used in your CDE needs to be hardened before it’s placed in production. The goal of hardening a system is to remove unnecessary functionality and configure what is left in a secure manner. Every application, service, driver, feature, and setting installed on a system introduces vulnerabilities.
According to requirement 2.2, you must “address all known security vulnerabilities and [be] consistent with industry-accepted system hardening standards.”
Here are recommended resources for system hardening:
Center for Internet Security (CIS)
International Organization for Standardization (ISO)
SysAdmin Audit Network Security (SANS) Institute
National Institute of Standards Technology (NIST)
SYSTEM CONFIGURATION MANAGEMENT
Consistency is key when trying to maintain a secure environment. Once system hardening standards and settings have been defined and documented, it is critical that they are applied to all systems in the environment in a consistent manner. Once each system and device in the environment has been appropriately configured, you still have work to do.
Make sure someone is responsible for keeping the inventory current and based on what is actually in use.
This way, applications and systems that are not approved for use in the CDE can be discovered and addressed.
Many organizations, especially larger ones, turn to one of the many system management software packages on the market to assist in gathering and maintaining this inventory. These applications are capable of scanning and reporting on hardware and software used in a network and also detecting when new devices are brought online. These tools are often able to enforce configuration and hardening options, alerting administrators when a system isn’t compliant with your internal standard.
TIPS FROM AN AUDITOR
REQUIREMENT 2: SYSTEM CONFIGURATION
You are required to use industry accepted configuration and hardening standards when setting up systems that are part of your PCI scope.
Configuration and hardening requirements apply to all computer systems, network devices, and applications used to process or secure cardholder data. This may include things like web servers, database software, firewalls, point-of-sale systems, or workstations used to process credit card transactions.
Examples of system hardening practices include:
Disabling services and features you don’t use
Uninstalling applications you don’t need
Limiting systems to perform a single role
Removing or disabling default accounts, changing default passwords
Configuring other security settings
Permitting anything unnecessary to remain on a system opens you up to additional risk and possible vulnerability.
Often, organizations get overwhelmed trying to understand how and where to begin implementing system configuration standards, especially in an environment that has expanded and changed over time.
The first step in securing your environment to meet PCI standards is to understand where credit card data is stored, processed, and transmitted.Begin by documenting the flow of cardholder data through your environment, making a list of each system, device, and application it touches along the way. Next, look at the systems and applications that, while not directly touching the data, can affect the security of those that do. Add this information to your documentation.
The key to effective system configuration and hardening is consistency. Once you have identified the systems and applications that need attention and documented a standard that meets your environment’s requirements, make sure processes are in place to follow this standard as time goes on. Keep your standard and process up to date as your business changes and as you discover new threats and vulnerabilities.
Automated tools can simplify the task of enforcing configuration standards, allowing administrators to quickly discover systems that are out of compliance.
SecurityMetrics Principal Security Analyst | CISSP | CISA | QSA | CCSFP |CHQP
SECURE CARDHOLDER DATA
ENCRYPT CARDHOLDER DATA
According to requirement 3, stored card data must be encrypted using industry-accepted algorithms (e.g., AES-256). The problem is many organizations unknowingly store unencrypted primary account numbers (PAN), often because of misconfigured software.
Not only must card data be encrypted, but the encryption keys must also be protected. Not protecting the encryption key location using a solid PCI DSS encryption key management process is like storing your house key in your front door lock.
Assign the responsibility of keeping unencrypted card data off your systems to an individual or team. Have this person or team define, document, and follow a process of periodic data discovery cycles to recheck and ensure systems remain clean of unencrypted card data
2022 PANSCAN® DATA ANALYSIS
Storage of unencrypted payment card data increases an organization’s risk and liability in the event of a data breach.
Since 2010, SecurityMetrics PANscan® has discovered over 3 billion unencrypted PANs on business networks. In 2021, users scanned over 2,500computers and 208,444 GBs. Here are some key statistics:
77% of PANscan® users discovered unencrypted PAN data
5% stored track data (i.e., data inside magnetic stripe)
Over 105,000 PANs were found
In the latest study by SecurityMetrics, 77% of PANscan® users found unencrypted PAN data on their network.
KNOW WHERE ALL CARDHOLDER DATA RESIDES
An essential part of eliminating stored card data is using a valid cardholder data discovery tool and methodology. These tools help identify the location of unencrypted PAN so you can securely delete or encrypt it. They also help identify which processes or flows might need to be fixed.
Remember, payment card data can easily leak due to poor processes or misconfigured software. Start by looking where you think the data is, and then look where it shouldn’t be.
You should create and document a current cardholder flow diagram for all card data flows in your organization. A CHD flow diagram is a graphical representation of how card data moves through an organization. As you define your environment, it’s important to ask all organizations and departments if they receive cardholder information, and then define how their answers may change CHD flows.
To accurately craft your CHD flow diagram, ask yourself:
- What device(s) am I using for transactions? A virtual terminal? POS system?
- What happens to the card data after a transaction?
- When is data encrypted? Is it even encrypted at all?
- Do I store card data before it’s sent to the processor for approval?» How and when does settlement occur? Real time or end of day?
- How is data authorized and returned by the processor?Is card data backed up on my system? Are backups encrypted? Is my backup server at a different data location?
- Where might card data be going or moved in processes not part of authorization and settlement?
Once you identify new processes, you can begin to determine how to either fix the process or add it into your normal environment flow.
TIPS FROM AN AUDITOR
REQUIREMENT 3: PROTECT CARDHOLDER DATA
Don’t keep any data you don’t need. If you only need the last four numbers ofPAN, get rid of the rest! For each element of cardholder data, ask yourself if you really need it or if it is just nice to have. I have found that some companies have a lot of data they really don’t need and never ask if they need it. The more data you keep, the higher the risk.
IT should work closely with all business groups to decide what data the company needs, where to store it, and for how long. Data retention policies are key to ensuring that your data has the appropriate controls. Periodic assessments of data retention and data mappings should be performed.Data requirements might change over time, so check often.
It is important to know what data you actually store, process, and/or transmit. If you don’t know what you have, it is difficult to implement the correct controls around it. Data flow mapping helps you understand the data coming in to and out of your organization. Create data flow diagrams for your entire organization (on all information you deem sensitive), not just for yourCDE environments. You might miss something if you only focus on the CDE and CHD.
In addition, use automated tools that can help you search for and find unencrypted CHD. You will be surprised what you find outside of your CDE.Run these tools often to ensure data is where it should be.
SecurityMetrics Senior Security Analyst | CISSP | CISA | QSA
SECURE DATA OVER OPEN AND PUBLIC NETWORKS
For requirement 4, you need to identify where you send cardholder data. The following are common places PAN are sent:
Third parties that store or handle PAN
Outsourced management of systems or infrastructure
You need to use encryption and have security policies in place when you transmit cardholder data over open, public networks.
STOP USING SSL/EARLY TLS
Based on vulnerabilities in web encryption, discontinue or remove all instances of SSL and early TLS, unless existing implementation is necessary for regular business operations. The only acceptable use of these outdated protocols is if your POS/POI hardware currently in use does not support later versions of secure TLS.
Your systems may still be using SSL and early TLS, so you should contact your terminal providers, gateways, service providers, vendors, and acquiring banks to determine if the applications and devices you use have this encryption protocol.
Examples of applications that may still use SSL/early TLS include:
POS/POI hardware terminals
Virtual payment terminals
The PCI Council believes that SSL and early TLS will no longer protect cardholder data.
Please note that organizations using POS/POI terminals with existing implementations of SSL and early TLS must ensure that the devices in use are not susceptible to any known exploits for these insecure protocols.Check with your merchant bank or POS/POI supplier if you have questions about that.
Merchants that have older POS/POI terminals that still use the insecureSSL/TLS protocols still should have a Risk Mitigation and Migration Plan in place. According to the PCI Council, this document will “detail [your] plans for migrating to a secure protocol, and also describe controls [you have] in place to reduce the risk associated with SSL/early TLS until the migration is complete.”
TIPS FROM AN AUDITOR
REQUIREMENT 4: SENDING DATA OVER OPEN AND PUBLIC NETWORKS
Build off of the data flow diagrams discussed in the tips in Requirement3. Know exactly where CHD is coming from and being sent to inside and outside of your organization. Make sure your CHD is encrypted when transmitted over open public networks using strong and industry-accepted encryption technologies.
Are you using strong encryption on all CDE impacting services? I have noticed that some companies are still using older technologies even though the latest is also supported. For example, CDE web servers using TLS 1.2are still accepting connections using TLS 1.0. Disable all insecure protocols and encryption.
Companies should also leverage tools that can analyze web services and report any insecure setups. You may not be aware of all your services accessible over the Internet. Run these tools often to help ensure you are using acceptable protocols and encryption strengths.
SecurityMetrics Senior Security Analyst | CISSP | CISA | QSA
PROTECT SYSTEMS WITH ANTI-VIRUS
REGULARLY UPDATE YOUR ANTI-VIRUS
Anti-virus software needs to be installed on all systems commonly affected those commonly affected by malware, regardless of its location. Make sure anti-virus or anti-malware programs are updated on a regular basis to detect known malware. Maintaining an up-to-date anti-malware program will prevent known malware from infecting systems.
Depending on your relationship with your POS vendor, they may or may not maintain your anti-virus scanning. If your vendor doesn’t handle your anti-virus, it’s up to you to ensure regular scanning is conducted.
Using outside sources such as the United States Computer Emergency Readiness Team (US-CERT), SANS Institute, and vendor/anti-virus threat feeds, merchants can identify emerging malware and attacks on systems. They should then configure systems to alert and report on suspicious activity, such as new files added to known malware directories or unauthorized access attempts.
Vigilant vulnerability management is the most effective way for you to proactively reduce the window of compromise, greatly narrowing the opportunity for hackers to successfully attack your systems and steal valuable data. As part of your vulnerability management strategy, make sure to include updated anti-virus software.
TIPS FROM AN AUDITOR
REQUIREMENT 5: IMPLEMENT AND UPDATE YOUR ANTI-VIRUS
System administrators have the responsibility of making sure their anti-virus software, including the signatures, are up to date.
After a software upgrade, verify that signatures are able to be updated. The new software may use different firewall rules or directory permissions, requiring some system configuration changes to ensure signature updates continue.
PCI DSS requires anti-virus software to be installed on all systems that are commonly affected by malware (e.g., Windows). While Linux servers are often considered systems not commonly affected by malware, it’s highly recommended that anti-virus software be installed for any web-facingLinux servers.
SecurityMetrics Security Analyst | CISSP | CISA | QSA | SSF | SSL
UPDATE YOUR SYSTEMS
REGULARLY UPDATE AND PATCH SYSTEM(S)
Application developers will never be perfect, which is why updates to patch security holes are frequently released. Once a threat actor knows they can get through a security hole, they pass that knowledge to other criminals who could then exploit this weakness until a patch has been deployed.
Quickly implementing security updates is crucial to your security posture. Patch all critical components in the card flow pathway, including:
Older Windows systems can make it difficult for merchants to remain secure, especially when the manufacturer no longer supports a particular operating system or version (e.g., Windows 7, Windows Server 2008 R2).
Operating system updates often contain essential security enhancements that are specifically intended to correct recently exposed vulnerabilities.When using an unsupported OS that doesn’t receive such updates and patches, the vulnerability potential increases exponentially.
Be vigilant about consistently updating software associated with your system. Requirement 6.2 states that organizations must “install critical patches within a month of release” to maintain compliance. Don’t forget about critical software installations like credit card payment applications and mobile devices. To stay up to date, ask your software vendors to put you on their patch and upgrade notification list.
Keep in mind that the more systems, computers, and apps your company has, the more potential vulnerabilities it may be exposed to.
Another way to stay on top of vulnerabilities is through vulnerability scanning, which is arguably the easiest way to discover software patch holes that cyber criminals would use to exploit, gain access to, and compromise an organization.
ESTABLISH SOFTWARE DEVELOPMENT PROCESSES
If you develop payment applications in house (e.g., e-commerce websites, POS applications), you must use strict development processes and secure coding guidelines as outlined in the PCI DSS. Don’t forget to develop and test applications according to industry-accepted standards like the Open WebApplication Security Project (OWASP).
Be vigilant about consistently updating the software associated with your system.
WEB APPLICATION FIREWALLS
Requirement 6.6 requires public-facing web applications to regularly monitor, detect, and prevent web-based attacks, such as implementing web application firewalls (WAF) in front of public-facing web applications. Even though these solutions can’t perform the many functions of an all-purposenet work firewall (e.g., network segmentation), they specialize in one specific area: monitoring and blocking web-based traffic.
A WAF can protect web applications that are visible or accessible from the Internet. Your web application firewall must be up to date, generate audit logs, and either block cyberattacks or generate a cyber security alert if it detects attack patterns.
TIPS FROM AN AUDITOR
REQUIREMENT 6: SYSTEM UPDATING AND SOFTWARE DEVELOPMENT
System administrators have the responsibility to ensure that all system components (e.g., servers, firewalls, routers, workstations) and software are updated with critical security patches within 30 days of public release.If not, these components and software are vulnerable to malware and security exploits.
Quickly implementing security updates is crucial to your security postures.
Systems or software might be excluded from updates because they weren’t able to communicate with the update server (e.g., WSUS, Puppet). This broken communication could have resulted from a network or system configuration change. It’s imperative that system administrators are alerted when security updates fail.
Another important subsection of requirement 6 is the need to have proper change control processes and procedures.
Development/test environments must be separate from production with proper access control in place to enforce access rights.
Separation of duties must be implemented between personnel assigned to development/test environments and those assigned to production.
Production data (e.g., live credit card numbers, live personally identifiable information) must never be used in test/development environments.
All test data and accounts must be removed before a production environment becomes active.
Change control procedures related to implementing security patches and software modifications must be documented.
Companies need to embrace the idea of change control for their software development and system patching/updating.
There are four requirements detailed by the PCI Council of what a proper change control procedure must contain:
Changes must have a documented explanation of what will be impacted by the change.
Changes must have documented approval by authorized parties.
Changes to an organization's production environment must undergo proper iterations of testing and QA before being released into production.
Change control procedures must always include a back-out or roll-back procedure in case the updates go awry.
When developing software (e.g.,web applications), it’s crucial that organizations adopt industry-accepted standards or best practices for coding, such as OWASP. This will guide them in enforcing secure coding practices in their application development process and keep software code safe from malicious vulnerabilities (e.g.,cross-site scripting, SQL injection, insecure communications, CSRF).
Insecure communications, for example, was in the spotlight since SSL andTLS 1.0 are no longer considered acceptable protocols when data is being transmitted over open, public networks. Everyone should be on TLS 1.2 now.
SecurityMetrics Security Analyst | CISSP | CISA | QSA | SSF | SSL
RESTRICT ACCESS TO CARDHOLDER DATA AND SYSTEMS
You should have a role-based access control (RBAC) system, which grants access to cardholder data and systems on a need-to-know basis. Configuring administrator and user accounts helps prevent exposing sensitive data to those who don’t need to know this information
PCI DSS requires a defined and up-to-date list of the roles with access to the cardholder data environment. On this list, you should include each role, the definition of each role, access to data resources, current privilege level, and what privilege level is necessary for each person to perform their normal business responsibilities. Users must fit into one of the roles you outline.
Have a defined and up-to-date list of roles with access to the card data environment.
User access isn’t limited to your normal office staff. It applies to anyone needing access to your systems behind the desk, such as an IT group or maintenance professional. You need to define and document what kind of user permissions they have.
TIPS FROM AN AUDITOR
REQUIREMENT 7: RESTRICT ACCESS
This requirement is one of the oldest and most basic parts of the PCI DSS.
There’s no new trend or solution.But not all organizations accurately comply with this requirement or have even tried role-based access at all.
This is all you need to know: don’t give access to people (or services) who don’t need it. Cardholder data and card systems should only be accessible to those that need that information to do their jobs. Once you’ve implemented access privileges, make sure to document it.
This is all you need to know:don’t give access to people who don’t need it.
QSA | CISSP
USE UNIQUE ID CREDENTIALS
WEAK PASSWORDS AND USERNAMES
If a username or password doesn’t meet the recommended security standards for length, uniqueness, and complexity, that password will be a vulnerability that could allow an attacker to gain access to your environment and sensitive information. A weak password is vulnerable to a brute-force attack of guessing the password to a user account. Once the attacker has gained access, they will then work to escalate their account privileges through a variety of attack vectors, including: a brute force attack leveraging a rainbow table, a social engineering campaign or through exploiting an unpatched vulnerability.
Having a nondescript username and a strong password will make guessing your login credentials exponentially more difficult.
PCI DSS specifies that passwords must be changed every 90 days (the new password cannot be the same as any of the previous four passwords used)and must be comprised of either at least seven characters of both numbers and letters or have the complexity and strength that is at least equivalent to seven characters of both numbers and letters.
Passwords that fall short of this criteria can easily be broken using a password-cracking tool. Computing power continues to increase and what seems like a good password may in reality be easy to break.
The longer the password and the more special characters allowed, the more difficult it will be for an attacker to crack a password.
With this security comes a risk posed by human nature. When a password is too hard to remember, it is often written down and placed in an easy to access location. Be sure to review and update your company password policy so that increasing the complexity doesn’t undermine security objectives.
PCI DSS requires the disabling of default accounts and having unique user and admin account names instead of using system defaults or common usernames (i.e., admin, an organization's name, or a combination of the two). A company is much more secure if an attacker has to first guess the username before cracking its corresponding password.
Be sure that an account lock-out is set to at most six consecutive failed login attempts within a 30-minute period. Requiring an administrator to manually unlock accounts will discourage automated hacking methods.
The more manual steps hackers have to go through, the more likely it is they will move on to an easier target.
IMPLEMENT MULTI-FACTOR AUTHENTICATION
System security should not be based solely on the complexity of a single password. No password should be considered uncrackable. That’s why multi-factor authentication (MFA) is an effective solution to secure remote access and is a requirement under the PCI DSS.
Configuring multi-factor authentication requires at least two of the three following factors:
- Something you know (e.g., a username and password, PIN number)
- Something you have (e.g., hardware token, smart card)
- Something you are (e.g., a fingerprint, ocular scan, voiceprint)
A few examples of effective multi-factor authentication for remote access could include:
The remote user enters their username and password, and then must enter an authentication code that is available to them through an RSA token in their possession.
The remote user enters a password and biometric to log in to a smartphone or laptop. The individual then provides a single authentication factor (e.g., another password, digital certificate, signed challenge response) to connect to the corporate network.
Your authentication mechanisms should be out-of-band and independent ofeach other. There should be a physical separation between mechanisms sothat access to one factor does not grant access to another, and if one factoris compromised, it does not affect the integrity and confidentiality of anyother factor.
Additionally, make sure that you “incorporate multi-factor authentication for all remote network access (both user and administrator, and including third-party access for support or maintenance) originating from outside the entity’s network.”
If a remote access application configuration only requires a username and password to access sensitive data or systems and devices that store, process, or transmit cardholder data, the application has been configured insecurely.
TIPS FROM AN AUDITOR
REQUIREMENT 8: USE UNIQUE ID CREDENTIALS
Requirement 8 is all about having unique ID information. You must have your own unique ID credentials and account on your systems and devices so that you can prove with audit log files who committed the error or malicious action. With a shared account a malicious user would be hard to uniquely identify.
Do not use generic accounts, shared group passwords, or generic passwords.
As a system administrator, best practice is to have a regular account that is used for day-to-day work and a different administrative account when performing administrative functions.
Security professionals recognize that passwords are no longer sufficient to secure data. While passwords are still required, they simply are not secure enough. You must set strong, long passwords.
To meet PCI requirements, a password must contain at least seven characters and be complex, with both alphabetic and numeric characters
An easy way to remember complex passwords is by using passphrases. Passphrases are groups of words with spaces in between (e.g., “Star Wars“”ROS 2019 was WAY better than TLJ 2017!"). A passphrase can contain symbols and upper- and lower-case letters. It doesn’t have to make sense grammatically. Pass phrases are generally easier to remember but more difficult to crack than shorter passwords.
In addition to strong passphrases, password manager software can help you use different passwords for all of your accounts. Some password manager scan even work across multiple devices through the use of a cloud-based service. You need different passwords for different services so that if one service gets compromised, it doesn’t bleed into other sites’ passwords.
If your email account password is compromised and you use the same password across several devices, or even use that email address to receive the reset password emails from several websites, you have a major security problem on your hands.
SecurityMetrics Security Analyst | CISSP | CISA | QSA
ENSURE PHYSICAL SECURITY
CONTROL PHYSICAL ACCESS TO YOUR WORKPLACE
Employees may think physical security only applies after hours. However, most data thefts (e.g., social engineering attacks) occur in the middle of the day.
Mitigate the risk of physical threats by implementing physical security policies and procedures that preserve onsite business security for your critical assets and data. For example, if you keep confidential information, products, or equipment in the workplace, secure these items in a locked area. If possible, limit outsider access to one monitored entrance, and (if applicable) require non-employees to wear visitor badges.
Don’t store sensitive information in the open. Many companies that have services requiring repeat billing or batch processing keep physical copies of credit card information in easily accessible areas for convenience. While this collection of paper copies may make life easier, it puts valuable cardholder data at risk of theft unless appropriate controls are in place.
Employee access to sensitive areas should be controlled and must be related to an individual’s job function.
To comply with this PCI DSS requirement, you must document:
- Who has access to secure environments and why they need this access
- What, when, where, and why devices are used
- A list of authorized device users
- Locations where the device is and is not allowed
- What applications can be accessed on the device
- Logging of access attempts
Access policy and procedure documentation must be kept up to date and followed, especially when individuals are terminated or their job roles and responsibilities change.
Best practice is not to allow these removable devices to leave the office, but if they do, consider attaching external GPS tracking and remote wipe technology on all laptops, tablets, external hard drives, flash drives, and mobile devices.
The majority of physical data theft takes only minutes to plan and execute.
Make sure all workstations and mobile devices have an automated time out or logout (e.g., a password-protected screensaver pops up on a computer after a set amount of time). This reduces the window of opportunity for unauthorized users to access data from these devices and systems when nobody is looking.
KEEP TRACK OF POS TERMINALS
Organizations that use POS POI systems, PIN pads, and mobile payment devices are required to do three new things:
- Maintain an up-to-date list of all devices (9.9.1) including physical location, serial numbers, make, and model.
- Periodically inspect devices (9.9.2). You should ensure device surfaces haven’t been tampered with, make sure serial numbers match, and check that seals haven’t been broken. This could be a very large task depending on the size of your organization. Whether you inspect devices every day or every month is based on your tampering risk level (e.g., publicly accessible 24/7 gas station terminals vs. a behind-the-counter card swipe device). Document your findings.\
- Provide staff awareness training (9.9.3) for staff who interact with card-present devices on a day-to-day basis (e.g., cashiers), and record the who, what, and when for future reference. Training should include how to report suspicious behavior and what to do when third parties claim they need to work on your system. For example, rather than assuming IT support staff came in last night to install a new device on the side of a terminal, employees should be trained to question if it’s supposed to be there, and then to notify management (according to documented incident response policies and procedures).
TRAIN EMPLOYEES EARLY AND OFTEN
While you may understand how to protect customer card information, your employees may not. That’s why regular security training is so important.
Social engineering is a serious threat to both small and large businesses.A social engineer uses social interaction to gain access to private areas, steal information, or perform malicious behavior. Employees fall for social engineering attacks more often than you may think.
For example, if someone walked into your storefront and said they were there to work on your network and needed you to lead them to the server room, would your employees think twice to verify their identity?
Train your employees to question unusual behavior. Establish a communication and response policy in case of suspicious behavior. Train employees to stop and question anyone who does not work for the company, especially if the person tries to enter the back office or network areas.
PHYSICAL SECURITY BEST PRACTICES
Most physical security risks can be prevented with little effort. Here are a few suggestions to improve your physical security:
While working on your risk assessment, look for physical security risks.
- Lock all office doors and applicable equipment (e.g., mobile devices)when not in use day and night.
- Require passwords to access computers and mobile devices.
- Encrypt your data or don’t store data on these devices.
- Use screensavers and privacy monitors on computers.
- Install and use blinds in all office windows.
- Keep logs of who enters and leaves.
- Keep track of devices that go in and out.
- Have policies in place for stolen equipment (e.g., a good incident response plan).
- Train staff against social engineering.
- Limit access to CHD through role-based access.
- Have staff report suspicious activity and devices.
- Monitor sensitive areas with video cameras and store the video logs for appropriate durations.
TIPS FROM AN AUDITOR
REQUIREMENT 9: IMPROVE YOUR PHYSICAL SECURITY
Having electronic access on doors, using cameras to monitor all entries and exits to secure areas, implementing multiple levels of access based on a business need, and approving visitor/employee access are all standard controls for physical security.
Once you know what systems you need to protect, put controls in place that can log and restrict access to them (e.g., badge readers). A good risk assessment would determine an appropriate amount of money to spend on controls necessary to mitigate the identified risk.
Today, you see more organizations hosting their systems in outsourced data centers. Data centers generally have great physical security because they pay attention to the basics. They use cameras to monitor all entries and exits, have multiple levels of access (e.g., lobby, mantrap, hallways, data floors, and cages) to segment physical areas and limit access only to individuals who have approved access. They also use different levels of authentication requiring both badge and biometrics (e.g., fingerprint, retina) for access.
Digital IP-based cameras are becoming more common, making it easier and more cost effective to deploy and monitor camera systems. These camera scan take snapshots of people and then send those snapshots to security supervisors for verification.
It’s also necessary to protect card-swipe devices. Merchants must monitor these devices for tampering or complete replacement. Make sure attackers don’t substitute, bypass, or steal your terminal. You and your employees must know what the tamper properties are (e.g., seals, appearance, weight)and test them often. Security best practice is to mount devices with tamper resistant stands and screws.
Lastly, it’s important to have good security training for your management and employees. Help them understand malicious conduct and motivate them to report suspicious behavior and violations of company policy and procedures.
SecurityMetrics Security Analyst | CISSP | CISA | QSA
IMPLEMENT LOGGING AND LOG MONITORING
SYSTEM LOGS AND ALERTING
System event logs are recorded pieces of information regarding the actions taken on computer systems like firewalls, office computers, or payment applications.
Log monitoring systems (e.g., Security Information and Event Management[SIEM] tools) oversee network activity, inspect system events, alert you to suspicious activity, and store user actions that occur inside your systems.Think of these tools as your lookout, providing you with data breach alerts.The raw log files are also known as audit records, audit trails, or event logs.
Most systems and software generate logs including operating systems,Internet browsers, POS systems, workstations, anti-malware, firewalls, and IDS/IPS. Some systems with logging capabilities do not automatically enable logging, so it’s important to ensure all systems create and collect logs. Some systems generate logs but don’t provide event log management solutions. Be aware of your system capabilities and install third-party log monitoring and management software as needed.
ESTABLISHING LOG MANAGEMENT
Logs should be collected and sent to a central location, whether an on site logging server or an online service. Businesses should review their logs daily to search for errors, anomalies, or suspicious activities that deviate from the norm.
From a security perspective, the purpose of a log alert is to act as a red flag when something potentially malicious is happening. Reviewing logs regularly helps identify issues in your system.
Given the large amount of log data generated by systems and networking devices, it’s impractical to manually review all logs each day. Log monitoring software takes care of this issue by using rules to automate log review and only alert on events that might be real issues. Often this is done using realtime reporting software that alerts you via email or text when suspicious actions are detected.
Often, log monitoring software comes with default alerting templates tooptimize monitoring and alerting functions immediately. However, not everyone’s network and system designs are the same, and it’s critical to correctly configure your alerting rules during setup.
Logs are only useful if they are regularly reviewed.
LOG MANAGEMENT SYSTEM RULES
Here are some event actions to consider when setting up your log management system rules:
New login events
Malware attacks seen by IDS
Denial of service attacks
Errors on network devices
File name changes
File integrity changes
Shared access events
New service installation
New user accounts
New processes started or running processes stopped
Modified registry values
Scans on your firewall’s open and closed ports
To take advantage of log management, look at your security strategy and make sure the following steps are taken care of:
Decide how and when to generate logs.
Secure your stored logs so they aren’t maliciously altered by cybercriminals or accidentally altered by well-intentioned employees.
Assign an employee you trust to review logs daily.
Set up a team to review suspicious alerts.
Spend time to create rules for alert generation (don’t just rely on a template).
Store logs for at least one year, with three months readily available.
Frequently check log collection to identify necessary adjustments.
Diligent log monitoring means that you’ll have a quicker response time to security events and better security program effectiveness. Not only will log analysis and daily monitoring demonstrate your willingness to comply with PCI DSS requirements, but it will also help defend against internal and external threats.
Organizations should review their logs daily to search for errors, anomalies, or suspicious activity that deviates from the norm.
TIPS FROM AN AUDITOR
REQUIREMENT 10: AUDIT LOGS AND LOG MONITORING
It’s critical that you configure the log monitoring solution correctly so that the appropriate directories, files, security controls, and events are being monitored. Given the large amount of log data generated by systems, it’s virtually impossible to manually analyze logs from more than one or two systems.
You likely need SIEM tools to sift through logs and drill down into problems.In the past, SIEM systems were mainly utilized by large corporations, but smaller companies now realize system monitoring can help identify malicious activity and attacks.
Organizations often struggle with good log review processes. Using SIEM tools can enable you to have real-time alerting to help you recognize a current attack and initiate your incident response plan.
It is a good idea to test your alerting capabilities as part of your incident response test to ensure alerts are being generated and critical systems and applications are being appropriately monitored.
To correlate events over multiple systems you must synchronize system times. All systems should get their system time from internal time servers, which in turn receive time from a trusted external source.
PCI DSS requires service providers to implement a process to detect and respond to failures of critical security controls in a timely manner. You need to be able to detect these failures and have defined incident responses in place. Your response plans not only need to address the response to fix the problem, but also identify risks created by the failure, find root causes, document lessons learned, and implement any necessary changes to prevent failures from happening again.
Regular log monitoring means a quicker response time to security events and improved security program effectiveness.
SecurityMetrics Security Analyst | CISSP | CISA | QSA
CONDUCT VULNERABILITY SCANS AND PENETRATION TESTS
UNDERSTAND YOUR ENVIRONMENT
The types of systems that make up a business’s IT environment influences the kind of attacks to which they’re susceptible; therefore, a security testing plan should be tailored to the environment.
Defects in 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.A vulnerability scanning process helps to identify vulnerabilities, so they can be corrected.
In the case of custom in-house applications, code testing and independent penetration testing can expose many of the weaknesses commonly found in application code (especially home-grown varieties).
These types of scans and tests are the best line of defense in identifying weaknesses so they can be corrected before deployment.
VULNERABILITY SCANNING VS.PENETRATION TESTING
Some mistakenly believe vulnerability scans are the same as professional penetration tests.
Here are the two biggest differences:
- A vulnerability scan is automated, while a penetration test includes a live person that runs tests against your network.
- A vulnerability scan only identifies vulnerabilities, while a penetration tester digs deeper 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 an easy way to gain weekly, monthly, or quarterly insight into the status of your systems, while penetration tests are a more thorough way to evaluate overall security.
VULNERABILITY SCANNING BASICS
A vulnerability scan is an automated, high-level test that looks for and reports potential vulnerabilities in systems and applications.
PCI DSS requires two types of vulnerability scanning: internal and external.
An external vulnerability scan is performed from outside of your network and identifies known weaknesses in perimeter network devices, servers, or applications. All external IPs and domains exposed in the CDE, or that can provide access to the CDE, are required to be scanned by a PCI ApprovedScanning Vendor (ASV) at least quarterly.
An internal vulnerability scan is performed from within your network, and it looks at other hosts on the same network to identify internal vulnerabilities. These scans are also required to be performed at least quarterly for PCI compliance.
Think of your environment as a house. External vulnerability scanning is like checking to see if doors and windows are locked, while internal vulnerability scanning is like testing to see if bedroom and bathroom doors are locked.
Vulnerability scanning is an automated method to identify potential harmful vulnerabilities, so you can remediate processes to ensure network security.
Typically, vulnerability scanning tools will generate an extensive report of discovered vulnerabilities with references for further research on these vulnerabilities. Some reports even offer suggestions on how to fix discovered issues.
Running vulnerability scans is like going to a doctor for a checkup. If the doctor discovers a potential health issue and makes a recommendation for treatment, it is up to the patient to follow the doctor’s advice. Simply discovering the issue doesn’t fix the problem. Act quickly on any discovered vulnerabilities to ensure security holes are plugged, and then re-scan to validate that the vulnerabilities have been successfully addressed.
RUN EXTERNAL VULNERABILITY SCANS
For many organizations, external scans must be performed by a PCI ASV to validate PCI compliance.
An ASV is required to go through a rigorous yearly recertification process, during which each ASV runs their PCI scanning tool on PCI Council-approved sites planted with vulnerabilities to test which vulnerabilities the tool find sand misses.
Remember, just because an ASV runs your external vulnerability scan, it doesn’t mean your organization is secure. After receiving your scan report, you’re responsible for fixing discovered vulnerabilities and then re-scanning your environment until vulnerabilities have been properly addressed.
RUN INTERNAL VULNERABILITY SCANS
People often assume that if an ASV handles their external vulnerability scans, it means they’re compliant. However, if your ASV currently performs your external quarterly scans, understand they’re not likely handling your internal quarterly vulnerability scanning.
There are a variety of tools to help you comply with internal vulnerability scan requirements. For example, you can:
- Purchase an internal vulnerability scanning tool from your ASV or another service provider.
- Download an open source internal vulnerability scanning tool.
Keep in mind that the scanning tool you use still needs to be configured by a security expert after you purchase or download it.
Typically, if you purchase a vulnerability scanning tool or appliance, some support should be available. But if you download free scanning tools, take time to research and implement configuration best practices.
Remember, when it comes to vulnerability scanning, your organization is responsible for scan configuration, actual scanning, findings review, and vulnerability remediation.
PENETRATION TESTING BASICS
Penetration testing takes vulnerability detection to the next level.Penetration testers are people that analyze networks and systems, identify potential vulnerabilities or coding errors, and try to exploit them. In simple terms, penetration testers attempt to break into your company’s network by exploiting weaknesses the same way a hacker would. However, unlike a hacker, the penetration tester documents and communicates their methods so that you can fix vulnerabilities and improve security
A penetration test is a thorough, live examination designed to exploit weaknesses in your system.
Depending on your SAQ, PCI DSS requirement 11.3 may require an annual internal and external penetration test, but even if not required, performing regular penetration testing is a security best practice. Anyone can request a penetration test to measure their business’s security.
The time it takes to conduct a penetration test varies based on network size, system complexity, and the individual 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 detailed description of attacks used, testing methodologies, and suggestions for remediation.
In addition to annual penetration tests, perform a penetration test whenever large infrastructure changes occur to check if these changes introduced new vulnerabilities.
DIFFERENT TYPES OFPENETRATION TESTING
NETWORK PENETRATION TEST
The objective of a network penetration test is to identify security issues with the design, implementation, and maintenance of servers, workstations, and network services. PCI compliance requires these tests to be performed from both outside and within your environment, targeting the cardholder data environment at all access points.
Commonly identified security issues include:
- Misconfigured software, firewalls, and operating systems
- Outdated software and operating systems
- Insecure protocols
- Weak authentication practices
- Overly permissive access controls
MOBILE PENETRATION TEST
The objective of a mobile application penetration test is to identify security issues resulting from insecure development practices in the design, coding, and publishing of the software that supports a mobile application.
Commonly identified security issues include:
- Insecure local storage
- Information disclosures
- Injection vulnerabilities (e.g., SQL injection, cross-site scripting (XSS),remote code execution)
- Broken authentication (i.e., the log-in panel can be bypassed)
- Broken authorization (i.e., low-level accounts can access high-level functionality)
The objective of a segmentation check is to confirm that firewalls and other controls are preventing access to cardholder data and other sensitive environments as intended. Basically, segmentation checks confirm if network segmentation is set up properly.
For service providers that use segmentation to limit PCI scope, you’re required to conduct penetration tests on segmentation controls every six months and after any significant change to segmentation controls/methods.
Commonly identified security issues include:
- TCP access is allowed where it should not be
- ICMP (ping) access is allowed where it should not be
APPLICATION PENETRATION TEST
The objective of an application penetration test is to identify security issues resulting from insecure development practices in the design, coding, and publishing of the software.
- Commonly identified security issues include:
- Injection vulnerabilities (e.g., SQL injection, cross-site scripting, remote code execution)
- Broken authentication (i.e., the log-in panel can be bypassed)
- Broken authorization (i.e., low-level accounts can access high-level functionality)
- Improper error handling
- Vulnerable or outdated plugins, libraries, or other application dependencies
WIRELESS PENETRATION TEST
The objective of a wireless penetration test is to identify misconfigurations of authorized wireless infrastructure and the presence of unauthorized access points.
Commonly identified security issues include:
- Insecure wireless encryption standards
- Weak encryption passphrase
- Unsupported wireless technology
- Rogue and open access points
Social engineering assessment are used to test the effectiveness of an organization’s security awareness training. The tester will use typical business scenarios and personnel interactions to identify gaps in established security policies or human error. The goal of the tester is that of an attacker:to take advantage of the employee and trick them into doing something they shouldn’t.
Commonly identified security issues include:
- Employee(s) clicked on malicious emails
- Employee(s) allowed unauthorized individuals into secure areas
- Employee(s) connected a randomly discarded or discovered USB to their workstation
- Employee(s) divulge sensitive or secret information
TIPS FROM AN AUDITOR
REQUIREMENT 11: PENETRATION TESTING
If your organization is required to be PCI compliant, don’t procrastinate beginning the penetration test process. Finding and engaging a good penetration testing partner can take more time than you realize.
In performing PCI DSS assessments, it is common to see an organization’s penetration testing process, from start to finish, taking as long as everything else involved in the assessment combined.
If you wait until your QSA is onsite, or until your SAQ is due, to discuss penetration test scope, methodology, and objectives, you may be unable to meet your PCI compliance deadlines. Start thinking about penetration testing months before your PCI deadlines.
Remember, the required annual penetration test can begin before your PCI assessment, but you can’t be validated as PCI compliant before the testing is finished.
SecurityMetrics Security Analyst | CISSP | CISA | QSA
START DOCUMENTATION AND RISK ASSESSMENTS
REGULARLY DOCUMENT BUSINESS PRACTICES
Not only do policies and procedures need to be in place, but they also need to be documented. Policies should be written down and easily accessible by all employees.
Documentation helps protect your business from potential liability in the event of a breach. Thorough and accurately documented security policies and procedures help forensic investigators see what security measures your company has in place, and demonstrate your company’s proactive and committed approach to security.
If you are a service provider, your executive management is required to implement a PCI DSS Charter. This charter must establish responsibility for the protection of cardholder data and grant authority to create and implement a PCI DSS compliance program, including overall accountability for maintaining PCI DSS compliance. It must also define how the person responsible for PCI DSS compliance will communicate with executive management.
Third parties (e.g., partners, vendors, service providers) that have access to your CDE or cardholder data present a risk to the security of your environment. You must have a list of all third-party service providers you use, the PCI requirements these service providers impact or manage on your behalf, a process for performing due diligence prior to engaging a third party, and a way to monitor the PCI compliance of each third party you’ve engaged.
For PCI compliance, documentation of all security measures and actions should be updated regularly.
Documents you’ll want to include in your security policy:
ESTABLISH A RISK ASSESSMENT PROCESS
PCI requires all entities to perform an annual risk assessment that identifies critical assets, threats, vulnerabilities, and risks. This exercise helps organizations identify, prioritize, and manage information security risks.
Organizations that take a proactive approach to security will use internal and external resources to identify critical assets, assess vulnerabilities and threats against those assets, and implement a risk management plan to mitigate those threats.
A risk assessment should occur at least annually and after significant changes in your environment or business processes.
Just because a system is vulnerable doesn't mean it's exploitable or even likely to be exploited. Some vulnerabilities may require so many preconditions that the risk of a successful attack is virtually zero.
Part of a risk assessment is to assign a ranking or score to identifiedrisks. This will help establish priorities and provide direction on what vulnerabilities you should address first. Methodically identifying, ranking, and mitigating risks can decrease the time an attacker can access and negatively affect your systems, and over time closes the door to the attack.
PCI DSS TRAINING BEST PRACTICES
If you think your employees know how to secure cardholder data and what they’re required to do to be compliant, you’re probably mistaken. In fact, most breaches can be traced back to human error. Although most workers aren’t malicious, they often either forget security best practices or don’t know exactly what they’re required to do.
Unfortunately, many hackers will take advantage of human error to gain access to sensitive data. For example, when employees leave mobile devices in plain sight and unattended, they provide potential access to passwords, multi-factor authentication tokens, and other valuable information. Hackers may access networks because employees set up easy-to-guess passwords.And the list goes on.
Often, people are the weakest link in your overall security scheme.
By informing employees about and holding them accountable for their responsibilities, you can better protect your business and customers.
Employees need to be given specific rules and regular training. A security awareness program that includes regular training (e.g., brief monthly training or communications) will remind them of the importance of security, especially keeping them up to date with current security policies and practices.
- Communicate often: Focus each month on a different aspect of data security, such as passwords, social engineering, or email phishing.
- Give frequent reminders: Emphasize data security best practices to your employees through emails, newsletters, meetings, or webinars.
- Train employees on new policies ASAP: Newly hired employees should be trained on security andPCI policies as quickly as possible.
- Make training materials easily available: Intranet sites are a great way to provide access to training and policy information.
- Set clear expectations: Don’t present training asa list of “Do Nots.” Rather, help employees see that they all have a vested interest in protecting the organization and its business.
- Create incentives: Reward your employees for being proactive.
- Regularly test employees: Create an environment where employees aren’t afraid to report suspicious behavior.
TIPS FROM AN AUDITOR
REQUIREMENT 12: PCI COMPLIANCE BASICS
The risk assessment is where a lot of organizations struggle with PCI compliance. Many treat it as simply another item on the to-do list. In reality, a risk assessment can be the most important part of your overall security and compliance program, since it helps you identify systems, third parties, business processes, and people that are in scope for PCI compliance.
Too many companies approach PCI as simply an “IT issue” and are surprised when they realize PCI compliance touches a lot of other business processes and practices. If you aren’t doing a formal risk assessment now and are intimidated by the process, start small and plan to increase the scope of the review each year.
Another area of difficulty, especially for small organizations, is putting together a comprehensive and relevant security awareness program. Don’t be afraid of what you don’t know!
Even if you aren’t a security expert yourself, there is a wealth of security related information available online, and many resources that make it easy to present a polished training program to your employees. This is one area where the help of an outside security expert or partner can be valuable.
SecurityMetrics Security Analyst | CISSP | CISA | QSA
HOW TO PREPARE FOR A DATA BREACH
You can’t afford to be unprepared for the aftermath of a data breach. It’s up to you to control the situation, minimize damage to customers, reduce costs associated with a data breach, communicate properly to various authorities as set out by various standards and regulations, and protect your business.
The following section will help you better understand how to successfully stop payment card information from being stolen, mitigate damage, and restore operations as quickly as possible.
INCIDENT RESPONSE PLAN OVERVIEW
If your organization is breached, you may be liable for the following fines, losses, and costs:
Unfortunately, every organization will experience system attacks, with some of these attacks succeeding.
A well-executed incident response plan can minimize breach impact, reducef ines, decrease negative press, and help you get back to business more quickly. In an ideal world (and if you’re following PCI DSS requirements),you should already have an incident response plan in place, and employees should be trained to quickly deal with a data breach.
If there is no incident response plan, employees scramble to figure out what they’re supposed to do, and that’s when mistakes can occur.
For example, if employees wipe a system without first creating images of the compromised systems, then you would be prevented from learning what happened and what you can do to avoid re-infection.
INCIDENT RESPONSE PLAN PHASES
An incident response plan should be set up to address a suspected data breach in a series of phases with specific needs to be addressed.
The incident response phases are:
- Phase 1: Prepare
- Phase 2: Identify
- Phase 3: Contain
- Phase 4: Eradicate
- Phase 5: Recover
- Phase 6: Review
It’s important to discover a data breach quickly, identify where it’s coming from, and pinpoint what it has affected.
PHASE 1: PREPARE
Preparation often takes the most effort in your incident response planning, but it’s by far the most crucial phase to protect your organization.
This ongoing phase includes the following steps:
- Ensure your employees receive proper training regarding their incident response roles and responsibilities.
- Develop and regularly conduct tabletop exercises (i.e., incident response drill scenarios) to evaluate your incident response plan.
- Ensure that all aspects of your incident response plan (e.g., training, hardware and software resources)are approved and funded in advance.
PHASE 2: IDENTIFY
Identification (or detection) is an ongoing process where you determine whether you’ve actually been breached by looking for deviations from normal operations and activities.An organization normally learn they have been breached in one off our ways:
- The breach is discovered internally(e.g., review of intrusion detection system logs, alerting systems, system anomalies, or anti-virus scan malware alerts).
- Your bank informs you of a possible breach based on reports of customer credit card fraud.
- Law enforcement discovers the breach while investigating the sale of stolen card information.
- A customer complains to you because your organization was the last place they used their card before it began racking up fraudulent charges.
PHASE 3: CONTAIN AND DOCUMENT
When an organization becomes aware of a possible breach, it’s understandable to want to fix it immediately.
However, without taking the proper steps and involving the right people, you can inadvertently destroy valuable forensic data. Forensic investigators use this data to determine how and when the breach occurred, as well as help devise a plan to prevent similar future attacks.
When you discover a breach, remember: don’t panic, don’t make hasty decisions, don’t wipe and reinstall your systems (yet), and contact your forensic investigator to help you contain the breach.
Steps to consider during containment and documentation:
- Stop the leakage of sensitive data as soon as possible.
- Unplug affected systems from the network, rebuild clean new systems, and keep old systems offline. This is the best option if it’s possible, it allows a forensic investigator to evaluate untouched systems. This is easier to do in virtual server environments but can be costly.
- If system replacement is not possible, the next main task will be documentation. This means you need to preserve as much information as possible for forensic analysis. If you know how to take a complete image of your system, please do so. If you know where the virus files are, copy that directory to a backup. Resort to screenshots or phone videos of behaviors as a last resort before taking action to change the systems.
- Call in a professional forensic investigator to help learn about the breach. In some industries, this may be a required step (such as when payment data is stolen), but it’s always recommended to get forensic analysts involved, so you can develop better future processes.
PHASE 4: ERADICATE
After containing the incident, you need to find and remediate the policies, procedures, or technology that led to the breach. This means all malware should be properly removed, and systems should again be hardened, patched, and updated.Whether you do this or bring in a third party to help you, it’s important to be thorough. If any security issues or traces of malware remain in your systems, you may still be losing sensitive data (with your liability increasing).
PHASE 5: RECOVER
Recovering from a data breach is the process of restoring and returning affected systems and devices back into your business environment. During this time, it’s important to get your systems and business operations up and running again as quickly as possible.Remember to ensure all systems have been hardened, patched, replaced, and tested before you consider reintroducing the previously compromised systems back into your production environment.
PHASE 6: REVIEW
After the forensic investigation, meet with all incident response team members and discuss what you’ve learned from the data breach, reviewing the events in preparation for future attacks.This is when you will analyze everything about the breach. Determine what worked well and what didn’t in your response plan. Use this information to revise your plan.
WHAT TO INCLUDE IN AN INCIDENT RESPONSE PLAN
Creating an incident response plan can seem overwhelming. To help you accomplish this task, develop your incident response plan using smaller, more manageable procedures.
While every organization needs varying policies, training, and documents, there are a few itemized response lists that most organizations should include in their incident response plan:
- Emergency contact and communications list
- System backup and recovery processes list
- Forensic analysis list
- Jump bag list
- Security policy review list
EMERGENCY CONTACT AND COMMUNICATIONS LIST
Proper communication is critical to successfully managing a data breach, which is why you need to document a thorough emergency contact/communications list. Your list should contain information about: who to contact, how to reach these contacts, the appropriate timelines to reach out, and what should be said to external parties.
Make sure to document everyone that needs to be contacted in the event of a data breach, such as the following individuals and groups:
- Your response team
- Your executive team
- Your legal team
- Your forensic company
- Your public relations advisor(s)
- Affected individuals
- Law enforcement
- Merchant processor
Your incident response team should craft specific statements that target the various audiences, including a holding statement, press release, customer statement, and internal/employee statement. For example, you should have prepared emails and talking points ready to go after a data breach.
- Your statements should address questions like:
- Which locations were and are impacted by the breach?
- How was the breach discovered?
- Is any other sensitive data at risk?
- How will the breach affect patients and the community?
- What services or assistance (if any) will you provide your patients?
- When will you be back up and running?
- What will you do to prevent data breaches from occurring again?
Identify in advance the party within your organization that is responsible for timely notifications that fulfill your state’s specific requirements. This could be your inside legal counsel, newly hired breach management firm, orC-level executive. This person should be trained and notification templates should be written in advance.
Your public response to the data breach will be judged heavily, so review your statements thoroughly.
SYSTEM BACKUP AND RECOVERY PROCESSES LIST
Your system backup and recovery processes list will help you deal with the technical aspects of a data breach.
Here are some things that should be included:
Process for disconnecting from the Internet(e.g., who is responsible to decide whether or not to disconnect)
System configuration diagrams that include information like device descriptions, IP addresses, and OS information
Process for switching to redundant systems and preserving evidence
Process for preserving evidence (e.g., logs, time stamps)
Practices to test the full system backup and system recovery
Steps to test and verify that any compromised systems are clean and fully functional
This list helps you preserve any compromised data, quickly handle a data breach, and preserve your systems through backups. By creating and implementing this list, your organization can lessen further data loss and help you return to normal operations as quickly as possible.
FORENSIC ANALYSIS LIST
A forensics analysis list is for organizations that use in-house forensic investigations resources.
Your forensic team will need to know where to look for irregular behavior and how to access system security and event logs. You might need multiple lists based on your different operating systems and functionalities (e.g.,server, database).
Your forensic team may need the following tools:
- Data acquisition tools
- Clean/wiped USB hard drives
- Cabling for all connections that they could experience in your environment
- Other forensic analysis tools (e.g., EnCase, FTK, X-Ways)
If your organization doesn’t have access to an experienced computer forensic examiner in-house, you will want to consider hiring a forensic firm, vetting them in advance with pre-completed agreements. This vetting process helps ensure you get an experienced forensic investigator when you need it.
JUMP BAG LIST
Your jump bag list is for grab-and-go responses (i.e., when you need to respond to a breach quickly). This list should include overall responses and actions that employees need to take immediately after a breach. Your list will keep your plan organized and prevent mistakes caused by panic.
Here are some things to include in your jump bag:
- Incident handler’s journal to document the incident (e.g., who, what, where, when, why)
- Incident response team contact list
- USB hard drives and write-blockers
- USB multi-hub
- Flashlight, pens, and notebooks
- All of your documented lists
- USB containing bootable versions of your operating system(s)
- Computer and network tool kit
- Hard duplicators with write-block capabilities
- Forensic tools and software (if you decide to use in house forensic investigations resources)
SECURITY POLICY REVIEW LIST
Your security policy review list deals with your response to a breach and its aftermath. This list helps you analyze the breach and shows you what changes need to be made.
Your security policy review list should include documentation of the following things:
When the breach was detected, by whom, and through what method• Scope of the incident and affected systems• Data that was put at risk• How the breach was contained and eradicated• Work performed or changes made to systems during recovery• Areas where the incident response plan was effective• Areas that need improvement(e.g., which security controls failed, necessary security awareness program changes)
The purpose of this list is to document the entire incident, what was done, what worked, what didn’t, and what was learned.
You should look at where your security controls failed and how to improve them.
DEVELOP YOUR INCIDENT RESPONSE PLAN
Developing and implementing a thorough incident response plan will help your business handle a data breach quickly and efficiently, while also minimizing the damage from a data breach.
STEP 1: IDENTIFY AND PRIORITIZE ASSETS
Start by identifying and documenting where your organization keeps its crucial data assets. Assess what would cause your organization to suffer heavy losses if it was stolen or damaged.
After identifying critical assets, prioritize them according to the importance and highest risk (e.g., risks based on your annual risk assessment),quantifying your asset values. This will help justify your security budget and show executives what needs to be protected and why it’s essential to do so.
STEP 2: IDENTIFY POTENTIAL RISKS
Determine what risks and attacks are the greatest current threats against your systems. Keep in mind that these risks will be different for every organization.
For organizations that process data online, improper coding could be their biggest risk. For a brick-and-mortar organization that offers Wi-Fi for their customers, their biggest risk may be improper network access. Some organizations may place a higher priority on ensuring physical security, while others may focus on securing their remote access applications.
Here are examples of a few possible risks:
- External or removable media: Malware executed from removable media (e.g., flash drive, CD)
- Attrition: Employs brute force methods (e.g., DDoS, password cracking)
- Web: Malware executed from a site or web-based app (e.g., drive-by download)
- Email security: Malware executed via email message or attachment(e.g., malware, ransomware)
- Impersonation: Replacement of something benign with something malicious (e.g., SQL injection attacks, rogue wireless access points)
- Loss or theft: Loss of computing device or media (e.g., laptop, smartphone)
STEP 3: ESTABLISH PROCEDURESIf you don’t have established procedures, a panicked employee may make detrimental security errors that could damage your organization.
- Your data breach policies and procedures should include:
- A baseline of normal activity to help identify breaches
- How to identify and contain a data breach
- How to record information on a breach
- Notification and communications plan
- Defense approach
- Employee training
Over time, you may need to adjust your policies according to your organization’s needs. Some organizations might require a more robust notification and communication plan, while others might need help from outside resources.
However, all organizations need to focus on employee training (e.g., your security policies and procedures).
STEP 4: SET UP A RESPONSE TEAM
Organize an incident response team that coordinates your organization’s actions after discovering a data breach. Your team’s goal should be to coordinate resources during a security incident to minimize impact and restore operations as quickly as possible.
Some of the necessary team roles are:
- Team leader
- Lead investigator
- Communications leader
- C-suite representative
- IT director
- Public relations
- Documentations and timeline leader
- Human resources
- Legal representative
- Breach response experts
Make sure your response team covers all aspects of your organization and understand their particular roles in the plan. Each member will bring a unique perspective to the table, and they should own specific data breach response roles that are documented to manage a crisis.
STEP 5: SELL THE PLAN
Your incident response team won’t be effective without proper support and resources to follow your plan.
Security is not a bottom-up process. Management at the highest level (e.g.,CEO, VP, CTO) must understand that security policies–like your incident response plan–must be implemented from the top and be pushed down. This is true for both enterprise organizations as well as mom-and-pop shops.
For enterprise organizations, executives need to be on board with your incident response plan. For smaller organizations, management needs to support additional resources for incident response.
When presenting your incident response plan, focus on how your plan will benefit your organization(e.g., financial and brand benefits).For example, if you experience a data breach and manage the incident poorly, your company’s reputation will likely receive irreparable brand damage.
The more effectively you present your goals, the easier it will be to obtain necessary funding to create, practice, and execute your incident response plan.
STEP 6: TRAIN YOUR STAFF
Just having an incident response plan isn’t enough. Employees need to be properly trained on your incident response plan and know what they’re expected to do after a data breach. This means training your team on a regular basis to ensure they know how to respond.
The regular work routine makes it easy for staff to forget crucial security lessons and best practices.
Employees also need to understand their role in maintaining company security. To help them, teach employees to identify attacks such as phishing emails, spear phishing attacks, and social engineering efforts.
TEST YOUR INCIDENT RESPONSE PLAN
To help staff, regularly test their reactions through real-life simulations, also known as tabletop exercises.Tabletop exercises allow employees to learn about and practice their incident response roles when nothing is at stake, which can help you and your staff discover gaps in your incident response plan (e.g.,communication issues).
TYPES OF TABLETOP EXERCISES
In a discussion-based tabletop exercise, incident response team members discuss response roles in hypothetical situations. This tabletop exercise isa great starting point because it doesn’t require extensive preparation or resources, while it still tests your team’s response to real-life scenarios without risk to your organization.
However, this exercise can’t fully test your incident response plan or your team’s response roles.
In a simulation exercise, your team tests their incident responses through a live walk-through test that has been highly choreographed and planned.This exercise allows participants to experience how events actually happen, helping your team better understand their roles.
However, simulation exercises require a lot of time to plan and coordinate, while still not fully testing your team’s capabilities.
In parallel testing, your incident response team actually tests their incident response roles in a test environment. Parallel testing is the most realistic simulation and provides your team with the best feedback about their roles.
Parallel testing is more expensive and requires more time planning than other exercises because you need to simulate an actual production environment, with realistic systems and networks.
CONDUCT A TABLETOP EXERCISE
Before conducting a tabletop exercise, determine your organization’s needs by asking:
- Has your incident response team received adequate training about their roles and responsibilities?
- When did you last conduct a tabletop exercise?
- Have there been any recent organizational changes that might affect your incident response plan?
- Has there been any recent guidance or legislation that might impact your incident response plan?
Next, design your tabletop exercise around an incident response plan topic that you want to test. Identify any desired learning objectives and outcomes. From there, create and coordinate with your tabletop exercise staff (e.g.,facilitator, participants, data collector) to schedule your tabletop exercise.
When designing your tabletop exercise, prepare the following exercise information in advance:
- A facilitator guide that documents your tabletop exercise’s purpose, scope, objective, and scenario, including a list of questions to address your exercise’s objectives.
- A participant briefing that includes the tabletop exercise agenda and logistics information.
- A participant guide that includes the same information as the facilitator guide, except it either doesn’t include any of the questions or includes a shorter list of questions specifically designed to prepare participants.
- An after-action report that documents the evaluations, observations, and lessons learned from your tabletop exercise staff.
After conducting a tabletop exercise, set up a debrief meeting to discuss incident response successes and weaknesses. Your team’s input will help you know where and how to make necessary revisions to your incident response plan and training processes.
DATA BREACH PREVENTION TOOLS
INSTALL AND REVIEW FILE INTEGRITY MONITORING SOFTWARE
File integrity monitoring (FIM) software is a great companion for your malware prevention controls. New malware comes out so frequently you can’t just rely on anti-virus software to protect your systems. It often takes many months for a signature of newly detected malware to make it into the malware signature files, which allows it to be detected by antivirus software.
Configure FIM software to watch critical file directories for changes. FIM software is typically configured to monitor areas of a computer’s file system where critical files are located. FIM tools will generate an alert that can be monitored when a file is changed.
Malware is software that consists of files that are copied to a target computer. Even if your anti-virus software cannot recognize the malware files' signatures, FIM software will detect that files have been written to your computer and will alert you to check and make sure you know what those files are. If the change was known (like a system update), then you don’t need to worry. If not, chances are you have new malware added that could not be detected and can now be dealt with.
FIM can also be set up to check if web application code or files are or were modified by a threat actor.
Here are examples of some places where FIM should beset up to monitor:
- OS critical directories
- Critical installed application directories
- Web server and web application directories
- User areas (if it's an employee-facing computer)
INSTALL INTRUSION DETECTION AND PREVENTION SYSTEMS
One of the reasons data breaches are so prevalent is a lack of proactive, comprehensive security dedicated to monitoring system irregularities, such as intrusion detection systems (IDS) and intrusion prevention systems (IPS).
Using these systems can help identify a suspected attack and help you locate security holes in your network that attackers used. Without the knowledge derived from IDS logs, it can be very difficult to find system vulnerabilities and determine if cardholder data was accessed or stolen.
By setting up alerts on an IDS, you can be warned as soon as suspicious activity is identified and be able to significantly minimize compromise risk within your organization. You may even stop a breach in its tracks.
For more preventive measures, you might consider an IPS, which also monitors network activity for malicious activities, logs this information, and reports it; but it can prevent and block many intrusions that are detected. An IPS can drop malicious packets, block traffic from the malicious source address, and reset connections.
An IDS can help you detect a security breach as it is happening in real time.
DATA LOSS PREVENTION SOFTWARE
In addition to these, you should have data loss prevention (DLP) software in place. DLP software watches outgoing data streams for sensitive or critical data formats that should not be sent through a firewall, and it blocks this data from leaving your system.
Make sure to properly implement it so that your DLP knows where data is allowed to go, since if it’s too restrictive, it might block critical transmissions to third party organizations.
PCI DSS BUDGET
The cost of PCI compliance depends on your organization's structure. Here are a few variables that will factor into the cost of your overall compliance to the PCI DSS:
Your business type (e.g., franchise, service provider, mom-and-pop shop): Each business type will have varying amounts of transactions, cardholder data, environment structure, risk levels, and merchant or service provider levels, meaning that each business will have different security requirements.
Your organization size: Typically, the larger the organization, the more potential vulnerabilities it has. More staff members, more programs, more processes, more computers, more cardholder data, and more departments mean more cost.
Your organization’s environment: The type of processing systems, the brand of computers, the kind of firewalls, the model of back-end servers, etc. can all affect your PCI cost.
Your organization’s dedicated PCI staff and outside help: Even with a dedicated team, organizations usually require outside assistance or consulting to help them meet PCI requirements.
The following are estimated annual PCI budgets:
* Keep in mind this budget doesn’t include implementing and managing security controls, such as firewalls, encryption, and updating systems and equipment.
CREATE A SECURITY CULTURE
Unless someone oversees PCI on management’s side (not just IT), PCI compliance won’t happen. We often see companies with various groups (e.g., networking, IT, HR, Risk) expecting other departments to take charge of PCI compliance. Other times, organizations expect a QSA to be the PCI project manager, which is not feasible.
Security is not a bottom-up process. Management often says or implies that IT should “just get their organization secure.” However, those placed in charge of PCI compliance and security may not have the means necessary to reach their goals.
For example, IT may not have budget to implement adequate security policies and technologies (e.g., firewalls, FIM). Some may try to look for free software to fill in security gaps, but this process can be expensive due to the time it takes to implement and manage. In some instances, we have seen that the IT department wanted their PCI auditor to purposely fail their compliance evaluations so they could prove their higher security budget needs. Obviously, it would have been better to focus on security from the top level down beforehand.
C-level management should support the PCI process. If you are a C-level executive, you should be involved with budgeting, assisting, and establishing a security culture from the top-down.
Additionally, organizations can sometimes focus on becoming "certified"as PCI compliant, while not actually addressing, monitoring, and regularly reviewing critical security controls and processes. Keep in mind that this attitude of just checking off SAQ questions doesn't make an organization PCI compliant, nor will it protect them from future data breaches.
OVERCOME MANAGEMENT’S BUDGET CONCERNS
If you’re having problems communicating budgetary needs to management, conduct a risk assessment before starting the PCI process. NIST 800-30 isa good risk assessment protocol to follow. At the end of your assessment, you’ll have an idea of your compromise probability, how much a compromise would cost, and the impact a breach might have on your organization(including brand damage).
Simply put, you need to find a way to show how much money weak security will cost the organization. For example, “if someone gains access to the system through X, this is how much it will cost and how much damage it will cause.” Consider asking marketing or accounting teams for help delivering the message in more bottom-line terms.
If possible, work with a QSA to come up with security controls to address what tools you may need to implement.
TIPS FROM AN AUDITOR
PCI DSS RESPONSIBILITIES AND CHALLENGES
In my experience, small merchants and service providers tend to struggle with documenting and following policies and procedures. During a PCI DSS assessment, a QSA will verify that required policies and procedures are in place and being followed.
Smaller merchants and service providers whose CDE consists of only a few machines often feel that they don’t have time to document procedures.Unfortunately, it’s not uncommon to perform a renewal assessment where the business neglected to maintain compliance due to employee turnover and lack of documentation.
At a minimum, small merchants should set up a PCI email user or active directory account and add reminders in their calendar to perform security processes throughout the year (e.g., quarterly vulnerability assessment scans, semi-annual firewall reviews). The evidence collected from these tasks can then be sent to that PCI account for storage. This is a low-cost solution that can help key personnel keep PCI DSS compliance on their minds throughout the year. It will also help document necessary evidence for their annual self-assessment (or to their assessor).
Large enterprise organizations usually document their policies and procedures sufficiently. They generally have specific and thorough change control processes, and they typically follow documented approval processes prior to implementing changes to their CDE. Unfortunately, due to their size and the different entities involved in their CDE management, their reaction time tends to be much slower, with different stakeholders often making contradictory decisions. When vulnerability scans or penetration tests identify weaknesses that may place their CDE at risk, it’s not always apparent which group should be responsible for addressing these vulnerabilities.
To address some of these concerns, service providers are required to define a charter for the organization’s compliance program, involving executive management. While this is only required for service providers, it’s recommended that larger merchants follow this requirement as well.
Large organizations and service providers should establish an officialPCI charter that describes the management and accountability of the organization’s compliance program (requirement 12.4.1). Additionally, they should implement internal audit procedures to ensure security practices are properly in place throughout the year (requirement 10.8 and 12.11).
PCI compliance cannot just be an annual audit event.
Often, organizations are not leveraging many of the PCI requirements in away that actually increases security for their CDE.
For instance, PCI requires log centralization and daily reviews. PCI also requires change detection or FIM on CDE systems to detect unauthorized changes to key files and directories. To achieve compliance, organizations might set up log monitoring and FIM, but then ignore every alert coming their way. They may technically have FIM and log monitoring in place, but these systems alone are not making their environments more secure.
If organizations do not take the necessary time and effort to respond to genuine alerts, the only thing they will gain are check marks on their SAQ.
SecurityMetrics Senior Security Analyst | CCSFP | MCIS | CISSP | CISA | QSA
TERMS AND DEFINITIONS
Advanced Encryption Standard (AES): A government encryption standard to secure sensitive electronic information.
Approved Scanning Vendor (ASV): A company approved by the PCI SSC to conduct vulnerability scanning tests.
Captured: Data is being recorded, gathered, and/or stored from an unauthorized source.
Card Verification Value (CVV/CSC/CVC/CAV): Element on a payment card that protects information on the magnetic stripe. Specific acronyms depend on the card brand.
Cardholder Data Environment (CDE): Any individual, software, system, or process that processes, stores, or transmits cardholder data.
Cardholder Data (CHD): Sensitive data found on payment cards, such as an account holder name or PAN data.
Data Loss Prevention (DLP): A piece of software or strategy used to catch unencrypted data sent outside the network.
Exfiltrated: Unauthorized data is transferred from a system.
Federal Information Processing Standards (FIPS): US federal government standards for computer security that are publicly announced (e.g.,encryption standards).
File Integrity Monitoring (FIM): A method to watch for changes in software, systems, and applications to detect potential malicious activity.
File Transfer Protocol (FTP): An insecure way to transfer computer files between computers using the Internet. (See SFTP)
Firewall (FW): A system designed to screen incoming and outgoing network traffic.
Hypertext Transfer Protocol (HTTP): A method of communication between servers and browsers. (See HTTPS)
Hypertext Transfer Protocol Over Secure Socket Layer (HTTPS): A secure method of communication between servers and browsers. (See HTTP)
Incident Response Plan (IRP): Policies and procedures to effectively limit the effects of a security breach.
Information Technology (IT): Anything relating to networks, computers, and programming, and the people that work with those technologies.
Internet Protocol (IP): Defines how computers send packets of data to each other.
Intrusion Detection System/Intrusion Prevention System (IDS/IPS): Types of systems that are used to monitor network traffic and report potential malicious activity.
Multi-factor Authentication (MFA): Two out of three independent methods of authentication are required to verify a computer or network user. The three possible factors are:
Something you know (such as a username and password)
Something you have (such as an RSA token or one-time password token)
Something you are (such as fingerprint or iris scans)
National Institute of Standards and Technology (NIST): Federal agency that measures standards and maintains the National Vulnerability Database (NVD).
National Vulnerability Database (NVD): A repository of all known vulnerabilities, maintained by NIST.
Network Access Control (NAC): Restricts data that users, apps, and programs can access on a computer network.
Open Web Application Security Project (OWASP): A non-profit organization focused on software security improvement. Often heard in the context of “OWASP Top 10,” a list of top threatening vulnerabilities.
Payment Card Industry Data Security Standard (PCI DSS): Requirements put together by the PCI SSC, required of all businesses that process, store, or transmit payment card data to help prevent cardholder data theft.
Payment Card Industry Security Standards Council (PCI SSC): An organization established in 2006 by Visa, MasterCard, American Express, Discover Financial Services, and JCB International to regulate cardholder data security.
Point-To-Point Encryption (P2PE): Payment card data encryption from the point of interaction to a merchant solution provider.
Primary Account Number (PAN): The 14 or 16 digits that identify a payment card. Also called a bank card number.
Qualified Security Assessor (QSA): Individuals and firms certified by the PCI SSC to perform PCI compliance assessments.
Risk: The likelihood a threat will trigger or exploit a vulnerability and the resulting impact on an organization.
Risk Assessment (RA): An assessment of the potential vulnerabilities, threats, and possible risk to the confidentiality, integrity, and availability of payment data held by an organization.
Risk Management Plan (RMP): The strategy to implement security measures to reduce risks and vulnerabilities to a reasonable and appropriate level.
Role-Based Access Control (RBAC): The act of restricting users’ access to systems based on their role within an organization.
Secure File Transfer Protocol (SFTP): A secure way to encrypt data that is in transit.
Secure Socket Layer (SSL): An outdated Internet security standard for encrypting the link between a website and a browser to enable transmission of sensitive information (predecessor to TLS).
Self-Assessment Questionnaire (SAQ): A collection of questions used to document an entity’s PCI DSS assessment results, based on their processing environment.
Threat: The potential for a person, event, or action to exploit a specific vulnerability.
Transport Layer Security (TLS): A more secure Internet security standard for encrypting the link between a website and a browser to enable transmission of sensitive information (See SSL)
Two-Factor Authentication (TFA): (See MFA)
Virtual Private Network (VPN): A strategy of connecting remote computers to send and receive data securely over the Internet as if they were directly connected to the private network.
Vulnerability: A flaw or weakness in procedures, design, implementation, orsecurity control that could result in a security breach.
Vulnerable: A system, environment, software, and/or website can be exploited by an attacker.
Web Application Firewall (WAF): An application firewall that monitors, filters, and blocks HTTP traffic to and from a web application.
Wi-Fi Protected Access (WPA): A security protocol designed to secure wireless computer networks.
Wi-Fi Protected Access II (WPA2): A more secure version of WPA. (See WPA)
Wired Equivalent Privacy (WEP): An outdated and weak security algorithm for wireless networks.
Wireless Local Area Network (WLAN): A network that links to two or more devices wirelessly.
We secure peace of mind for organizations that handle sensitive data. We hold our tools, training, and support to a higher, more thorough standard of performance and service. Never have a false sense of security.
We are a PCI certified Approved Scanning Vendor (ASV), Qualified SecurityAssessor (QSA), Certified Forensic Investigator (PFI), and ManagedSecurity provider with over 20 years of data security experience. From local shops to some of the world’s largest brands, we help all businesses achieve data security through managed services, compliance mandates (PCI, HIPAA,GDPR), and security assessments (HITRUST consulting and assessments).We have tested over 1 million systems for data security and compliance. We are privately held and are headquartered in Orem, Utah, where we maintain a Security Operations Center (SOC) and 24/7 multilingual technical support.