email article printer friendly

Managing for Security
Set up a life cycle for security to make your enterprise proactive in protecting applications and data
by Peter Varhol

August 2003 Issue

Security of applications and infrastructure is uppermost in the minds of most enterprise IS professionals. Yet the largest burden is placed on the IS professionals charged with keeping the application running and serviceable in production, in part, because the IS infrastructure itself—the networks, servers, and especially clients—are a primary source of security breaches. These battles are fought typically by IS operations staff, who have little control over either the incursion or those who left the door open.

Another part of the burden is because security, even today, is usually an afterthought that doesn't make it onto the radar screen until the application is nearing deployment. Security is rarely called out in user requirements, and architects and developers are not anxious to make work for themselves that doesn't contribute to fulfilling those requirements. Unless it is a standing directive that security be part of all custom application work, little more than cursory thought is given toward constructing an application that is safe from illicit manipulation.

But with this strategy enterprises will always be behind the power curve when it comes to handling malicious intent. Those charged with protecting data assets or application integrity lack knowledge of specific vulnerabilities and are faced with managing security based on incomplete information, which often leads to poor choices on balancing security versus accessibility, and these choices result in poor usage models or badly secured applications. Architects or developers will always give at least some thought to security in application development, but much of it is forced on the process by external dependencies. For example, databases are almost always at least password protected, so applications have to perform at least basic authentication before gaining access. However, in at least some cases the database username and password are poorly protected. They may be contained within a client-side script, or passed across the network in the clear.

Problems like these won't be found unless the IS staff conducts a security audit before the application is deployed to the production systems, or until the password is stolen and the database compromised or corrupted. In either case, the damage has already been done. If the problem is discovered in an audit, the application will have to go back to development for repair, which is a much more costly proposition than if it had been built right the first time. If the problem becomes uncovered as a result of an attack, then the theft or destruction of data will come with the cost of hard cash or equally hard-won customer goodwill.