While accepting that it is pretty near impossible to write applications that at some stage in the future will not fall prey to some clever new attack model, should we not expect a better performance from organizations that make a living from advising the rest of us on how best to improve our own IT security?
In its introduction, Qualys was surprisingly generous in its defense of the quartet, when admitting that finding four fellow security companies on its top-five hit-list came as no surprise, as most security products were written when attacks focused on vulnerabilities in system software. Perhaps a ‘there but for the grace of God go I’ approach applies here!
Today, it is clearly the case that significantly more security attacks focus on applications, and, as many security products have an operational need to run with very high privileges, they themselves have become prime targets.
Microsoft, which incidentally does not feature very prominently in this week’s vulnerability list, has for some time been preaching the mantra that secure programming skills are now far more valuable than programming skills alone, and this is something that the security industry as a whole needs to get a handle on. Sadly, many of our higher educational institutions continue to turn out computer science graduates and technologists without the skills to address the requirements of secure coding techniques, and therefore industry continues to bear the brunt of this skills shortfall.
Furthermore, at a business level, organizations still seem to have little in the way of opportunity to identify whether the applications that they choose to purchase have been developed using secure coding techniques. This is an area that must be pushed a lot harder.
After all, in the security arena many of our leading suppliers of security solutions are quick enough to tell us how well and efficiently they have integrated the latest set of third-party-acquired applications into their protection portfolios. Should they not also be telling us what steps were taken to ensure that new vulnerabilities were not introduced at the same time, and how any new products measured up to their own, hopefully, exacting security standards?
Interestingly, there are some things that organizations can do for themselves to improve the situation. They can, for example, choose to work with companies such as Fortify and others whose security products help to drive down development and application risk by providing software audit, development code testing, penetration testing, and deployment control processes.
The SANS and Qualys @RISK threat vulnerability newsletter highlighted the fact that no one is immune from common developer-generated vulnerabilities such as processor buffer overflows, remote code execution, and ActiveX control buffer overflows. Going forward, as technology qualifications move towards including security skills as a prime area of accomplishment – as they surely must – you may want to ask prospective vendors and service providers how well their technologists fared; after all, it is they that are making these people’s expensive skills available for hire.
Source: OpinionWire by Butler Group (www.butlergroup.com)
