Amichai Shulman: June 2008 Archives

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.

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.
  

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

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

There has been a lot of buzz in the past few weeks regarding database attacks occurring via SQL injection. Truth is that many (or even most) of the database attacks occur through a completely different channel - via compromised insiders.

In one of Imperva's whitepapers published a couple of years ago, "Top Ten Database Hacks and How to Stop Them" we stated the internal threat as the leading database threat. We gave the example of a university administrator being able to change grades. Ironically enough, last year this example turned into a real-life scenario when employees of Diablo Valley College abused their privileges in an ERP system to modify students' grades.

A few days ago, Kevin Beaver wrote a Microsoft SQL Server tip on how insiders hack databases. Kevin raises a couple of issues - the first, that the Internet contains a large resource of free hacking and database assessment tools for the attacker's use and the second - that the small, "unkept" databases are a vulnerable target and should not be overlooked.

Kevin is correct to declare that free database hacking tools are available, but I'd like to go further and say that there is no need to search the Internet for such (and sometimes, obscure) tools when they're already available at the fingertips of the hacker, sometimes even appearing as standard desktop tools. Take for example "Query Analyzer" by Microsoft, "SQL Plus" by Oracle. Even Microsoft Excel can be used as hacking tool. I detail the steps taken to perform such a successful attack (and of course, safeguarding against one) in the ADC paper "An Anatomy of a Database Attack".

Regarding those servers that do not receive all the maintenance and upgrading attention that is required - it is precisely for this reason that database security assessments are necessary and require a good automation tool that could help in enterprise server discovery and enterprise data discovery which assess which servers are those that appear in the organization, and furthermore what is that data stored in these servers.