S 4.101 Firewalls and encryption
Initiation responsibility: Head of IT, IT Security Officer
Implementation responsibility: IT Security Officer, Administrator
Since data is sent using unforeseeable routes and nodes on the internet, the sent data should only be transmitted in an encrypted form, as far as possible. Encrypting the data traffic via the internet may be implemented in two different ways:
- encryption on the security gateway and/or network connection elements that may be used for establishing secure sub-networks,
- encryption on the terminal devices that is used by the users depending on the demand, for example.
Both procedures have specific advantages and disadvantages in favour of one or the other variants depending on the application context.
Encryption by the security gateway
In order to exchange data with external communication partners using a public network and/or to grant these access to one's own network, it may make sense to establish Virtual Private Networks (VPNs). For this, all connections from and to these partners should be encrypted so that unauthorised persons may not access these connections. Numerous hardware and software solutions can be used for establishing encrypted connections. If only a few properties are to be connected to each other, hardware solutions based on symmetric cryptographic procedures constitute a particularly simple and secure solution.
Information on the integration of VPN components into security gateways can be found in S 4.224 Integration of VPN components into a security gateway.
Encryption and decryption may be performed on different devices, if required. For example, a hardware solution in the packet filter could work as encryption device. This particularly makes sense if no unencrypted communication is to be performed using this device.
Integrating the encryption on the ALG provides the advantage of easier (centralised) user administration. Moreover, an attacker who managed to gain control of an external information server is not able to eavesdrop on the encrypted communication.
Encryption on the terminal devices
In order to protect the confidentiality of certain data, particularly when sending emails, using mechanisms allowing end-to-end encryption is recommendable.
For this, the freely available program package PGP (Pretty Good Privacy) is very often used for the email service, for example (see S 5.63 Use of GnuPG or PGP), and the Secure Shell protocol (SSH) is used for accessing other computers. For trustworthy data transmission with selected partners on the internet, only transmission programs and protocols supporting an encryption of the transmitted data should be used. Insecure clear text protocols such as Telnet and FTP should not be used in public networks without taking additional safeguards (for example, tunnelling using an encrypted connection or a real VPN).
On the other hand, end-to-end encryption of the data is also a huge problem for the efficient use of filter mechanisms of a security gateway.. If transmitting encrypted data using the security gateway is permitted (e.g. SSL), filters on the application level are no longer able to check the user data for viruses or other malware, for example. Encryption also significantly limits the logging options.
Having the data traffic temporarily decrypted by the security gateway may be a solution for this problem. For example, there are corresponding proxies for SSL terminating the SSL connection at the security gateway and making the decrypted data flow available for filtering. If required, the data can then be re-encrypted for the transmission to the terminal device.
It is not possible to provide any general recommendation in favour of or against the use of encryption using the security gateway. This depends on the requirements in the individual case and therefore an evaluation in the application context should be performed.
| On the security gateway: | On the terminal devices: |
|---|---|
| + central data verification+ central key distribution+ detailed accounting - access from the security gateway to the internal network - no end-to-end security | + end-to-end security + no logging issues +/- user-dependent - no control options on the security gateway - public key infrastructures are often required |
Table: Advantages and disadvantages of the different implementation options
If it is defined for certain services or protocols that end-to-end encryption is to be used (and/or approved), it may become necessary to take additional safeguards for the terminal devices. This should be checked within the framework of an additional security analysis.
Review questions:
- Have the requirements as to when communication with external partners must be encrypted for the security gateway been defined based on the organisation's security policies?