If you are wondering about the answer to this question regarding Web Application Security, you must read the following article in the Register and then get some further gory details and examples from the Daily WTF. In this story, the personal details of Oklahoma crime offenders were made public for at least three years. And I mean all the personal details: names, addresses, dates of birth, social security numbers, even medical records - the full monty.

The Oklahoma Department of Corrections website was vulnerable to SQL Injection not by mistake but by design. Exposing information not only belonging to sex offenders (exposing the exposed), but also of other offenders. And as the SQL vulnerability had appeared through the state's Sexual and Violent Offender Registry, it actually allowed anonymous Web users to report their neighbor that moved the fence by 2 inches as a violent sex offender...

One of the outcomes of the PCI Security Standards Council information supplement for PCI DSS requirement 6.6 that I blogged about last week,  is providing a definition of Web Application Firewalls. The definition was made by creating 3 different set of required capabilities:

1. List of recommended capabilities. Tasks "that a WAF should be able to do"
   
2. More advanced capabilities listed as "additional recommended capabilities for certain environments".
3. Even more advanced capabilities listed as "additional considerations"

It is a bold attempt to create a product definition for the market by listing different requirements. Thus far, the industry is based on the Web Application Security Consortium (WAFEC) , that develops the industry standard testing criteria for evaluating the quality of web application firewall solutions.

I was very excited when I examined the list, as a close review of all the requirements reveals that the folks at the PCI Security Standards Council added some very advanced capabilities. Without arguing whether scanners are capable identify the issues that WAF are now required to address. In my opinion, out of the list of 10 recommended capabilities, two capabilities stand out:

1. Prevent data leakage--meaning have the ability to inspect web application output and respond (allow, block, mask and/or alert) based on the active policy or rules, and log actions taken.
2. Inspect any protocol (proprietary or standardized) or data construct (proprietary or standardized) that is used to transmit data to or from a web application, when such protocols or data is not otherwise inspected at another point in the message flow.
   

The first requirement, data leakage prevention is clear and understood in light of the overwhelming number of organizations that had suffered from information breaches (this topic alone can fill up this blog...)

But the second requirement is more interesting. It clearly links between application that provide data and web applications. It requires to inspect (and protect) any protocol that is used to deliver data to web applications. In other words, inspecting SQL is now a recommended requirement for Web Application Firewalls!

When you look at the picture below, you can see that this is exactly what we've been talking about in the past 5 years or so. In our very first product announcement in October 2002,  Shlomo Kramer stated : "Our vision is simple: Secure the Enterprise Application Sphere... ... from web servers to application servers and databases"



SANS endorsed this approach when they published the SANS top 20 Internet Security Risks of 2007 by stating the same: "It is not sufficient to protect the database alone...all the associated applications need to be secured".
Rich Mogull was talking about it when he wrote about protection of content (SB: data) in business applications "....from your web application stack to internal applications and databases." 

And now the PCI Data Security Standards....
It is very rewarding to see how the industry is accepting our very original vision now.

There's been a lot of security talk recently regarding the latest massive attack where hundreds of thousands of URLs have been hacked. Add to this that many of the infected sites belong to some big-name organizations such as the UN, the Department of Homeland Security, and UK Civil Service to mention just a few and you've got the whole world talking about this!

This attack exploits an SQL injection vulnerability in order to inject HTML code into pages that create an IFRAME which downloads a malicious payload into the victim's browser. The Hacker Webzine gave quite a thorough analysis on this type of attack [traceback] - to summarize, the attacker uses a hexadecimal notation to represent character strings which contain the commands to be executed in the DB server. Unfortunately, traditional signatures against SQL Injection will not catch an attack vector using this evasion technique as mentioned is a past whitepaper of mine. This current massive SQL Injection attack has reminded me of the other immense SQL Injection attack which took place at the beginning of March. In that attack, hackers injected IFRAME tags to Websites' search result which eventually get indexed by Google. That attack in turn reminded me of another similar widespread attack which occurred in January which redirected users of those vulnerable sites to a different domain. In all these cases huge amounts of websites have been infected by script injection, using a single non-customized attack code. There must have been some kind of automation for so many sites to have been compromised within such a short time period. My guess is that the attacker used a botnet and Google searches to launch the attack, two techniques that combined together result in a tremendously fast and efficient distribution of malware. Search engines used as a platform for malware distribution is not a new concept, "The Search of Death" as described by the Imperva ADC warned of a mega-worm crawling its way to vulnerable websites using search engines, and we've seen the proliferation of the famous SantyWorm which defaces websites by exploiting certain php vulnerability - finding those vulnerable machines just by searching Google.

It would be interesting to see the details of these attacks unravel. Unfortunately, I do not believe that these massive attacks will fade out in the short run. On the contrary, I believe that the usage of SQL Injection as a method of site defacement and malware distribution will continue to be one of the most-spoken about security challenges we face this year.

Last week, the PCI Standards Council has issued a press release and a supplement document clarifying some of the ambiguous points in the PCI standard, including section 6.6.

SecureSphere addresses 8 or 10 of the 12 PCI requirements (depends on interpretation and not all of the sections have a lengthy clarification), including web application security as well as the database security and cardholder data protection requirements. However, section 6.6 is one of the common use cases. Requirement 6.6, which becomes effective on June 30, 2008, provides two options which are intended to address common threats to cardholder data and ensure that input to web applications from un-trusted environments is fully inspected. The Information Supplement for requirement 6.6 gives organizations clarification on implementing application code reviews (option one) and/or application firewalls (option two).

The first option for application code review for meeting Requirement 6.6 is now subdivided
into four alternatives designed to meet the intent of the requirement. They include:

• Manual review of application source code
• Proper use of automated source code analyzer (scanning) tools
• Manual web application security vulnerability assessments
• Proper use of automated web application security vulnerability assessment (scanning) tools.

The second option for Requirement 6.6 is a Web Application Firewall (WAF - which is now finally described including a list of recommended capabilities for WAF, additional
recommended capabilities for certain environments, additional considerations for organizations implementing a WAF and additional sources of information on Web application security).

Since PCI version 1.1 was introduced in 2006 we worked with hundred of organizations to meet the PCI requirement, ensuring that web application are protected and secured. During this time, we have learned that once a vulnerability is discovered in a production system, it may take weeks and even months until most organizations can patch, test and deploy the fix.

According to the PCI Standards Council, "The intent of Requirement 6.6 is to ensure web applications exposed to the public Internet are protected against the most common types of malicious input."

It adds that "Keeping in mind that the objective of Requirement 6.6 is to prevent exploitation of common vulnerabilities...Properly implemented, one or more of these four alternatives could meet the intent of Option 1 and provide the minimum level of protection against common web application threats"

While scanners of any kind would be very useful during the development cycles or as part of the QA process, they will not be able to protect web applications once a new vulnerability is identified. In fact, it creates a new type of problem to the organization, as the managers running the scanners might be aware and accountable for newly discovered vulnerabilities that can not be  fixed in due time.

Both technologies (actually all three) should be in use by organizations following best practices, but for those trying to get the most bang for the buck in the short term, the place to start is with a Web Application Firewall.  WAFs are a faster and more cost-effective approach to meeting the PCI requirements without facing the accountability of knowing about a vulnerability, not to mention SecureSphere's other benefits as it addresses more than just section 6.6 alone.

This week has raised once again the question regarding the effectiveness of patching as a security countermeasure. The past Tuesday is known to Microsoft users as Patch Tuesday, where Microsoft released eight fixes as part of its monthly security update, five of these fixes rated as critical. And tomorrow, Oracle is releasing its quarterly Critical Patch Update. The pre-release announcement states that the patch contains 41 security fixes, 17 of which are aimed at the Oracle Database itself, two of them are remotely exploitable without the need for any database credentials. Both vendors urge their customers to deploy patches immediately in order to keep their systems secure, but we all know that this is an unrealistic demand.

The operational burden involved in patching production system across an enterprise is such that it effectively limits patching frequencey to once or twice a year. Even if we are the optimistic type of DBAs, we still have to assume a time frame of weeks until a patch is deployed. This is a huge window of opportunity for hackers to launch their attack campaigns. We have seen actual attack campaigns popping up as early as a day after a patch has been released.

Leaving aside the time required for patch deployment, the fact that a security patch was released means that the vulnerability was already known to the vendor for several months, even up to 24 months... The vulnerability itself might have been present in the product for years (I have personally reported a vulnerability to a vendor, which has been present in all versions of the product for 10 years). Take for example the latest "Pwn to Own" contest by TippingPoint. The Vista Laptop was cracked, as Shane Macaulay exploited a Flash vulnerability. A few days later, Adobe announced that it knew of this bug, apparently it had been reported 5 months earlier, and yet the appropriate fix has been shipped out only last week. It is naïve to assume that the "bad" guys get to know about the vulnerabilities only when the patches are released. After all, malware markets are thriving and clandestine organizations pay top money to "security experts" to go ahead and find these security gaps (See talk by "Geekonomics" author David Rice who lectured on this underground world at last week's IT 360 conference in Toronto).

I haven't even mentioned yet the Botnet industry as a global industry as presented at the panel discussion on Wednesday's RSA 2008 Conference, didn't even start to talk about the operational hazards involved in patching production applications (see Microsoft's IIS patch problems last year and the list of software that would fail to correctly function when SP1 is applied to Windows Vista).

So, in fact we see once again that there is a huge window of opportunity for hackers to exploit known vulnerabilities where organizations rely on patching as their first line of defence. This of course calls for a different type of security solution provided by 3rd parties to provide timely detection of published vulnerabilities, as well as protection against 0-day attacks, without impacting the stability of the protected server / application. This type of solution in the form of an independent security gateway (sometimes referred to as "Virtual Patching") is probably a must have in today's turbulent information security reality.

On a completely different note, I'd like to mention an incident which happened last week where 370,000 HSBC customer details were lost. Originally, these records were supposed to be sent electronically through an encrypted channel under a well-established security policy. However, communication was down on a certain day and the records were sent via a courier service, but never really arrived as the disc got lost. Sort of reminds me of last year's incident where JFCU meant to transfer a file on an encrypted disk sent by courier, according to their set security policies, and because of some transmission error, the file was posted to the printer's Web site in an unencrypted format, the site later being indexed by Google for anyone to see. Seems that Murphy's Law which instates that if something may go wrong, it will go wrong definitely applies in the security realm - each time a security policy is bypassed, expect a security breach to happen.

So the party RSA is over. Even though most bloggers and reporters

In my opinion, the report of hackers assault epilepsy patients might be the first recorded occurrence of physical, human damage due to large scale hacking. We heard about medical facilities attacks and records destruction in the past. But according to wired,the incident, possibly the first computer attack to inflict physical harm on the victims, began Saturday, March 22, when attackers used a script to post hundreds of messages embedded with flashing animated gifs.
Wow. I wonder what's next, programing HAL 9000?

I attended one of the most interesting customer meetings yesterday. It was interesting because the customer is asking to deploy SecureSphere in order to protect the entire universe. His universe. As you can guess, this company (let's keep the name to ourselves) is developing one of the coolest games. This is a multilayer online game that has its own economy. This economy is managed by the users and just like any other economy; some users are more corrupt than others. SecureSphere is protecting the treasury database, ensuring that (real life) gamers will not cheat and destroy the (virtual) economy. Just imagine that a virtual bank will start to offer cheap loans to other users that can not afford to pay mortgages... it can destroy the economy.... In short, I was very excited to learn about this opportunity and watch how imagination sometimes is well connected with reality.

So how is the car related to this post? On the way to the data center, we spotted one of those beauties. The Bugatti Veyron is the most powerful, most expensive, and fastest street-legal production car in the world, with a proven top speed of over 400 km/h (407 km/h or 253 mph). The title of the most expensive mass production car in the world comes with a price tag of $1,700,000. Watching this car and thinking about the economy, one can REALLY understand why treasury applications should be protected. Not just in the virtual world.   

 

What makes a solution better, unique and different?

Boston, MA

Today, I participated in a security panel that was (very well) organized by our partner, Netanium Network Security, Inc. Four different vendors, focusing on solving different aspects of information security, answered the moderator's questions and guided the audience through our collective experience. One of the guys at the audience asked us "what makes you better than your competitors". Each vendor answered slightly different, yet very similar, highlighting manageability, flexibility, scalability, ease of use etc. I decided to give a different perspective and explained that in my opinion, the reason that customers select our solutions and choose us as their trusted application data security and compliance companion is due to our ability to perform two tasks better than anyone else: 1) Being visionary, passionate and know exactly what needs to be developed and delivered in order to solve the problem, address customer needs, fit into their environment and create a platform for growth. 2) Ability to execute, as it is not enough to have a great vision. A great company is capable to take its vision and create the right products, providing the best support and deliver the necessary services.

I guess that in a way, I was saying that our solutions are better since we have faster products; it can be managed easier, scale better and provide the necessary flexibility. But we will sustain this advantage by continuing to deliver our vision.

SecureSphere Wins another WAF shoot out

What a great start for my first blog post with our new blogging system. Information security magazine published a review of six (6) web application firewall products. Beside winning this shoot-out review and scoring top marks in each category: ease of installation and configuration; administration; depth of security policy control; monitoring, alerting, auditing and reporting; and overall security effectiveness. SecureSphere received a rare compliment. The magazine names it "The closet thing to a silver bullet". Anyone in the security industry will tell you that "there is no silver bullet". I tend to agree. No product is perfect and its effectiveness is based on the defined policies and how well it's being integrated into the network, and more important the business process.  SecureSphere is not different in that sense, however, its administrative interface, security capabilities, multiple deployment options and depth of policy control makes it unique and different.  The metaphor of the silver bullet applies to any straightforward solution perceived to have extreme effectiveness, and when we're thinking about it, SecureSphere is indeed the closest thing to a silver bullet for application security and compliance: it was designed, engineered and built to solve application security problems.

 

Anyone that had to hunt werewolves, know what I'm talking about. http://en.wikipedia.org/wiki/Werewolf).

 

Read more about the review at http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci1303838,00.html