As president and lead security specialist of a company that performs security assessments for a wide variety of organizations, I often see the same issues over and over. So I'd like to share with the Ars audience the top 10 most common security problems I see on a daily basis, along with some tips on how to address them.

1) Monolithic Network

A monolithic network is one where all devices are on a single physical and logical network. Most small- and medium-sized businesses are set up in this way, usually for the sake of making things easy. The problem with this arrangement is that any one vulnerability exposes the whole network to further compromise. When combined with the common (but mistaken) stance that internal networks are fundamentally distinct from external networks, a monolithic network can be particularly risky.

In today's security world, there is no longer a clear distinction between internal and external networks. The more modern client-side and web-based attacks make even the best perimeter defenses useless. As such, it's important to act as if every piece of your network is as vulnerable to outside attacks as the machines currently sitting outside your firewall.

So how does one go about addressing this problem? Well, 99 percent of the solution lies in planning and research. First, start with a firewall. A well-segmented network should not have any two segments touch through anything but the firewall, which means that each segment needs a separate interface on the firewall. Many smaller IT shops know firewalls only as 2- or 3-sided devices that separate public, private, and maybe DMZ (demilitarized zone, a protected place for public servers). But what you really need is something with as many interfaces as you can afford. Many commercially supported firewalls come in relatively cheap 8 port configurations, but you can always load up an old PC with as many ethernet cards as it can hold (quad port cards help in these cases) and install a linux- or BSD-based firewall. Whichever option you choose, be sure that the hardware is reliable, because it will be a single point of failure for your network.

Once you have the hardware lined up, the first part of the planning process is to draw lines in the sand. This will differ for each organization, but make a list of every device on the network, and categorize them into departments, functions, and security needs. Segmentation should happen along these lines, separating groups from each other. Almost always, you'll want to have an administrative network segment, which is where all the administrative interfaces for servers, routers, firewalls, printers, and the like should be pointed.

The second part of planning is research and testing. Before you make any real changes, you need to know exactly what devices communicate with each other and over what ports, and what sort of traffic will be moving through them. This step, while enormously time-consuming and sometimes frustrating, will give you insight in to your network that you've never had before. By forcing all traffic to flow through a firewall (and thereby having to create rules to allow it to do so), you gain an incredible amount of knowledge about how your network actually works. An added bonus is that you'll likely find things running that shouldn't be, or you'll uncover things that have been long forgotten.

Once it is all said and done, you should have a network that is bundled in to nice, neat packages. You should now have hugely improved visibility, along with the tools to control traffic like you've never had before.

So, how does this make you more secure? Well, if your firewall has an integrated IDS/IPS (intrusion detection/prevention system), almost any attack traffic will be forced to pass over it, which will give it a much higher chance of being detected. Should something actually get past the firewall, the compromise will be contained within the network segment where it occurred, which makes it much easier to identify and clean up.

2) Patching

Despite all the awareness around patching that popular tools like Microsoft's Windows Update have created in the last several years, it seems that some people still don't get it. While I do generally find that the majority of Windows PCs are up-to-date on patches, most other systems are often left behind. This generally affects legacy systems (that old PC in the corner running some ancient piece of software that people still use once a month or so), but the problem is also rampant in infrastructure devices.

The common thinking (especially concerning infrastructure and extraneous devices like printers) is that patching is either unnecessary, or that the device is too critical to risk bringing down in order to do regular patching. Often, people take the attitude of, "I'll patch it if it fixes a problem that immediately affects functionality," which is unfortunate.

There are also common misconceptions about the power available to an attacker in devices like printers and other embedded devices. Most people think that printers and the like are relatively simple machines that don't have anywhere close to the capabilities of a normal desktop PC. In reality, many of the newer printers run full operating systems (often Linux or VXWorks), which have vulnerabilities just like Windows or any other desktop OS. What's more, these devices are often in the best position from an attacker's point of view, because they don't get patched unless they're broken, and they don't get monitored for malicious traffic in the same way that client and server PCs do.

The real issue here is to be consistent. Include all devices in your patch management cycle (however limited it may be). Printers, routers, switches, wireless APs, and legacy machines all have vulnerabilities, just like clients and servers. In most cases, the damage that can be done by leveraging smaller devices in a network is equal to or great than it would be if a PC was compromised. Unfortunately, the options for securing an embedded device are more limited than those available for a PC, so keep them patched to avoid trouble.

3) RDP

One of the protocols I like to use as an example when discussing man-in-the-middle (MITM) attacks is Microsoft's Remote Desktop Protocol (RDP). For those unfamiliar with it, RDP is a client and server application and protocol that's used to remotely control the desktop of a Windows machine. Quite often, RDP used by IT departments to administer servers, and to provide remote help to employees. The problem with RDP is that, by default, it sends data in the clear. As such, anyone sitting on the local network is able to sniff traffic and recover the credentials used to make the RDP connection. In bigger shops, these credentials are often tied to directory systems, which mean that a set of valid administrator credentials will work over the whole network of machines.

To an attacker, this is gold. All an attacker has to do after compromising one machine is to wait for an administrator to do some maintenance work (a creative attacker would probably create a problem for the administrator to go check on) and harvest the credentials.

Microsoft has a page describing how to wrap RDP in an encryption layer like SSL or TLS, but that only prevents a MITM attack should the end user actually heed warnings about bad certificates when they come up. In the long run, I usually suggest that people look for an alternative to RDP that best fits their needs and doesn't have the inherent security issues. Most of all, disable RDO if isn't being used, and if it does absolutely need to be used, wrap it in encryption, and keep in mind that someone may be watching.

4) Telnet and SNMP

It amazes me that, in this day and age, we're still relying on telnet to administer devices. Just like RDP, telnet sends all data in the clear, which means that an attacker who is listening on the local network is able to read credentials without an issue. The problem today is that many devices still ship with telnet enabled, and often don't give the option of using SSH (a secure alternative to telnet).

For any devices you may have that use telnet, be aware that any communications which use that protocol are completely insecure. Disable telnet if possible, and replace it with SSH. Where it can't be disabled, use a password that's different than you use anywhere else.

Another common weak point in networks is SNMP (simple network management protocol). Many infrastructure devices like switches, routers, firewalls, and wireless APs have it enabled by default so that administrators can monitor the devices and keep track of utilization. From an attacker's point of view, SNMP is a great resource for information. Aside from statistics about network and device usage, SNMP usually also offers up system software versions, installed software information, and sometimes more. But that's just the tip of the iceberg. There have been a slew of SNMP-related vulnerabilities where administrative passwords can be retrieved, full device configurations can be pulled, and, in some cases, settings can be changed without authentication.

As with everything else, disable it if you don't use it. If you do use it, secure it properly.

5) Administrative Interfaces

If your secretary can pull up a browser and get to the web interface of your router, firewall, or switch, you're doing something wrong. While the administrative interfaces of these devices should be password protected, there have been many cases where this authentication can be bypassed by other vulnerabilities. Given the extremely low rate on average at which patches get deployed for these kinds of devices, there's a pretty good chance that some significant vulnerability will be present on your network for a long time before it gets dealt with.

One very simple principal in security is that of "least privilege." In a nutshell, this principle states that all users should operate with privileges to access exactly what they need, and nothing more. When executed properly, "least privilege" minimizes the risk of any one vulnerability being exposed. In practice, this means that an access list should be set up on the devices in question, and only administrative workstations should be allowed to get to the administrative interface. Proper network segmentation gives you an additional layer of control over this, by allowing the access list to be enforced before the device even gets involved.

I particularly like devices which allow me to move an administrative interface to a different VLAN. This way, I can collect all of my administrative interfaces on one VLAN, and watch them closely. Of course, I don't rely on this one layer of security alone. I also set lengthy passwords on all interfaces and rotate the passwords regularly. This might be a bit excessive for some organizations, but I believe that the administrative interfaces of servers and infrastructure devices represent the single biggest lump of power over any given network, and they should be protected as such.

6) Wireless

Proper wireless network (802.11a/b/g/n) security is quite simply out of reach for most organizations. Unless you have the resources to implement WPA2 Enterprise (and even then), it is best to either discontinue using wireless networking, or to move your wireless network to its own segment.

It is also important to keep in mind that the usable range of wireless is often longer than you think it is. Where you might be able to get 100' of usable range from a laptop, an attacker with proper (and often inexpensive) equipment can get up to a mile. Given that WEP (both 64- and 128-bit), WPA1/2 (PSK), and LEAP are all easily crackable using free tools, limiting the exposure is usually the best option.

7) Lack of Proper DNS structure

In the order of things that make the Internet work, you start with electrons and photons which travel across wires and fibers (respectively). Then comes the routing of packets. Right after those two things comes DNS, which is the underlying mechanism for translating domain names into numbers, and vice versa. Additionally, DNS is used to establish (or assist in establishing) trust between hosts. One notable example is SMTP, which usually performs a number of DNS lookups before accepting mail from other hosts. Having a tidy DNS structure is critical to making certain services work reliably, and even more important in securing your domain from certain attacks.

While even the most perfect DNS structure won't save you from most kinds of attacks, it is important to anchor all other services in your domain by following a few rules. Firstly, be sure to have the MX records point to an A record which matches the greeting line of your SMTP server. Also be sure to have this work in reverse (the domain name in the SMTP greeting line needs to resolve to the same IP as the mail server). While only the more strict mail servers check for this, it will prevent some legitimate mail from being delivered correctly. The second item to check is that the registrar's DNS server list for your domain matches the NS records for your domain. I've seen this error come up quite often in organizations which have moved hosting providers or ISPs without double-checking the resulting DNS configuration.

Aside from basic structure for functionality, DNS can provide security though the use of SPF records, which define which servers are allowed to send mail for the domain. Many of the larger mail hosts support this, and it is one of the few defenses against phishing attacks that target your domain.

One of the best tools out there for checking all of this and more is DNSReport at DNSStuff.com. It's a paid service, but well worth it to ensure that every facet of your public DNS structure is properly done and that everything matches up as it should. (I have no relation to this company; I'm merely a satisfied customer.)

8) Wireless Keyboards/Mice

Aside from presentation and other special needs, wireless keyboards and mice have no place in a place of business. This applies doubly to any organization dealing with sensitive data. With the fairly recent cracking of the Microsoft wireless keyboard encryption, and others sure to follow, wireless input devices are pretty much equivalent to keyloggers that operate from outside your building.

The solution here is simple: use only wired keyboards and mice except where absolutely necessary.

9) Firewalling

In line with the above theme, I've found that few organizations run software firewalls on machines inside their networks. And, as was discussed earlier, the proliferation of client-side and other attacks put the internal network more at risk than ever.

For the most part, this problem is pretty easy to solve. Windows XP, Windows Server 2003, and newer versions of Windows all come with built-in firewalls which are configurable using Active Directory. While they aren't the best, they're better than nothing, and you can configure them such that only certain machines on your network have access to the ports needed for administration. Other OSes (Mac OS X, and most Linux distributions) come with similar built-in firewalls or have freely available firewalls which provide at least baseline functionality.

10) Network Access Control

When I talk to people about Network Access Control, it usually conjures images of incredibly expensive solutions from different vendors that are restricted to working on one platform; and they often just make everyone's lives miserable. Fortunately, that's not what I'm talking about, here. Instead, I'm referring to the lowest-tech version of Network Access Control.

Far too many times I've walked in to a facility and have had free-roaming access to unoccupied offices and conference rooms, all stocked with open access to ethernet jacks on the corporate network. Almost every single time I've tried, the ports have been live and I received an IP address immediately. This is a huge issue.

Fortunately, the solution is simple. First, refer to the first item on my list and get the network segmented properly. It amazes me to no end when people put servers in a highly locked and guarded room, but have a monolithic network and an empty conference room on the other side of the building. Physically, I can't get in to the server room, but by plugging in to the jack in the conference room, I might as well be able to walk right in. If network segmentation has been done such that ports which might be used by non-employees (i.e. jacks in conference rooms, and lobbies) are automatically in their own network, that solves one part of the problem, but what of the rest of the ports, which do need to be on the internal network? Simple: unplug them. Unplugging unused ports at the switch or patch panel completely eliminates the possibility that they could be abused in the first place. Furthermore, it minimizes the amount of ground you'll need to cover when auditing what is actually plugged in to your network.

Conclusion

Overall, there are some simple steps you can take to make your network more secure. Most of them are cheap or free. Some require a good deal of time investment, but reward you greatly once complete. Getting ahead of the curve almost always pays off, and security is no exception. Of course, all I've written above is not going to apply equally to all networks or organizations. The best thing you can do for yourself is to get a professional second opinion. A knowledgeable security professional who assesses your network and delivers a report is pretty much handing you what you need to procure funding and resources to pursue these projects.