Securing the Internal Network

Securing the Internal Network

ByBob Williams

SecureWiFi Networking Consulting

The goal of this document is to define new guidelines in order to improve the security in Microsoft Windows-based internal networks. In order to be useful in real situations, these measures have been implemented to obtaining the lowest-cost possible approach, and to prevent such a project to become financially prohibitive. Security being a field in constant evolution, it is possible that new solutions can be integrated to these ideas in the future.

Introduction

One of the first things you learn when you start looking into computer security is that about 80% of the attacks reported on networks come from the inside, principally from fired or disgruntled employees, from external consultants or from malicious hackers that got inside the network one way or the other (non-secured Internet connection, plugged-in modems, social engineering, got hired by the victim under false pretensions, etc.). Since the inception of the Internet, this number tends to lower, but latest estimates still show that between 60%-80% of network incidents happen on the internal network. The majority of computer security companies will put most of their efforts on securing the periphery of the network, while leaving the internal network itself completely open. A lack of consciousness about this problem, or by lack of competence, or more often, by lack of money for a project affecting all workstations on a network, the internal network takes a low priority.
I could see for myself on a few occasions, that once the periphery of the network is circumvented, the rest of the network is just like a big ripe fruit that we simply have to pick. This is why it is imperative to define measures that will enhance the global security of computer networks, while trying to keep the costs as low as possible. This is possible with the help of optimizing the tools that are already in place and by automating the deployment process. Automation is the preferred method as it reduces cost and the possibility of human error.

Definition of the multi-level approach

We often hear that computer security is not a product in itself, but more of a process that we constantly have to review due to the quick evolution of the technology and the vulnerabilities that might come with it. This is why it is recommended to implement multi-layer security architecture on your network, in order to prevent having a single point of failure. This is the strategy I chose to follow when I wrote this document. Not only the act of securing the internal network is part of a multi-layer strategy, but the multi-layer strategy will also be applied in order to secure the network.It is important to mention that the measures described in this document apply principally on securing Windows workstations. These measures can also be applied on Windows servers, but server administration implies other measures that are out of the scope of this document. Also out of the scope of this document are the measures to take to secure the periphery of your network, such as firewalls and IDS (Intrusion Detection System). Even if these measures are not covered in this document, it is important to take these into account in a global computer security strategy.
There is a bit of common sense that says "There is a conflict between ease-of-use and security." In order to have an efficient result; the solutions proposed must find the balance between these two concepts. In the case of Microsoft Windows, I think there is enough fat in the ease-of-use side that we can cut in it generously and this way re-establish the balance between ease-of-use and security. The different concepts that I will explain later are in part derived from my previous whitepapers, and in part from recent experiences. More precisely, this document will speak of antivirus protection, personal firewalls, securing the operating system and the various applications used on workstations, and various deployment techniques that can be used to facilitate the task.

Maximizing antivirus protection

For a long time, it was believed that a good antivirus and a firewall were all that was necessary to efficiently protect a network. Of course, this is not true anymore, but we must not neglect an antivirus solution as a means of securing our network. It is important to know that an antivirus application is not a panacea, and that it is easy for someone who knows about antivirus to circumvent such an application (which is why we are taking a multi-level approach). It is even more important to know that in order to be efficient, the antivirus product has to be regularly updated and properly configured.
In most of the cases, default installation is the norm, and this kind of configuration usually leaves holes in terms of antivirus protection. Sometimes we see antivirus installed only on critical machines or servers. Every workstation on the network should be equipped with antivirus, even if your mail server is equipped with antivirus and content-filtering products. All that is needed to compromise the security of a network is a single vulnerable machine, so it is necessary to define protection measures that take this reality into account.
In order to have maximum protection from your antivirus product, the chosen product must be able to scan files and programs in real-time in memory as well as files residing on the hard disk. Practically all antivirus products offer this functionality today. It is important to configure the antivirus product in order to scan for every type of file. It is very easy to camouflage a virus to look like an innocuous file (I Love You, Life Stages and Anna.Kournikova are good examples. With the processing power available in today's machines, there is no reason not to scan every file on a machine. You may have to put some exceptions however, depending on your environment (for example, I exclude for scanning my .pgd encrypted disk file). If the software lets you do so, you should also scan compressed files. If the antiviral software offers a heuristic detection engine on top of signature matching, then you should enable this also.
What good is it to put in place protection measures if we are not in a position to evaluate their efficiency? When default configuration is in place, it means that in the best of cases, the software will write its log files on the local hard drive on which it is installed. Some products gives you the possibility to chose the destination of your logs files, preferably on a central server (often a simple UNC path like \\centralserver\sharedfolder will work). I strongly recommend the use this functionality, as it will increase your capacity to understand and evaluate the scope of a virus infection when it happens, without having to hop from machine to machine to review log files. In a crisis situation, such a setup saves you time and gives you the global picture, which is essential while trying to stop the crisis. If the software also lets you send alerts by e-mail or pager, then it should be turned on. This will notify your staff as soon as an infection occurs, and from their desk they can easily check the centralized log files and make the call: simply an old virus that got cleaned on the way to the network, or a large-scale infection prompting for more immediate action? Some products do not let you change the log files destination, which means that good products may be overlooked simply because they lack this feature. To solve this, there is LogAgent, a program written in Perl that will monitor log files for changes, and will forward these changes to a central location.
The last aspect to consider is the updating of the antivirus definition files used by the software to identify the possible viruses that could try to get on your network. Because of the way that signature-matching works, if a virus signature is not included in the signature database, then chances are good that it will go undetected (heuristics tries to solve this problem, but can induce the possibility of false alarms). Usually, the software will be configured to be updated once a month, fetching its files directly from the vendor's website. Depending on the level of paranoia expressed by your company (and the rapid growing rate of virulent activity), this should be done daily or weekly, and the updates should be done from an internal server, where the network administrator has previously put up-to-date files. This will prevent network congestion. I will cover later in this paper how to deploy your solutions on your network containing your custom configuration.
One last word relative to virus protection: for the past 4 years or so, virus writers primarily focuses on exploiting some flaw in a well-known software in order to propagate their piece of malicious code. The most dangerous is Outlook (and its cousin counterpart, Outlook Express). This software, which features functionality such as e-mail, agenda, calendar, and so on... sports multiple vulnerabilities. It the number one choice for virus propagation. Before Outlook, it was considered impossible to get infected by a virus simply by reading e-mails. One had to open an attachment in order to be infected. Anyone pretending the opposite would quickly be made fun of and proved to his peers that he didn't grasp the mechanics of computer science. This is not true anymore since the coming of Outlook. Because of this new functionality (others would say vulnerability) all things are now possible.
It is very hard to secure Outlook in order to make it inoffensive, and on top of that, the default configuration (which is highly insecure) is the most used in companies. For these reasons, many companies will put in place several antivirus utilities on various points on the network architecture. These utilities are for the most part useless against new, unknown threats. The analogy of a chain, where the weakest link is the one that will break when the chain breaks, is often applied in the world of computer security. By strengthening all the other links in your computer architecture (antivirus on servers and workstations, mail filtering, etc.), but keeping the weakest link on your network (Outlook), then you can only be sure that the chain will break with yet another wave of Outlook virus. I know that what I am saying here is not popular, but if you really make a big step forward in virus protection, ban Outlook and Outlook express from your network (and I point here to the clients, not the Exchange server, which can be used with other mail clients).

Setting up personal firewalls

For a bit more than 2 years now, a new kind of software has made an appearance in the computer security market, personal firewalls. These are numerous and vary in their functioning from one product to the other. For this reason, I recommend that you research which products are available and evaluate how they work, in order to find which one best suits the needs of your company. Personal firewalls don't all behave the same, and it is on this point that I'd like to expand a bit. Let's take for granted that there is a firewall protecting the internal network from the Internet. What would then be the advantage of installing a personal firewall on a PC that works on the same principles as the main firewall, that is a firewall that filters incoming and outgoing traffic based on rules defined on some characteristics of the concerned IP packets? A packet sent by a malicious person that achieves a pass on the firewall, because it conforms to the rules put in place, has all the chances to do the same when it is confronted with the personal firewall. Since the chances are great that the packet will also conform to the rules of the personal firewall, unless the rules from the two types of firewalls are sensibly different, the packet has a pass.
Another strategy, that I find particularly interesting, is a personal firewall that manages incoming and outgoing traffic based on the permissions set for the application requesting the connection, in opposition to the source and destination of IP addresses and ports. This type of firewall also makes a difference between the internal and external network, which makes it possible to obtain a good granularity on the type of traffic accepted or refused. On top of that, this type of firewall is made to stop right from the PC any connection attempt made by Trojan horses, denial-of-service agents, and some spyware. It is possible, for each application on the PC, to authorize, to refuse or to ask for permission for each connection, either on the internal or external network. It is possible to determine which applications have the permission to act as servers, which means that it can accept connections from other machines on a specific port. Applications not defined in the permission list will always ask for permission by default.
By this design, if a Trojan horse gets on the PC via an e-mail attachment, it will never be able to receive the connection requests sent by the malicious hacker, even if this one is located on the internal network. The danger with this strategy is to be too permissive with your applications. For example, if we leave the command prompt FTP tool, then it is possible for a cracker to craft a Trojan horse that will use the FTP tool on the victim PC to send collected information out of your network without triggering any alarm. Other scenarios using other commonly used software are possible. In the end, it comes down to the risk exposure you can cope with. But still, be careful when designing your rules. At a minimum, all command prompt tools should at least ask for permission, as they offer no graphical hint of their usage. At the least, your personal firewalls will work as a complement to your main firewall, instead of just being a redundancy of the same strengths and weaknesses.
In order to increase your network security, I recommend the various servers on your network become the "internal network". This way, it becomes impossible for a workstation to connect to another workstation on your IP network. This will force all electronic communications to transit via your servers (file server, print server, mail server, DNS, firewall, etc.) before getting to its destination, and makes it impossible (*) for an insider to hack into someone else's PC via the network.
Certain products will still let you associate specific ports to each application, which gives you one more degree of granularity in your setup. Of course, in order to be efficient, we must have a good idea of what is installed on the workstations, and which network these applications should be allowed to connect with. By enumerating the applications allowed for network activity (you should have this detailed in your corporate security policy document), it then becomes easy to put standards that prohibits unwanted applications, such as chat clients, and instant messaging. To achieve this, the configuration has to be protected by a password.
As with antivirus, it is a wise choice to centralize your log files and keep and active eye on them. We will see later how to make pre-configured installation packets to deploy your personal firewalls effectively.

Optimizing operating system security

Here we will discuss one of the most problematic aspects about securing the internal network, securing the operating system on each workstation on the network. Why is securing the internal network often left undone? It is a relatively complex task, and it traditionally needs to be done by hand, machine by machine, which implies high costs for workforce and is prone to errors. Corporate IT departments usually don't have the required knowledge necessary to deploy securely configured PCs in the first place, and even if it is the case, it often needs to checked and updated.To give you an idea of the size of the task, there is the deactivation of the guest account, forcing a complex password for the local admin account, removal of unnecessary services and components (such as the Posix and OS/2 subsystems), restrict access to the LANManager hash, restrict access to folders and registry hives, applying service packs and fixes, just to name a few. The list is rather long, and it is easy to understand why this aspect is so often left aside: the time required to do all this manually on all PCs on a network is an enormous task.
In order to solve this problem, Pedestal Software created a graphical interface tool, called Security Expression. This tool lets you audit and configure remotely Windows NT and 2000 machines by comparing it to a set of pre-defined security policies that correspond to the secure configuration we wish to obtain. (I tried to stay vendor-independent in this article, but I actually don't know of another similar product.). There are some sample configuration files that come with the program, and more you can download from the company's website. One of the sample files corresponds to the recommendations made by the SANS Step-by-Step, another one corresponding to the "Microsoft Security White Paper", and three others corresponding the standard US Navy configuration for workstations and servers. These files are redundant in the fact that they cover at least partially the same holes, I prefer the Navy files. They are more thorough, and you can modify to suit your needs.
This software doesn't need any installation of agents on the workstations. We only have to install it on a machine that is connected to the network (administrator's machine is a good idea), and we simply have to give it the administrator's login information of the domain we want to secure. The software will then proceed to a complete scan of the machines on the domain, matching their configuration against the security policy we want to implement. Once the scan is complete, the program presents an easy to understand report that shows item by item if the configuration complies with the security policy or not. With a single click of the mouse, we can start a similar process that will take care of modifying the workstation configuration to make it comply with the security policy, thus securing the various parts of the operating system on each workstation. We can also use Security Expression on a regular basis to test the integrity the configuration base, or to update new policies to cover newly discovered vulnerabilities.
Security Expression passes its requests by using the NetBIOS protocol, which is the basic protocol in a Microsoft Network, along with the administrator's credentials, to audit and configure the workstations. It is also possible to create your own configuration files, which can be drafted from the sample files that come with the program. In its simplest usage, Security Expression can add, modify or delete registry keys, user accounts and groups, files or ACL's, and probably a bit more. It is possible to include scripts or programs to give you more tools to deploy your secure configuration. You can also use this to deploy service packs and hotfixes, or other programs like the ones that we discussed above.


Optimizing applications security

So far, we have taken steps to try to protect against viruses, Trojan horses, DoS agents, and we have considerably secured the operating system environment in order to reduce the number of vulnerabilities in the network. We could be thinking that our task is coming to an end, and that we have finally leveled the challenge of securing our internal network. Not yet.. We still have to take into account the various applications that the users need to conduct their daily business, which could also host several flaws that could compromise the security of our network. Remember the Outlook example I gave you? It is true that with all the steps we have taken so far to secure our network, it could be harder for a potential intruder to achieve its goal. As long as there is an open door, there is always a way to make it open wider, and wider, up to the point to it will circumvent all our previously taken security measures.
Another application that needs a special attention is the web browser, be it Internet Explorer, Netscape, Opera or other. It is important to reduce the capabilities of this type of software, because it is an open window on your network. For example, it could be dangerous to accept blindly the execution of Java, JavaScript or VBScript applets. Also, the acceptance of ActiveX controls is renowned as being non-secure. These controls give the possibility to web authors (anyone) to execute code on your machine without restriction. It is important to take preventive steps to filter these possibilities, but still leaving enough room for an enjoyable web experience. Again, risk-exposure acceptance is a key factor here. E-mail applications also need similar adjustments, such as the de-activation of VBScript execution in HTML message for example. If you can, disable HTML mail altogether if you want to sleep tight at night.
In fact, each application installed on your machines that connects in one way or the other on the network should be the object of specific research on how to remove known vulnerabilities. The same could be said of application software that has the capacity to execute code under one form or another. One such example is the popular word processing Microsoft Word, which has the ability to execute macros (and was at the origin of a new breed of viruses). Once the risk factor associated with each standard application on your internal network machines have been identified, and that the necessary changes have been thoroughly tested and approved, we can once again use Security Expression to deploy the configuration changes on existing machines.

Deployment

In a security context, the ideal situation is to reformat the machines and reinstall everything from scratch and secure everything before putting the machines on the network. In real life this is simply too costly for many companies, and is a huge task to undertake, not to mention lost productivity usually encountered in big deployment projects. So the next best thing is to secure the existing machines with the different tools covered so far in this paper, and take the bet that these new security measures will be able to stop, or at least detect, any previous security breach.
As we have seen, it is very costly to make an enterprise-wide software deployment by going from machine to machine (I still often see it done this way), and it opens the door to human mistakes. In the case of a simple configuration change, we have seen that Security Expression was letting us do the changes remotely. It is also possible, with the use of scripts, to use it to deploy software. Another approach that I favor particularly is to create custom installation packages according to our specifications (with an application like InstallRite, which is free). The installation of this custom package on a machine will not need any other effort to make its configuration match our specifications.
InstallRite works by taking a snapshot of all your hard disk and registry content, before and after the installation of your software, and identifies the changes made to the system by the installation (files or registry keys that have been added, removed or modified). It can then extract these files and registry keys and create a self-extract program that will automatically install the software with the desired configuration. The trick is to configure your software before taking the second snapshot of your system. You can use this to deploy your pre-configured antivirus, personal firewalls and any other productivity software you may want to deploy. The installation itself can then be launched from the login script or any other method you prefer.

Costs and savings

So far, I only have covered the technical aspect of such a project, neglecting the financial aspect for text clarity. You should already have a good idea of where the costs are going to come from: software licenses. Indeed, you will have to account one software license per workstation on the network for each application that you want to deploy. Cost reductions are achieved by checking for applications that can be reused (antivirus, for example) and by simplifying deployment procedures. The same is true for Security Expression, since its license is based on the number of machines of your network. For bigger networks, a corporate license is usually available and can offer a good licensing alternative.
The other cost-factor is workforce. Everybody knows it; qualified technical workforce is rare and expensive. This is why it is important to have an efficient deployment scheme to simplify the task and reduce the number of staff needed. We can easily count between 1 hour and 1 hour 1/2 per machine for a technician sitting at a machine and implementing mechanically all the things covered in this document, on top of the time necessary for the initial analysis phases of the project (identification of standard software, definition of configuration, tests, etc.). It is a complex and repetitive task that is error-prone and where mistakes can leave a big hole open in the network that you worked so hard to secure. By automating the task (the same analysis phase is still necessary) the deployment time can be drastically reduced to approximately 5-15 minutes per PC for the same amount of work, depending on various technical factors like processor time and network speed. Nonetheless, the saving in time and workforce is enormous, given the level of security obtained by these measures.
Integrated commercial solutions vs. independent products
I talked about various types of tools as independent entities. There are some commercial integrated solutions for workstation security, which include an antivirus, a personal firewall, VPN, encryption and IDS system. These applications are all optional components that can be added or modified at will via a common central interface. In fact, the graphic application that manages this multi-tool solution is not very different from what we have seen, but has the advantage of showing a common interface and tool to configure and deploy all these solutions.
Even if an integrated solution has some advantages, it also has a few inconveniences. One of these inconvenience lies in the fact that the distribution of the software packages is more complicated than it should be, and you may have to launch your installation routine a few times to cover all the machines in the network. Another inconvenient is that the interface that shows the log files doesn't do anything more than simply show the log text, and sometimes it does so in a clumsy way. Nothing beats looking at the log files with a good text editor. The biggest problem is probably the fact that vulnerability present in one component can mean that vulnerability is also present in another components of the suite. That means that it can be exploited to shut down the integrated solution altogether. Using different products from different vendors doesn't necessarily guarantee that such a thing can not happen, but vulnerability present in one product has a minimal chance to have an impact on the other products.

Conclusion

In this document, I wanted to discuss a problem in computer security that is often overlooked, either for technical or financial reasons: the security of the internal network. More than half (and even near 80% according to certain sources) of reported computer security incidents are done from inside the network. This is at least partially in contradiction to measures traditionally implemented to secure a network, habitually against outside attacks (firewalls, IDS, content filters,...). Although these measures are necessary, they are for the most part useless in the scenario of an attack coming from the inside. They become useless as well if an outside intruder finds a way to circumvent them. The biggest challenge while securing a Windows-based internal network remains the complexity of the task and the volume of machines affected. For these reasons, the cost associated with this kind of project is often judged prohibitive, and is left aside as a result
I have shown with this document that with the different tools available and with a little imagination, it is possible to obtain an appreciable increase in security on the internal network, for only a fraction of the price normally associated with this kind of work. We now have deployment solutions that make it affordable enough to interest companies who would like to protect their data assets.