In the last year, there have been a number of organisations offering rewards, or “bounty” programs, for discovering and reporting bugs in applications. Mozilla currently offers up to US$3,000 for crucial bug identification. Google pays out $1,337 for flaws in its software. Deutsche Post is currently sifting through applications from “ethical” hackers to approve teams who will go head-to-head and compete for its Security Cup in October. The winning team can hold aloft the trophy if they find vulnerabilities in its new online secure messaging service—that’s comforting to current users. Are these incentives the best way to make sure your applications are secure?
No. These sorts of schemes are nothing short of a publicity stunt and, in fact, can be potentially dangerous to an end user’s security.
Inviting hackers to trawl all over a new application prior to its launch simply grants them more time to interrogate it and identify weaknesses, which they may decide are more valuable if kept to themselves. Once the first big announcement is made detailing who has purchased the application, with the time and location the product is to go live, the hacker can use this insight to breach the system and steal the corporate jewels.
A further worry is that while on the surface it may seem that these companies are being open and honest, if a serious security flaw were identified, would the developers raise the alarm and warn people? It’s my belief that they’d fix it quietly, release a patch and hope no one hears about it. The hacker would happily claim the reward, promise a vow of silence, and then “sell” the details on the black market, leaving any user with a great big security void in their defenses just waiting to be exploited while the patch is being developed, if the patch even succeeds at all.
Sometimes it’s not even a flaw in the software that can cause problems. If an attack is launched against the application, causing it to fail and reboot, then this denial of service attack can be just as costly to your organisation as if the application were breached and data was stolen.
A final word of warning is that, even if the application isn’t hacked today, it doesn’t mean that tomorrow they’re not going to be able to breach it. Windows Vista is one such example. Microsoft originally hailed it as its most secure operating system it’d ever made, and we all know what happened next.
As we all know, IT is never infallible. That’s why penetration testing is often heralded as the hero of the hour. However, penetration testing has moved on and, while still valid in certain circumstances, historical penetration testing techniques are often limited in their effectiveness.
Let me explain: A traditional test is executed from outside the network perimeter with the tester seeking applications to attack. However, as these assaults are all from a single IP address, intelligent security software will recognize this behavior. Within the first two or three attempts, the source address is blacklisted or firewalled, and all subsequent traffic is seen and treated as malicious.
There isn’t one single piece of advice that is the answer to all your prayers. Instead, you need application testing combined with intrusion detection, both working in harmony to achieve a secure system.
The reason I advocate application testing is, if you have a public-facing application that’s been compromised, the financial impact to the organization could potentially be fatal. There are technologies available that can test your device or application with a barrage of millions upon millions of iterations, using different broken or mutated protocols and techniques in an effort to crash the system. If a hacker were to do this and caused it to fall over or reboot, this denial of service could be at best embarrassing but at worst detrimental to your organisation.
Intrusion detection, capable of spotting zero-day exploits, must be deployed to audit and test the recognition and response capabilities of your corporate security defenses. It will substantiate that not only is the network security deployed and configured correctly, but also that it’s capable of protecting the application that you’re about to make live or have already launched, irrespective of what the service it supports is (be it e-mail, a Web service, anything).
The device looks for characteristics in behavior to determine if an incoming request is likely to be either good and valid or malicious. This provides not only reassurance, but also all-important proof that the network’s security is capable of identifying and mitigating the latest threats and security-evasion techniques.
While we wait with baited breath to see who will lift Deutsche Post’s Security Cup, we mustn’t lose sight of our own challenges. My best advice would be that, instead of waiting for the outcome and relying on others to keep you informed of vulnerabilities in your applications, you must regularly inspect your defenses to make sure they’re standing strong with no chinks. If you don’t, the bounty may as well be on your head.
Anthony Haywood is the CTO of Idappcom, which makes IT security and application security tools.
