S 2.71 Determination of a security gateway policy

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator, IT Security Officer

The security gateway policy determines the behaviour of the security gateway. It defines what information, services and protocols the security gateway handles in which way and who is allowed to use them. This policy should not be confused with the security policy for the security gateway in which provisions are laid down for the secure operation of the security gateway itself.

Communication requirements

The first step in establishing a policy is to determine which types of communication with the external network are permitted. When defining the communication requirements, the following questions in particular must be answered:

• Which information should the security gateway allow to leave outwards and/or to enter inwards?
• Which information should the security gateway conceal (e.g. the internal network structure or the user names)?
• Which authentication procedures should be used inside the network requiring protection and/or for the security gateway (e.g. one-time passwords or chip cards)?
• Which access possibilities are needed (e.g. only via an Internet service provider or also via a modem pool)?
• What data throughput is to be expected?

Selection of services

The communication requirements are the basis for determining which services are permitted in the network requiring protection.

A distinction must be made between those services permitted for the users in the network requiring protection and those permitted for external users.

If, for example, e-mail is to be received (which is generally the minimum requirement), the security gateway must allow the SMTP protocol to pass through.

The policy must clearly state which services are permitted for which users and/or computers and for which services confidentiality and/or integrity must be guaranteed. Only services which are absolutely necessary should be permitted. All other services must be forbidden. This must also be the default setting: All services for which there are no explicit rules must be forbidden.

It must be specified for each permitted service which functions of the protocol used may be utilised and which should be forbidden (e.g. the "PORT" command from FTP to prevent active FTP) and which transmitted user data should be filtered

It must be defined on which days of the week and at what times of the day the provided services can be used.

For short-term changes (e.g. for tests) or new services, exceptions to these rules should be provided for.

The filters must fulfil certain requirements: the packet filters using the header information of the services of layers 3 and 4 of the OSI layer model (IP, ICMP, ARP, TCP and UDP) as well as the security proxies using the information of the services of the application layer (e.g. Telnet, FTP, SMTP, DNS, NNTP, HTTP). An overview of aspects to be observed for correct operation of the various individual protocols and services can be found in S 5.39 Secure use of protocols and services. Using this as a basis, filter rules must be drawn up (see S 2.76 Selection and implementation of suitable filter rules).

Organisational regulations

In addition to the establishment and implementation of filter rules, the following organisational regulations are required:

• Persons responsible both for the design and the implementation and testing of the filter rules must be appointed. It must be clarified who is authorised to alter filter rules, e.g. for testing new services.
• It must be defined which information is logged and who evaluates these protocols. All connections which were correctly established and those which were denied must be logged. Logging must comply with the data protection provisions.
• The users must be informed in detail of their rights, particularly with regard to the extent of the user data filtering.
• It is recommended to make documentation available to the users specifying which services can be used to what extent and whether certain issues need to be observed.
• Attacks on the security gateway should not only be successfully prevented, but also detected quickly. Attacks can be detected by evaluating the log files. However, the security gateway should also be able to issue warnings or even trigger actions on the basis of predefined events such as repeated entries of incorrect passwords on an application level gateway or attempts to establish forbidden connections.
• It must be clarified which actions are started in the event of an attack, for example whether the attacker should be traced or whether the external network connections should be disconnected. As this can have a great effect on network operations, persons responsible who are able to decide whether there is an attack and which corresponding actions are to be initiated must be appointed. The tasks and authorities for the persons and functions in question must be clearly stipulated.

The following questions must be clarified when determining the policy:

• What damage can be caused to the network requiring protection if the security gateway is bypassed? As there is no such thing as absolute protection and security, a decision must be taken as to whether the maximum possible damage is acceptable or whether additional safeguards must be taken.
• What residual risks exist when the security gateway is operated properly? These may be vulnerabilities in the equipment and operating systems used.
• How quickly is an attack on the security gateway detected?
• What protocol information is still available after a successful attack?
• Are the users willing to accept the restrictions caused by the security gateway?

The decisions made must be documented in the policy. In addition, it is important that the relevant information and reasons on which the decisions are based are also documented in such a manner that they can be understood at a later point in time (for instance, when revising the policy). This background information does not necessarily have to be included in the policy itself; instead, it is recommended to draw it up in a separate document.

Review questions:

• Is there a policy for the security gateway defining and documenting the behaviour regarding information, services and protocols in a comprehensible manner?
• Has it been specified that only services and programs which are absolutely necessary are allowed to be available on the security gateway?
• Have persons responsible both for the design and the implementation and testing of the filter rules been appointed?
• Are countermeasures for detected attacks on the security gateway defined?
• Is the security gateway able to issue alerts for predefined events?
• Are the present residual risks when the security gateway is operated properly known?