Network security is arguably one of the most critical functions of IT – yet I frequently see organizations that have overlooked easily implemented security design practices. Here are a few common mistakes that could compromise your network defenses and put company assets at risk.
Note: This article is also available as a PDF download.
1: Set it and forget it
The first flaw I want to talk about is more a planning flaw than a design flaw. It involves what I like to think of as the “set it and forget it” mentality. This is what happens when organizations work hard to secure their networks without stopping to reevaluate their security plans again. The threats to security are constantly evolving, and your security architecture must evolve too. The best way to accomplish this is to reevaluate your security needs on a regular basis.
2: Opening more firewall ports than necessary
We all know that opening an excessive number of firewall ports is bad, but sometimes opening ports is unavoidable. For instance, take Microsoft Office Communications Server 2007 R2. If you are planning on providing external access, about a dozen ports must be opened. In addition, OCS 2007 R2 assigns a wide range of ports dynamically. So what’s a security administrator to do?
One of the best solutions is to make use of a reverse proxy (such as Microsoft’s ForeFront Threat Management Gateway). A reverse proxy sits between the Internet and the server that requires the various ports to be opened. While there is no getting around the need for open ports, a reverse proxy can intercept and filter requests and then pass them on to the server they’re intended for. This helps hide the server from the outside world and helps ensure that malicious requests do not reach the server.
3: Pulling double duty
With the economy in shambles, there is increasing pressure to make the most of existing server resources. So it might be tempting to host multiple applications or multiple application roles on a single server. While this practice is not necessarily bad, there’s a law of computing that states that as the size of the code base increases, so does the chance that an exploitable vulnerability exists.
It isn’t always practical to dedicate a server to each of your applications, but you should at least be careful about which applications or application roles are hosted on a single server. For example, at a minimum, an Exchange 2007 organization requires three server roles (hub transport, client access, and mailbox server). While you can host all three roles on a single server, you should avoid doing so if you are going to be providing Outlook Web Access to external users. The Client Access Server role makes use of IIS to host Outlook Web Access. Therefore, if you place the client access server role on the same server as your hub transport and mailbox server roles, you are essentially exposing your mailbox database to the Internet.
4: Ignoring network workstations
About a year ago, someone asked me during a radio interview what I thought was the single biggest threat to network security. My answer was, and still is, that workstations make up the single largest threat. I constantly see organizations that go to great lengths to secure their network servers but practically neglect their workstations. Unless workstations are locked down properly, users (or malicious Web sites) can install unauthorized software with untold consequences.
5: Failing to use SSL encryption where it counts
We all know that a Web site needs to use SSL encryption any time a user is going to be entering sensitive information, such as a username and password or a credit card number. However, many organizations make some bad decisions when it comes to securing their Web portals. The security flaw I see most often is including insecure content on a secure page. When this happens, users receive a prompt asking if they want to display both secure and insecure content. This gets users in the habit of giving Internet Explorer permission to provide insecure content.
A less obvious but even more common problem is that organizations often fail to encrypt critical pages within their Web sites. In my opinion, any page that provides security information, security advice, or contact information should be SSL encrypted. It isn’t that these pages are especially sensitive. It’s just that the certificate used by the encryption process guarantees to users that they are accessing a legitimate Web page rather than a page someone has set up as a part of a phishing scam.
6: Using self-signed certificates
Since some organizations completely neglect the importance of SSL encryption, Microsoft has begun to include self-signed certificates with some of its products. That way, Web interfaces can be used with SSL encryption even if the organization hasn’t acquired its own certificate yet.
While self-signed certificates are better than nothing, they are not a substitute for a valid SSL certificate from a trusted certificate authority. Self-signed certificates are primarily intended to help boost a product’s security until an administrator can properly secure it. Yes, a self-signed certificate can provide SSL encryption, but users will receive warning messages in their browsers because their computers do not trust the certificate (nor should they). Furthermore, some SSL-based Web services (such as ActiveSync) are not compatible with self-signed certificates because of the trust issue.
7: Excessive security logging
Although it’s important to log events that occur on your network, it’s also important not to go hog wild and perform excessive logging. Too much logging can make it difficult or impossible to locate the security events you’re really interested in. Rather than trying to log everything, focus on logging the events that are really meaningful.
8: Randomly grouping virtual servers
Virtual servers are commonly grouped on host servers by their performance. For example, a high demand virtual server might be paired on a host with a few low demand virtual servers. From a performance standpoint, this is a good idea, but this approach may not be the best idea from a security standpoint.
I recommend using dedicated virtualization hosts for any Internet-facing virtual servers. In other words, if you have three virtual servers that provide services to Internet users, you might consider grouping those servers on a virtualization host, but don’t put infrastructure servers (such as domain controllers) on the host.
My reasoning behind this is to provide protection against an escape attack. An escape attack is one in which a hacker can escape from a virtual machine and take control of the host. To the best of my knowledge, nobody has figured out a way to perform a real-world escape attack yet, but I’m sure that day is coming. When it does, your odds of prevailing against the attack are going to be a lot higher if virtual machines that are exposed to the Internet share a virtualization host only with similarly hardened Web-facing servers.
9: Placing member servers in the DMZ
If you can avoid it, try not to place any member servers in your DMZ. If compromised, a member server can reveal information about your Active Directory.
10: Depending on users to install updates
One last common security flaw is depending on users to deploy security patches. I have seen several network deployments recently that use WSUS to patch network workstations. Unfortunately, many of these deployments rely on the users to click the option to install the latest updates. The problem with this is that the users know that the update process is going to require them to reboot their computers. Some users may end up putting off the updates indefinitely. Rather than relying on the end users, use a patch management solution that pushes security patches automatically without giving users a choice in the matter.
