Test your products before deployment. So writes Juha-Matti Tirilä, security researcher, Codenomicon Ltd.
Bugs are more than a nuisance; they are a hole in your security through which hackers can access your systems. The number one security threat is not a malicious attacker, but poorly managed development processes. Technologies are increasingly complex, and at the same time release cycles are not only faster, but also more complicated, involving outsourcing. The later testing is carried out, the more difficult it is find the problem. And, the later you test, the more expensive and less thorough the fixes are. So, to test effectively, test proactively.
It is not always clear what you need to do to be properly prepared for security threats – with the growing market of add-on security products aiming at making us pay for the comforting feeling of being secured, one should be aware that the biggest danger lies within. It is not that systems are purposefully left insecure, with the intention of adding security armour around the product afterwards, but rather; they accidentally and invariably turn out that way. Companies offering software-operated products must understand that security is something that has to be built into the product from the ground up; the most common source of exploitable vulnerabilities is the ever-abounding population of software bugs. Yes, just the programming mistakes, that many think of just as development-phase nuisances or quality issues at worst, are the ones that leave the back door open for intruders.
Understanding the nature of built-in vulnerabilities is also the key to understanding why off-the-shelf add-on security solutions can not truly secure systems from attackers. What makes those hiding bugs so dangerous is that they are frequently only discovered after product deployment and delivery. In contrast to flaws discovered before release, vendors are unaware of these unknown bugs, and are therefore not prepared to provide fixes for them. Attackers are constantly looking for such holes. When discovered by hackers, these vulnerabilities are used in exploits that are invariably able to bypass intrusion detection and prevention systems by virtue of their novel nature – their characteristics are unknown to security mechanisms so there is no one to stop them. Such a suddenly emerging threat is called a Zero Day Vulnerability, and what companies practicing solid and well managed security measures at all phases of production, aim for is that day ‘0’ should never dawn!
It is important to understand that the bug peril not only affects companies building software, but also the next layers in the food chain, reaching out to end customers. As soon as buggy software hits the mass market, the time bomb is ticking: when someone or something makes the flaw surface, the race is on between the vendors and attackers. Exploitation implies cost, and this is enough of an incitement for attackers. Vendors, being well aware of this race, have to rush with writing and deploying fixes, and this process subjects involved parties to many dangers. What follows may be downtime, impaired QoS, exposure of confidential material, or incomplete and hard-to-employ patches that, in the worst case, also introduce new attack angles in the form of new bugs! The list goes on. And, this cost is not only inflicted upon the vendor who provided the software, but also on their customers using the programs.
It really is this simple: the earlier vulnerabilities are discovered, the easier and cheaper they are to fix. With pure software products, the difference in the price of a bug found during development and a bug found only after the release is already significant, however, the more complex the product in which the software is used, the bigger the price difference. Just think about the recent car recall programs as an example. New security processes should not be frowned upon as an extra cost, but rather welcomed as cost savers. Proactive testing is an investment that will pay for itself. By testing your systems proactively, you can avoid security related issues later on during the software life-cycle.
While robust security testing, immediately before deployment, does prevent vulnerabilities from being delivered to the market, it is just the first step in the right direction. Whether the product is pure software or a hardware system relying on software components, robustness testing should be an integral part of development as early as possible. Production phase processes, as such, have dramatically improved over the years, for example, broader perspectives on Software Development Life Cycle have sanitized many aspects of programming management. The same goes for hardware manufacturers. However, instead of just looking at the product life cycle from a feature oriented perspective, the developers must also consider products’ security life-spans, and perform the appropriate security and robustness checks at each phase. Therefore, security testing procedures must not be seen to live in a domain separate from product development, but should be considered an integral component therein.
So, don’t ignore those annoying little bugs. That way only the hackers win. By testing your software proactively, you are able to produce better, safer software making your customers, and ultimately you, the winner.
Note
Codenomicon is exhibiting at Infosecurity Europe 2011, an information security event from April 19 to 21, at Earl’s Court, London. The event provides a free education programme, with exhibitors showcasing technologies. For further information visit –
