Friday, 11 June 2010

The return of the Proof of Concept hack

This week’s news of a breach at the AT&T network, which exposed 114,000 accounts of the recently launched iPad, is today an FBI investigation. The group that identified the breach is known for publicizing other weaknesses that can lead to breaches, such as Safari and Amazon.

The compromised accounts – which include some of most powerful people on the planet – will likely suffer no long-term effects. The point of this attack was not to gain access to specific accounts, but to show that a breach of this sort could be done. It is, therefore, more like the proof of concept attacks that were popular 10 years ago. The goal of a proof of concept attack is notoriety for the hackers and embarrassment for the company involved. What is encouraging is that the FBI is taking investigative action. Only when there are severe consequences associated with proof of concept activities will they cease to be an issue

Tuesday, 4 May 2010

The US Treasury Trail

News is emerging of a hack at the US Treasury Department, in which a series of websites associated with the U.S. Bureau of Engraving and Printing (BEP) were affected.

Visitors to the sites were directed to another site in the Ukraine, one that is notorious for installing malware on computers.

The attackers targeted a cloud computing company that hosted the BEP’s pages.

This hack has the elements for a good press story because it involves a government agency, the Ukraine and the cloud environment. But, these elements are not newsworthy.

US governmental sites have been under attack for the past year, and these prior attacks should have been a call to action for all federal and state IT departments to review their security policies and practices.

The hackers’ purported destination of Ukraine is also not newsworthy.
Hackers will not attempt access in their own country but will target foreign sites, knowing that the likelihood of prosecution is slim to none.

That this happened in the cloud is also not a news hook. Cloud environments are no more or less safe than any other environment. Agencies putting their information in the cloud should know the security measures and practices involved.

What is newsworthy? The fact that there are still questions about the number of people affected and even whether all of the affected sites are disabled is disturbing.
All organizations, especially government agencies, should have a disaster recovery plan in place in the event of a breach. This plan should include informing those involved with the basic details of what happened, who was affected, and what people should do.

The reality is likely that the US Treasury is looking to answer those questions now, which comes too little too late.

Monday, 19 April 2010

No surprises in the OWASP 2010 tail – Injection remains the number-one stinging risk in 2010

OWASP have released their 2010 “top 10” Application Security Risks. Topping the list (again) is the “Injection” risk. People involved in both application security and database security will not be surprised. The world is awash with applications that have each been poorly engineered in their own individual manner. It is an easy mistake to make, but very difficult to rectify without good tools and technologies to deploy.

Comparing this year’s results and those from 2007 shows that the top three risks remain unchanged 1. Injection; 2.0 Cross-Site scripting (XSS); 3. Broken Authentication and Session Management. New entrants to the list are: Security Mis-configuration, ranked sixth, and Un-validated Redirects and Forwards coming at the bottom of the list.

It is interesting that security mis-configuration is a rising risk. It seems that system owners are at least trying to use security features, but are failing to get it correct. Getting any security system just right without disturbing the business is notoriously difficult.

Even more difficult is retrofitting security into an enterprise application environment which has a complex array of components – each tailored to the business. Good application security requires strong knowledge of the application operation combined with the ability to accurately prevent (or block) out-of-policy interactions. For example, the protection of a database from a poorly written web facing application requires a firewall that can determine that a query is inappropriate and stop it from ever reaching the database.

One does not need a crystal ball to forecast next year’s winner of the list!