S 3.301 Security gateway (firewall)
Description
A security gateway (often referred to as a firewall) is a system consisting of hardware and software components that is used to securely connect IP networks. To obtain secure connections, the technical communication capabilities are restricted to the capabilities properly defined in an security policy. Security in the case of connected networks means that only the desired accesses or data streams are allowed between different networks.
Security gateways are installed at the main connection point between two different trustworthy networks. Internet-to-Intranet connections are not the only example of networks with different levels of trustworthiness. For example, an organisation can have two internal networks with different protection requirements when the office communication network is separated from the network of the personnel department, which is used to transmit personal data requiring special protection.
The reason for the use of the term security gateway instead of the more commonly used term firewall is to illustrate that it usually takes more than a single device nowadays to secure a network gateway. Instead, a whole series of IT systems performing different tasks, e.g. packet filtering, protection against viruses, or monitoring the network traffic ("intrusion detection") are usually used today.
This module only describes the threats and safeguards which apply specifically to security gateways. In addition, the threats and safeguards which apply specifically to the IT system used to implement the security gateway also need to be taken into account. In many cases, the components of a security gateway are implemented on a Unix system, in which case the threats and safeguards described in module S 3.102 Servers under Unix must be taken into account in addition to the threats and safeguards described in the following.
Threat scenario
The following typical threats to the IT-Grundschutz of a security gateway are assumed to exist:
Organisational Shortcomings
| T 2.24 | Loss of confidentiality of sensitive data of the network to be protected |
| T 2.101 | Inadequate contingency planning for a security gateway |
Human Error
| T 3.3 | Non-compliance with IT security measures |
| T 3.9 | Improper IT system administration |
| T 3.38 | Errors in configuration and operation |
Technical Failure
| T 4.10 | Complexity of access possibilities to networked IT systems |
| T 4.11 | Lack of authentication possibilities between NIS server and NIS client |
| T 4.12 | Lack of authentication possibilities between X server and X client |
| T 4.20 | Overloaded information systems |
| T 4.22 | Software vulnerabilities or errors |
| T 4.39 | Software design errors |
Deliberate Acts
| T 5.2 | Manipulation of information or software |
| T 5.9 | Unauthorised use of IT systems |
| T 5.18 | Systematic trying-out of passwords |
| T 5.24 | Replay of messages |
| T 5.25 | Masquerade |
| T 5.28 | Denial of services |
| T 5.39 | Infiltrating computer systems via communication cards |
| T 5.48 | IP spoofing |
| T 5.49 | Abuse of source routing |
| T 5.50 | Abuse of the ICMP protocol |
| T 5.51 | Abuse of routing protocols |
| T 5.78 | DNS spoofing |
| T 5.143 | Man-in-the-middle attack |
Method recommendation
To secure the information system examined, other modules will need to be implemented in addition to this module. These modules are selected based on the results of the IT-Grundschutz modelling process.
A security gateway does not provide protection from attacks within the internal network. To protect the internal network against attacks from insiders, all necessary security safeguards must be implemented, even when using a security gateway. If the internal network is a Unix or PC network, then the security safeguards described in the corresponding modules must be implemented.
The security gateway should be set up in a separate server room. The safeguards to implement in this case are described in module S 2.4 Server room. If no server room is available, then the security gateway can also be set up in a server cabinet as an alternative (see module S 2.7 Protective cabinets). If security gateway will not be operated by the organisation itself but rather by a service provider, then module S 1.11 Outsourcing must be applied. In particular, the recommendations in S 5.116 Integration of an email server into a security gateway should be taken into account.
A series of safeguards need to be implemented to set up a security gateway successfully, starting with the design and purchasing phases and continuing through to the operation of the components. The steps to take to accomplish this as well as the safeguards to implement in each phase are listed in the following.
Planning and design
In order to connect networks with different protection requirements to each other, firstly a concept for connecting networks using a security gateway should be developed (see S 2.70 Developing a concept for security gateways). Amongst other things, the following should be considered here:
- specifying the security objectives
- adapting the network structure
- identifying the basic requirements
A policy for security gateway must be drawn up that specifies which information, services, and protocols are treated in what way, i.e., for example, which services are allowed and who may use them (see S 2.71 Establishing a policy for a security gateway). This includes the following aspects:
- selecting the communications requirements
- selecting the services (before selecting the services the explanations and general conditions stated in S 5.39 Secure use of protocols and services should be read.
- organisational regulations
In addition, a security policy must be drawn up for the security gateway that provides specifications and information on the secure operation and secure administration of the security gateway or its individual components (see S 2.299 Drawing up a security policy for a security gateway).
For secure connection of the organisation's networks to the Internet, a concept for the type of the internet connection and its reliable protection must be developed (see S 2.476 Concept for secure Internet connection).
Purchasing
Before purchasing the components of the security gateway, a basic structure for the security gateway which suits the particular organisation should be selected (see S 2.73 Selecting suitable basic structures for security gateways). Criteria for purchasing packet filters and application-level gateways can be found in S 2.74 Selection of a suitable packet filter and S 2.75 Selection of a suitable application-level gateway.
There are different options for establishing an Internet access. In addition to the appropriate access technology, an Internet Service Provider (ISP) has to be selected. The ISP provides the connection to a dial-in node and can also offer additional services (see S 2.176 Selection of a suitable Internet service provider).
Implementation
To appropriately set-up a security gateway, the following aspects should be implemented, amongst other things:
- drawing up and implementing filter rules (see S 2.76 Selection and implementation of suitable filter rules)
- implementing the IT-Grundschutz safeguards for the components of the security gateway
- implementing the IT-Grundschutz safeguards used to monitor the IT systems of the internal network
- taking the general conditions for the secure use of the individual protocols and services into account (see S 5.39 Secure use of protocols and services)
- integrating any additional components (see S 2.77 Integration of servers in the security gateway)
Operation
To securely operate a security gateway over the long term, a series of safeguards is required (see S 2.78 Secure operation of a firewall). Amongst other things, these include:
- regularly checking the currency and correctness of the settings
- modifying in line with changes and tests
- logging activities on the security gateway and evaluating the log data (see S 4.47 Logging of security gateway activities)
- making contingency plans for the security gateway (see also module S 1.3 Business continuity management)
- performing data backups (see module S 1.4 Data backup policy)
Disposal
Components of the security gateway can contain a large amount of security-related data such as configuration or password files. For this reason, all security-related information must be deleted from the devices prior to their disposal (see S 2.300 Secure withdrawal from operation or replacement of components of a security gateway).
Contingency Planning
If a security gateway or even only individual components contain errors or fail, then this can have immediate or serious consequences. For this reason, adequate precautions must be taken in case of emergencies (see S 6.49 Data backup in a database).
There can be a number of reasons for deciding against the use of a security gateway. These could be the purchase costs or the administrative effort, or the fact that the existing residual risks cannot be taken into consideration. If an Internet connection is still required, a stand-alone system can be used as an alternative (see S 5.46 Installing stand-alone-systems for Internet use).
The bundle of safeguards for security gateways is presented in the following.
Planning and design
| S 2.70 | (A) | Developing a concept for security gateways |
| S 2.71 | (A) | Determination of a security gateway policy |
| S 2.299 | (A) | Drawing up a security policy for a security gateway |
| S 2.301 | (Z) | Outsourcing the security gateway |
| S 2.476 | (A) | Concept for secure Internet connection |
Purchasing
| S 2.73 | (A) | Selecting suitable basic structures for security gateways |
| S 2.74 | (A) | Selection of a suitable packet filter |
| S 2.75 | (A) | Selection of a suitable application-level gateway |
| S 2.176 | (Z) | Selection of a suitable Internet service provider |
Implementation
| S 2.76 | (A) | Selection and implementation of suitable filter rules |
| S 2.77 | (A) | Integration of servers in the security gateway |
| S 3.43 | (C) | Training the security gateway administrators |
| S 4.224 | (Z) | Integration of VPN components into a security gateway |
Operation
| S 2.78 | (A) | Secure operation of a firewall |
| S 2.302 | (Z) | Security gateways and high availability |
| S 4.47 | (A) | Logging of security gateway activities |
| S 4.100 | (C) | Security gateways and active content |
| S 4.101 | (C) | Firewalls and encryption |
| S 4.222 | (B) | Correct configuration of security proxies |
| S 4.223 | (B) | Integration of proxy servers into the security gateway |
| S 4.225 | (Z) | Use of a logging server on a security gateway |
| S 4.226 | (Z) | Integration of virus scanners into a security gateway |
| S 4.227 | (C) | Use of a local NTP server for time synchronisation |
| S 5.39 | (A) | Secure use of protocols and services |
| S 5.46 | (A) | Installing stand-alone-systems for Internet use |
| S 5.59 | (A) | Protection against DNS spoofing in authentication mechanisms |
| S 5.70 | (A) | Network address translation (NAT) |
| S 5.71 | (Z) | Intrusion detection and intrusion response systems |
| S 5.115 | (Z) | Integration of a web server into a security gateway |
| S 5.116 | (Z) | Integration of an email server into a security gateway |
| S 5.117 | (Z) | Integration of a database server into a security gateway |
| S 5.118 | (Z) | Integration of a DNS server into a security gateway |
| S 5.119 | (Z) | Integration of a web application with web, application, and database servers into a security gateway |
| S 5.120 | (A) | Handling of ICMP on the security gateway |
Disposal
| S 2.300 | (C) | Secure withdrawal from operation or replacement of components of a security gateway |
Contingency Planning
| S 6.94 | (C) | Contingency planning for security gateways |