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.

This is a little old, but I just came across a reference to it on the Security Metrics mailing list. Robert X. Cringely writes about a metric to predict emerging global leaders in technology (and presumably economic development and power) that is based on the number of Cisco Certified Internetwork Experts (CCIEs), broken down by country. Cringely writes:

Where I took a step further was to divide the number of CCIEs into each country’s population, then do the same for each country’s Gross Domestic Product and correct for widely varying populations and states of economic development. For a baseline, then, the U.S. has at present 5,863 CCIEs, which is 1.947 CCIEs per 100,000 population and $2.2 billion of GDP per CCIE.

The results for Europe and North America are not surprising, with Canada, the UK, and Ireland being relatively close to the US. What is more interesting are the numbers for Asia.

India has 0.036 CCIEs per 100K to China’s 0.22 per 100K — a 7X differential — while India has $10 billion in GDP per CCIE to China’s $3.3 billion. There is no doubt that there is plenty of network expertise in India, but these numbers show that expertise isn’t making it out of the technology centers to the rest of the country. China, on the other hand, is developing its IT infrastructure much more broadly. This also doesn’t take into account the simply huge numbers coming out of Hong Kong, where there are 3.3 CCIEs per 100K and $1.13 billion in GDP per CCIE — numbers that might properly be added to the rest of China in some accounts.

Japan has 1.23 CCIEs per 100K to South Korea’s 1.9, but the significant difference between these two countries is the $4 billion per CCIE in GDP for Japan compared to $1.28 billion in South Korea, which is clearly investing massively in network infrastructure.

Looking 30 years into the future I think it is clear that the regional leaders will be China and Korea, NOT India and Japan.

Thanks to Josh Stephens, Head Geek at SolarWinds, for mentioning Athena FirePAC on his blog.

“FirePAC is cool because it evaluates the ACLs on your Cisco PIX and ASA, Juniper NetScreen, and Checkpoint firewalls and tells you where you’ve left holes or where you’ve duplicated functionality…. Definitely something you should check out.”

SolarWinds offers highly affordable network management products that can be downloaded over the web and installed and running in minutes. Their Orion NCM tool is a great complement to Athena FirePAC, simplifying the process of acquiring firewall configurations for analysis.

I found it interesting that after building software to break CAPTCHAs, the software found application in scanning books. It’s obvious in hindsight (just like many other applications such as gramaphone for music) but nevertheless interesting. Read more here.

One would have thought that when installing a VoIP device in an organization which works with sensitive data, the primary concern would be security.  Not always. This blog explains how simple things such as keeping voice and data networks separate can do a lot of good. The blog also has a reference to another article on VLANs and Multiple Device Authentication which suggests simple guidelines for port security.

One of the reasons why security is overlooked in this case could be that the people selling VoIP devices hardly highlight security issues and only focus on the cost saving factors. Beware!

Here is an interesting  article on one possible way in which companies can be PCI compliant; just don’t ever store, process, or transmit cardholder data - let someone else do it for you. This is because PCI only applies to you if you store, process, or transmit cardholder data.

Here is a report on how FireEye is fighting the Srizbi Botnet, which as of 13 July 2008, was believed to be responsible for roughly 40% of all the spam on the net.

The way Srizbi works: a client side Trojan gets instructions from a control server to send spam. If the control server goes down (it’s a spam server and hence someone will bring it down sooner or later), the Botnet resurrects itself by computing the address of new domains. Folks who maintain Srizbi would ensure that the new domains are quickly registered, which would take over as controllers.

Srizbi was recently fought by

1. pulling down existing domains that work as controllers
2. buying new domains that the Trojans would seek

This approach isn’t feasible as there is a cost involved in buying domains. What would be a better approach? Since in this case, FireEye has significant information about clients infected with Srizbi, I was wondering if making such information public would be useful. Of course this might make these machines more vulnerable once such information is out. Hence, would it make sense to share this information only to organizations that are in the business of anti-virus, malware detection, etc, so that they could do a much better job? For e.g., there doesn’t seem to exist, a central repository for information such as virus dictionaries, etc. Of course it might be against the business model of the organizations, but I really can imagine a lot of obvious ways by which this approach could be very rewarding.

Here is  quite a practical and straight-forward FAQ to PCI compliance.  A couple of interesting items from the FAQ -

• Cost of compliance:  for smaller companies it is about $10,000 to $25,000 and for larger companies it is about $3 million to $5 million.
• Frequent compliance related problems: inadequate policies and improper network segmentation.

Considering the capability of Athena FirePAC, it should help in bringing down this cost and effort quite significantly  (especially since policy analysis and comparison is such a core feature of FirePAC).