The classic network model of the roaring nineties is long gone. Many people still talk about "inside" and "outside" the firewall in relation to viruses, worms, Trojans and virtually every other threat. This is an immediate sign that you're dealing with a rookie.
Why? Well the answer is simple: the VPN.
Virtual Private Networks (VPNs, define) are a top technology where important security concerns are often overlooked. VPNs blur the lines of where network boundaries begin and end. Sure, companies spend millions on familiar antivirus products, but rarely do they overspend to understand where new threats may be breeding. And since VPN technology has only recently proven its utility, many organizations are rushing to drop it in. This creates two areas of concern.
Unfortunately, most IT shops don't have a dedicated security team to call on for answers so the senior technician is tasked with understanding technologies that can fill entire four-year degree programs. VPNs open your organization to a new league of threats.
But all is not lost.
There are several things that can be done before you find yourself in a crisis. The first is to understand how your VPN extends the network. Do this by testing the features you want to use in a lab environment. See if viruses can pass through the device from an infected home user or contractor. Find out if it uses standard protocols or if it has vendor specific protocol sets and the implications of each. Test how traffic flows and how you can manage it.
Pay close attention to split tunneling, that is, can the users connect to your organization while at the same time connect to the open Internet or other hostile networks. Be sure your solution allows for client side policy enforcement. This is the biggest and most important feature of any VPN solution because you can effectively force VPN users to have a certain level of protection before entering your organization.
Finally, "blackbox" test the solution. Throw everything but the kitchen sink at it to see how it holds up. You will be surprised how many big name products overlook security issues while in a rush to get their product out to market. Once you sort these things out, see if you can mold the device to your current security policy. If your policy doesn't address these concerns, you'd better get one in place that does.
Remember, classic computing models are dead. You have to adapt your current practices and policies to fit the new face of network computing.
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:
- Tight timelines
- Developers who don't take security in account while writing code
- Interfacing with legacy apps
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.
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.