Security

Internal defenses are part of layered security strategy

A smart administrator will protect IT resources not only from the outside world, but from other resources inside the network as well.

A layered approach to security is a good idea. There's little to quibble about there. The specific needs of an effective layered security strategy may be open to debate, however. The truth is that those needs vary from case to case, and may vary wildly in some cases.

A common mistake of those who do not employ an effective layered security strategy, though, is to focus on perimeter security. It's increasingly popular amongst the avant-garde of security professionals to claim there is no perimeter, but the truth is more prosaic: there's a perimeter, but there's a lot more to security than the perimeter. Much of the philosophy of layered security is a response to the need to address more than mere perimeter security.

Firewalls are not enough, these days (if they ever were), to effectively protect the data moving around inside your network. Even ignoring for a moment the fact that an Internet-connected network would never need to be connected to the Internet if data did not cross the perimeter, and still probably need securing even outside the perimeter at times, the view that one's network is some kind of atomic, indivisible resource that needs all security measures focused on protecting it as a whole is mistaken. The various parts and operations of your network all need their own individual protection measures too -- even protection from each other.

A failure in penetration protection at the perimeter of a network is never an impossibility. Local wardrivers and other wifi security crackers, exotic threats such as van Eck phreakers (at least in theory), and unscrupulous or incautious employees with physical access can all introduce threats to the network, bypassing common perimeter defenses entirely. It is for this reason that one should employ a layered network security strategy -- to design one's security policy not only to attempt to keep the threats out, but also to provide the means to respond effectively to breaches, and to keep sensitive data and resources as well-protected as possible even if security has in some manner been compromised.

One of the most common failures in this regard is that of undertaking significant effort and expense to secure traffic outside the perimeter with encryption and authentication measures while assuming that data communications inside the perimeter are necessarily safe. Protective measures for your IT resources should be implemented even for operations that take place entirely within a nominally trusted network. In other words, even a supposedly trusted network should be regarded as untrusted -- just, perhaps, less severely untrusted than other networks, such as the Internet itself. Such measures should include, but not be limited to, the following:

  • Systems internal to your network should be protected as though they were connected to public wireless network with Internet access and no perimeter security measures at all, such as many coffee shop networks. Each should have its own firewall running, unnecessary services turned off, and necessary services configured to minimize vulnerability -- even if you think nobody will be able to even attempt to crack security from outside the local network.
  • Secure user authentication should always be used when accessing resources across the network. If some malicious security cracker manages to gain a foothold on a system within your network -- perhaps some desktop system that uses a Web browser, email, and IM client to talk to the outside world -- he or she might then be able to use it to stage attacks against more other systems. If secure authentication is necessary to access your mail server, it won't be easy to turn it into a virus delivery platform; if for your file server, it won't be as easily ransacked; if for your firewall, it won't be as easily reconfigured to allow further access to the network from the Internet. Part of secure authentication, of course, is ensuring that only very well secured systems are allowed as the source of remote access.
  • Security assurance and disaster recovery resources on your network, such as integrity auditing and backup servers, should be as impervious to attacks launched from local systems as threats originating outside the network perimeter. Logging servers should listen, but not broadcast; backup servers should never allow anything copied from another system to be executed on them; integrity auditing servers should not be subject to any control by the systems whose integrity they're meant to audit.
  • Communications across the internal network should always be encrypted. If you have a consumer grade router/firewall appliance with a Web interface, it should be accessed via an HTTPS encrypted connection. If you must access the shell on a Unix system, use OpenSSH rather than RSH or other unencrypted tools. Network filesystem shares should be accessed using tools such as SSHFS that encrypt the entire session using strong, peer reviewed cryptographic algorithms, rather than unencrypted, poorly encrypted, or only partly encrypted NFS or SMB/CIFS shares.

Just as a boxer may wear a mouth guard to protect his teeth from each other, and not merely rely out outward defenses against an opponent's punches, you should secure everything within your network against the rest of your network to protect it in the event your trust in your own IT resources doesn't save you from unexpected threats that may penetrate or circumvent your perimeter security.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

8 comments
gregfeenstra
gregfeenstra

I like what you are saying here! With regards to encryption for all, end-to-end, how does this impact the use of WAN optimization technologies and the such? Are we reduced to pony-up for additional and potentially expensive bandwidth and slower performance?

gregfeenstra
gregfeenstra

I like what you are saying here! With regards to encryption for all, end-to-end, how does this impact the use of WAN optimization technologies and the such? Are we reduced to pony-up for additional and potentially expensive bandwidth and slower performance?

gregfeenstra
gregfeenstra

I like what you are saying here! With regards to encryption for all, end-to-end, how does this impact the use of WAN optimization technologies and the such? Are we reduced to pony-up for additional and potentially expensive bandwidth and slower performance?

Sterling chip Camden
Sterling chip Camden

With people connecting laptops to the local network, running software from thumbdrives, and maybe even leaving a wireless connection open to the outside world.

richa.mittal
richa.mittal

If you need an all in one solution then I would look at something like unified threat managment also known as a UTM.Cyberoam firewall is the only UTM firewall that embeds user identity in firewall rule matching criteria, enabling enterprises to configure policies and identify users directly by the username rather than through IP addresses. Cyberoam???s powerful hardware firewall provides stateful and deep packet inspection, access control, user authentication, network and application-level protection. The ICSA-certified Cyberoam firewall is available along with VPN, gateway anti-virus and anti-spyware, gateway anti-spam, intrusion prevention system, content filtering, bandwidth management and multiple link management, providing comprehensive security to small, medium and large enterprises, including remote and branch offices. Cyberoam is a Check Mark Level 5 certified UTM solution. Key Features 1.Stateful Inspection Firewall 2.Centralized management for multiple security features 3.Embeds user identity in rule-matching criteria 4.Multiple zone security 5.Granular IM, P2P controls 6.ICSA certified

apotheon
apotheon

How well do you protect the nodes on your network from each other? Are there measures you take in this area that weren't covered in the article? Are there measures suggested by the article that you don't employ?

apotheon
apotheon

There is likely to be a performance and resource consumption hit for encryption, but how much depends on the specific encryption protocols used. Like any other networking protocols, network encryption protocols must be designed with packet size in mind and with traffic density in mind. Some encryption protocols (such as OpenSSH) actually implement compression, reducing the required bandwidth, but that's at a cost of increased latency in some cases because the sender must take extra time to compress before sending and the receiver must take extra time to inflate after receiving, in addition to the extra overhead of encrypting and decrypting. For low-bandwidth operations that don't require the most precise timing (such as IMs and other small payloads), the extra latency overhead shouldn't be a significant problem. For bigger data transfers, such as a 4GB file, the encryption overhead may prove more substantial (especially depending on the design of the encryption protocol used). On the other hand, if you turn on compression in OpenSSH, this may offset the latency by effectively reducing the total volume of data that has to be schlepped across the network; an extra fifteen seconds of time spent compressing and inflating may be more than compensated by reducing the effective size of the transfer from 4GB to 3.7GB (note that I'm making up numbers here -- I haven't benchmarked OpenSSH compression performance to have anything like exact figures to offer). Ultimately, the answer to your question is "It depends on the encryption protocol you use, how you have things configured, and specifically what traffic you're encrypting." I wish I could offer something more straightforward as a response.

tomg1234
tomg1234

I am always surprised at how company's rely solely on written policy without physical support. The sheer volume of small high volume memory devices used unknowingly on "protected networks" is staggering. Network administrative control including history logs is simple to put to work, yet overlooked by many.

Editor's Picks