Use our guide as a resource for your PCI compliance efforts.
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.
Some organizations have simple, easy-to-correct vulnerabilities that could lead to data breaches. In other instances, organizations with intricate IT defenses and processes are overridden by an employee opening a phishing email.
Our guide was specifically created to help merchants and service providers address the most problematic issues within the 12 PCI DSS requirements, including auditors’ best practices and IT checklists.
Our guide is not intended to be a legal brief on all requirements and aspects of PCI compliance. Rather, it approaches PCI from the perspective of a security analyst, focusing on how to protect your cardholder data. Thus, we recommend using it as a resource to help with your PCI compliance efforts.
Ultimately, our goal is to help you better protect your data from inevitable future attacks.
MATT HALBLEIB
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.
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):
Milestones
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
The Payment Card Industry Data Security Standard (PCI DSS) was established in 2006 by the major card brands (e.g., Visa, MasterCard, American Express, Discover Financial Services, and JCB International).
All businesses that process, store, or transmit payment card data are required to implement the security standard to prevent cardholder data theft. The investigation of numerous credit card data compromises has confirmed that the security controls and processes required in the PCI DSS are essential to protecting cardholder data.
Merchants often have a difficult time attaining (or maintaining) compliance for a variety of reasons. Many smaller merchants believe it’s too technical or costly, while others simply don’t believe it’s effective and refuse to comply. In fact, our data concluded that the average breached organization at the time of data compromise was not compliant with at least 47% of the PCI DSS requirements.
93.3% of SecurityMetrics customers that started their SAQ have achieved passing status
REQUIREMENT 1: PROTECT YOUR SYSTEM WITH FIREWALLS
REQUIREMENT 2: USE ADEQUATE CONFIGURATION STANDARDS
REQUIREMENT 3: PROTECT STORED 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 TESTING
REQUIREMENT 12: START DOCUMENTATION AND RISK ASSESSMENTS
TOP 10 FAILING SELF-ASSESSMENT QUESTIONNAIRE (SAQ) SECTIONS
We scanned our merchant database in search of the top 10 areas where SecurityMetrics merchants struggle to become compliant. Starting with the least adopted requirement, these are the results:
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.
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.
If the people, process, or technology component stores, processes, or transmits cardholder data (or is connected to systems that do), it’s considered in scope for PCI compliance. This means that PCI requirements
apply and the system components must be protected.
System components likely in scope for your environment include:
Depending on the way you process, store, and transmit payment data, there are different SAQs that you must choose to fill out. For example, if you don’t have a storefront and all products are sold online through a third party, you probably qualify for SAQ A or SAQ A-EP. These different SAQ types will be further explained later in this section.
93.6% of SecurityMetrics customers who started their SAQ went on to complete it in 2021.
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.
You need to understand your business environment—especially what systems are included and how those systems interact with sensitive data.
You are then required to apply PCI DSS security requirements to all system components included in or connected to the cardholder data environment (CDE), which is “comprised of people, processes, and technologies that store, process, or transmit CHD or sensitive authentication data.”
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.
When performing your annual PCI DSS scope assessment, list and confirm all connected-to systems, which are system components that:
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.
Segmentation prevents out-of-scope systems from communicating with systems in the CDE or from impacting the security of the CDE. An out-of- scope system is a system component that:
To be considered out of scope, controls must be in place to provide reasonable assurance that the out-of-scope system cannot be used to compromise an in-scope system component. Here are some examples of controls you can use:
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.
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.
In my experience performing PCI audits, entities often overlook the same types of systems when doing their own PCI scoping. For instance, call centers usually pay little attention to QA systems, which often store cardholder data in the form of call recordings. These systems are in scope for all PCI requirements!
Simple questions can help you begin the scoping process. For example, ask yourself:
There are always processes you might not realize. For example, if you are a retail store that swipes cards, do you ever take card numbers over the phone or receive emails with card information? Are any paper orders received? Organizations often have finance, treasury, or risk groups that have post-transaction processes involving cardholder data. It is important to include these processes when determining scope.
Don’t forget power outage procedures where card data is sometimes taken down manually. For example, in most call centers, we’ve discovered that agents are typically unaware that card data should never be written down. But when the application they use for recording cardholder data freezes, they tend to resort to typing or writing it down in a temporary location and retrieving it later for entry. These temporary locations are rarely considered in an organization’s PCI compliance efforts but can lead to increased risk and should be included in PCI scope.
Often, paper trails of hand-written information or photocopied payment card data can sometimes fill multiple rooms. Even if card data is 10 years old, it is still in PCI scope.
If you access a web page for data entry, there’s a decent chance card data can be found in temporary browser cache files. In addition, it’s the website developer’s responsibility to make sure websites don’t generate cookies or temporary log files with sensitive data. However, you don’t always have full control of your website, which is why it’s important to evaluate all systems for cardholder data, even where you might not expect it to reside.
For organizations with web portals, if someone mistypes card data into an address or phone number field, iti s still considered in PCI scope.
You might think your databases are set up to encrypt all cardholder data. However, servers you consider out of scope will often hold temporary files, log files, or back-ups with lots of unencrypted data. System administrator folders on file servers are also common culprits, as they often back up failing servers in a rush to prevent data loss without considering the PCI implications.
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®.
For organizations with web portals, if someone mistypes card data into an address or phone number field, it is still considered in PCI scope.
Organizations need to have methods to detect these mistakes and prevent or delete them. Some use a data loss prevention (DLP) solution to help them with this process.
The next step in determining your PCI scope is to find everything that can communicate with the devices you have identified. This is often the hardest part about scoping because you may not understand what can communicate to your systems. Ask yourself:
If you have a server that handles cardholder data, you must always consider what else communicates with that server. Do you have a database server in some other zone you consider out of scope but is reaching that web server to pull reports and save data? Anything that can initiate a connection to an in-scope server that handles cardholder data will be in scope for compliance.
In addition, if your system in the CDE initiates a communication out to a server in another zone, that server will also be in scope. There are very few exceptions to this.
MATT HALBLEIB
CISSP | CISA | QSA (P2PE) | PA-QSA (P2PE)
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 A
SAQ A-EP
SAQ B
SAQ B-IP
SAQ C-VT
SAQ C
SAQ P2PE
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:
Some merchants will have multiple payment flows that together may not fit any SAQ type besides the SAQ D. For instance, a merchant may have an outsourced e-commerce payment channel that would fit the SAQ A but may also accept card-present transactions using an analog-connected bank terminal (SAQ B).
A merchant with multiple payment channels will likely be required to complete the SAQ D as they would not be able to affirmatively answer the qualifying criteria questions when taking looking at their multiple payment channels together.
Some merchant banks will allow a merchant to assess each payment channel separately with the SAQ that matches each payment channel.So, in the case of an SAQ A + SAQ B combo environment, the merchant maybe able to complete an SAQ A to cover their e-commerce channel and anSAQ B to cover the card-present payment channel and provide their bank with both SAQs
If your merchant environment consists of two or more simple payment channels, it may be worth your time to have a conversation with your merchant bank to see if you would be able to assess each payment channel separately.
In 2018, the PCI council released a new payment security tool–the DataSecurity Essentials (DSE) Evaluation Tool–to simplify security evaluation and increase security awareness for eligible small merchants. The DataSecurity Essentials Evaluation Tool includes 15 new categories from the PCICouncil–based on payment acceptance methods–which will help smaller merchants simplify their compliance process and get the most benefit from their efforts.
“Merchants are only eligible to use a Data Security Essentials evaluation if they have been notified by their acquirer [aka their merchant bank] that it is appropriate for them to do so.”
To find out more information about DSE evaluations and your possible options, contact your merchant bank.
The adoption of PCI DSS version 4.0 will include an overlapping sunset date for PCI DSS version 3.2.1 so that the transition between versions will be smooth. The adjacent diagrams show PCI DSS 4.0 development and transition timelines we put together from information provided by the PCICouncil. The dates in the timelines are the best available at publishing, but it is felt that these dates do represent a very accurate release and transition schedule. One thing to focus on is that ample time has been provided for the transition from PCI DSS 3.2.1 to PCI DSS 4.0.
In addition, any new requirements being added to the standard will be future-dated when the standard is released, in order to allow new processes to be developed before any new requirements will be enforced. So, remain calm and keep progressing in your compliance efforts with the current version of the standard.
Why is the PCI Council making a major rewrite of the PCI DSS when it is considered to be a fairly mature standard? There are four major reasons for the changes:
1. ENSURE THE STANDARD CONTINUES TO MEET THE SECURITY NEEDS OF THE PAYMENTS INDUSTRY
As time moves on, technology changes and so do the attack vectors of bad actors trying to compromise systems.
It is important to keep up with this changing technology. PCI DSS 4.0will address these changes, from scoping to cloud computing. The following table shows some of the expected areas of further guidance and definition. This may not be an exhaustive list but will give you some ideas of what to expect.
2. PROMOTE SECURITY AS A CONTINUOUS PROCESS
From the beginning, PCI DSS requirements were created to help organizations develop security best practice habits that would be followed year-round, rather than only during an annual assessment period.
Many organizations have been able to make this transition to the mindset of security as a lifestyle, while others are still focused on passing an assessment and moving on.
PCI DSS 4.0 will continue to emphasize this transition to security as a business-as-usual process. For example, there may be changes in sampling guidance to include more gathering of validation information over a period of time to support and ensure that a continuous security process is in place.
The release of the new 4.0 version may cause anxiety for those already familiar with the current PCI DSS requirements. Rest assured that the 12 core PCI DSS requirements remain fundamentally the same; version4.0 is not a totally new standard.
3. ENHANCE VALIDATION METHODS AND PROCEDURES
The PCI Council wants to look at validation methods and procedures to make sure they are meshing with the new PCI DSS 4.0 release.
Currently, there is not much information available on this topic from the Council, but we do know that they will be seeking feedback from participating organizations on ways to improve this aspect. For example, it is expected that the SAQ and AOC processes and contents will be evaluated and enhanced. It remains unclear how or if the new customized approach methods will be applicable to current SAQ validation methods.
4. ADD FLEXIBILITY AND SUPPORT OF ADDITIONAL METHODOLOGIES TO ACHIEVE SECURITY
QSAs sometimes get asked the question “our methods are secure; can’t I meet this requirement another way?” The response had to be “we could look at defining a compensating control, but that is considered a temporary solution until you can meet the requirement the right way."
Version 4.0 of the PCI standard will try to resolve this scenario byintroducing the concept of validation of a security control using aCustomized Approach. Now, for those companies who have controls alreadyin place that meet the requirement as stated, that still works and is a viableway to achieve compliance.
This familiar method is the Defined Approach, and it’s essentially what we have been doing for the past 16 years. Either approach option can be used for a PCI DSS requirement and approaches can even be mixed up within a single Report on Compliance (RoC).
The biggest new aspect around the new 4.0 version is the concept that PCIDSS will allow customization of requirements and testing procedures.
There are many ways to secure computer systems and networks. Many companies have security solutions in place that may meet the intent of a security objective but not meet a specific requirement. This approach could let entities show how their specific solution meets the intent of the security objective and addresses the risk, and therefore provides an alternative way to meet the requirement.
This new approach will take the place of compensating controls in the 4.0standard. The PCI council has stated that “Unlike compensating controls, customized validation will not require a business or technical justification for meeting the requirements using alternative methods, as the requirements will now be outcome-based.”
This new validation method will most likely result in more assessment work initially for the entity in order to prepare documentation and risk assessment data for a QSA to evaluate. It will then require specialized testing procedures to be developed by the QSA and agreed upon by the entity (see adjacent chart).
The customized approach will not be for everyone and will be most suited for entities with mature security and risk assessment processes in place.
The custom process provides the advantage of defining a more permanent solution for compliance validation of specialized security controls. This is different from previous temporary compensating controls in earlier versions of the standard, where you had to document a justification for the control with a business or technical constraint.
The customized approach offers more validation flexibility, but it’s not ideal for everyone. The following figure illustrates where responsibilities lie when using the customized approach.
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.
Therefore, an assessment using the customized approach will likely cost more than an assessment using the defined approach, but it may be a more cost effective method when all aspects are considered. Be sure to look fora QSA with the depth and years of experience necessary to validate custom controls and make appropriate testing procedures.
The Customized Approach method shouldn't be a way to disengage from your assessment. Rather, utilizing the Customized Approach should encourage working closely with your QSA.
PCI DSS version 4.0 may seem daunting but is actually an improved way to counteract the techniques used by threat actors. Preparing for compliance to version 4.0 is straightforward if you are already working towards or maintaining compliance to PCI DSS 3.2.1.
Since the beginning of the COVID-19 pandemic, many companies have shifted to allowing employees to work from home. It is important to remember that if cardholder data is processed, transmitted, or stored by employees working from home, their home environment will be part of the organization’s PCI scope.
When scoping a work-from-home implementation where employees will be collecting or processing cardholder data, begin by mapping out the flow of cardholder data.
Questions to answer:
Realize that any system involved in the storage, processing, or transmission of cardholder data is in-scope for your environment, as is any system that can affect the security of these devices.
Many organizations will already have an existing CDE with mature controls designed to protect customer data. When implementing a work-from-home scenario, attempt to leverage the tools and security controls that exist in the corporate environment.
Assume that the employee’s home network and computer are not a secure option for processing payments. You can maintain the security stance of your CDE by extending your CDE network via VPN connectivity and providing company-owned mobile devices that have been hardened and can be managed remotely. Also, keep in mind that split tunneling should be disabled in order to maintain proper network segmentation.
Most enterprise phone deployments have moved to Voice over IP (VoIP).VoIP offers great flexibility that can also be leveraged in a work-from-home scenario. If your CDE includes telephone-order options, send VoIP endpoints home with your employees that will extend your VoIP system over an encrypted connection (such as a VPN).
For more information on protecting voice communications, see the PCISSC’s guidance on Protecting Telephone-based Payment Card Data.
If you are unable to extend your CDE network to remote locations, implementing P2PE may be a good option to reduce both the cost of compliance and the risk to your customer’s payment data.
There are a variety of P2PE devices that can be used to input cardholder data. Some of these devices are standalone terminals, while others can be used as a USB connected keypad. Implementing a P2PE endpoint may allow you to keep the employees’ computer and network out of scope for your environment.
SecurityMetrics Payment Card Industry Forensic Investigators (PFIs)*thoroughly analyze the point-of-sale (POS) or e-commerce environments of organizations that suspect a payment card data compromise.
Through a forensic examination of the in-scope computer systems related to the processing of customer payment card information, data acquired from the breach site can reveal when and how the breach occurred, contributing vulnerabilities, and aspects of the IT environment out of compliance with thePCI DSS.
SecurityMetrics Forensic Investigators have witnessed the rise and fall ofpopular attack trends over 20 consecutive years.
Comparing 2021 forensic trends to previous years, SecurityMetrics’ ForensicInvestigators conducted more investigations of e-commerce environmentsthan of point-of-sale (POS) environments.
The following section will further discuss predicted trends for 2022.
*SecurityMetrics PFIs are Qualified Security Assessors, but do not perform a complete QSA audit of each PCI requirement during a PCI forensic investigation. PCI DSS requirement data is analyzed to the extent observed throughout the course of an investigation.
PREDICTION 1
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.
However, we predict that there will be more payment iFrame breaches with transparent payment completion (i.e., no suspicious pop up errors). These invisible heists will likely happen via zero-day browser exploits or other javascript based attacks.
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.
We’re going to see iFrames broken through this method, where they use the browser itself to capture credit card data. Javascript libraries such as node.js and angular.js are also under constant threat
PREDICTION 2
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.
PREDICTION 3
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.
PREDICTION 4
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.
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.
HARDWARE FIREWALLS
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
SOFTWARE FIREWALLS
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
Inexpensive
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
NETWORK SEGMENTATION
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.
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:
JEN STONE
SecurityMetrics Principal Security Analyst | CISSP | CISA | QSA | CCSFP |CHQP
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.
SYSTEM HARDENING
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:
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.
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:
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.
JEN STONE
SecurityMetrics Principal Security Analyst | CISSP | CISA | QSA | CCSFP |CHQP
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:
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:
Once you identify new processes, you can begin to determine how to either fix the process or add it into your normal environment flow.
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.
BEN CHRISTENSEN
SecurityMetrics Senior Security Analyst | CISSP | CISA | QSA
For requirement 4, you need to identify where you send cardholder data. The following are common places PAN are sent:
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:
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.”
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.
BEN CHRISTENSEN
SecurityMetrics Senior Security Analyst | CISSP | CISA | QSA
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.
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.
MICHAEL OHRAN
SecurityMetrics Security Analyst | CISSP | CISA | QSA | SSF | SSL
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-purpose network 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.
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.
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:
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.
-MICHAEL OHRAN
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.
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.
-MICHAEL OHRAN
QSA | CISSP
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.
ACCOUNT MANAGEMENT
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:
A few examples of effective multi-factor authentication for remote access could include:
Your authentication mechanisms should be out-of-band and independent of each other. There should be a physical separation between mechanisms so that access to one factor does not grant access to another, and if one factor is compromised, it does not affect the integrity and confidentiality of any other 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.
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.
MICHAEL MAUGHAN
SecurityMetrics Security Analyst | CISSP | CISA | QSA
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:
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:
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.
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.
MICHAEL MAUGHAN
SecurityMetrics Security Analyst | CISSP | CISA | QSA
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:
To take advantage of log management, look at your security strategy and make sure the following steps are taken care of:
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.
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.
-MICHAEL MAUGHAN
SecurityMetrics Security Analyst | CISSP | CISA | QSA
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:
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:
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:
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:
SEGMENTATION CHECK
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:
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.
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:
SOCIAL ENGINEERING
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:
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.
DAVID PAGE
SecurityMetrics Security Analyst | CISSP | CISA | QSA
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.
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.
DAVID PAGE
SecurityMetrics Security Analyst | CISSP | CISA | QSA
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:
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:
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:
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:
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.
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
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:
PUBLIC COMMUNICATIONS
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.
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:
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:
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.
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:
STEP 3: ESTABLISH PROCEDURESIf you don’t have established procedures, a panicked employee may make detrimental security errors that could damage your organization.
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:
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.
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).
DISCUSSION-BASED EXERCISE
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.
SIMULATION EXERCISE
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.
PARALLEL TESTING
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:
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:
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.
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:
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.
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.
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.
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.
JEN STONE
SecurityMetrics Senior Security Analyst | CCSFP | MCIS | CISSP | CISA | QSA
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:
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.
MATT HALBLEIB
GARY GLOVER
JEN STONE
MICHAEL SIMPSON
BENJAMIN CHRISTENSEN
MICHAEL MAUGHAN
DAVID PAGE
MICHAEL OHRAN
TREVOR HANSEN
MARK MINER
WINN OAKEY
BRAD CALDWELL
REBECCA CAMEAU
MARJ ELDARD
DAVID ELLIS
AARON WILLIS
BRADLEY SMITH
CHANDLER LOVELAND
JOSHUA BRANDEBERRY
JACOB THAYNE
WHITNEY TAYLOR
BRAD NELSON
JEFF MCKENNA
CHUCK BRAILSFORD
DON ROBERTSON
TYLER FARR
SIDNIE ANDERSON
RICH BUSHELL
JON CLARK
EMMA DUFF
HUNTER STEFFEN
SARAH KEMPLE
KATHERINE BULLOCK
EMORY FRENCH-FOLSOM
BEN CALDWELL
HIEDI BLACKWELDER
ERIC SMITH
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.
.svg)
