email article printer friendly more resources

Dispel 7 Common Security Myths
Knowing the truth about security myths in the enterprise will enable you to avoid making costly mistakes.
by Thomas Wagner

September 2002 Issue

For this solution: .NET SDK

In today's hyper-connected world it's easy to get bombarded with questionable information. As you attempt to establish a secure network for your enterprise, you're apt to filter through a tremendous amount of fiction before you arrive at the best solution. Unfortunately, some of these untruths become myths, and spread through the IT industry until they're considered common knowledge. This wreaks havoc in the businesses that buy into these popular beliefs. Think of these pieces of inaccurate information as verbal viruses, and you'll get the idea of their potential harm.

In this article, I'll address seven popular myths and will explain what you can do to combat them. I'll cover how to set up a defense strategy and the potential security impact prevalent new technologies such as Web services and the Microsoft .NET Framework have. With this knowledge, you'll be better equipped to avoid making costly mistakes. I'll also cover a vulnerability that's rarely acknowledged: a company's own employees.

Myth #1: Unix systems aren't as susceptible to hackers.
Fact: Any code platform is susceptible to attacks. This myth about Unix systems is a case of "the grass is always greener on the other side," and most likely originates with Windows network administrators. The Windows platform is a popular and well-publicized target of hackers, so it's understandable that a beleaguered admin might assume Unix-based systems are less susceptible. However, in truth, any machine on a public network, along with its installed software, is a potential target.

You can categorize software into one of two groups—operating systems (OS) and applications—and both groups are susceptible to different types of attacks. OSes are most often made vulnerable when core modules are built incorrectly and the modules fall victim to buffer overflows. Hackers can execute this type of attack against any code base, regardless of whether it's Unix, Windows, or Linux. Attacks on the OS are especially frustrating to you as the customer, because you rely on the OS manufacturer to supply a patch or another resolution.

It's even more common for attacks to be directed at specific applications. For many years application developers believed they could control the parameter information that's passed into a method call and how the method is called, and, therefore, didn't need to double-check the content of the parameters as they are being used by the method. In these developers' defense, until recently, this method sufficed. However, the interconnected nature of today's networks makes it crucial for developers to ensure an application's security. If you manage a development team, you need to make sure your team verifies the contents of variables as they're processed. This requires more up-front design, increases the scope of a project, and frequently impacts the performance of the code itself; but it's the only way to ensure hackers don't change the variable content of ABC to XYZ. Your team must assert the information by traversing various method calls to verify that what is at the end of the method is what it was expected to be.