BT MSSG      & 

          Sanjay Mehta, Senior Vice President, Breach Security

The nirvana of that moment in time when you are completely secure without a single vulnerability in sight is unfeasible and, even if it were possible, it would be fleeting.  Despite our fondest wishes for this moment, we accept the fact that our networks are vulnerable and are in a constant state of flux, causing the vulnerabilities to alter and the risks to change.  Organizations struggle with how to continue to develop their core business while managing their risk and doing it all with fewer people and resources than they had last year.  The only way this is possible is to work smarter – but how does that translate into practice?

We accept that our security is flawed, so it becomes critical that we place security devices wherever we have high or unacceptable risk.  It is essential that the security alerts from security products like WAFS, firewalls, IDS/IPS as well as host information and application logs are centralized.  The devices we select are critical and should be chosen in line with risk.  It is worth bearing in mind that web applications are one of our largest areas of risk and were one of the key areas of focus in PCI DSS 1.2 which was based on the forensics of card breaches.

Once the devices are selected, then the complexity of managing this new technology comes into place and again, outsourcing is a serious option for companies that are constrained by head count.  The footprints of what has happened on our network is in our log files, and it’s impossible to check the multitude of consoles for the vast array of product that we have, so it is critical we centralize our log files and have the capability to correlate and look for patterns of attacks.  Unfortunately, security breaches are not limited to 9 to 5 or business hours, so our security monitoring framework must be built to take this intelligence, look for patterns of attacks and be manned 24×7.

This week’s RSA Conference pinpointed the problem of treating compliance as a single point in time. 

Most companies breathe a sigh of relief once PCI compliance is “achieved” via an audit or code review.  IT professionals move on to the next priority, and often, compliance “maintenance” is forgotten.  In doing so, they fail to understand that audits and code reviews are outdated the moment they are completed.  Web applications continue to be developed and altered, and as a result, continued compliance can’t be ensured with the “one-time look” that occurs with audits and code reviews.  And it would certainly be cost-prohibitive to conduct an audit or review with each application change.

Fortunately, continuous PCI compliance can be achieved using a web application security solution that provides real-time, continuous security for all protected web applications. 

In today’s compliance landscape, it’s simply not enough to know that a problem exists.  Sophisticated web application security solutions help companies mitigate problems.  Organizations need to have a real-time solution – not just a single look in time – to be truly secure and PCI compliant.

Here is more information on how vulnerability scans and code reviews compare to web application firewalls:

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.

SQL injection attacks are the No. 1 cause of data loss according to the 2009 Data Breach Investigations Report by Verizon. The report points directly to secure coding in PCI DSS and the need for code review or web application firewalls (WAFs).  While SQL injection attacks are often detected incorrectly by IDS/IPS, specialist application monitoring presented within a WAF gives far better accuracy with detecting application layer attacks.  

To shed more light on web application firewall technology, we have asked our technology partners at Breach Security to offer their insights.  Here’s what Ryan Barnett, Director of Application Security Research at Breach Security, has to say:

There was an interesting article on Computerworld’s website entitled, “We’ve been blind to attacks on our Web sites.”  The article drives home an important use-case for WAFs – visibility of web traffic. Too many people get caught up in the “block attacks with a WAF” mentality that they forget about the insight that can be gained by simply having full access to the inbound request and response data.  From the article:

Of course, as the security manager, I can’t afford a false sense of security, so I recently took some steps to find out just what was going on within our Web servers’ network traffic.  And it turns out that many attacks have been getting through our firewalls undetected.  We’ll never know how long this has been going on.

                         — Computerworld, J.F. Rice, “We’ve been blind to attacks on our Web sites” (June 23, 2009)

This is a typical first reaction.  Most of today’s network firewalls have some sort of Deep Packet Inspection capabilities.  However, most people don’t use it due to performance hits.  The firewalls are mainly geared towards whether to allow a connection based on the source destination IPs and Port combos instead of the actual application payloads.  This is somewhat like when you use the telephone to call someone.  A firewall would just check to see if you are allowed to call that phone number, but it doesn’t usually look at what you are saying in the conversation once you are connected.

The other big hindrance to inspecting web traffic at a network firewall is SSL.  You have to be able to decrypt the layer 7 data in order to inspect it.

My company’s front-end Web servers, which directly receive connections from the Internet through our firewalls, are definitely a hot spot in our network.  The firewalls and IDS allow us to see some of what’s going on, but can they really detect active content-based attacks?  To find out, I installed a Web application firewall in my company’s DMZ to tell us about active attacks that may not be identified by our other devices.  I set the device up in monitor mode, though it can be set up to block attacks, because my goal was just to see what was going on.  I wanted to know more about what’s inside the connections to those Web servers.

           — Computerworld, J.F. Rice, “We’ve been blind to attacks on our Web sites” (June 23, 2009)

The WAF can initially be deployed for detection only or monitoring mode to allow for visibility.

What I discovered is that our Web sites are being “scraped” by other companies — our competitors!  Some of the information on our sites is valuable intellectual property.  It is provided online, in a restricted manner (passwords and such), to our customers.  Such restrictions aren’t very difficult to overcome for the Web crawlers that our competitors are using, because webmasters usually don’t know much about security.  They make a token attempt to put passwords and restrictions on sensitive files, but they often don’t do a very good job.

            — Computerworld, J.F. Rice, “We’ve been blind to attacks on our Web sites” (June 23, 2009)

Scraping attacks that are executed by legitimate users and aim to siphon off large amounts of data are a serious threat to many organizations.  These types of attacks cannot be identified by signature based rules as there is no overt malicious behavior to identify if only one individual transaction is inspected.  Behavioral analysis needs to be employed to correlate multiple transactions over a specified time period to see if there is an excessive rate being used.  Anti-automation defenses are critical.

Our Web application firewall found some other problems as well.  We experience hundreds of SQL injection attack attempts every day.  So far, none has been successful, but I’m amazed at the sheer volume.  I can’t imagine anyone having the time to sit around trying SQL injection attacks against random Web servers, so I have to assume that these attacks are coming from automated scripts.  In any case, they are textbook examples of SQL injection, each one walking through various combinations of SQL code embedded in HTML.  It looks like we’ve done a good job of securing our Web applications against these attacks, but it’s always a little disconcerting to hear invaders pounding on the door.

                        — Computerworld, J.F. Rice, “We’ve been blind to attacks on our Web sites” (June 23, 2009)

Having visibility into the types of automated attacks launched against a web application provides two key pieces of data:

1. Understanding of the Threat component of the Risk equation – There are many academic types of debates and discussions that happen early on in the development of software.  One of the more challenging aspects to quantify is the threat.  Is there really anyone out there targeting our sites?  Where are they coming from?  What attacks are they launching?  Without this type of confirmed data obtained from the production network, it is difficult to accurately do threat modeling.

1. Validation of secure coding practices – It will become evident very quickly whether or not the web application is vulnerable to these types of injection attacks.  If the application does not implement proper input validation mechanisms, then there is a possibility that the injected code will be executed and the application will respond abnormally.  By inspecting both the inbound request and the outbound response, it is possible to confirm if/when/where input validation is faltering.

BT’s Managed Security Solutions Group is the first global MSSP to work with Breach Security’s WebDefend to ensure that application attacks detected by the WAF can flow into a central security monitoring framework while providing the maximum amount of intelligence to SOC engineers to ensure state of the art monitoring.  Most customers struggle with increasing number of management consoles and alerting frameworks.  The capability to plug web defend into a central framework enables organizations to have the benefit of 24×7x365 monitoring.

http://www.verizonbusiness.com/resources/security/reports/2009_databreach_rp.pdf

http://www.breach.com/

http://www.computerworld.com/s/article/340216/We_ve_Been_Blind_to_Attacks_on_Our_Sites

http://www.breach.com/news-events/press-releases/2009-10-06_WebDefend4.html