S 2.70 Developing a concept for security gateways

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: IT Security Officer

The connection of a local network to a global network such as the Internet leads to a new supply of information. Networking the computer systems locally ensures that every workstation computer is able to access the variety of information available.

However, connecting these networks also poses new threats because, in principle, data does not only flow from the outside into the network requiring protection, but can also flow in the other direction. Furthermore, the ability to execute commands on computers in the local network from a remote computer (e.g. from the Internet) directly threatens the integrity and availability of the local computers, and therefore indirectly threatens the confidentiality of the local data as well.

A subnetwork requiring protection should therefore only be connected to an untrustworthy network when this is absolutely necessary. This applies especially to connections to the Internet, which is one of the least trustworthy networks existing due to the high number of users. It is also necessary to check the extent to which the network to be protected should be divided into subnetworks, because certain computers or areas of the network to be protected are not permitted to connect to the Internet or are only permitted to do so under certain conditions, and whether a stand-alone system will suffice for connection to the Internet (see S 5.46 Installing stand-alone-systems for Internet use and module S 3.8 Internet PCs).

To guarantee the security of the network to be protected, it is necessary to use a suitable security gateway. However, the following general conditions must be fulfilled by the security gateway in order for it to provide effective protection:

The security gateway must

• be based on a comprehensive security policy,
• be integrated into the IT security concept of the organisation,
• be installed correctly, and
• be administered correctly.

Connections to untrustworthy networks must only be allowed after it has been verified that it is possible to manage all risks involved with the selected security gateway concept and considering the personnel and organisational conditions.

There are various ways available to implement a security gateway. In order to determine which concept is most suitable for the intended use, it must first be clarified which security objectives are to be fulfilled by the security gateway.

Examples of security objectives include:

• protection of the trustworthy (internal) network against unauthorised access from untrustworthy networks,
• protection of the data transmitted and stored locally against attacks to their confidentiality or integrity,
• protection of the local network components against attacks to their availability (this applies especially to information servers that provide the general public with information from inside the organisation),
• availability of the information in the external network in the internal network to be protected (however, the availability of this information is secondary to protecting the local computer and information!),
• protection against attacks based on IP spoofing that abuse the source routing option, the ICMP protocol, or routing protocols,
• protection against attacks on newly discovered, security-related software vulnerabilities (since the number of the potential attackers with a connection to the Internet and their level of expertise must be assumed to be high, this security objective is particularly important),
• protection against unwanted data leaks.

Based on the security objectives, a security policy must be created that specifies the tasks of the security gateway and the requirements placed on it. This security policy must be embedded in the security strategy of the particular organisation and therefore needs to be co-ordinated with Security Management.

The decisions made when developing the security policy for the security gateway should be documented in an understandable manner together with the reasons for making these decisions.

The security policy is implemented on the security gateway by implementing the security gateway itself, by selecting suitable hardware components, packet filters, and Application Level Gateways, and by carefully specifying and configuring filter rules.

The terms "packet filter" and "Application Level Gateway" are important in the following sections and will therefore be explained briefly at this point to avoid misunderstandings:

• Packet filters are IT systems with special software that filter the information based on the header data in the lower layers (transport layer or connection layer) of the OSI model and then either forward or reject the packets according to special rules (see S 2.74 Selection of a suitable packet filter). Packet filters make their decisions based on, for example, the source and destination addresses or ports in a packet without having to examine the contents of the packet.

• An Application Level Gateway is an IT system that filters the information in the application layer (i.e. the actual contents (user data) of a packet or several contiguous packets) and can prohibit or allow connections or certain commands according to special rules (see S 2.75 Selection of a suitable application-level gateway). While the packet filter works on layer 3 and 4 of the OSI model, gateways work on layer 7. An Application Level Gateway is generally implemented on one IT system that is exclusively used for this purpose and the scope of commands of which are reduced to only what is actually required.

In order for a security gateway to provide a network with effective protection against attacks from outside, several basic prerequisites must be fulfilled:

• All communication between the participating networks must go through the security gateway first. In order to meet this requirement, it must be ensured that the security gateway is the only interface between the two networks. Rules must be imposed specifying that no other external connections can be established by bypassing the security gateway.
• A security gateway may only be used as a protective transition area to the internal network. For this reason, the security gateway itself must only provide the services necessary for this purpose and not provide any other services, for example a web server. How to properly integrate information servers and other components running on separate systems into a security gateway is described in a series of separate safeguards for each of the different systems (see for example S 4.223 Integration of proxy servers into the security gateway or S 5.115 Integration of a web server into a security gateway.
• Administrative access to the components of the security gateway must only be possible over a secured connection, for example over a secure console, over an encrypted connection, or over a separate network (an administration network). A console should be set up in a server room (see S 2.4 Server room).
• A security gateway is based on the security policy defined for the network to be protected and only allows the connections specified in the security policy. It may be necessary to specify these connections in great detail (possibly including separate specifications of IP addresses, services, times, directions, and users).
• Suitable personnel must also be available to design and operate a security gateway. The amount of time required to operate a security gateway should not be underestimated. The evaluation of the recorded log data alone usually takes a lot of time. The administrator must possess in-depth knowledge of the IT components used and must also receive corresponding training.
• The users of the local network should only be forced to accept the minimum number of limitations possible due to the use of a security gateway.

A security gateway can protect the internal network against many of the risks involved when connecting to the Internet, but not all of them. When designing a security gateway and creating a security policy, it is necessary to keep the limits of a security gateway in mind at all times:

• A security gateway only checks the protocols and not the information transmitted. Checking the protocol can confirm, for example, that an e-mail was sent using proper commands, but such a check cannot provide any information on the actual contents of the e-mail.
  The filtering of active content may only be partially successful under certain circumstances because not every method of embedding active content can be detected.
• As soon as users are allowed to communicate over a security gateway, they can open tunnels with any other protocol through the communication protocol used. This means an insider could allow someone from outside access to internal computers or could use unauthorised protocols him-/herself. The unauthorised use of tunnel procedures is normally very difficult to detect.
• Restricting Internet access to specific web servers is practically impossible because many web servers can also be used via proxies. For this reason, it is easy to bypass the blocks defined for certain IP addresses.
• Software used for filtering based on web addresses (URLs) is often designed poorly. For example, it is possible that the software does not detect all address forms. The following example using the BSI web server should show which forms of address are available for use. The list is far from complete, since individual letters can also be represented by escape sequences.
  • www.bsi.bund.de
  • www.bsi.de
  • 194.95.176.226
  • 3261051106
• In addition, URL filters can be bypassed using "anonymisers".
• The filters for spam mail are not fully developed. No SMTP proxy can determine without a doubt if the recipient actually wants the corresponding e-mail or not. A spam mail should only be deleted when it is possible to reliably verify the sender of the email. This is not possible though using the conventional SMTP protocol alone.
• Security gateways do not provide protection against denial-of-service attacks. If an attacker disables the connection to the provider, for example, then even the best security gateway will not help. In addition, errors in the implementation of the protocols in end devices are always appearing, and these errors cannot be detected by security proxies.
• A security gateway can secure a network gateway, but it does not have any influence on the security of the communication in the network!
• Even security gateway components developed especially with security aspects in mind can contain programming errors in spite of the great care taken when programming.
• Security gateways can only offer limited protection against errors specified deliberately or accidentally in the configurations of the clients and servers to be protected.
• It may be possible to exploit back doors built into the software used through a security gateway. In extreme cases, the software of the security gateway itself contains back doors.
• The correct configuration of the components of the security gateway is often very demanding. Errors in the configuration can lead to security gaps or failures.
• If the documentation of the technical features of the security gateway provided by the manufacturer is poor, then errors during configuration and administration are much more likely.
• If the components of the security gateway do not provide enough performance, then the availability can be adversely affected. For example, if the computer on which an HTTP security proxy is running is not powerful enough (not enough memory or a processor that is too slow), then this can seriously affect the speed of Internet access.
• It cannot be prevented that attackers analyse the components of the security gateway with the help of vulnerability scanners.
• A security gateway cannot be protected against deliberate or accidental violations of the security policies and security concepts by the users.
• A security gateway does not protect against misuse of the approved communication by inside attackers.
• A security gateway does not protect against social engineering.
• If mobile end devices (laptops, PDAs, etc.) also used by employees when outside are connected to the internal network, then it is possible for malware (viruses, worms, Trojan horses) to infect the trustworthy network from these devices.
• A security gateway cannot protect the trustworthy network against infections from malicious software on removable media (e.g. CD-ROMs, diskettes, or USB sticks).

Review questions:

• Is there a concept for the security gateway which covers the intended use and the security objectives?
• Is the use of the security gateway mandatory for all network communication?
• Is administrative access to the components of the security gateway only possible over a secured connection?