We recently received the following question from a customer about the security checks included in the PCI compliance analysis performed by Athena FirePAC:

I just ran Athena FirePAC on an ASA firewall that is failing PCI requirement 1.3.6 due to SYN flood protection not enabled. I understand what SYN flood protection does, but I believe ASA firewalls still processes in a stateful manner, even without SYN flood protection turned on. This failure would indicate that the firewall will process a non stateful packet, and I don’t believe that’s the case. Can someone advise on why FirePAC failed us on this requirement?

The PCI DSS control item 1.3.6 says, “Implement stateful inspection, also known as dynamic packet filtering. (That is, only ‘established’ connections are allowed into the network.)” It is true that Cisco ASA firewalls implement stateful inspection, as do most modern firewalls including Check Point, and Juniper Netscreen. So checking for it is a moot point.

Rather than simply making this a “checkbox” item in the PCI DSS compliance analysis provided by Athena FirePAC, we decided to take this as an opportunity to check for additional protection against some common attacks that exploit the stateful nature of TCP connections. The SYN flood attack is one example.

In Cisco ASA firewalls, the NAT and Static commands have a parameter that specifies the maximum number of embryonic connections allowed per host. An embryonic connection is a connection request that has not finished the three-way handshake between source and destination. The default is 0, which means unlimited embryonic connections are allowed. Setting the embryonic connection limit to a non-zero value lets you prevent SYN flood attacks by dropping connections after the limit is reached. FirePAC checks if this limit is not set, i.e. 0, which means unlimited embyronic connections are allowed. If it is 0, the host is susceptible to the SYN flood attack and the security check is flagged. FirePAC performs similar checks for Juniper Netscreen and Check Point firewalls as well.

As I’ve noted elsewhere, simply passing a PCI compliance audit is not a substitute for security. You really have to know what’s going on in your firewall to ensure that it’s configured securely. Given some of the changes announced earlier this year by the PCI council, these kinds of robust and detailed analyses will be required to show that that the PCI in-scope network is truly secure and controlled. FirePAC includes these kinds of additional checks to help you get it right.

News of the massive data breach at Heartland Payment Systems that may have compromised tens of millions of credit and debit transactions was all over the Internets today. It appears to have been a targeted attack involving malicious software installed on the company’s payment processing network that was designed to track and report the magnetic information stored on the back of a credit card as it was being sent for processing to Heartland by thousands of the company’s retail clients. Rich Mogul over at securosis observes that, “the biggest breaches now involve attacks installing malicious software to sniff data — including TJX, Hannaford, Cardsystems, and now Heartland Payment Systems.”

It’s worth noting that as a level 1 payment processor, Heartland is required to be PCI compliant. PCI requires that you segment your transaction data from other networks, that you have a firewall that restricts connections between public servers and cardholder data, and that you document and justify the services and ports necessary for business. The new PCI DSS Compliance report available in the recent release of Athena FirePAC automates the process of assessing firewalls for compliance.

All of which is well and good and will certainly provide reasonable protection from random hacking attempts. The trouble is that even though PCI is among the most advanced security compliance standards out there, passing a compliance audit won’t really protect you from targeted attacks such as this. You have to know what’s going on in your network and how your defenses really behave. A simple inspection of your firewall rules won’t identify the true exposures in your network or identify the data assets at risk. You need to know exactly which services and ports are allowed to connect to all of your IT and network assets. This comes from understanding how the ACLs, address translations, and the routing table all work together to control the traffic flowing through your firewall. Although difficult to get right, Athena FirePAC excels at this kind of policy analysis. It can identify exactly which assets are exposed to risky services and which rules cause the most problems. It can tell you what the impact of changes to the firewall configuration will be before deploying them to the device. This kind of information is invaluable when trying to track down and repair exposures in your network before the data thieves find their way in.

The new version of Athena FirePAC is now available for download. Try it out free for 30 days. We’ve added a bunch of cool new features in this release. The new user interface shows you a list of all your licensed firewalls and is a breeze to work with. FirePAC now provides a compliance assessment report for the PCI Data Security Standard v1.2. The PCI assessment correlates the policy analysis performed by FirePAC with the PCI requirements for firewalls and presents the results in a single convenient report. We’ve also added a new report that identifies the top offending rules that are responsible for the most security exposures in the firewall configuration.

And lots more too. Check it out!