While I agree in theory with the recent eWeek editorial, “Its Time to Abandon Insecure Languages,” I think IT managers will have to do something about insecure Web sites, applications and network infrastructure before ISVs and code jockeys finally decide to produce applications and devices that are designed with security in mind.
My recommendation, based on a number of conversations with mainly front-line IT specialists, along with reading a large number of security-oriented product pitches and books, is to focus on procedure.
In the just released book, “Hacking Exposed, Web Application Security Secrets and Solutions,” by Joel Scambray and Mike Shema ($49.99 in paperback, from McGraw-Hill/Osborne, the authors begin by discussing reconnaissance, in the now-classic approach of anti-hacking books. In much the same way that every book Ive read about TCP/IP starts out talking about the seven layers of an IP protocol stack, this book starts out with a basic discussion of how Web applications are architected and how they work. (You can read my complete book review here.)
My point is that IT managers actually need to focus on putting a basic security plan in place because products, in general, have been written first of all with performance in mind. And with almost no outside regulation (meaning laws and rules that set standards for performance), software and hardware makers have developed some very risky behaviors. They get away with these risky behaviors because productivity gains from using their products outstrip losses due to faults or leaky security.
But lately, losses caused by poor security have been nipping at the heels of productivity. Even this state of affairs wont motivate IT suppliers until, as eWeeks editorial quite rightly points out, companies start to vote with their pocketbooks. However, as any junkie knows, its hard to come clean after years of bad habits.
And thats why savvy IT managers should bring the security focus back to what Ill call procedure-based security. The tenets are quite simple—some of them can be automated, but most still require a high degree of human involvement.
First, know the organizations business processes. Its impossible to design cost-effective security plans if IT doesnt know whats worth protecting, and what it costs not to protect the network.
Second, know the network. Use reporting tools to get an accurate picture of the network as it functions normally. There are a number of tools that use anomalous behavior to nail bad actors.
Third, involve several curious people. Put people who ask thoughtful, mildly paranoid questions in the security team. And make it a requirement that these people rotate duties, so that the cycle of “fresh eyes” is at least every three months.
Fourth, vote with the organizations wallet. Insist that software and hardware be designed so that patches, when needed, are well-managed and straightforward to install.
Is your security procedure more involved than a call to 9-1-1? Senior Analyst Cameron Sturdevant can be contacted at [email protected].