Enterprise security in 2008: Building trust into the application development process


Enterprise security in 2008: Building trust into the application development process

Information security in 2007 stood out from previous years because of the growing commercialization of malware. The Storm botnet launched in January, for example, and it is now estimated to encompass anywhere

Continue Reading This Article

Enjoy this article as well as all of our content, including E-Guides, news, tips and more.

By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

Safe Harbor

between one and five million compromised PCs. There are strong signs that this infrastructure is now being split up and sold off as well. Botnets have been for hire for a while, but this year's malware smacks of a well-planned business strategy, and a very successful one at that.

Vendors unite!
To have any chance at taking the Internet back from the hacker community, enterprises must advocate for far better cross-vendor cooperation. At present, there are too many disparate, commercially motivated attempts to provide security products -- and the process isn't working. Unless security is seamless, hackers will exploit any gaps they find. The only way to close those gaps is for cooperating vendors to ensure that buyers can use different security products together knowing that they are compatible and work as promised across heterogeneous networks.

A good example of this problem is spam. It's a drain on Internet resources, organizational infrastructures and the average user's time, and could be dramatically curtailed with existing technologies if only the industry could agree on how to implement them. Two technologies have emerged to identify email senders: Sender Policy Network and DomainKeys Identified Mail. Both approaches have pros and cons, but unless one is adopted across the board, or better still, another method combining the best of both, spam will continue to devastate the Internet. Maybe it's even getting to the point where the problem requires a government mandate to unite all concerned parties in a common direction!

Keep your enemies close -- and your developers closer
Maybe 2008 will see a breakthrough in industry cooperation, but there is a major concern for the upcoming year that each organization will have to fight alone. As the evolution of malware becomes more commercial, competition amongst hackers will increase, and no stone will be left unturned when they look for ways to plant and execute malicious code.

Last month I wrote about the problems of cross-build injection, application attacks that insert malicious code while a program is actually being compiled. This emerging threat is an example of how hackers are looking at every aspect of the application development and deployment lifecycle, finding where they can take advantage of weaknesses to plant their code.

We know that security incidents are as likely to come from inside the network as from the outside. The internal attack vector, however, has to be taken seriously. The next step up from a "cross-build" type of attack is to "inject" a malicious developer into a software house. It could also be possible to subvert an existing employee. Disgruntled employees have long been a problem in various industries, including those of software. A rogue developer embedding malicious code into commercial products would be disastrous. A backdoor built into a killer app would be devastating.

Microsoft's sixth law of Immutable Laws of Security states that "A computer is only as secure as the administrator is trustworthy." The rule can also be applied to software and developers. Sadly, staff-vetting and monitoring are going to be a growing part of security policy.

Consider advocating for full background checks prior to employing new developers, and assessing these employees at periodic intervals thereafter. The checks must include temporary employees and contractors, too.

Separation of duties in network administration is commonplace, and a separation of coding duties is needed as well. Certainly code-review duties should be completed by a different set of developers. Diversifying a developer's tasks is a way of minimizing the opportunities to subvert the development process. On the upside, it can also make a developer's day more varied and interesting.

During 2007, we saw further evidence of the increasing sophistication of the hacker community. The ingenuity of many viruses and phishing scams is now on a par with any killer apps released by the IT industry giants. Fighting back against the new threats requires a reliable team, whether it's a group of cooperative vendors or a strong development staff of dependable members. The IT industry is as smart as the hacker community; it just needs to unite behind a common purpose.

About the author:
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Mike is the guest instructor for several SearchSecurity.com Security Schools and, as a SearchSecurity.com site expert, answers user questions on application security and platform security.

This was first published in January 2008

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.