Top 10 Network Security Audit Fails
PCI DSS assessment issues haven’t changed in years.
|By: Gary Glover|
Obviously these concerns merit a discussion.
Let’s delve a little deeper into the top 10 network security audit fails (in no particular order) to help you understand what projects need your attention in your business data environment.
SEE ALSO: Top 5 Security Vulnerabilities Every Business Should Know
1. Poor or no card data environment (CDE) segmentation
In my experience with PCI DSS assessments, poor segmentation is often a security problem. Here are some of the poor segmentation practices:
Flat network architecture
Flat network architecture is a common problem where the network contains both card data systems and those that have nothing to do with card data (e.g., office systems, email servers). By isolating card data systems from others with network segmentation, you can more easily safeguard zones that need protection (i.e., ones that handle card data), minimize scope, minimize the attack surface, and not waste resources on areas that don’t require fortification.
Misconfigured or non-existent firewalls
A correctly configured firewall makes it harder for criminals to access your network/system and strengthens your segmentation. To reinforce a firewall, strengthen your inbound/outbound firewall rules, only allow secure protocols, and frequently check firewall rules against accepted standards. Watch for protocols you say are necessary between a less secure zone and a more secure zone—like windows file share or Active Directory traffic. These protocols compromise the security of the zone you’re trying to protect.
Unsecured wireless networks
Unsecured Wi-Fi was the attacker’s point of access in the well-known T.J. Maxx data breach back in 2007, and I expect similar wireless issues continue to assist multitudes of hackers today. Wireless network segments should be protected with WPA2 encryption using a strong wireless password. For additional security, don’t allow any wireless access into the card data environment, period.
SEE ALSO: Wireless Access Point Protection: Finding Rogue Wi-Fi Networks
2. Not understanding the flow of card data through the networkTo secure payment card data, you must be the expert on everything that happens with card data in your organization. It’s not good enough just to have an idea in your mind; you need to document the flow via a card data diagram or detailed description.
Learning about card data processes by interviewing employees isn’t enough. You must look in places you don’t expect. A data discovery tool like PANscan is the best way to find locations that contain hidden card data.
SEE ALSO: How Much Credit Card Data do You Store? (It's More Than You Think.)
Once you find caches of card data and understand the data process, you need to decide if the data in question was collected on accident or for a purpose, and if you can eliminate the need to keep that data around.
SEE ALSO: PCI DSS Requirement 3: What You Need to be Compliant
Being an expert on the flows of card data in your network is the only way you’ll be able to understand your PCI DSS requirements and successfully pass a PCI DSS assessment.
3. Insecure remote access into CDECybercriminals love when you use remote access. Why? It’s a method to access card data systems from outside your network perimeter that’s often poorly secured.
Ideas to protect remote access technologies range from log alerting implementation to default username alteration, but the secure solution is to implement two factor authentication.
Many remote access packages only require a user ID and password to gain access, and that’s not good enough. Multiple independent factors of authentication are needed to protect remote access. Instead of two knowledge-based identifiers, a second, different factor is needed like biometric fingerprint or physical token.
It’s important to note that many merchants have external contractors that help administrate their remote access systems. The merchant, not the third party, is responsible for making sure the remote access process and technology is secure.
4. Stored card dataAs per PCI DSS requirement 3, stored credit card data must be encrypted using industry-accepted algorithms (e.g., AES-256). No homegrown encryption methods allowed!
Not only must card data be encrypted, the utilized encryption keys must be protected as well. If you don’t protect the location of the encryption key using a solid PCI DSS encryption key management process, it’s like storing your house key pushed into your front door lock.
As mentioned before, an essential part of eliminating stored card data is through the use of a good card data discovery tool and methodology. Begin where you think the data would be, and then look where it shouldn’t be. Remember, payment card data can easily leak due to poor processes or misconfigured software.
To be effective, data discovery must be repeated frequently. I can’t tell you how many times I’ve examined a network after last year’s clean network security audit and found all kinds of data because of process and code changes.
SEE ALSO: How Much Credit Card Data do You Store? (It’s More Than You Think.)
5. Poor application security (web, payment apps, etc.)Just buying a PA-DSS validated payment application does not automatically make you compliant. You must install it correctly per the vendor’s directions. I often find customers who use a PA-DSS validated payment application but install it incorrectly, resulting in sensitive information storage in places like error logs.
If you develop payment applications in-house (e.g., ecommerce websites, POS applications) you must use very strict development processes and secure coding guidelines as outlined in the PCI DSS. Don’t forget to develop and test applications in accordance with industry accepted standards like OWASP.
If a web application is used to take payment data, a web application firewall should be installed in front of the application and kept well tuned. This helps avert common attacks like SQL injection.
6. Weak patch managementIt always surprises me that businesses don’t regularly install software updates. To maintain security and PCI DSS requirements, you must have a well-documented patch management process and follow it religiously.
Patch all critical components in the card flow pathway. This includes operating system and critical software applications like payment applications, databases, web servers, etc.
7. Access control issuesAccess control is required on all computer systems or network gear in the card data network. All systems in the CDE should have a login step that requires a personal user ID and unique password per user (no default usernames or passwords!). Many compromises are caused by something as simple as not changing default system passwords or software permissions (e.g., operating system, network gear, databases).
The best way to assign correct permissions to employees is through role-based access. Role-based access means users are only allowed the bare minimum access their job requires. Their access level doesn’t impede their job responsibilities, and one less person has access to CDE data.
8. Lack of vulnerability scanningAll external IPs (and domains) exposed from the CDE must be scanned by a PCI ASV (Approved Scanning Vendor) at least quarterly. All systems within the CDE must be scanned for vulnerabilities from an internal perspective as well to help prevent hackers moving from system to system exploiting common security holes.
Despite what many businesses believe, scanning is not enough. You can’t just scan and sit on the report. Act quickly on any vulnerabilities discovered to ensure security holes are plugged.
SEE ALSO: SecurityMetrics Scanning FAQ for Customers
9. No event log collection or monitoringLog monitoring systems oversee network activity, inspect system events, and store user actions. The problem is logging features may not be turned on by default on various types of systems within the CDE. Traceable logging must be enabled to ensure useable log data is available. Make sure all log sources are identified (e.g., web server logs, payment application logs, operating system access logs).
Collecting raw log data in a centralized monitoring location is only useful if an alerting notification system is in place. Often, automated filtering software is used to summarize and deliver warnings if patterns of attack are detected. These notifications should be monitored daily and acted upon if necessary.
10. Lack of security processes and policiesDocumentation and well-developed PCI security policy processes are often labeled "overkill," but I have personally seen that without set security procedures, companies fall right back into old habits of lax security.
SEE ALSO: 6 Ways to Make Data Security Consistent in Your Business
Here are some great process tips that secure businesses employ:
Get everyone involved
All parties involved in the security of card data (from cashiers to IT administrators) need to have clearly assigned responsibilities for continual protection of card data. If someone doesn’t know their security responsibilities or isn’t following them, they could be the chink in the armor that leads to the loss of card data.
Get management buy-in
Security never really works from the bottom up. It should be mandated and supported from the top down. I’ve been in many audit situations where the IT technical staff wanted a “failing” audit report so that management would have to notice the issue and get involved. Don’t be that company!
Employers hiring new employees with access to card data should have confidence in each employee’s ability to secure that card data. If your state law allows it, conduct background checks. For hired employees, don’t fall into the annual training trap. Train on security as often as possible, and employees will retain more.
Need help training employees? Check out our PCI Security Training.
Monitor third party PCI compliance
Many merchants rely on outsourcing for IT functions. If using outsourced third-party vendor services with access to your collected card data, you are responsible for making sure they agree to follow PCI DSS requirements. Don’t just take their word for it. Develop reasonable verification checks and only select vendors with your same dedication to security.
Assess risks and re-scope CDE frequently
Processes dealing with card data may change frequently due to the nature of a growing business. Define triggers that will result in a reassessment of any risks to card data (e.g., new software used, new data center location) as well as time-based triggers (e.g., annual assessment). This ensures new technology, processes, and vulnerabilities in the security posture don’t go undiscovered.
SEE ALSO: How to Make Your Auditors Happy and Pass Your Next PCI DSS Audit
How to break the fail-cycleAs a security professional I often feel like a broken record. I give the same advice to business after business, year after year. Change your passwords. Update your software. Follow your policies. People have trouble considering security a constant process.
Your compliance does not end with a checked checkbox.Any change, no matter how small, could inadvertently take you out of compliance and make you vulnerable to attack.
Security isn’t a one-time thing. Security is a business-as-usual practice.
Gary Glover (CISSP, CISA, QSA, PA-QSA) is Director of Security Assessment at SecurityMetrics with over 10 years of PCI audit experience and 25 years of Star Wars quoting skills. May the Force be with you as you visit his other blog posts.