SMB Guide To Credit Card Regulations, Part 2: The Low-Hanging Fruit

The PCI Security Standards Council has created a document outlining a prioritized approach to help businesses comply with PCI DSS. It's a way to grab the low-hanging fruit, helping businesses tackle some of the more simple tasks that can provide a greater security ROI. I've boiled it down here to help small to midsize businesses (SMBs) get started.The official document is about 15 pages of an organized chart, outlining tasks and subtasks as they relate to the PCI DSS requirements and the six primary milestones of the Prioritized Approach document. Those six milestones and goals are:

1: Remove sensitive data and limit data retention.

2: Protect the networks.

3: Secure payment card software applications.

4: Monitor and control access to your systems.

5: Protect stored cardholder data.

6: Finalize remaining compliance efforts, and ensure controls are in place to meet the rest of the PCI DSS requirements.

Instead of regurgitating the dozen or so pages of itemized tasks, I thought it would be more useful to identify a set of specific tasks for small businesses to address, by category. Each task relates to one or more milestones in the Prioritized Approach and helps achieve one or more of the PCI DSS requirements.

Network and Device Low-Hanging Fruit 1. Create a network drawing. It doesn't have to be pretty, but you NEED to have one. While Visio is the preferred tool, even a hand sketch or Microsoft PowerPoint or Publisher graphic would do the trick. If you're not sure where to start, then draw a rectangle, label it and start following the cords. Use that in combination with your network mapper of choice, but don't just use a mapper. Specifically, label all external connections, identifying the ports and where they go.

2. Use firewalls. In a nutshell, use 'em. At a minimum, PCI DSS wants you to have a firewall between your internal network and the external, between cardholder data and any wireless, and between cardholder data and a DMZ. Your firewall of choice could be logically or physically segmented and should include stateful inspection technology and perform NAT between the inside and anything public or external.

3. Document rules. Create some basic documentation of security technologies used in your environment. Most specifically, review and document firewall and router ACL rules, briefly noting what each component of the rule is (source/destination) and why that traffic is allowed or blocked. PCI DSS recommends you review the rule set every six months. While I doubt that's an immediately attainable goal, SMBs could start with an initial review and start scheduling annual reviews to note changes.

4. Segment wireless. There are a variety of PCI DSS requirements that cover wireless networking and those rules apply whether or not you have wireless. That's a different conversation. For now, know that any wireless needs to be segmented, by firewall, from the network with your cardholder data. You can segment physically, using two different ports on a firewall, or logically, using VLANs that terminate at the firewall.

5. Secure management traffic. It's often overlooked but easy to fix. At a minimum, configure key network and security devices to use SSH instead of telnet and https instead of http. SNMP v2, although not encrypted, is still an accepted level of security in most environments, but you might also want to consider moving to SNMP v3 for added security and encryption. SNMP can be used to monitor and manage (change configurations) switches, routers, firewalls and wireless devices and can be just as important as locking down CLI and GUI access. Changing to secure management takes just a few clicks or a couple lines of command.

6. Synchronize watches! Use a timeserver on the network so times match and event data can be correlated in the event of an attack. Almost any basic server hanging around can pull double-duty as a time server.

7. Review security logs. PCI DSS would like to see you review logs daily. Most SMBs don't have the resources dedicated to that, so I'd recommend you start with a monthly or quarterly review. You might want to bite a day off at a time while you're getting used to sifting through the logs. In this case, a SIEM tool would be a great help. Specifically, they want you to look at logs on IDS/IPS devices, authentication servers. You're looking for suspicious entries, which is really nebulous and changes for every network. Start with firewall/IDS/IPS logs that document blocked traffic, signature matches and high priority events, then be on the lookout for things like failed login attempts on authentication servers.

8. Use IDS/IPS to monitor systems with cardholder data. Whether your cardholder data is accessible internally or externally, PCI DSS would like to see it monitored by an IDS or IPS system. For SMBs, this could mean different things. Very small businesses could choose to layer IDS/IPS on a firewall or UTM device already in place, while midsize to larger SMBs could have the resources to invest in a stand-alone system that could sit directly in front of the cardholder data. Either way, some IDS/IPS is better than none and even an integrated IDS/IPS adds the benefit of some basic protection from known signatures.

Users, Passwords and Authentication Low-Hanging Fruit 1. Provision unique user accounts. Create unique accounts for everyone -- even part-time and contract employees -- and do not allow the use of shared or group accounts and passwords, specifically for systems holding cardholder data as well as any system or device that can gain access to another system with cardholder data. Ideally, you'd have the majority of your authentication tied to directory services (such as Active Directory) and provision role-based access per user. This goes for any accounts for Web-based applications as well. If something happens to your data, you need to know WHO did it.

2. Use network device change management. Use those unique user accounts for authentication when making changes to networking devices. Instead of using shared admin accounts and passwords, use remote authentication by way of RADIUS or TACACS. It sounds complicated, but it's not. You just tell your switch or firewall to point to your domain directory to authenticate and then specify which group has access to manage that device. You can (and should) keep a master admin or root account for each device, but that should be a closely guarded secret and not used by staff to maintain the devices. Yet again, if something happens or changes, you need to know WHO did it.

3. Change default passwords. Everyone has that heat-of-the-moment frenzy when moving and changing devices in the network. Often it leads to devices being left partially configured and secured. This is some of the lowest-hanging fruit! Too many businesses leave default management passwords on devices. It's such an easy thing to fix. Log in, use the GUI or your management software and change the default passwords, remove the built-in accounts and change the default SNMP community strings. In wireless environments, be sure no generic or default preshared keys are in use.

4. Incorporate two-factor authentication for remote users. If you let employees (or anyone) connect to your network remotely, then use at least two factors of authentication. A domain credential can be one. Something as simple as a certificate on the computer can be the second. Your remote access solution may have a variety of other options as well; most offer token-based authentication, one-time passwords, and email or text credentials as the second factor. Certificates are free or inexpensive, depending on whether you have a certificate server in your network whereas physical tokens can be costly for some SMBs. The other options are usually integrated directly in the remote access solution.

5. Set strict user account policies. This is another no-brainer that takes almost no time and zero money. You can start with policies and processes to quickly deprovision or revoke accounts immediately when an employee leaves. Set password strength requirements on your domain servers and force password changes. PCI DSS recommends password changes every 90 days. I personally disagree with that number; I think it's too short. People forget passwords that change frequently and end up writing them down or caching them. For an SMB, I recommend starting gradually to change and enforce password policies every six months and work from there.

That wraps up our recommendations for grabbing the low-hanging fruit in the areas of network and user management. Keep your eye out for the following portions of the low-hanging fruit tasks.

Jennifer Jabbusch is a CISO and infrastructure security specialist at Carolina Advanced Digital. By day she architects enterprise security solutions and by night, well, she does the same thing. For Dark Reading, she melds her enterprise experience and intimate knowledge of small business operations to deliver relevant security guidance for SMBs everywhere.

? Permalink

More Insights

White Papers

• RHEV for Servers: Competitive Pricing whitepaper
• IDC Whitepaper: Red Hat Enterprise Virtualization

More >>

Reports

• Strategy: LTE: Huge Technology, Huge Challenges
• Strategy: What's Next for Certificate Technology

More >>

Webcasts

• Creating an Agile, Flexible Cloud Computing Model
• How to Build a Next-Generation Big Data Architecture

More >>

---