Different Access for Different Organizations

Before developing your security policy, determine whether you will need to have different policies for different locations or if you will have only one. If you have a single security policy, you can enforce the same policy on all firewalls and other security devices, usually from a single management station. Otherwise, you will have to maintain a different policy for different locations. Although for business reasons this might be necessary, it can add a level of complexity to your environment that could decrease your overall effective security. If it is necessary, make sure it is thoroughly documented. Some different types of organizations that may have differing access requirements include:

- SOHO The Small-Office-Home-Office network is often more concerned with accessibility than security, since these organizations often do not have dedicated IT professionals on hand, or may have an “IT person” who is doing double-duty while performing accounting or other administrative duties. In most cases, SOHO offices aren’t terribly concerned with accessing resources hosted by remote networks; most SOHO access rules will pertain to a self-contained environment. (One major exception to this is that many small businesses will outsource services such as e-mail rather than run their own local servers.) Despite this focus on accessibility and ease of use, it’s just as critical to maintain the security of desktops and servers within a SOHO environment as in the largest of enterprise networks.

- Small/medium enterprise When networks become larger than the typical SOHO configuration, you’ll begin to see networks that run more infrastructure services in-house, including DHCP, DNS, e-mail, and VPN services. Here you’ll also see the beginnings of access requirements that cross the boundaries of trusted networks, where you may need to configure a trust relationship or a federated access for a B2B arrangement between vendors or suppliers. Small- to medium-sized enterprise networks will typically have one or more dedicated IT staff available of varying skill levels who can implement network security policies and procedures.

- Large enterprise The largest organizations will typically have an extensive IT infrastructure to match.This typically means multiple layers of firewalls in place, both perimeter firewalls and internal firewalls to protect highsecurity areas on an internal LAN such as Human Resources or Research & Development. Enterprise networks will also usually have IT personnel of several levels of expertise, ranging from desktop or help desk support representatives to specialized network, firewall, or e-mail server administrators. Trusted Networks It is not easy to define what a trusted network consists of, or what comprises a trusted network even within a single corporation or entity, since the concept of “trust” doesn’t apply equally even within a single company you’ll still want to control access to sensitive information such as payroll or HR information.

Defining Different Types of Network Access

Not every network segment is used by the same users or applications; moreover, usually the user defines which applications need to be run in a network segment. Each application has its own requirement regarding bandwidth and security, and the network security policy has to be defined with all those requirements in mind. Let us imagine a hypothetical network that has been designed to support a large financial company. In our example, we have a company with:

- The Board of Directors and high-level executives These are either nontechnical users or ones whose computer knowledge is not very current (they may have left a technical position some years ago).The challenge here is that they usually want access to everything and want to be able to do what they want, no matters what it is; it’s incredibly common to find organizations with firewall and proxy server rule-sets that have exceptions called something to the effect of “Allow VPs All Access.”You need to gain buy-in from these high-level executives for your network security policy to succeed, even when it means their own access needs to be curtailed.

- Engineering These may be users with a high computer and networking knowledge, and possibly know more than you do! On the other hand, you may be dealing with people with a great deal of knowledge in their own specific field, but with no knowledge about computer networks or security.

- Sales, Procurement, Financial These users usually do not have a strong technical and security knowledge, but may be managing valuable data such us provider information, future projects, products prices, confidential commercial operations, etc.These users usually require a fairly free level of Internet access to interact with and research customer and suppliers networks.

- Human Resources department It is critical to secure this area, not because of any Internet access requirements, but because this department manages personal data. Depending on the country you are doing business in, there are numerous laws and regulations to protect employee and customer personal data.You will need to fulfill all the requirements of such laws while allowing your HR staff enough privileges to perform their jobs.

- Marketing, Public Relations, and similar departments These users may have specific requirements of network access.Talk with them, analyze their answers, and define a policy that suits their needs and allows them to do their work without compromising the business security.

NOTE

Involving the directors in security managing will greatly improve the success of your security policy not an easy task, but essential. They may need to be informed, for example, that having full and unfiltered Internet access poses a risk to the security of their business.

Untrusted Networks

The federation of networks that became the Internet consisted of a relatively small community of users by the 1980s, primarily in the research and academic communities. Because it was rather difficult to get access to these systems and the user communities were rather closely knit, security was not much of a concern.The main objective of connecting these various networks together was to share information, not keep it locked away.Technologies such as the UNIX operating system and the TCP/IP networking protocols that were designed for this environment reflected this lack of security concern; security was simply viewed as unnecessary. By the early 1990s, however, commercial interest in the Internet grew.These commercial interests had very different perspectives on security, often in opposition to those of academia. Commercial information had value, and access to it had to be limited to specifically authorized people. UNIX,TCP/IP, and connections to the Internet became avenues of attack and did not have much capability to implement and enforce confidentiality, integrity, and availability. As the Internet grew in commercial importance, with numerous companies connecting to it and even building entire business models around it, the need for increased security became acute. Connected organizations now faced threats they never had to consider before. When the corporate computing environment was a closed and limited-access system, threats mostly came from inside the organizations.These internal threats came from disgruntled employees with privileged access who could cause a lot of damage. Attacks from the outside were not much of an issue since there were typically only a few, if any, private connections to trusted entities. Potential attackers were few in number, since the combination of necessary skills and malicious intent were not widespread. With the growth of the Internet, external threats grew as well.There are now millions of hosts on the Internet as potential attack targets, which entice the now large numbers of attackers.This group has grown in size and skill over the years as its members share information on how to break into systems for both fun and profit. Geography no longer serves as an obstacle, either.You can be attacked from another continent thousands of miles away just as easily as from your own town. Threats can be classified as structured or unstructured. Unstructured threats are from people with low skill and perseverance.These usually come from people called script kiddies attackers who have little to no programming skill and very little system knowledge. Script kiddies tend to conduct attacks just for bragging rights among their groups, which are often linked only by an Internet Relay Chat (IRC) channel. They obtain attack tools that have been built by others with more skill, and use them, often indiscriminately, to attempt to exploit vulnerability in their target. If their attack fails, they will likely go elsewhere and keep trying. Additional risk comes from the fact that they often use these tools with little to no knowledge of the target environment, so attacks can wind up causing unintended results. Unstructured threats can cause significant damage or disruption, despite the attacker’s lack of sophistication.These attacks are usually detectable with current security tools. Structured attacks are more worrisome because they are conducted by hackers with significant skill. If the existing tools do not work for them, they are likely to modify them or write their own.They are able to discover new vulnerabilities in systems by executing complex actions the system designers did not protect against. Structured attackers often use so-called zero-day exploits, which target vulnerabilities the system vendor has not yet issued a patch for or does not know about. Structured attacks often have stronger motivations behind them than simple mischief.These can include theft of source code, theft of credit card numbers for resale or fraud, retribution, or destruction or disruption of a competitor.A structured attack might not be blocked by traditional methods such as firewall rules or detected by an IDS. It could even use noncomputer methods such as social engineering.

NOTE

Social engineering, also known as people hacking, is a means of obtaining security information from people by tricking them. The classic example is calling up a user and pretending to be a system administrator. The hacker asks the user for his or her password to ostensibly perform some important maintenance task. To avoid being hacked via social engineering, educate your user community that they should always confirm the identity of any person calling them and that passwords should never be given to anyone via e-mail, instant messaging, or the phone. To guard against social engineering and similar security hazards, user education should be an integral part of any network security policy. Another key task in securing your systems is closing vulnerabilities by turning off unneeded services and bringing them up to date on patches. Services that have no defined business need present an additional possible avenue of attack and are just another component that needs patch attention. Keeping patches current is one of the most important activities you can perform to protect yourself, yet one that many organizations neglect. The Code Red and Nimda worms of 2001 were successful primarily because so many systems had not been patched for the vulnerabilities they exploited, including multiple Microsoft Internet Information Server (IIS) and Microsoft Outlook vulnerabilities. Patching, especially when you have hundreds or even thousands of systems, can be a monumental task. However, by defining and documenting processes, using tools to assist in configuration management, subscribing to multiple vulnerability alert mailing lists, and prioritizing patches according to criticality, you can get a better handle on the job. One useful document to assist in this process has been published by the U.S. National Institute of Standards and Technology (NIST), which can be found at http://csrc.nist.gov/publications/nistpubs/800-40/sp800-40.pdf (800-40 is the document number). Also important is having a complete understanding of your network topology and some of the key information flows within it, and in and out of it.This understanding helps you define different zones of trust and highlights where re-architecting the network in places might improve security for example, by deploying additional firewalls internally or on your network perimeter.