Anonymous has announced Operation Robin Hood.  The purpose, according to Anonymous:

Operation Robin Hood is going to return the money to those who have been cheated by our system and most importantly to those hurt by our banks. Operation Robin Hood will take credit cards and donate to the 99% as well as various charities around the globe.

Anonymous also claims:

We are going to show you banks are not safe and take our money back. We are going to hit the true evil while not harming theirs customers and helping others. [Emphasis ours.]

This begs the question:  Who pays for stolen credit cards?   
A. Banks
B. Retailers 
C. Consumers/credit card companies' customers

If you anwered C, you're right.

Consumers are using their credit cards more, which has provided a large black market for credit card numbers.  The markets have become quite efficient.

The problem is that from a consumer standpoint, there's no liability for a stolen card.  The fraudulent transaction is not charged back to the consumer.  The problem is that this misleads consumers--and Anonymous--into thinking that consumers are spared while banks and retailers are screwed.  Wrong.

The reality:

• The retailers who accepted the stolen credit card (not knowing it was stolen) lose price of the merchandise purchased.
• Credit card companies increase fees and interest rates.  Fraud costs, in effect, are distributed back to the general pool of consumers.

So who's funding Operation Robin Hood?  Anyone with a credit card.  This very likely includes the many members of Anonymous.

Yesterday, we blogged on cyberinsurance.  

Many of the same dynamics that apply to "regular" insurance also apply to cyber insurance.  Consider:

• Lower premiums for "good" behavior--One of our customers, for instance, reduced their insurance premiums by several million dollars per year by implementing Imperva and other data security technologies.  In the event of a data breach incident, demonstrating appropriate technology measures were in place will help fight claims with the insurance provider as well, i.e., "We made significant investments to protect against data loss."
• Insurance payouts aren't a given--This past July, Sony and its insurance carrier, Zurich, got locked in a legal battle over Zurich's refusal to pay for damages from Sony's breach.  The article cautions:

"There are probably still some risk managers out there that think that their comprehensive general liability policy cover breaches," says Sagalow, who was one of the main experts in charge of first drafting cyberinsurance policies for Zurich when he worked for the company prior to starting his own consulting shop. "These types of cyberevents are not covered in the typical standard forms of insurance."

We've discussed at length the security issues with SharePoint.  To get a scope of SharePoint's growth and footprint, this site on sharepoint provides excellent statistics.  (Note:  Installing SilverLight is required).

Looks like Hacktivism strikes again.  Here's the pastebin info.

A few observations:

• Unclear how they passwords were breached.  However, it seems safe to say we have a case of SQL injection.
• The UN's password policy is pretty bad:  no strong passwords and, in some cases, no passwords even required.  Additionally, they didn't even encrypt their passwords.

The UN makes an obvious target:  Perhaps the UN Security Council can pass a resolution to perform basic security?  

Great piece, a must read.  Just another example of how cyber security is becoming part of the "everyday" business.

Most interesting snippets (direct quotes):

1. Many insurance companies have a good grasp on how to provide protection, but trying to figure out how to quantify losses incurred from a breach is an inexact science. Downtime, informing users of a security risk, protection against libel, and slander accusations all cost money, and not all companies—especially small businesses—have the income to cover it.
2. In 2008, only about 1.5 out of every 10 of AON’s clients was interested in or in the process of buying cyberinsurance, said Kevin Kalinich, national managing director for cyber liability. This year, that number has jumped to 4.2 out of every 10. 
3. Standalone policies such as AIG’s netAdvantage and Chubb’s SafetyNet and CyberSecurity have an annual premium of about $3,500 per $1 million insured. Small business policies can run up to $5,000 to $25,000 per million, with deductibles of up to $25,000, according to Small Business Review.
   The cost of a policy depends largely on what kind of protection a business already has in place, says Kalinich. A $5 million company may pay $50,000 to $70,000 in coverage, while a different company in the same business with the same revenue but weaker cybersecurity policies could pay more than $100,000.

The recent Facebook virus attack got a lot of attention.  

Facebook has, in effect, blamed browsers:

In a statement on Tuesday, Facebook said the images were the result of a “coordinated spam attack,” and that users were tricked into pasting code to their browser’s URL bar, which, unbeknownst to them, executed “malicious javascript,” in turn summoning and disseminating the images. According to Facebook, the technical reason for the violations involved a “self-XSS vulnerability in the browser.

The reality?  This is social engineering attack which means the vulnerability resides neither on browser nor server, but on the human.

Classic PEBKAC (problem exists between keyboard and chair).

When the user is tricked into copy pasting javascript in the address bar, the javascript gets executed in the context of the site, which achieves the same results as having XSS in the site.

Most modern browsers (Chrome, IE9, for example) block that option to protect users from themselves. Need proof?  Try copy pasting "javascript:alert(1)" into the address bar and see the javascript get stripped (as opposed to directly typing it on address bar).  The issue:  there are a lot of users that don’t use latest versions.

This has nothing to do with cyber security and I'm not sure who produced the video, but this is certainly amusing for the holiday traveler:

Happy Thanksgiving from Team Imperva.

From today's Chicago Tribune:

Sara Glashagel, 27, a special education teacher [pictured below] who is the wife of Antioch's head football coach, allegedly got hold of an administrative password and inflated the grades for 64 students — 41 of them football players, authorities said.

...teachers normally do not have access to each other's grade books and that the changes had been made using an administrative password. He didn't know how Sara Glashagel allegedly got hold of the password, but he said that after the security breach was discovered, all of the district's passwords were changed and made more complex.

The interesting part is the admission that the passwords were "made more complex."  This implies that the previous passwords were probably quite simple, possibly not requiring any special hacking skills.

On November 15, Larry Suto published a report analyzing how effective WAFs and IPS products are at protecting Web applications against external attack. 

Overall, Imperva performed well in the review. Imperva finished as the top performing WAF vendor.  In fact, according to the profile of Imperva SecureSphere (on page 7):

Imperva has a high quality protection engine with a very robust set of basic policies. It is also one of the easier WAFs to configure and provides the most value straight out of the box…it became clear that it was a very effective solution.

A few observations:

• This report highlights how WAFs are an important application security technology.  Most tuned WAFs managed to block more than 60% of what a vulnerability scanner threw at them.   Though many WAFs required extensive tuning, a few hours of work meant you could dramatically decrease the odds of an application breach.
• Not all WAFs are created equal.  Some required a lot of tuning, some didn’t.  The reviewers tested Imperva as well as Barracuda, Citrix, DenyAll, F5, ModSecurity, Sourcefire, and an unnamed IPS. Imperva SecureSphere mitigated more vulnerabilities than any other solution, both with and without virtual patching. Without tuning, SecureSphere blocked 88% of vulnerability exploits and 89% with tuning.  By contrast, some blocked 26% or less without tuning and could block 82% or less with tuning.

A few critiques:

• The testing methodology for virtual patching wasn’t optimal.  The main tool that was used to test the efficacy of virtual patching was the same tool that created the virtual patching policies. This methodology is questionable because there isn’t variation in the way the vulnerability is tested from one scan to the next.  As a result, most WAFs and IPS products simply applied a single RegEx policy per vulnerability to remediate the way that the scanner looks for the vulnerability. In the real world, URL encoding and other evasion techniques could circumvent these RegEx policies in most cases, so relying on a single RegEx signature to block advanced attacks like SQL injection would result in a high rate of false positives or false negatives, depending on how one constructed the RegEx. Imperva imports vulnerability results from scanners, but then it applies its own security policies to stop vulnerabilities. Instead of simply relying on a single RegEx to mitigate a vulnerability, Imperva has developed advanced security engines that normalize and inspect Web requests. Imperva’s security engines score requests based on application profile violations, HTTP protocol violations, attack keywords, and attack signatures to correctly identify attacks. We believe that our approach is much more accurate, more difficult to evade, and less likely to generate false positives.  
  
  What is the proper way to test WAFs?  To test WAFs, you should NOT JUST generate attack traffic.  The most effective method would be to generate both attack and legitimate traffic. This approach makes it possible to test the ability of a WAF to detect malicious traffic and also to distinguish malicious traffic from good traffic. It provides a real world testing scenario in which the WAF must block attack traffic, and avoid blocking good traffic (i.e., generating false positives).

• Conflating WAFs and IPS.  According to a recent 451 Group market study (registration and purchase required) from August 2011, WAFs are the fastest growing segment in application security.  IPS vendors, hoping to get in the action, have begun to claim WAF-like functionality.  In reality, to secure Web applications, organizations must be able to stop technical attacks, business logic attacks, and Web fraud.
  • Technical Attack Protection (SQL Injection, XSS, Directory Traversal): Imperva SecureSphere offers advanced protection against technical Web attacks. SecureSphere normalizes data to protect against evasion techniques. SecureSphere can also defend against session-based attacks like cookie poisoning and session replay. IPS products must rely on RegEx signatures created by a scanner to stop technical attacks. These RegEx signatures would be easy to circumvent by using comments and encoding. In addition, an IPS would not be able to stop session or cookie tampering.
  • Business Logic and Automated Attack Protection (Scraping, App DDoS, Parameter Tampering, Brute Force): Web Application Firewalls like SecureSphere can protect against business logic attacks. An IPS product is not designed to stop advanced business logic attacks that could lead to a data breach or application downtime.
  • Web Fraud Prevention (Zeus, SpyEye, Gozi): The SecureSphere Web Application Firewall can protect against Web-based fraud caused by malware. An IPS cannot detect or stop fraud malware.

Other considerations when considering WAFs
In addition to security coverage, businesses must consider the operational aspects of deploying a Web application security solution. Businesses should evaluate the accuracy of the solution, ability to protect dynamic applications, monitoring, and management.

• Security Accuracy: Imperva has gone to great lengths to provide advanced Web application protection. Correlating Web profile violations with protocol anomalies, attack keywords and attack signatures greatly reduce false positives and false negatives. This is one of the main reasons why Imperva SecureSphere is a widely deployed Web application firewall—because organizations know they can trust Imperva to block attacks while limiting the number of false positives. Alternatively, the RegEx expressions created by an application scanner would generate false positives by triggering violations on any attack keywords.
• Protection of Dynamic Applications: SecureSphere can protect dynamic applications. In contrast, it would be difficult for a scanner to virtually patch Web application elements that are dynamically created—like dynamic URLs or restful applications.
• Monitoring and Forensics: Imperva SecureSphere provides detailed security alerts with the entire Web request, the server response code, and the user name of the attacker. It even shows the exact string in the request that triggered the violation. Comprehensive alerts, as well as a powerful reporting framework, make it easy for organizations to investigate Web application attacks. IPS products are not designed for Web application security and will not display the entire Web request in security alerts.
• Scalable Management:  Imperva SecureSphere offers centralized management. The MX Manager can centralize all policy control, application profile information, signature updates, monitoring and reporting for multiple Web Application Firewalls. For extremely large-scale deployments, Imperva offers the SecureSphere Operations Manager which centrally manages multiple MX Managers. Most IPS solutions are not designed for large scale deployments to protect critical Web applications.

Some interesting news from the healthcare industry:  There have been 355 medical data related breaches, involving 10,120,287 records that have been made public since 2010. 

However, the article highlights a survey showing that consumers are in fact pretty practical when it comes to electronic health records:

Despite all this bad news, a recent survey found that such occurrences probably won't temper the trust consumers have in data sharing or using electronic health records. According to a survey of 1,000 consumers conducted by the PwC Health Research Institute, 60 percent of respondents would be comfortable having their health data shared for improving overall care, 54 percent for improving decision-making in their care, and 36 percent to provide data for better analysis of doctor's performance.

That being said, security is a factor in the consumer's mind:

However, only 30 percent of respondents said, if factors such as cost, quality, and access were even among competing providers, clear security and privacy policies would impact their healthcare decisions.