We published a review of Parmy's book here.  One of our researchers, Nitzan, also read the book and summarized his key takeaways:

Some interesting security-related takeaways:

• At least in the first successful Anonymous DDoS attacks, it is estimated that 80-90% of the malicious traffic was generated using 1-2 big botnets, and just 10-20% of the traffic was generated by Anonymous “volunteers” using LOIC. The non-technical “volunteers” were not aware that their participation exposed their IPs, and Anonymous organizers often deliberately misled them about this.
• Attacks were initiated for various (and sometimes conflicting) reasons, including hacktivism (e.g. the struggle for Democracy in Middle-Eastern countries); AntiSec (anti WhiteHat security firms);  Fun (i.e. Lulz); Opportunities (found exploits); Ego wars (between hacker groups, and between hackers and security/media people); etc.
• Attacks by LulzSec, as opposed to Anonymous, were more coordinated and more harmful, as a result of the group’s structure: a small core of skilled and closely-cooperating leaders. Each participant contributed according to his skills set: vulnerability scanning; vulnerability exploitation; analysis of extracted emails & DB contents; PR; communication with supporters and hacking community.
• The most successful attacks were those in which a vulnerability was exploited undetected for a long period. The hackers could get deeper and deeper into the organizations data, get more and more information, and publicly announce the attacks only when they already extracted a massive data set and had found information that would draw a lot of attention from hackers & media.
• Interactions with other hackers were a major factor to the success (and eventual failure) of LulzSec. Often, exploits were sourced-out for verification; data was sourced-out for analysis; money contributions could be received and used for purchasing resources. Sometimes the entire attack was carried out by an outsider hacker, who just contributed its results for publication via LulzSec. 

From: http://thedoghousediaries.com/1757

Great column by Imperva's Tal Be'ery explaining why the LinkedIn breach exceeds 6.5M users.  The fun bits:

In the RockYou password breach , which now serves as the gold standard for passwords study, it was found that the uniqueness of the password was less than 50%, i.e. each password was used more than twice on average. Therefore, it’s safe to assume that the number of accounts directly hit with such hypothetical breach would well exceed the 10 Million mark. For this reason, we will use 10M as our approximation for the number of breach-able accounts.

Now let’s move forward with an estimate of collateral damage. How many friends did the directly hit accounts have? A naïve approach would be to multiply 10M by the number of the average unique friends each member has. It’s easy to see that if the number exceeds 16, then 10M breached accounts would span the whole 160M members of the social network.

Great piece from SearchSecurity:

The application security challenge has become so difficult to address through development, Krikken said, that he instead encouraged enterprises to consider an alternative strategy that relies less on developers and more on integrating defensive technologies – like Web app firewalls (WAFs), database audit and protection (DAP) products and XML gateways – into the enterprise application architecture. He said externalized components such as WAFs should be used in concert with code frameworks and platform features to fill in security functions.

Glad to see Gartner coming around this.  We've long argued that WAF and SDLCs are natural partners.

Once again, we hear rumblings of a "hack back" effort.  We blogged on this before and even provided a technical schematic.  The article explains:

Known in the cyber security industry as "active defense" or "strike-back" technology, the reprisals range from modest steps to distract and delay a hacker to more controversial measures. Security experts say they even know of some cases where companies have taken action that could violate laws in the United States or other countries, such as hiring contractors to hack the assailant's own systems.

A history lesson is due here.  There was a similar movement by the end of the 90s. It usually ended up with companies spending many resources to eventually either take down the computer of an old lady. Its not clear, given current crime landscape, how this could lead to actually thwarting the real perpetrators. There’s also the sad Blue Frog incident, in which a bunch of geeks didn’t realize that criminals have a tendency to violence even if they are cyber criminals.

What was the Blue Frog incident? They were an Israeli anti-spam company. They installed an agent on each client machine that would automatically follow the link on spam emails, effectively creating a DoS attack against those who use spam for advertising.  They went down in a big bang when spammers launched a devastating attack against their hosters and no hoster would support them.

Today, we released our latest Hacker Intelligence Initiative report, A CAPTCHA in the Rye.  We detail how are CAPTCHAs broken by hackers and what should security teams do to make them stronger yet appealing to consumers who intensively hate them.

Why would hackers want to bypass CAPTCHAs? What is the motivation?
CAPTCHAs are put in place to protect sites from automation of actions.  There are many types of hacker activities that are used to break CAPTCHAs, such as:

• Searching databases – a hacker may want to enable a user to search a database to see what you have and possibly download the contents.
• Adding comments on sites – a hacker may want to automatically add SPAM comments to all the posts in your site with links to, for example, websites with malware.
• Account creation – The site wants to prevent an automat from creating a lot of fake accounts to dupe legitimate users.

Is there specific website they target?
Hackers are often scraping websites that contain personal details. Some example that are presented in the report:

• Collecting financial details from online tax payment
• Collecting personal details from voting related sites, i.e., transactions or personal details etc…

What CAPTCHAs work?
Security teams should use novel CAPTCHA methods that make the CAPTCHA into something enjoyable, like a mini-game.  Also, we help identify how to present a CAPTCHA only when users exhibit suspicious behavior by implementing various automation detection mechanisms.

To download our report, click here (no reg required).

Lots of discussions on the shortage of security professionals.  One interesting symptom:  “In some cases, security firms have retaliated by refusing to send their most talented cyber experts on government jobs for fear of losing them. Instead they send their "B Team" consultants, Moss said.”

The same article predicts dire consequences according to Symantec CEO Enrique Salem, “it's going to be a bigger issue from a national security perspective than people realize.”

The premise is that labor is the key.  True but that’s not the complete picture.  The hacking industry has scaled via automation and crowd sourcing.   Why can’t security do the same?  In order to fill the labor and expertise gap, the security industry will need to focus on three things: 

1. Automation. A security solution that incorporates automation into its product; such as receiving 3^rd-party feeds and learning normal behavior, allowing the enterprise to spend time elsewhere.
2. Ecosystem. A solution that has a developed ecosystem.  For example, an ecosystem would allow the integration of 3^rd-party solutions.  In the past, a whole middleware industry was been built to bring enterprise supply chains together.  Security needs to go in the same direction but with an additional emphasis on information sharing about threats.
3. Self-service. A vendor that offers users the ability to query an online knowledge base and participate in vendor forums for resolving an issue.  Hacker forums were around long before the rise of social networks, good guys could learn from this example.

According to this, Chinese equipment makers have built backdoors into their hardware (which may be the root of Mr. Panetta's remarks).

First, a little perspective:  Most intelligent networking equipment, manufactured by almost any vendor anywhere in the past 20 years have been shown to contain some kind of a backdoor.  Master passwords for routers and secret technician codes for mobile phones or set top boxes have been published over the year (not to mention those secret key combination in Microsoft products that invoke flight simulator games).  This development begs two questions:

What percentage of infrastructure, civilian as well as military, is vulnerable to APT (enemy) shutdown?
The answer really depends on which country, what infrastructure and who is the enemy. In general large modern economies with decentralized infrastructure are less vulnerable. If you have twenty telcos, for example, each using equipment from 2-3 different vendors than the chances for a single blow by an adversary that controls a back door in the equipment of a single vendor are low.

What can companies do about it?
The “text book” mitigation strategy is indeed the use of redundant equipment by multiple vendors. This recommendation conflicts with the attempt to lower the costs of deployed system (as operating two different types of equipment by the same team is of course more costly). 

Research attributes nearly half of a typical website's traffic to automated bots. This puts the odds of falling victim to a cyber attack at 100%. With the press of one key, an unskilled, inexperienced hacker can attack hundreds of applications within minutes.

Automation tools, such as SQLMap and Havij, open new avenues for amateur and professional hackers to evade security defenses. How will your team prepare for, and stop, malicious, automated site traffic and defend against zero-day attacks?

This June 20th live webinar will:

• Highlight observed trends in the automation of SQLi and RFI attacks
• Reveal the warning signs of an automated attack
• Suggest identification methods and proven countermeasures to stop attacks

Register for Webinar

Download Report (below)

Imperva is proud to announce that it is collaborating with Cisco to host Imperva’s virtual WAF on the Cisco Nexus 1010-X virtual services appliance.  This joint solution will streamline deployment and management of the SecureSphere Web Application Firewall (WAF) in virtualized data centers.  

Today, SecureSphere WAF physical appliance is deployed by network/security teams.  However, deploying SecureSphere as a virtual machine requires that network/security administrator have access to VM management tools – to install the virtual appliance as a VM, upgrade SW and its overall lifecycle management.  This can have implications in terms of segregation of duties processes established in IT environments, for meeting compliance and audit requirements as well as to implement security controls.  Additionally, when the WAF virtual appliance is deployed with virtual workloads, CPU capacity planning must occur as VMs share the server’s CPU resources. Our joint solution is designed to provide the following customer benefits:

• Respect separation of duties between the network/security administrators and virtualization administrators as network/security team does not need access to VM management tools
• Offload security processing from virtual server clusters to the dedicated Cisco Nexus 1010-X appliance. 

Hosting SecureSphere on the appliance eases the deployment of networking and security services in a virtual environment. The Cisco N1010-X also includes high availability features such as restart-on-failure and device management tools that help maximize uptime and improve operations. As a dedicated hardware platform, the Cisco N1010-X will have minimal impact on the performance or the availability of virtual server clusters.  This solution is designed to enable organizations with virtual server environments to quickly deploy the SecureSphere Web Application Firewall on Cisco N1010-X without needing to re-architect their virtual server environment.

With virtual SecureSphere WAF hosted on Cisco Nexus 1010-X, customers continue to enjoy the benefits of protecting web applications and meeting PCI 6.6 compliance requirements while simultaneously simplifying deployment and lifecycle management in virtualized data centers.

 Availability of this join solution will be available in the fourth quarter of 2012.