For organizations that process, store or transmits credit card data, achieving PCI compliance is causing them to evolve from using a periodic security checklist to employing a continuous process to achieve and maintain a state of security and compliance.  For the security practitioners, this has certainly been a great way to connect with the rest of their organization and explain the risks related to data compromise.  However, now we have the challenge of determining what steps we need to take to meet the compliance requirement while making our networks and systems secure as required.

The PCI Security Standards Council recently released the Prioritized Approach to pursue PCI DSS 1.2 compliance with its six milestones.  Any vendor who provides some sort of PCI compliance-related solution will no doubt be working to implement this approach into their solution in the near future, if they have not done so already. The prioritized approach is a roadmap to meet PCI compliance, but all requirements must still be met.

Although many examples can be drawn upon in the 12-requirement structure, let’s examine Requirement 6 — Develop and maintain secure systems and applications.  And more specifically, let’s look at PCI DSS Requirement 6.6.

For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes
• Installing a web-application firewall in front of public-facing web applications

Prior to the release of the final DSS, this was probably one of the most discussed new requirements that merchants and service providers would need to comply with.  Initially, it was thought that the requirement would include all three — manual application assessment, regular use of automated assessment tools and installation of a web application firewall.  This is in addition to the requirement for a code review before a custom application goes into production and whenever any changes are made.

In a perfect world where resources are truly limitless, an organization would do all three and would always implement a layered or defense-in-depth approach.  However, “all of the above” is typically not a practical option for most organizations because trying to implement all three elements often brings other complexities, not to mention an increase in cost and resource requirements.

So let’s take a quick look at the type of analysis typically done when we are forced to choose one method over another.  The first option is a manual web application review and assessment. Assuming you select a reputable professional services organization, this is a good option since it is likely to proactively catch the flaws in an application before cardholder data is compromised. This is especially true if the flaws are complex, requiring a sort of connect-the-dots approach, and should be performed just prior to the application being put into production and made publicly available.  For this and other reasons, a competent human can often find flaws that an automated solution cannot.  However, this option is more costly, especially when an application frequently changes.  The testing procedure does allow for this assessment to be performed by a qualified employee of the company who is independent of the web development team.  Certainly, this makes cost much less of an issue, but typically such resources are scarce within organizations.

An alternative to the manual web application assessment is to use an automated tool or service. Only recently has this become a more viable option, as web application assessment tools have largely required a human with advanced knowledge of web application security to tune them during the assessment of optimal results.   A few service-based or cloud-computing options have emerged recently for automated web application assessment.  For an organization that does not have the in-house expertise and needs to perform these web application security assessments on a regular basis, these services are a good option and more cost-effective as compared to the manual approaches discussed earlier.

The service-based approach allows for the automation of repeatable techniques used to identify the most prevalent vulnerabilities, identifies vulnerabilities of syntax and semantics in custom web applications, performs authenticated crawling, profiles the target application, and ensures accuracy by reducing false positives and false negatives through automated testing.  Nonetheless, there is no “silver bullet” to detecting web application vulnerabilities.  Even when using an automated solution, there is still a need at times to perform source code analysis, manual assessment or on-site penetration testing.

The third option is to deploy a web-application firewall (WAF) in front of all publicly facing web servers.  This is also a fairly new technology, and it can be a good, cost-effective option for an organization with a small number of web applications that are not overly complex and dynamic or don’t process a high volume of transactions.  However, the technology and the hardware it runs on are relatively expensive and as best practice, it is not recommended to deploy a large number of web applications behind a single WAF.  In addition, it can be quite challenging to properly configure a WAF to detect and block all malicious traffic that the PCI requirement mandates without breaking some critical functionality along the way.  And with the current move towards cloud computing for all types of applications, the downsides to deploying a WAF are further amplified.  A new option is to combine the benefits of web application scanning to dynamically update and configure the WAF to block for new threats as the application changes. 

Finally, with all these tough choices on the road to PCI compliance, organizations of all sizes really need to look at compliance holistically rather than trying to solve each requirement independently with decisions based solely on which option is least costly.  Organizations need to understand which solutions will meet their needs and partner with providers who can help them meet the PCI DSS requirements effectively.

We are currently in the middle of the largest worm outbreak in history. Estimates for the number of PC’s infected by this polymorphic worm, known as Conficker or Downandup, ranges from 9 million to 15 million PC’s. Even at 9 million, that is still almost a full order of magnitude larger than the Storm worm which peaked with a 1 million zombie army in September 2007.

To understand how staggering the infection numbers are for Conficker, consider that at its peak Conficker was growing at a rate of over 1 million new infections per day compared to the Storm Worm’s peak of 1 million total infections.

What Can We Learn from Conficker?

While it is likely that this saga is only in its beginning stages, since security experts are still waiting to see what this massive worm will do once it is given its attack instructions, we can learn some lessons about security monitoring immediately. The good news is you can take action right now to prepare yourself for the next wave of attack. These lessons should not be new to anyone using BT’s Managed Security Monitoring solutions, but they are worth repeating again.

1. Monitor everything. We all know that the sooner you know about an attack, the easier it is to contain and the less damage that will be done to your network. While we all have to operate within security budget constraints, it may be worth revisiting how those dollars are being spent. Consider what devices can be added to your current event monitoring. While IDS/IPS monitoring often comprises the core of most security monitoring implementations, BT MSSG actually detected more Conficker worm attacks from monitoring firewall traffic logs.

2. Revisit your Security ROI. The return-on-investment for your security dollars is often underappreciated in the same way to how homeowners or auto insurance is not appreciated until a loss occurs. In the case of a worm outbreak that may have large operational costs, or potentially real business losses, you have to factor in the probability of a loss and the expected cost of a loss to determine your ROI.

3. Don’t be complacent about process. Security is a process. We saw a few incidents this past month where users thought they had IPS signature coverage for Conficker, but, in fact, did not. Users often rely on automated signature updates, but there are many scenarios where specific policies or configuration changes need to be made actively to enable the IPS signatures. If you have an internal process to verify regular updates are active, make sure they are beging followed. You may want to consider adding an additional process so that when BT (or other security vendor) sends out a Risk Assessment, internal verification of vendor IPS/IDS signatures and proper configuration occurs. If you are not staffed to perform these types of functions, consider outsourcing alternatives, such as letting BT manage your IPS/IDS devices.

Beware of Patched, Yet Infected Systems

Even if you have applied the MS08-067 updates, be aware that your Windows hosts may have been infected prior to applying patches!

Let’s look at some data from Qualys to provide some perspective on the expediency of applying Windows patch updates.First, recall that Microsoft believed the vulnerability was so significant that it released an unusual out-of-cycle patch update on October 23, 2008. There was an alert issued 2 days prior to the patch update and the news and awareness cycle around MS08-067 and Conficker has continued since then. Despite this high level of awareness, Qualys’ Wolfgang Kandek reported that 30-days after the MS08-067 update, 50% of Windows machines were unpatched and that after 120 days, 30% of Windows systems were still unpatched. Keep in mind that organizations using Qualys vulnerability scanning tend to have greater security awareness and procedures in place, so the percentage of unpatched systems in the wild is likely much higher.

Secondly, consider whether any Windows systems in your environment may have been vulnerable to attack , even if for a brief period of time, before patches were applied. Do you have mobile users who take their laptops out of the office where the attack could have occurred? If you do this would mean that none of your security monitoring infrastructure would have detected the initial infection. Do you allow users to plug in USB keys that could have been infected from outside your network? Do you have VPN, extranets, or any other types of network access that could allow a system outside of your control to communicate with systems within your network?

If you answered yes to any of the above questions, it is possible that you could still have infected, yet fully patched systems.

As a worst case scenario, consider the risk of having an idle Conficker worm. The Storm Worm had large subsets of the worm population idle which were communicating only to its command & control hosts but not spreading or performing any reconnaissance activity so as to minimize detection. If the rumor is true that the people behind Conficker are the same as those behind the Storm Worm, it would not be unreasonable to assume that detection avoidance tactics may be employed with Conficker.

Bottom Line

Patch now, patch often! Make sure that all your monitoring is enabled and any signs of attack activity are investigated. Where ever possible, monitor everything: IDS/IPS, firewall traffic, host and application activity. Run the Windows Malicious Software Removal Tool (MSRT) on all Windows hosts, even if you do not suspect they are infected. This can be an enormous task for large organizations, but consider running the MSRT in silent mode as part of a domain login profile.

Windows MSRT: http://support.microsoft.com/kb/890830

Deployment of MSRT in an enterprise environment: http://support.microsoft.com/kb/891716

Finally, be ever vigilant and don’t forget that we’re still early in the life cycle of this worm. For all the attention that the Storm Worm received, remember that Conficker is at least a full order of magnitude greater in size. Moreover, we have yet to see what the impact will be when Conficker’s controllers finally tell it to “do something.”