Wi-Fi security is a big deal. The widespread adoption of Wi-Fi over the last decade combined with early security protocol design flaws, multiple high-profile security breaches, and the recent explosion of mobile commerce initiatives have placed Wi-Fi security at the forefront of industry regulations and corporate IT security budgets.
Early Adopters and Lessons Learned
High profile security breaches, notably affecting TJ Maxx and Heartland Payment Systems, have brought with them increased scrutiny around proper wireless network security implementation. Many organizations in the retail and banking industries were early adopters of corporate Wi-Fi networking, identifying opportunities for business process and workflow improvement driving operational efficiencies that could dramatically improve their finances and increase profitability.
However, the flip side of early adoption is that the adopters usually find that first or second generation technology is quickly outdated. The sunk cost in already deployed hardware or software usually makes spending additional funds for upgrades, or worst case forklift replacements, an unattractive proposition.
In the case of Wi-Fi networking, not only did early adopters in the retail and banking industries face quickly outdated technology, they faced serious security risks that were not apparent at the outset. The security flaws inherent in the Wired Equivalent Privacy (WEP) protocol used in first generation Wi-Fi products lead to serious risk of information disclosure and data leakage. In order to combat these risks, organizations that were early adopters of Wi-Fi systems are often forced to upgrade legacy hardware and systems, which means a potentially very large financial expense. For example, many retail organizations rely on mobile devices to provide barcode scanning and inventory management that run on hardware platforms with minimal processing and capacity capabilities. These platforms often only support WEP for basic security and require replacement in order to provide more robust security offered with WPA or WPA2.
The Cost of a Breach
Implementation of more robust wireless security practices has often taken a backseat to financial performance of the company. Spending additional money to enhance security when the currently deployed equipment and technology meet operational requirements can be a difficult effort. Crafting a proposal for Wi-Fi security upgrades requires sound business justification using either quantitative or qualitative risk analysis, or a combination of both methods. This may include a financial comparison between required security upgrades (the cost of compliance) versus the costs of non-compliance which includes estimated security breach costs, regulatory fines in the event of security breach, non-compliance fees from Acquiring Banks assessed on a regular basis (typically monthly), higher costs or potential loss of permission to process credit card transactions, stricter compliance requirements and higher remediation expense in the future, and damage to brand reputation. Those are some serious financial repercussions for not meeting PCI compliance requirements! With the average cost of a data breach in U.S. around $3.4 million, organizations are increasingly weighing the likelihood of a security incident and including budgetary funds for remediation efforts.
There are benefits for the merchant in the PCI DSS audit compliance process as well. Those may include an overall reduced risk of fraud, better understanding of their own environment, and “safe harbor” provisions in the event of a data breach if the merchant is PCI compliant.
Retailers Focus on PCI
The focus of most security remediation efforts in retail environments initially lands on meeting the Payment Card Industry Data Security Standard (PCI DSS). The PCI DSS standard is an industry regulation requiring organizations that handle cardholder data to meet a minimum set of security standards to minimize the risk of cardholder data theft or loss. Faced with stiff penalties and fines for not meeting PCI guidelines, retail organizations have focused initial remediation efforts on PCI audit compliance. Additional focus is placed PCI as first-step remediation effort since the PCI standard is very detailed and specific in nature, providing retailers with a very clear and understandable set of requirements which they must meet.
The good news is that retailers have begun making traction in wireless network security because of this industry mandate and the large-scale data breaches experienced by TJ Maxx and Heartland. The downside is that many smaller retailers often lack the technical expertise or resources required to implement wireless security.
The recent release of PCI DSS version 2.0 provides a good opportunity to review these “minimum” industry guidelines for wireless networks and provide advice for retail organizations to achieve a successful audit.
The Proper Approach to a PCI Audit
Knowing the proper approach to completing a PCI audit will go a long way to making the process as efficient as possible, eliminate redundant work, and minimize remediation efforts to manageable portions. Following these guidelines will make the process much simpler for your organization.
1. Limit Scope
The golden rule of PCI audit compliance is to limit the scope of the audit. PCI is focused on protecting cardholder data. Therefore, networks and devices that are appropriately segmented from the cardholder data environment (CDE) will not be in scope for the audit. By ensuring that any network or device that does not interact with cardholder data is firewalled from the systems that store, transmit, or process cardholder data will limit the effort required to demonstrate PCI compliance. It is not enough to firewall systems from cardholder data stores, they must also be firewalled from systems that also transmit or process that data.
However, limiting scope requires thoughtful network design and thorough documentation of cardholder data and application flows. This is not a trivial undertaking, but is the most efficient method to achieve PCI compliance in the long-run.
If the scope is not limited, every single network, client device, and application flow in your environment is subject to PCI audit and requirements. This can exponentially grow the resources required to document, assess, and remediate non-compliant systems in your environment.
The golden rule of PCI audit compliance is to limit the scope of the audit. PCI is focused on protecting cardholder data. Therefore, networks and devices that are appropriately segmented from the cardholder data environment (CDE) will not be in scope for the audit. By ensuring that any network or device that does not interact with cardholder data is firewalled from the systems that store, transmit, or process cardholder data will limit the effort required to demonstrate PCI compliance. It is not enough to firewall systems from cardholder data stores, they must also be firewalled from systems that also transmit or process that data.
However, limiting scope requires thoughtful network design and thorough documentation of cardholder data and application flows. This is not a trivial undertaking, but is the most efficient method to achieve PCI compliance in the long-run.
If the scope is not limited, every single network, client device, and application flow in your environment is subject to PCI audit and requirements. This can exponentially grow the resources required to document, assess, and remediate non-compliant systems in your environment.
2. Evidence Documentation
When preparing for a PCI audit, prepare evidence documentation for each applicable requirement section in advance using a standard format. Evidence gathered should include process and procedure documents, screenshots of applicable network device configuration (including timestamps), sample system alerts, and applicable pictures when describing physical components. Organize the documentation based on the PCI requirement sections to make finding and reviewing evidence as simple for the auditor as possible. Documentation for multiple requirements will likely overlap, in which case it may make sense to submit the same document(s) for several requirements. Create a list of the documents being submitted into evidence for each requirement or provide the auditor with some form of evidence matrix to ease the review process. All process documentation should be reviewed quarterly for accuracy, and include version control information within the document.
Ultimately, easing the job of the auditor through standard document formatting and clear labeling will reduce confusion and prevent duplication of evidence gathering and discussion.
When preparing for a PCI audit, prepare evidence documentation for each applicable requirement section in advance using a standard format. Evidence gathered should include process and procedure documents, screenshots of applicable network device configuration (including timestamps), sample system alerts, and applicable pictures when describing physical components. Organize the documentation based on the PCI requirement sections to make finding and reviewing evidence as simple for the auditor as possible. Documentation for multiple requirements will likely overlap, in which case it may make sense to submit the same document(s) for several requirements. Create a list of the documents being submitted into evidence for each requirement or provide the auditor with some form of evidence matrix to ease the review process. All process documentation should be reviewed quarterly for accuracy, and include version control information within the document.
Ultimately, easing the job of the auditor through standard document formatting and clear labeling will reduce confusion and prevent duplication of evidence gathering and discussion.
3. Security as a Continual Process
As prescriptive as the PCI DSS standard is in detailing specific requirements, auditors often focus on an organization’s ability to integrate sound security practice into daily operations. The PCI audit is only a snapshot in time of an organization’s compliance, and alone it does guarantee the security of sensitive data. A short-term focus on achieving PCI compliance for the current audit will lead to manual evidence collection, process documentation, and narrowly focused remediation efforts. Instead, focus on secure system design, process establishment and improvement, and integration of remediation efforts into larger systems architecture planning. This will incorporate security practices into ongoing operational activities of the organization, reduce manual effort required to compile and maintain evidence, and put the organization in a better stance to proactively identify and remediate security risks on a continual basis.
As prescriptive as the PCI DSS standard is in detailing specific requirements, auditors often focus on an organization’s ability to integrate sound security practice into daily operations. The PCI audit is only a snapshot in time of an organization’s compliance, and alone it does guarantee the security of sensitive data. A short-term focus on achieving PCI compliance for the current audit will lead to manual evidence collection, process documentation, and narrowly focused remediation efforts. Instead, focus on secure system design, process establishment and improvement, and integration of remediation efforts into larger systems architecture planning. This will incorporate security practices into ongoing operational activities of the organization, reduce manual effort required to compile and maintain evidence, and put the organization in a better stance to proactively identify and remediate security risks on a continual basis.
4. Present Evidence, Don’t Ask for Guidance
Once the time comes for the actual audit, proper communication of the evidence can reduce uncertainty regarding the effectiveness of current systems to secure cardholder data. Organizations should interpret PCI requirements and define how to approach and implement solutions to meet each requirement prior to the audit. The organization is in the best position to understand current systems architecture, analyze security risks, and remediate gaps. Have a well-defined approach that is documented and practiced within the organization.
When presenting evidence, detail the solutions in place and be well versed in how they demonstrate compliance. Be confident in your solutions, and let the auditor identify opportunities for improvement. Don’t ask for guidance; it is not the auditor’s job to architect solutions for your organization, and without communicating a solid internal approach it will be clear to the auditor that significant gaps and vulnerabilities likely exist.
Once the time comes for the actual audit, proper communication of the evidence can reduce uncertainty regarding the effectiveness of current systems to secure cardholder data. Organizations should interpret PCI requirements and define how to approach and implement solutions to meet each requirement prior to the audit. The organization is in the best position to understand current systems architecture, analyze security risks, and remediate gaps. Have a well-defined approach that is documented and practiced within the organization.
When presenting evidence, detail the solutions in place and be well versed in how they demonstrate compliance. Be confident in your solutions, and let the auditor identify opportunities for improvement. Don’t ask for guidance; it is not the auditor’s job to architect solutions for your organization, and without communicating a solid internal approach it will be clear to the auditor that significant gaps and vulnerabilities likely exist.
5. Establish a Consistent Relationship with the Auditor
Maintain the same audit company, and audit individual(s) or teams year over year. This will reduce time and effort to familiarize the auditor with your environment. Ultimately this will reduce audit expense and ease the process so that your organization can focus on remediating gaps and assessing new systems and environments that change from year to year.
Maintain the same audit company, and audit individual(s) or teams year over year. This will reduce time and effort to familiarize the auditor with your environment. Ultimately this will reduce audit expense and ease the process so that your organization can focus on remediating gaps and assessing new systems and environments that change from year to year.
PCI Requirements for Wireless Networks
Wireless network administrators should initially focus their efforts on the following core requirements that are likely to require evidence for in-scope wireless segments by most auditors. The following list of requirements focus on Wi-Fi infrastructure compliance, and do not cover other related systems, such as servers, user database and directory policies, firewall policies, client device hardening, etc., that may or may not be covered by the same engineering group in your organization but wireless networks rely upon.
Only a few changes were made between versions 1.2.1 and 2.0 that affect wireless networks. These tips are only guidelines to get your organization started in the right direction. Individual organizations and auditors may require more or less evidence to achieve compliance.
1.1.2 Current Network Diagrams
Tip: Maintain high-level wireless network diagrams for each environment you support, depicting logical segmentation of wireless networks from the larger environment.
Tip: Maintain high-level wireless network diagrams for each environment you support, depicting logical segmentation of wireless networks from the larger environment.
1.2.3 Firewall between Wireless Networks and the CDE
Tip: This is a big focus point for PCI auditors, especially when assessing wireless networks, because proper firewall rules are a key component to preventing data breaches.
Tip: This is a big focus point for PCI auditors, especially when assessing wireless networks, because proper firewall rules are a key component to preventing data breaches.
2.1 Change Vendor-Supplied Defaults
Tip: Ensure all local admin, SNMP, console, and WLAN settings are changed from defaults in the approved internal configuration standards.
Tip: Ensure all local admin, SNMP, console, and WLAN settings are changed from defaults in the approved internal configuration standards.
2.2 Configuration Standards
Tip: Document approved internal wireless equipment configuration settings and establish processes for equipment staging, configuration audit, and remediation on a continual basis. Reference well-known secure configuration guides published by CIS, NIST, ISO, SANS, etc.
Tip: Document approved internal wireless equipment configuration settings and establish processes for equipment staging, configuration audit, and remediation on a continual basis. Reference well-known secure configuration guides published by CIS, NIST, ISO, SANS, etc.
2.3 Encrypt all Non-console Administrative Access
Tip: Ensure only secure protocols are used for administrative access, including SSHv2, HTTPS, and SNMP version 3. Do not use telnet for system administration.
Tip: Ensure only secure protocols are used for administrative access, including SSHv2, HTTPS, and SNMP version 3. Do not use telnet for system administration.
4.1.1 Wireless Encryption and Authentication
Tip: Wi-Fi networks are considered a public / open network by the PCI Council. Therefore, ensure all wireless networks use 802.11i equivalent authentication and encryption. This includes both WPA and WPA2. High preference for 802.1x based authentication. Pre-Shared Keys (PSK) may require demonstration of secure handling and rotation. WEP is no longer allowed, even for legacy installations.
Tip: Wi-Fi networks are considered a public / open network by the PCI Council. Therefore, ensure all wireless networks use 802.11i equivalent authentication and encryption. This includes both WPA and WPA2. High preference for 802.1x based authentication. Pre-Shared Keys (PSK) may require demonstration of secure handling and rotation. WEP is no longer allowed, even for legacy installations.
6.1 Install Security Patches
Tip: Install critical security patches within one month of announcement. This may require up-to-date maintenance and support contracts with vendors.
Tip: Install critical security patches within one month of announcement. This may require up-to-date maintenance and support contracts with vendors.
6.2 Identify New Security Vulnerabilities
Tip: Document the methods through which your organization monitors security advisories, including RSS feeds, vendor support processes, mailing lists, etc. Internal process should include ranking of vulnerabilities based on risk using well-known methods including CVSS, etc. This will be a requirement rather than a recommendation beginning in 2012.
Tip: Document the methods through which your organization monitors security advisories, including RSS feeds, vendor support processes, mailing lists, etc. Internal process should include ranking of vulnerabilities based on risk using well-known methods including CVSS, etc. This will be a requirement rather than a recommendation beginning in 2012.
6.4 Establish and Follow Change Control Procedures
Tip: Establish corporate processes to formally evaluate, test, approve, implement, and back-out changes to production environments. This ensures consistency of network configuration and formal approval by authorized parties for all system changes.
Tip: Establish corporate processes to formally evaluate, test, approve, implement, and back-out changes to production environments. This ensures consistency of network configuration and formal approval by authorized parties for all system changes.
9.1.3 Restrict Physical Access to Wireless Access Points
Tip: Document physical access point installation and security from tampering and theft. Deterrents such as ceiling height and monitoring can also be included to fulfill physical security requirements.
Tip: Document physical access point installation and security from tampering and theft. Deterrents such as ceiling height and monitoring can also be included to fulfill physical security requirements.
10.1 Establish a Process for Access Logging and Accountability
10.2 Implement Automated Audit Trails
10.3 Audit Trail Information Detail
10.4 Synchronize all Critical System Clocks
10.5 Secure Audit Trails
10.6 Review Logs at least Daily
10.7 Retain Audit Trail History for at least 1 Year
Tip: For requirements 10.1 through 10.7, ensure wireless network equipment logs all management access, commands, and security alerts (typically through TACACS+ or RADIUS), logs are reviewed daily by a security team, logs cannot be tampered by implementing file integrity monitoring on log servers, processes are implemented to retain logs for over 1 year, and that network equipment uses automated time synchronization (such as NTP).
Tip: For requirements 10.1 through 10.7, ensure wireless network equipment logs all management access, commands, and security alerts (typically through TACACS+ or RADIUS), logs are reviewed daily by a security team, logs cannot be tampered by implementing file integrity monitoring on log servers, processes are implemented to retain logs for over 1 year, and that network equipment uses automated time synchronization (such as NTP).
11.1 Perform a Wireless Analyzer Scan at least Quarterly
Tip: Establish a process for wireless scanning in either an automated or manual fashion. The method used must be “adequate” to detect and identify un-authorized wireless access points (rogues). This requirement is open to broad interpretation, but to minimize recurring expense of manual scans, implement automated scanning typically found in most enterprise-grade wireless equipment.
Tip: Establish a process for wireless scanning in either an automated or manual fashion. The method used must be “adequate” to detect and identify un-authorized wireless access points (rogues). This requirement is open to broad interpretation, but to minimize recurring expense of manual scans, implement automated scanning typically found in most enterprise-grade wireless equipment.
11.2 Perform Internal and External Vulnerability Scans at least Quarterly
Tip: Internal vulnerability scans should be performed and issues remediated immediately. Scans should be re-run until passing results are obtained with all “High” vulnerabilities resolved.
Tip: Internal vulnerability scans should be performed and issues remediated immediately. Scans should be re-run until passing results are obtained with all “High” vulnerabilities resolved.
11.3 Perform Internal and External Penetration Testing at least Annually
Tip: Exploitable vulnerabilities found must be remediated immediately.
Tip: Exploitable vulnerabilities found must be remediated immediately.
11.4 Use IDS/IPS to Monitor Traffic in the CDE
Tip: Implement IDS/IPS systems at the perimeter and at key points within the CDE to limit required traffic to be monitored and analyzed to a manageable quantity. If wireless networks transmit cardholder data directly (such as mobile point of sale systems), a wireless IDS/IPS solution is required.
Tip: Implement IDS/IPS systems at the perimeter and at key points within the CDE to limit required traffic to be monitored and analyzed to a manageable quantity. If wireless networks transmit cardholder data directly (such as mobile point of sale systems), a wireless IDS/IPS solution is required.
12.1 Establish, Publish, Maintain and Disseminate a Security Policy
12.3 Develop Acceptable Use Policies
12.9 Implement an Incident Response Plan
Tip: Although 12.1, 12.3, and 12.9 are not direct requirements for wireless networks, ensure your organization has established policies that guide the security practices and govern the use of technology within your organization. These policies are the fundamental cornerstone of that serve as a reference map for engineers to guide system architecture decisions within your organization. An incident response plan should be documented for handling all security alerts identified for use within the organization and generated by the monitoring systems.
Tip: Although 12.1, 12.3, and 12.9 are not direct requirements for wireless networks, ensure your organization has established policies that guide the security practices and govern the use of technology within your organization. These policies are the fundamental cornerstone of that serve as a reference map for engineers to guide system architecture decisions within your organization. An incident response plan should be documented for handling all security alerts identified for use within the organization and generated by the monitoring systems.
Conclusion
Remember, achieving PCI compliance does not mean your network is secure, but that it meets minimum industry regulation. Take a proactive approach to integrate security into all aspects of network, system, and application design. Make it a habit and integrate it into your organizational practices.
Maintaining a “secure” network is not a one-and-done activity, it is a habitual practice that is continuously refined.
Cheers,
Andrew vonNagy
This article originally appeared on CWNP.com. Thank you to Marcus, Kevin, and the team over at CWNP!
"For requirements 10.1 through 10.7, ensure wireless network equipment logs all management access, commands, and security alerts (typically through TACACS+ or RADIUS), logs are reviewed daily by a security team,"
ReplyDeleteugh. things like this probably make it hard for smaller retailers to impliment a pcidss compliant wifi network. i know i don't have time to review security logs daily.
Hi Brian,
ReplyDeleteFor smaller retailers, focus on identifying the critical log entries that are generated by the Wi-Fi network, forwarding logs to a central collection point (syslog server such as Kiwi or Splunk for example), and setup automated alerts when the critical events occur (via email, SMS, pager, etc.).
This can eliminate a large portion of manual work required, especially for small businesses. The devil is always in the details though, so try to be thorough in identifying and documenting what log entries are deemed "critical" and which ones are not, as the auditor will likely review that list in-depth.
Andrew
yeah i think that really is key. i do log everything centrally on a plain syslog server, but am drowning in logs from all the devices & servers. i've only traditionally kind of kept logs for when something bad does happen, instead of trying to leverage them to keep something bad from happening. might have to look at something like splunk. thanks!
ReplyDelete