June 2008 Archives

It seems that there is renewed interest in protecting enterprise applications (e.g. SAP).  Our own Sharon Besser blogged about it, McAfee's Rees Johnson blogged about this here and there has been some commentary from Eric Kang on how PCI DSS applies to SAP here.  SAP even has a list of complementary security providers (software, hardware and services) on this site (yes, Imperva is on this list as well).

Why is there so much focus on protecting applications that enterprises use to run their business?  Well, if you need to ask... But seriously, do think back for a bit and see what your own applications contain.  I suspect that most companies keep at least the following data:

• Customer names, addresses, credit references, payment history, tax ID numbers, etc.
• Employee names, social security numbers, addresses, bank account numbers (for automatic deposit of paychecks)
• Supplier/partner information (similar to customer information above)

You can see why the "bad guys" are after enterprise applications now.  And, as Eric Kang noted above, most of the PCI consultants don't understand ERP applications.  The problem here is obvious, the solutions, not so.  I could talk about how our SAP-certified WAF is one answer to this and how our DAM solution is another but then I would be pitching products...

I saw Karl Fisch's "Did You Know?" video few months ago and it had a huge impact on me. I think that it's a must see movie for everyone involved with corporate, business and product strategy. Change happens. Period. So when I read Forrester's Noel Yuhanna "A New Role Is Emerging Within IT: Database Security Analyst (DSA)" I could not avoid thinking about this movie. Noel is describing that enterprises take stronger measures around database security to meet compliance requirements and defend against attacks and as a result, the need for security support and administration becomes critical. This is part of a change that we are witnessing within the Information Security and Risk community in the past 2-3 years. It's all about the data. Traditional security and hence traditional security jobs, are no longer adequate and there's a need for database security.  There is a gap between security staff and Database Administrators. IT security groups focus primarily on creating information security polices and procedures and defining the approaches departments need to take when securing data. Typically, they are not responsible for implementing the controls themselves but often delegate them to various IT groups. That's all part of the change that drives a lot of our customers. I would like to think that our strategy and vision provide customers with the tools to bridge this gap. By providing the needed tools in the most efficient fashion, organizations that are using SecureSphere can survive the change. The ending sentence of Noel's executive summary speaks for itself:

This role does not currently exist in most organizations, and it might be difficult to fill because of its cross-disciplinary requirements. Faced with an essential need and challenging role requirements, IT security organizations should get ready to staff the database security analyst (DSA) position.




Movie linked from http://theclosetentrepreneur.com/karl-fischs-did-you-know-presentation-remix

Nik Cubrilovic at TechCrunchIT brings the story of how Opera Software is building a team of "web evangelists" whose job it is to find sites that do not display correctly in Opera and are not standards-compliant, and then email the site owners. Great. I'm enjoying everything that comes from this company (using Opera Mini with my BlackBerry ).
But what about security? Why can't we email site owners when we find vulnerabilities?

Here's a challenge for myself and the others. Let's see if I'm falling into the SANS statistics I wrote about earlier: Can the community write a browser extension that identifies web vulnerabilities (there are many open tools), finds the site owner (there are tools that can do this as well), suggests a fix (might be tricky) and emails the web owner? In theory, it can work.

I just read a story about a server breach at 1^st Source Bank located in Indiana, USA. What caught my eye though was the fact that the breach was detected due to a massive numbers of fraudulent ATM transactions in Europe (specifically in Russia, Ukraine, Turkey and the Czech Republic) a month (!) later. These fraudulent activities were traced back to that server located across the ocean.

I presume that an individual (or an organization) hacked into the server, stealing data which was sold to different (or a network of) sources in Europe. These criminals then created debit cards based on this information to commit the fraud. The article does not specify the type of data which was stolen, but obviously it was enough to create the cards and furthermore, it must have also contained the secret PIN of the victims - after all, a PIN is required to extract money from the ATM. Well, at least this is how I read between the lines.

This incident emphasizes the motivation behind the PCI-DSS requirement which specifies that the PIN should not be stored at the database at all, nor the raw Track data. This leaves many open questions and me quite curious to know the turn out of the breach investigation. 

Looks like SANS decided to take a side in the discussion that Amichai and I have Check out SANS NewsBites Vol. 10 Num. 49 (June 20, 2008).

"A surprising result appeared in the first large test of the secure coding assessment exams in Java and C: they found that programmers are exceptionally well versed in the types of vulnerabilities that may crop up, but shockingly unable to find and fix those vulnerabilities. Apparently security awareness classes do not solve the problem, but give false confidence."

It seems that the Verizon 2008 Investigation Report provided us security researchers with loads of material to think about!

Today, my thoughts surround the evaluation of internal versus the external breach source. The report presents several surprising results regarding the data breach sources. While the common belief is that internal breaches are more frequent than external, the Verizon report presumably shows that the number of incidents originating from an internal source is four times less than those originating from an external source.

I believe there are a couple of explanations to these results. The first is that the report composers did not just differentiate between internal and external hacks, rather they added an additional group, that of "Partners." Most parties classified in the report as partners would have previously been classified as internal. Summing the caseload of partners and internal sources, we do receive quite a high number, although it is less than externally-driven breaches.

This brings me to the next main explanation. The report considers only data compromise incidents, while putting aside other types of security breaches which eventually result in fraud or theft. Take for example the cheating incident at UltimateBet and Absolute Poker. The poker-faced insider (or insiders) opened up multiple fake accounts exploiting the fact that insiders are allowed to view the competing players' cards.

I would say then, that although the number of attacks which result in data theft lean towards the external sources, the overall number of incidents which include different types of attacks against applications and knowledge-based systems are still mainly contributed by the organization's insider.

A couple of weeks ago Sharon discussed the Verizon 2008 Investigation Report. In particular, the monitoring and real time security issues as published in the report. He also included one of the report's graphs, that of Data Breach Discovery Methods.

It is this chart I'd like to focus on today. As the chart shows, 70% of data breaches are discovered by notification of third parties. This picture is the same as depicted from reading through news headlines of data breaches, as we presented in Imperva's webinar "Reading between the Lines" more than a year ago. Notification by third party is indeed the worst way to get informed of a security breach but this is mainly the way it occurs when Google Hacking is involved. We do not lack stories where a surprised individual finds her Social Security number appearing on the Web during a simple Google search. But we do not restrict the discovery only to Google Hacking. Take for example the data breach at UVa, published last summer. An SQL injection attack slipped under the radar for nearly 2 years before becoming public. Secure monitoring tools did not detect the flaw, nor was the illegal access identified in a timely fashion. Only when reviewing an unrelated defacement incident, the data theft was detected by chance - one year after the first hacking incident.

Verizon has also shown that only 4% of data compromises are discovered by event monitoring or log analysis. Verizon suggests that organizations install and manage event-logging type solutions. Going back to our above example, we read that the university maintains an extensive audit trail which allowed investigators to track 54 different attack incidents over a time frame of one year. Such an audit trail could not have mitigated the extent of this attack as it did not help the university to detect the breach in a timely fashion nor assist in providing details about the actual stolen records.

It is safe to conclude that event logging does not provide a comprehensive solution; rather we require a solution which separates the wheat from the chaff, and in our usage - to sift only those relevant events. In the best case, the solution should also go the next step and block malicious usage (as Sharon has suggested this week), but at a minimum any solution must be accurate enough to alert the proper resources.

If you are driving on highway 101 North from Sunnyvale to Redwood City you can see a billboard sign encouraging you not to serve alcohol to teens. Unfortunately, like thousands of  other commuters, I have plenty of time to stare at this sign every morning.

It's probably the security geek that lives in my head, but when I saw this sign, I was thinking about monitoring-only security solutions.  Any person using security solutions for monitoring only without enforcing blocking policies is unsafe and irresponsible. In some cases, I would go as far as considering security solutions that can't block major attack vectors (e.g. single packet attacks) as illegal. I truly believe that a security solution must be capable to prevent attacks in the first place. Please note that I'm making a distinguish between audit and security solutions. The former can be limited to monitoring only, but as we have learned, in many cases, audit leads to security, thus the right solution architecture must have prevention capabilities as well.

At Imperva, our philosophy (and products strategy) is the to provide granular prevention controls. Turning blocking is not like activating a big on/off switch. We provide granular controls using multiple methods allowing enterprise customers to prevent attacks. When I'm hearing that other vendors are not offering full enforcement or that customers are not using blocking at all, you can tell that I'm an orthodox. Don't get me wrong, monitoring web activity is very important. It is the first step, but it's not the destination. We need to PROTECT applications. Protection requires PREVENTION and prevention requires blocking. Of course, a product must be very accurate, able to handle the load, support enterprise requirements. but at the end of the day, WAF are a security tool. Customers should evaluate how WAF is blocking attacks, including the most sophisticated, single packet attacks.


At the SANS's Web Security Summit. One of the panelists was explaining how he is receiving SecureSphere real time blocking alert messages directly to his BlackBerry device. This panelist is the CISO of an organization that processes more than 70 billion financial transactions per year. SecureSphere is there, blocking attacks in production systems. My point here is that accuracy must be high in order to provide the CISO and of course IT, OPS and other parts of the organization the peace of mind when inspecting 70bn and more transactions per year in real time

I can't tell what other vendors are providing, but Imperva's customer survery statistics show that the vast majority of are running in block mode. Blocking attacks is cool, safe and responsible.




Image source: http://www.dontserveteens.org/materials/posters/14x48.pdf 

I am back from the HP Technology Forum & Expo 2008, taking place this year in Vegas. I was presenting in one of the breakout sessions after Howie Mandel's Thursday morning closing general session.

To be honest, my audience was a "little" smaller. Maybe it was the topic (or the presenter :-) but I was actually surprised from the number of attendees, all working for well known companies that are still in the process of compliance, determining the PCI scope or taking the risk of not being compliant. We are focusing on section 6.6 (and we should, just to remind you all, it goes into effect on June 30, 2008.), but there are plenty of organizations that are also trying to solve the other "challenging" topics. Here's the citation from the PR: 

The PCI Data Security Standard (DSS) provides an actionable framework for developing a robust payment card data security process including preventing, detecting, and reacting to security incidents. However, several requirements mandated by the PCI DSS such as tracking and monitoring cardholder data, rendering stored cardholder data unreadable, and application security pose considerable challenges for most organizations. Mr. Besser will discuss the three most difficult PCI DSS requirements, the pitfalls to avoid in trying to meet them, and best practices for making sure you pass a PCI Audit. He will also cover the recently published PCI DSS update titled, Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified, which goes into effect on June 30, 2008.

So, What have I learned: 

1. Many organizations are still not 6.6 compliant.
2. Some organizations continue to store sensitive authentication data such as PIN CVC2/ CVV2/ CID.
3. Few are still unaware of the full scope of PCI.

I guess that we still have a lot of work to do...

I just got back from a week long trip to Japan. I met with a few members of the press (if you read japanese, check out this article in the Nikkei BP's IT Pro magazine...I hope they got all my quotes right ;-) as well as partners and customers.  I also presented a session on Data Governance Trends for a full house seminar put on by Imperva distributor Tokyo Electron

My main conclusion after a week in Tokyo is that Application Data Security is thriving in Japan. Database security and database activity monitoring have been a strong market in Japan for the last year or eighteen months, primarily as a result of "J-SOX" (J-SOX is an informal name, the formal name is Financial Instruments and Exchange Law. It is similar to Sarbanes-Oxley in the US).  While I was there, this article (also in ITPro and written in Japanese) was published about Imperva DMG customer, Ace Insurance.

What struck me was the number of questions I got about PCI.  It came up in literally every meeting I had in Japan.  In my seminar presentation, I summarized where I think we are with PCI in the US (strong enforcement push by the card brands and adoption considerably underway) and in Eurpope (about 18 months behind the US on the enforcement/adoption curve, but currently meeting strong resistance and resentment).  I left my Japan comments blank, but throughout the week I drew the conclusion that while Japan is just starting out with PCI (I'd guess 9 months behind Europe), I think that adoption in Japan will overtake Europe fairly soon. 

I'm not sure if I know why, but my guess is that after a strong J-SOX push, the Japanese companies are more like US companies...they've been though the pain of a regulation once already, so they see a bit of the inevitablity.  Also, very much like the Americans - they DO NOT want to have to do data governance manually...so most of the questoins were about things like "How do I automate my compliance process?" and "What's the comparison of operational cost for code review/vulnerability scanning versus WAF?" (and yes, I explained why you need all of these things to work together).

Rohit's enthusiastic post regarding scanner integration did not include too many details on the approach chosen by Imperva to integrate scanners within the SecureSphere Web Application Firewall. Let me shade some more light on what we've been doing in the past few months.

To begin with, we did not fancy the paradigm of serving as a copy-paste gateway between a scanner (or a scanner service) and a WAF nor did we want to miraculously turn random scanner output into WAF rules. Rather, we were interested in integrating the scanner as part of the WAF vulnerability management cycle. The idea is to load the vulnerability information into the Web Application Firewall and have the user manage the vulnerability up to the mitigation stage. Accordingly, we did not want to incorporate a single scanner, rather to build a framework based on our OpenSphere initiative to accomodate various scanners and scanning services. This would require the gathering of vulnerability information from different sources, in particular from different Web Application scanners and from Web Application security services.

We faced quite a few challenges when designing this capability...

• The first was to translate vulnerability reports (file, database, etc.) of different scanners from their native format to a single uniform language. We were fortunate enough to have some of our partners to help us in this effort.
  
• The next challenge was creating a platform to support a constant update mechanism for new vulnerabilities being discovered by the different sources (namely, the scanners). This is where the "ADC Update", an integral feature of SecureSphere, came in handy as we were able to actually leverage this existing platform.
  
• In order to provide the tools for vulnerability management, we combined the information gathered from the external sources into SecureSphere's powerful and flexible built-in reporting engine. This allows the creation of reports with different levels of granularity according to those discovered vulnerabilities.
  
• Finally, we have provided an easy integration path to create security policies that would mitigate the vulnerabilities, keeping track of which vulnerabilities are being mitigated by which rules.
  

One of the more powerful tools which we rely on is SecureSphere's Correlated Attack Validation capability which allows us to provide effective and accurate mitigation against the found vulnerability. All these new and exciting capabilities are seamlessly packaged into the SecureSphere product and delivered to existing customers through the powerful "ADC Update" mechanism.

You can guess by the tone that I'm also excited about this new addition to the SecureSphere set of capabilities as it extends our support for the enterprise security life cycle even further.

 

- Amichai

Today is an exciting day for Imperva (and for me) as we are launching what I consider to be an extremely valuable offering that ties two distinct markets into an integrated solution.  I am talking about putting together penetration testing (aka black box testing) and web application firewalls.  While this concept has been tossed around recently in a few places - Gartner is quoted in Dark Reading and Rich Mogull wrote about it at Securosis.com - the actual integration and idea goes beyond the run-of-the-mill "lets reuse results" approach of other integrations like this.  Let me explain.

Imperva is allowing customers to take decisions on what and when to fix vulnerabilities in their web applications on their own schedule.  While that part is not necessarily new, what is new is that Imperva is opening up the web application firewall as a platform so penetration testing tools from more than one vendor can integrate with it.  And, here is the really different part, Imperva is also allowing these partners to take data from the web application firewall and improve the scanning process.  This "feedback" loop allows scanners to narrow the scope of the scan to just what has changed in the application, focus in on the areas of the application that handle sensitive data (e.g. credit card information) and provide additional insight into those parts of the application that are typically inaccessible to automated tools (e.g. those that require writing to the database or are accessed by completing transactions only).

This concept of improving the behavior of web application firewalls by taking ContentIn and giving relevant InformationOut is new and lends itself to other technologies, all aimed at improving the security of the infrastructure - did someone say Adaptive Security?

-- Rohit Gupta, VP Business Development, Imperva

I've always been blunt expressing my opinion about enterprise software vendors promoting patching as the only viable security solution. While vendors make it a habit to take offense at my postings and arguments that claim that patches are complementing to 3rd party security, they consistently provide more and more arguments to prove my point.

Last week, as an Oracle customer, I got an email from the Oracle support system, urging me to download and apply a new version of the April CPU patch (for HP systems only). It turns out that the original patch had an adverse effect on some of the functionality provided by Oralce products. As you can see, if you follow the link above, there are NO workarounds to solving this issue - which of course makes sense: it is a part of the Oracle product functionality and cannot be replaced (even temporarily) by a 3rd party solution. Security flaws, more often than not, can be mitigated using 3rd party solutions (sometime called "Virtual Patching"). Therefore it would be a far better strategy to first mitigate security risks using a 3rd party solution and then apply a patch after it has been tested rigorously in the enterprise test environment and its side effects are better understood. See also http://www.networkworld.com/news/2008/061108-mac-bug-forces-mozilla-to.html?page=1 for yet another beautiful example.

 

- Amichai

Sharon and I share the same basic conclusion, WAF should be used to provide application security at run time (but of course we work for the same WAF vendor :). I think though that the reason for not relying on secure coding practices is even more fundamental.

It is true that in a hypothetical world a WAF is required for mitigating that pain in the a** one additional bug left there after the sisyphysian effort made by programmers to write secure code. However, in reality developers are not motivated by code security regardless of what security officers may want to believe.

• First, programmers (especially the ones actually writing the code) are not reporting to the IT security people. In fact they rarely interact with them on daily basis (not to say yearly basis).
• Second, programmers (and their superiors, and their superiors' superiors) are measured by the throughput they provide in terms of functional code. Numerous models for measuring programmer efficiency and performance never take into consideration the "security" of the code. Models that try to weigh in the quality of the code in terms of actual bugs found in it are hard to implement since they can only be applied post mortem and since bug metrics themselves are rather fragile.
  

So in a realistic environment programmers care only about those parameters that can be measured by their superiors. Fast, neat coding is one of them, security is not! That's it plain and simple.

Take another look at it, if an application is missing a form, or fails to complete a transaction, it will not be released. If the application can complete the transaction but is known to have some security vulnerability related to it, 9 out of 10 times it will be released. Where would a programmer put his or her attention? Yet a completely different angle is specification vs. implementation, when a programmer is writing a piece of code there's usually a clear specification document to follow with respect to functionallity (up to the color and font of particular GUI elements). However, with respect to the security of a module there are rarely any clear specifications. We all know the cryptic statements "transaction should be secure", "users should be authenticated". There is rarely a clear list of attacks to be avoided or steps that should be taken in order to mitigate those attack There is therefore no real way for a programmer to write secure code per its specification.

In view of the above discussion I can say that while it is a nice idea to have programmers write secure code to begin with they probably will never be motivated to do so. This does not mean that we should give up on trying to make them security aware, it just means that security strategies should be devised to reflect this inherent behavior and that security resources should be allocated in a manner that reflects it.

- Amichai

We can't write secure code - so let's give up keep tryin'

Last week, Mike Rothman (here http://securityincite.com/TDI-2008-06-05#TB