Don’t patch it, it’s fine?

I wrote back in 2013 about my shock at discovering that the companies are now publicly calling to stop the investment in security and avoid fixing security bugs in my article Brainwashing in security. There, we witnessed the head of Adobe security, Brad Arkin, tell us that the companies should not be wasting their precious resources on “fixing every little bug”, agreeing to the comment made by another participant, John Viega from SilverSky, that:

“For most companies it’s going to be far cheaper and serve their customers a lot better if they don’t do anything [about security bugs] until something happens.”

All right, fast forward three years and Adobe becomes a showcase. Here is what Google senior security engineer Darren Bilby, speaking at the Kiwicon, has to tell us about the security of the contemporary software:

“We are giving people systems that are not safe for the internet and we are blaming the user,” Bilby says.

He illustrated his point by referring to the 314 remote code execution holes disclosed in Adobe Flash last year alone, saying the strategy to patch those holes is like a car yard which sells vehicles that catch on fire every other week.

The security strategy at Adobe is clearly paying its dividends. Way to go, Adobe, way to go…

 

Google bots subversion

There is a lot of truth in saying that every tool can be used by good and by evil. There is no point in blocking the tools themselves as the attacker will turn to new tools and subvert the very familiar tools in unexpected ways. Now Google crawler bots were turned into such a weapon to execute SQL injection attacks against websites chosen by attackers.

it_photo_76483_200x133The discussion of whether Google should or should not do anything about that is interesting but we are not going to talk about that. Instead, think that this is a prime case of a familiar tool that comes back to your website regularly subverted into doing something evil. You did not expect that to happen and you cannot just block the Google from your website. This is a perfect example of a security attack where your application security is the only way to stop the attacker.

The application must be written in such a way that it does not matter whether it is protected by a firewall – you will not always be able to block the attacks with the firewall. The application must also be written so that it withstands an unanticipated attack, something that you were not able to predict in advance would happen. The application must be prepared to ward off things that are not there yet at the time of writing. Secure design and coding cannot be replaced with firewalls and add-on filtering.

Only such securely designed and implemented applications withstand unexpected attacks.