Continued from Page 1.

Applications: What's under the hood?

Many organizations have learned that writing your own applications can save lots of money. New languages exist that bring interoperability to an entirely new level. With the ease of deploying Web-based apps and all the money being saved by not hiring consultants, what is the downside?

Well, I will tell you: application testing.

If we look a little closer, there are three factors that drive the development process:
  1. Tight timelines
  2. Developers who don't take security in account while writing code
  3. Interfacing with legacy apps
Add these up and you get a recipe for a security nightmare.

The truth of the matter is that the primary concern of many developers is whether the application works. Adding security adds time to the development cycle, and that in turn has a snowball effect on the entire initiative.

The point I try to make to application development groups is that your product, through interoperability, now has the capability of serving a much larger audience. This means that with increased exposure, the likelihood of a bug to surface grows exponentially.

Taking it one step further, the bug may turn out to be a gaping security hole, which will ultimately make its way back and the stigma will be attached to the entire development team. Buffer overruns, overflows and underruns are only the tip of the iceberg. The more portable languages and technologies are mixed in the pot, the greater the volatility of the final product.

Few take the time to understand how all of these technologies interact. True, they may present a pretty interface and a hip user experience but at the end of the day, this might be the exact recipe for your exit interview.

The solution is to audit these applications. Much more time has to be allotted for security audits and cross platform testing. This is a very large undertaking because there are many levels to address, so don't give up if the idea doesn't stick the first time around. Also keep in mind that security testing has to remain flexible because not every application or development initiative is the same.

Like I've said before, classic computing models and procedures are dead and this means classic development cycles are dead too. Until this issue is addressed, you'll find many organizations broken down on the side of the information superhighway wondering why their application has stalled out.

Wrapping up

The truth of the matter is that many important areas of network security are overlooked. Trying to pinpoint a mere two or three is very difficult. Network security needs to remain an elastic blanket that covers you based on your business model and its changing needs.

Network security is meant to be practiced, not advertised. How do you begin addressing it properly? Sit down and understand your business model. Identify how data is exchanged. Identify who will be responsible for your security practices.

Be sure that you integrate solid security practices within all of your development cycles. If you begin with these things, solid network security will begin to grow and before long will be a cornerstone of your organizational practices.