HSC
Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > Articles > Network Partitioning
Go to: HSC Trainings
Search:  
Version française
   Services   
o Skills & Expertise
o Consulting
o ISO 27001 services
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o ARJEL
o Training courses
o E-learning
   Conferences   
o Agenda
o Past events
o Tutorials
   Resources   
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
   Company   
o Hervé Schauer
o Team
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
 communication
 
 
o HSC Newsletter
o Press review
o Press releases
o Publications
   Contacts   
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|Network Partitioning  
> Access to the content HTML Beginning of the article  
> Description Introduction to the concept of network security through network partitioning.  
> Context & Dates Proposal for the 7th USENIX Unix Security Symposium - San Antonio, TX, 26-29 January 1998.
August 1997 
> Author Hervé Schauer (Herve.Schauer@hsc.fr) and Vincent Archer 
> Type  
> Abstract &
Table of content
Introduction
Defining the concepts
Separate securities
Methodology
Steps for partition
    Determine the domains
    Determine the flows
    Draw the flows
    Checking the security policy
    Creating the configuration
    Uploading the configuration
Conclusion  
> Related documents
themeNetwork Partitionning
[Presentation]  Industrial control systems security. Scadastrophe... or not. [15 May 2012 - French]
[Presentation]  Deperimetrization or not ? [22 November 2007 - French]
[Presentation]  Network security stakes [14 October 2004 - French]
[Article]  Networks Security [25 July 2000 - French]
[Presentation]  Distributed Network Security [12 May 2000 - English]
[Presentation]  Distributed Network Security [15 December 1999 - English]
[Presentation]  Distributed Network Security - From Firewall to Network Partitioning [30 November 1999 - French]
[Article]  Distributed Network Security - From the Firewall to Network Partitionning [November 1999 - French]
[Presentation]  Le cloisonnement de réseaux [18 August 1999 - English]
[Presentation]  Private networks partitioning [8 July 1997 - French]
[Presentation]  Intranets partitioning [June 1997 - French]
> Copyright © 1997, Hervé Schauer Consultants, all rights reserved.

 


Introduction

The corporate private networks are now all migrating out of proprietary solutions toward TCP/IP; already three-fourths of these are fully IP-based. These networks see a strong development of Internet-type technologies, such as SMTP Messaging, the Internet standard, or WWW corporate servers, today's main applications. Even the planet's biggest software editor had to follow suit, dropping NetBIOS, and providing through Outlook an Internet standard mail software, following the steps of Qualcomm's Eudora, Netmanage's Zmail or Netscape's Messenger. Now, there is a word to describe such a corporate network based on IP and Internet technologies: Intranet.

The corporate private networks are still developing, reaching all the subsidiaries that previously were unconnected. Again, Internet technologies such as IP Dialup, tunneling, and all the facilities to use the same Internet infrastructure to connect to the Internet are a big help.

All this expansion is not without its brand of problems, and first of those the security. How to master such exploding networks? How to prevent information theft, data corruption, server suborning? How to avoid intrusions, the building of hacking platforms with these large networks and many external links to the Internet, the contractors or customers? More and more, all of the corporate's jobs are linked through the same network, all of the corporation's sites are on the same footing, and even sometimes operations that are common with one's concurrents. With larger Intranets, the need of security and the control over connections, dialogs and to know who does what and with whom becomes greater than ever.

With all these dangers, the need of security has grown. Use of distributed security architectures, such as Kerberos, OSF/DCE, has mostly failed. Centralized signature is still in infancy. And mobile code, such as Java and Active-X throws most of the classical security policies out of the window. All the techniques currently emerging are simple or transparent technologies. Such as SSL wrapping for WWW servers, PGP cyphers for messages, all of which are easy to integrate.

An elegant solution is to develop the concept of network isolation or partition. The corporate network must be subdivided in various security domains, each of which is separated from the others by a partition gate. The partition gate can be a router, even an already existing router if the model supports IP filtering. Each security domain can be a lab, a project, or a corporate function, and could be built using the current virtual network facilities from the current routing equipment. Isolation is achieved by putting IP filtering between those real or virtual networks.

Putting this idea into practice can appear as an insurmountable task to network administrators and security officers. However, it is possible, and is the only way to ensure a homogenous, corporate-wide security policy over a large network.


Defining the Concepts

A domain is an association between:

  • data and applications;
  • users;
  • a security policy.

A security domain corresponds to an entity within the corporation, bringing together equipments with the same security requirements. Within the Intranet, it could be a geographical area, a department, a project, or even a single highly critical machine. In all cases, someone will be responsible for the entity's security needs.

The domain will appear as a virtual network, a set of local area networks, or even a single machine. Such a domain can be considered as a logical network. Those networks appear only within the reach of the corporate entity; no separate security domains can exist outside. Behind the last routers lay only a network of unknown structure, management, and therefore of low security.

The domain is defined by its perimeters. The control applied through network isolation does not address the behavior of the domain's contents, but only what happens on the boundaries. The domain itself is not controlled. The boundaries are IP filtering devices, usually a router or firewall.


Separate Securities

The TCP/IP security can appear at two levels:

  1. within the application layers (OSI layers 5 to 7)
  2. within the network layers (OSI layers 3 and 4)

The two types are very different. The security at the application layers generally uses an individual-based authentication, from something as simple as a password to as strong as tokens. This is the domain of the firewall. The security in the network layers uses an equipment-based identification, relying on the IP addresses within the data packets. This is the domain of the filtering routers, or the more recent packet inspectors software. Both have been used for a long time and have evolved in parallel.

The application-level security is usually more complex and cumbersome than the network-level security. Using an application authentication implies either modifications on the installed base, and is often visible to the user who has to modify the way it uses the services, because of the added authentication.

With a network-level security, you can have a centralized view of the security, without having to alter or modify the existing protocols, applications or user's habits.


Methodology

The two main problems must be separated at first:

  1. Private network isolation;
  2. Internet interconnection.

The connection with the Internet is a separate security concern. It must be kept separated from the internal network policy. Usually, they are handled at different levels. The needs, in terms of application services and protocols are very different. For example:

  • Intranet isolation might have to allow routing protocols between domains, whereas the Internet connection dynamic routing occurs on both sides, but rarely through the entrance;
  • A connection from the Internet to the internal network will usually require a strong authentication of the users, whereas authentication might not be necessary between some internal domains;
  • An alarm on an internal filtering equipment doesn't require the same reaction times as an Internet penetration attempt.

There are non obvious parts to delimiting the Intranet. For example, an IP Dialup connection for a company's employee can be authenticated at the line, equipment and individual level. The employee's laptop or home computer can then be considered part of the private network, with all the appropriate services. Or the same Dialup, from a contractor, or a nomadic employee, which is only identified at the level of the individual must be handled as an Internet access, and be handled by the Internet security platform.

Another case occurs when two geographically distinct LANs are interconnected through a public network to create a single Intranet. The operator may provide, through frame relay for example, the appropriate illusion. Or dataflows can be set-up through the Internet itself, using tunneling for the same effect.

The network isolation usually uses network-level security only. Application-level security is only necessary at the Internet connection points, or at the boundary of very high security internal domains. But using a network isolation does not prevent one from using an application filtering.


Steps for Partition

The main tasks when creating security domains are the following:

  1. Determine the security domains to isolate, and create the required network infrastructure needed to realize these;
  2. Determine which protocols flow between equipments in these domains;
  3. Draw the data flows;
  4. Validate the match between the data flows and the required security policy;
  5. Derive from point 2 and 4 the required configurations for all interconnection points;
  6. Apply the configurations on all filtering equipments.

Determine the Domains

The security domains to isolate must be determined according to the security policy. Each entity with a specific security concern has to be isolated along the other entities at the same level.

During this step, all the links between the future security domain, the other domains and the rest of the corporate network must be determined. The network has sometimes to evolve to reduce those links, and migrate all the protocols to IP-based protocols to avoid any non-IP dialog, thus avoiding protocols that are impossible or difficult to filter.

After this step, the security domains and all interconnection points are determined. The interconnection points will be the future IP filtering equipments.

Determine the Flows

Depending on the situation and security needs, the flows can be determined by polling the users about their applicative needs, or by doing audits at the interconnection points in order to determine which protocols are used.

Usually, asking users about their needs reveal 50 to 75% of the necessary data flows. The rest must be derived from the protocols observed on the network and the administrator's knowledge. But dialog with users has other uses, such as providing information about the upcoming security policy. A successful communication is the key to having the policy accepted, as opposed to having people trying to circumvent it.

The network audit is used only within an operation network. The audit is performed at each domain interconnection points, to make sure that only the protocols between each domain are considered.

Draw the Flows

From the security domains determined in step 1 and the data flows determined in step 2, dataflow maps can be drawn.

Each map shows the global network and one or more dataflow. Each dataflow is associated with a single application, no matter how many protocols this application requires. With such a map, anyone can visually access and understand what is required and what will be implemented.

Large networks will require 15 to 50 different flow maps, with up to 40 protocols going through some of the network isolation elements. Each map will show all protocols, their origins, and destinations. The flows represent what is needed at each interconnection point.

Checking the Security Policy

Those maps must be validated regarding the security needs. If the diagrams are clear, the management levels can even check what will be allowed on the corporate network.

After checking each protocol for security risks, such as intrusion possibilities, hidden channels and tunneling, and the actual application needs, the diagrams will have to be formally approved by both:

  • the security managers for each security domain
  • the overall security officer

Once these diagrams are approved, the security policy is based on the principle:

"What is not explicitly allowed is absolutely forbidden"

Creating the Configuration

Any technically proficient operator can derive an appropriate configuration for a network equipment from the various dataflows. This task is delicate and fraught with errors with a single router, however. Maintaining the consistency across a large number of filtering equipments, especially when using a wide variety of router and firewall models, quickly becomes almost impossible, and at best, time-consuming.

Graphical user interfaces have appeared on the market to solve this need. Often associated with a specific filtering equipment set, they facilitate the writing of access lists and filter set-up. However most of these software lacks either the capability of managing large number of routers, differing brands of filtering equipment, or just the overall vision of the network and the determination of what equipment should host what filters. Usually, they are no more than fancy editors for a line-based rule file.

There is no obstacle to having software doing simultaneously the geometry of the network and the repartition of the filters across this network. The Net Partitioner tool that we developed precisely for this purpose can handle many routers and some complex network topologies, deriving from the topology the need to apply a filter for a data flow at each point.

Any equivalent software should also be able to support all the filtering possibilities offered by the current routers, ranging from logging to encryption of specific dataflows as they cross insecure domains. A worthwhile addition is to check the coherency of the various configuration files generated.

Uploading the Configuration

Each filtering equipment has an operative role first in connecting the networks. Their management must be handled by the entities who have the responsibilities of the local networks, such as the computer department of a security domain. Their main concern is the availability of the network, not the filtering.

A security office must be created, with the exclusive task of applying the filters on the equipments, and handling the logging. The correct application of the security policy can only be made by delegating the security to a specific entity, who is responsible of the task.

Translating the dataflows into configuration files cannot be done at this level. Without a filter generator, the coherency between the different security domains cannot be enforced. However, the security office can handle locally the logging information and day-to-day management of the equipments.

The security office is the key to successful isolation. It will centralize the technical proficiency and the permanent updating of the security policies. The security office has a monopoly on security, and thus can ensure update validation, traceability through logging, alarms handling, and history archival. But the office has also to audit permanently the network to reduce the risk of creating separate connections, or hidden channels.


Conclusion

With the expansion of the Intranets, and the difficulties linked to the mastery of the wildly different protocols supported, the isolation of the network into separate "kingdoms" has become necessary. A simple, yet cost-effective alternative to the more complex firewall-based approaches, it allows a basic, but very important level of control over the security for large corporate networks. With the explosion of network use, and the ever increasing political, economical and *image* dependency on IP networks, fully open domains are no longer viable, and manual configuration and management are of the past.

Last modified on 10 June 2002 at 14:15:07 CET - webmaster@hsc.fr
Information on this server - © 1989-2013 Hervé Schauer Consultants