October 2015 Issue No: 1.1. CESG Architectural Pattern No. 17 Internet Gateways

(1)

CESG Architectural Pattern No. 17

Internet Gateways

(2)

Architectural Pattern No. 17

Internet Gateways

Issue No: 1.1 October 2015

(3)

Purpose & Intended

Readership

This Architectural Pattern is intended to assist system integrators and accreditors undertaking work for HMG on HMG systems by:

 Raising awareness of efficient, secure solutions to commonly raised business requirements

 Building an understanding of the capabilities and limitations of the Architectural Pattern in the context of a wider system

 Identifying the role of and requirements placed on each component of the Architectural Pattern

Assurance

Adherence to the principles set out in an Architectural Pattern does not automatically result in a secure system. It remains the role of the accreditor in collaboration with the system integrator, to satisfy themselves that the realisation of this Architectural Pattern and the implementation of each component is appropriate to the context in which it is deployed.

CESG provide a range of services that may be used to inform this process.

Summary

This Architectural Pattern describes security controls which can be used to secure an organisation’s access to the Internet.

This Pattern deals with generic usage scenarios, such as browsing the Internet, sending emails and accessing other generic uses. For specific use cases, especially where there is a perceived level of increased risk, it is recommended that you seek advice from CESG.

Additionally, this Pattern only highlights risks and mitigations. It is expected that the exact implementation will be appropriate to the environment and overseen by a CCP Certified Architect.

Feedback

CESG welcomes feedback and encourage readers to inform CESG of their experience, good or bad in this document. Please email: [email protected]

(4)

Chapter 1 - Scope

Business Scenario

1. This Architectural Pattern is intended to discuss security controls and considerations which should be taken into account when an organisation wishes to connect to services outside of their organisations perimeter.

2. This Pattern discusses a generalised gateway solution to achieve this business requirement.

3. This Pattern also provides examples of how to setup common services such as web access and email in line with the general recommendations.

4. It does not cater for organisations which may have specific requirements such as secure transfer of data to third parties, however the implementation of this Pattern should not prevent other usage scenarios. The principles in this Pattern can be used to implement more specific requirements where appropriate.

5. This Pattern is aimed at instilling good practice in network gateways and is applicable to networks running at OFFICIAL (with descriptors). Networks running at a higher classification will require more stringent controls and the architect may wish to consult CESG.

6. Depending on the size of the network, the architect may need to take a pragmatic approach to which elements of the Pattern are required for the network in question.

Pattern Overview

7. The Pattern aims to minimise the risks to the internal corporate network by limiting the scope for malicious code to be imported into or executed on the protected network and by limiting the scope for data leakage.

8. The Pattern uses a combination of border controls, device controls and monitoring to manage the risks of communicating to the Internet.

9. Where possible, organisations should attempt to use centrally managed gateways such as the GSi / PSN Internet Gateway as this allows for all departments, large and small, to be protected to the highest level by centralised controls and defensive monitoring.

Risk Table

10. Table 1 below identifies the principle risks, architectural controls and residual risks associated with this Architectural Pattern.

(7)

ID Risk Architectural Control Residual Risk

1 A user requests data from a remote service which contains malicious code which may harm client PCs

Depending on threat and risk appetite, the gateway uses whitelists, blacklists of known bad sites or site categorisation. It also inspects data being sent to the client

Remote servers which are deemed to be trustworthy may be compromised and serve exploit code which is then executed by the client

The clients restrict execution of scripts and plugins to reduce the attack surface for malicious

content to exploit

Malicious content making use of zero-day

vulnerabilities or exploit packing may not be detected

2 Malicious code which has managed to exploit a client device attempts to beacon or exfiltrate data to a command and control server

The gateway receives regular blacklist updates and blocks requests to known bad sites

Modern malware often rapidly changes command and control servers and domains to evade this type of blacklisting

The gateway inspects traffic and attempts to detect known malware command and control traffic

Some malware may obfuscate its C&C traffic to evade this detection The IDS / PM system

detects unusual traffic flows and raises an alert to the security team

Heuristic detection is inexact. Some malware traffic may not get flagged as suspicious.

The gateway only allows outbound connections on ports and protocols which support a specific business requirement

Malware may disguise its traffic to look like legitimate business traffic

3 An email containing a malicious file is sent to the user

The mail server rejects encrypted file attachments and filters potentially

dangerous file types as well as scanning the incoming mail for viruses

Signature based anti-virus is often defeated by modern malware packers increasing the risk that the malicious file is delivered to the user

The client device is locked down to reduce the risk of malicious code being able to execute or persist

Malicious code may be able to exploit vulnerabilities in the device, gaining

execution 4 An attacker attempts to

directly exploit the core mail server

The border firewall blocks all non-mail ports

There may be an unknown or un-patched vulnerability in the core mail server which allows an attacker to send a specifically crafted email to exploit the server. This risk is considered minimal at this impact level

(8)

ID Risk Architectural Control Residual Risk

For additional assurance, a Layer 7, SMTP aware security device can be used to scan and filter SMTP messages before they reach the mail server

More specialised (possibly targeted) attacks may be able to fool the Layer 7 device

5 Classified data is

maliciously or accidentally sent from the core network to the Internet

Controls discussed above at the gateway and IDS help to detect malware exfiltration

Where accidental release is a concern, requiring users to label messages with a “releasable” marking and implementing dirty word scanners in the gateway or email servers as well as manual review and release can help to detect

accidental or malicious release of data from a user

It is very difficult to prevent this form of leakage without severely impacting

usability. However

knowledge that a leak has taken place can be gained from the controls described

Table 1 – Risks, Architectural Controls and Residual Risks

Assumptions

11. We assume that the network being protected is running at OFFICIAL. For higher assurance networks, different, more stringent controls may be required. 12. We assume that the organisation wishes to connect their network to the Internet

(i.e. a totally un-trusted network).

13. We also assume that the architect is following good practice security principles, including:

 We assume that all devices have non essential ports and services disabled

 Firewalls must only permit traffic which is essential for system operation. Other ports and protocols must be blocked

 Networks existing in different trust domains (e.g. Internet facing web servers vs internal systems) are appropriately separated (out of the scope of this Pattern)

 All components must be still under vendor support and patched regularly. We would expect all devices to receive critical security patches as soon as practical

(9)

Standards and Guidance

14. This Pattern should be used in conjunction with other CESG standards and guidance.

15. Specifically, the architect may wish to consult

 CESG Architectural Pattern No. 4 (AP4) (reference [a]) and CESG Architectural Pattern No. 14 (AP14) (reference [b]), Import and Export Architectural Patterns for principles around moving data in and out of secure networks

 CESG Architectural Pattern No. 1 (AP1) (reference [c]), Auditing and Monitoring Across Security Domains

 CESG Good Practice Guide No. 13 (GPG 13) (reference [d]), Protective Monitoring for principles around how systems should be monitored

 CESG Good Practice Guide No. 17 (GPG 17) (reference [e]), Client System Security for principles around securing endpoints

 CESG Good Practice Guide No. 27 (GPG 27) (reference [f]), Online Social Networks for information regards threats specific to using social media sites

(10)

Chapter 2 - High-Level Overview

Principles

16. When building an Internet gateway, there are various key principles which should be followed:

 Outbound Connections – Connections should always be initiated from the more secure domain into the less secure domain (e.g. core network to DMZ). There may be situations where this is not possible, i.e. a DMZ mail server may need to connect into the core network to pass messages. This must be the exception, not the rule and appropriate monitoring should be in place to detect compromises

 Masking Internal Architecture – The internal architecture of your network (i.e. layout, IP addresses etc) should not be exposed to the external network. For example, using Network Address Translation so that the external network only sees a single IP address for the entire internal network

 Common Aggregation Point – All connections should pass through a common aggregation point. For example, for web browsing, all clients should be forced through a proxy server. This helps achieve the above point and provides a central point where monitoring can take place

 Encrypted Tunnels – Encrypted tunnels (such as SSL web browsing) increase the risk of malware entering the network undetected. We recommend that where practical, these tunnels should not be allowed to the untrusted network without being broken and inspected at the gateway. Sometimes this may not be practical (e.g. administrators needing SSH access to remotely hosted servers). In these cases, a pragmatic approach should be adopted where as many gateway controls as possible are implemented. See example architectures later

 Whitelisting and Blacklisting – Where practical, connection whitelists should be implemented. For example, whitelisting servers to which SSH connections are allowed to traverse the gateway firewall. Some activities, such as web browsing, do not lend themselves to whitelisting. In these cases it is recommended that a whitelist is used but when an unknown resource is requested, the user is asked to acknowledge that they are visiting an uncategorised resource. Blacklists should be used as an additional control to prevent access to obviously bad sites, but should not be relied upon exclusively as it is impractical to blacklist every bad site on the Internet

 Assured Products – Where reliance on a security feature is required, assured products checked by CESG approved schemes such as Commercial Product Assurance (CPA) should be used. The non-use of assured products requires a risk managed approach and it is recommended that non-assured products are replaced with assured versions when they become available

(11)

 Privileged Accounts – Privileged accounts should always be allocated to named administrators (as opposed to being generic accounts) and should not be allowed to connect to less trusted networks (such as browsing the Internet and viewing email) unless there is an unavoidable, specific, approved and audited business need

 Server Access to Untrusted Network – Servers in the core network should not have direct Internet access unless there is a specific, authorised business need. I.e. if an administrator needs to install software onto a core network server, they should obtain it on a development box and then copy it to the server as opposed to browsing the Internet on the server

 Break or Inspection on All Layers – Where practical, all layers (up to application, layer 7) should include some form for protocol break or inspection (depending on threat). This could include be as simple as passing connections through a proxy or may be more in depth, depending on specific threats

Generic Architecture

17. When designing a gateway, there are certain classes of control which should be employed. Below is a high level schematic of how a comprehensive gateway could be structured.

18. Note that although each component is shown as a separate block, it is possible that a single device may perform multiple functions. Should this be the case, the architect should consider how many security enforcing functions a single box should be allowed to perform, i.e. a single box that separates raw Internet from the OFFICIAL core network and performs the content inspection for the network would be a high risk design.

19. Additionally, the architect should adopt a pragmatic approach for smaller, lower risk networks where it is not appropriate or practical to implement all of the controls listed. For example, a full IDS/IPS solution for a low risk organisation of a few tens of employees may not be proportionate.

(12)

20. The components in the gateway zone may be in a different order depending on exact implementation. Any encrypted tunnels should always be terminated before content inspection or IDS / IPS is performed.

21. Component descriptions:

 Core Network – This is the network to be protected from the untrusted network. For the purposes of this Pattern, we will consider it to be protecting OFFICIAL data

 Core Firewall – This firewall sits at the boundary of the core network and prevents a compromised device in the gateway zone from directly attacking the core network

 Aggregation Point – This is a single point (e.g. a proxy server) that clients in the core network can connect to in order to utilise a specific type of service (such as web browsing). It provides a single point through which user authentication, audit and monitoring can take place

 Content Inspection – This will analyse the traffic exiting the network to perform data leakage prevention and traffic entering the network to detect and block possible malicious or high risk content

 Intrusion Detection / Prevention System – This attempts to detect or prevent attacks on the network, based on signature or heuristic matching of packets entering and exiting the network. Ideally an IDS system should not be inline, but should be fed by a network tap. If the department chooses to implement an IPS, this is likely to require an inline element. The architect should be aware of the availability risks of implementing an IPS, or inline IDS system as failure, or false identification of attacks could result in a self imposed denial of service

Core Network Tunnel Termination Content Inspection IDS / IPS Border Firewall Core Firewall Untrusted Network Gateway Zone Tunnel Rebuild Aggregation Point

(13)

 Tunnel Termination – As stated in the principles above, direct encrypted tunnels between the core network and an external server is strongly discouraged. This component will act as a man-in-the-middle of any encrypted tunnel, proxying the encryption and allowing inspection of underlying content

22. In addition to these components, additional items may be required in the gateway zone. For example, for user logging on the aggregation point or for mail routing if a mail relay is used, details from the corporate directory server may be required. If this is the case, care should be taken that the security of core network credentials are not compromised.

23. One example solution to these conflicting requirements may be to implement a read only domain controller in the gateway zone which only contains usernames and other required information and is mirrored from the core network periodically.

24. Implementing such a read only domain controller could also allow the mail relay to ascertain whether an incoming email is addressed to someone that actually exists in the organisation before forwarding it.

(14)

Chapter 3 - Sample Architectures

Overview

25. Taking the high level principles and classes of security control above, we can derive some sample architectures. The examples below should be treated as an aid only and may need to be adapted for the specific business scenario.

Use of Centralised Gateways

26. The ICT Strategy encourages departments to re-use existing services where possible, e.g. the use of a centralised PSN connected gateway. As such, where practically possible, Internet connections should pass through a centrally managed PSN gateway. Each available PSN gateway may implement different controls. These sample architectures are to aid the architect in deciding which gateway is appropriate for their organisation.

27. Certain business requirements may necessitate the use of non-centrally managed gateways. In such cases, these sample architectures can be used as a basis for building a custom Internet gateway.

Governance

28. It is likely that any gateway will end up needing to cope with more than a single protocol. It is also likely that the number of required protocols will increase over time.

29. This will invariably result in additional rules needing to be added to devices such as firewalls and content checkers.

30. For this reason, it is critically important that the gateway, its associated rule sets and the reasoning behind them are documented.

31. When changes are required to the gateway, the existing rule base and proposed changes should be reviewed by the organisation’s security team to ensure that the combination of different permits and denies on the various devices still protects the network as expected.

Web Browsing

32. This sample architecture shows how an organisation could setup a web browsing gateway.

33. We will consider two classes of organisation:

 Low Risk - A low risk organisation such as a local council

 High Risk – A high risk organisation such as a central government department

34. The architecture shown below is an overview of the components required. This architecture will be familiar to any network professional who has setup Internet access in a business environment. However, it is important to note that the security provided by this Pattern is more subtle, and is gained from how the

(15)

components are configured. Component configuration is discussed in the following sections.

Internet

Core Network DMZ External Network

Decreasing Trust Proxy / Content Filter Border Firewall Client PCs Core Firewall Web Browsing Data Flows Network Connections

Figure 2 - Architecture Overview – Simple Web Browsing Gateway

35. You will note that there is a single box marked “Proxy / Content Filter”. In reality, depending on implementation and vendor specific requirements, this may be multiple boxes.

Key Components

36. For web browsing, the key security components, configured in line with the following sections are as follows:

 The client – Client machines should be appropriately locked down, in

accordance with reference [g] and secured to minimise the risk of compromise

 Core Firewall – Protects the core network from compromised servers in

the DMZ

 Proxy Server / Content Filter – Acts as an aggregation point for all traffic

and performs security enforcing functions such as content scanning of files, SSL interception etc

 Border Firewall – Reduces the attack surface of the DMZ and protects

DMZ servers

Security Controls

37. This Pattern outlines an architecture for browsing the Internet which takes into consideration the following threats and situations:

 Websites which attempt to get the user to run malicious software

 Websites which contain malicious Javascript code designed to execute a “drive by” attack

 The increased prevalence of malicious code on “safe” sites (e.g. the 2011 MySQL homepage attack)

(16)

 Users accidentally or maliciously attempting to post classified information to the Internet. For a small, low impact organisation, we assume that data leakage prevention is too costly to maintain and that the risk is being accepted

 The increased threat from a targeted attack by means of sites which identify an individual as an employee of the organisation (e.g. social networking and forums). For a low risk organisation, it is assumed that this is not a significant threat

39. It is suggested that you read CESG Technical Threat Briefing No. 1 (TB1), Assessment of Technical Threat (reference [h]) if you require a detailed analysis of threats to corporate systems while browsing the Internet.

Expected Security Controls

40. For a low risk organisation, the following controls would be expected. For all of these controls, there may be business needs where specific users gain exemptions from these controls.

 User and machine logging on the proxy server with the ability to tie a specific web event to a specific machine / user combination

 Filtering of downloaded files to virus scan incoming data

 Whitelisting / blacklisting of websites to reduce the risk of a user navigating to a site which may be a security risk

 Good practice client configuration (supported, patched software, configured inline with relevant security guidance)

 Scanning of incoming files for malicious content

 MIME type blocking of potentially dangerous file types

 Consideration of policy on websites using HTTPS. An increasing number of sites use HTTPS. This can make it more difficult to inspect user web browsing for malicious content and generally additional proxy modules or devices are required. This risk must be addressed and either accepted, a subset of HTTPS websites allowed or a full HTTPS inspection module added to the design

41. For a high risk organisation, the following addition controls could be considered depending on specific threats:

 HTTPS interception and proxying to inspect content being transmitted in HTTPS sessions

 Intelligent monitoring for malware at the gateway (e.g. looking for beacon traffic, heuristic detection, bad user agents etc)

 Application aware filtering and inspection at the gateway and checking for unexpected application communications

 Additional client lockdowns, such as disabling JavaScript and active content (note that this may seriously degrade usability)

(17)

 Active content stripping at the gateway (such as removing JavaScript or active content as sites are requested)

Security Considerations

42. It should be noted that no single one of these controls provides the requisite level of defence by itself, but in union, the level of protection provided is increased.

43. For a low risk organisation, it may be appropriate to use a “proxy-on-a-stick” topology as opposed to having the proxy inline. This is where the proxy only has a single network connection with pre and post proxy traffic traversing the same network segment. There is a risk using this architecture that traffic may leak out of the network due to misconfiguration or failure of devices. There is also a risk as potentially dangerous traffic shares the same network segment as filtered traffic.

44. It must not be possible for a client to bypass the security controls (e.g. if the user removes the proxy configuration, it must not be possible to get a direct Internet connection).

45. It is recommended that where possible, for security enforcing functions, that CPA assured components should be used in preference to non-CPA assured components.

46. Some architectures require an intermediary network between the OFFICIAL network and the Internet. For example, the organisation may operate a low security permissive Internet browsing network with a more secure corporate network connected to this. It is important that this does not increase the risk to the OFFICIAL network through a less stringent combined control set. Examples of this may include:

 Allowing more inbound connections to the intermediary network for some services and then inbound connections to the OFFICIAL network from intermediary network for other services

 Having less controls on a proxy as it is only for the intermediate network, but then later allowing users from the OFFICIAL network to browse the Internet without a further proxy or upgrades to the controls on the original proxy

Alternatives

47. The architect should consider whether allowing machines on the core network Internet access via a gateway represents an unacceptable risk based on the organisation's threat profile. Similarly it should be considered whether the restrictions required for web browsing from terminals are likely to adversely impact business requirements. If the risk is deemed too high, or restrictions too great, alternatives can be investigated. These include:

 A browse down solution from the core network to a lower trust domain which has less restricted Internet access. See below. Limited web browsing from the

(18)

core network with separate machines on a separate “Internet” network for users requiring less constrained access

Browse Down Internet Access

48. If it is decided that it is too risky or too limiting to allow machines on the core network access to the Internet, an alternative is to provide an Internet “jump box” using a “Browse Down” architecture.

49. A CESG Architectural Pattern is being developed to fully describe this architecture. In the mean time, the key principles are listed below. If you require further guidance, please contact CESG.

50. In a Browse Down architecture, a thin client infrastructure is setup in a DMZ area, separated from the core network.

51. When a user on the core network wishes to access the Internet, they use a remote access tool to connect to the thin client server from where they can access the Internet.

52. The server and client must be appropriately locked down to minimise the risk of malicious code being able to infect the client (core network) via the DMZ server, but still allowing business function. The architect should consider the specific threats to the organisation, but some lockdowns which should be considered include:

 Preventing the sharing of drives and printers from the client to the server

 Using a basic protocol which does not support the offloading of tasks such as video rendering to the client

 Not supporting the pass through of USB devices

 Disabling copy and paste between the client and server. This is particularly useful if data leakage is a concern

 Using a pool of virtual machines for client connections which are reverted to a known good state after each client session to make it difficult for malware to gain persistence

53. Clients connecting to the thin client service must be authenticated, but the DMZ must not be allowed access to the core network directory server. It is possible to either setup completely different authentication on the browse down server or to clone the core network directory server, but use different passwords.

54. If using this architecture, it must still be possible to tie each web activity to an individual and machine on the core network.

55. This architecture does not by itself solve the data leakage issue, but can help (through mechanisms such as the disabling of copy and paste).

(19)

File Transfer

56. Many organisations will need to share files in an automated fashion with other parties. This often occurs using File Transfer Protocol (FTP) or similar measures. The principles described above for Internet browsing apply equally to file transfer. Additionally, the following should be considered.

57. In line with the general principles outlined above, FTP connections should be initiated outbound (i.e. the client on the core network and the server on the lower assurance network). Inbound FTP connections are out of scope for this Pattern.

58. Secure FTP (SFTP) must not be used to directly connect a machine in the core network to a machine in the untrusted network.

59. The content checker should scan the files being transferred for signs of malicious content.

Internet Email

60. As well as web browsing, an Internet gateway may be asked to handle email traffic destined for or received from the Internet. This paper considers the provision of OFFICIAL email from the core network to endpoints on the Internet. As with file transfer, the principles outlined in Internet browsing apply equally to this architecture.

Internet

Decreasing Trust

Mail Relay Border Firewall Mail Server Core Firewall

E-Mail

Data Flows

Network Connections

E-Mail

Figure 3 - Internet Email

Key Components

61. The key security components for providing two way email are as follows:

 The Mail Server – Should be appropriately configured and patched to

reduce the risk of compromise

 Core Firewall – Protects the core network from compromised servers in

the DMZ

 DMZ Mail Relay – Sends and receives email to and from the Internet.

Scans incoming email for malicious links, and attachments. Silently drops mails not destined for known internal addresses

(20)

 Border firewall – Reduces the attack surface of the DMZ and protects

DMZ servers

Other Non-Interceptable Protocols (SSH / VPN / Remote Desktop Access)

62. Often there are situations where protocols using either proprietary encryption or other technologies make it difficult to pass through a gateway.

63. Examples of these protocols include SSH for remote server administration, VPNs for connecting to partners and remote desktop access for remotely accessing machines (e.g. for administration purposes).

64. For a low risk organisation, it may be appropriate to directly connect to these services. In this case, the following controls should be applied:

 Restrict protocol functionality to reduce risk. For example, in remote desktop, disable clipboard, drive and printer sharing

 Only allow connections to a small number of specified endpoints which have been specifically authorised as being required for business purposes

 Ideally restrict outbound connections to be from a subset of machines, such as administrator workstations

 Generate an audit message from the firewall for each connection, recording the originating device and destination server

 If files need to be copied from the server, they should be subject to the same checking as if they had come from an untrusted source

 As well as these technical controls, good procedures are also recommended. Users should be trained in the risks posed and only users with a defined business need should be allowed to make such connections

65. For high risk organisations, a different set of controls is recommended:

 Use of a “jump off box”; a locked down machine which sits in a DMZ. The user connects to this box and then on to the target server

 This can be thought of as a browse down solution and isolates the core network from any compromise via the client

 For OFFICIAL, a well locked down remote access protocol with enhanced features such as local rendering and file transfer disabled provides reasonable assurance. However, if there are specific risks to the network from the data being accessed across the gateway, the architect may wish to investigate formally assured products

 From this box, the same controls as for the low risk scenario above should be applied

 Any files to be imported to the core network from this box should be subject to the same content checking controls as if they had come from an untrusted source

(21)

Chapter 4 - Firewalls

Function

66. The firewalls play a traditional role of preventing unwanted connections between security domains. The following lists some of their properties:

 The firewalls must only permit ports which are required for the gateway to operate (i.e. if only web browsing, as opposed to serving is required, port 80 / 443 should be allowed out but not in)

 When a packet is dropped by the firewall, ideally it should be dropped silently (as opposed to being dropped with a “refused” message)

67. Most modern firewalls provide additional protections on top of simple rule based allowing and blocking of traffic. For example, basic Denial Of Service (not Distributed Denial Of Service) attacks or port scanning. Where possible, these additional protections should be enabled.

68. Where practical, firewalls should be configured to silently drop packets instead of actively blocking requests.

69. The firewalls must produce logs of critical activity including: network address translation functions and permitted IP connections. These logs must be kept for a reasonable length of time to enable post incident investigation (sometimes months later) and should be sent to a central logging server.

70. The same border firewall may be used for both inbound (e.g. mail server) and outbound (e.g. web browsing) connections. For large organisations which are deemed to be the target of more sophisticated threat actors, the firewall rules should be configured in such a way that the different servers behind the firewall cannot talk to each other directly and the rules appropriately restrict the source and destination of traffic flows.

71. The same core firewall may be used for both inbound (e.g. mail server) and outbound (e.g. web browsing) connections with the same caveats as above. 72. In low risk environments, one of the firewalls may perform functions such as

alert generation in lieu of a dedicated IDS. This carries a risk that the firewall may itself be compromised, rendering alerts unreliable. Therefore in higher risk environments, the firewalls may form part of a wider IDS/IPS, but it is recommended that they are used in conjunction with an IDS fed by a network tap.

(22)

Chapter 5 - Aggregation Point (Proxy)

73. A common aggregation point for traffic exiting the network allows for centralised monitoring, authentication and control of traffic.

74. Most of the time, this aggregation function is performed by a proxy. This proxy (or similar appliance) should:

 Allow connections from a specified range of network devices

 Authenticate users (and optionally machines) before allowing access

 Log all activity in such a way that any request exiting the network can be traced back to a single machine and user

75. As well as this, some solutions, particularly more advanced proxies designed as all-in-one gateways may perform additional functions which form part of this gateway pattern such as:

 SSL proxying (Chapter 10); breaking connections to SSL protected services to allow for content inspection to occur. This is covered in more detail in a later section

 Content inspection (Chapter 6); analysing data being received into the network to spot suspicious or malicious code. This is covered in more detail in a later section

 Data Leakage Protection (Chapter 11); inspecting data being sent out of the network to detect potential leakage of sensitive information. This is covered in more detail in a later section.

76. The architect may also wish to consider a product which supports DNS filtering. This can protect against users attempting to resolve known malicious domain names. Additionally, malware is increasing using DNS as a command and control/exfiltration channel as DNS requests tend not to be as well monitored as web requests. Some DNS aware proxies can either by themselves or as part of an IDS system help protect against such activity.

77. As previously mentioned in Chapter 2, it is important to consider how many security controls you are happy to place into a single product. In the case of an all-in-one solution, a single vulnerability in the box may allow an attacker to completely bypass firewalling, protocol termination and content inspection as well as subverting logging. Depending on risk profile, this is unlikely to be an acceptable situation.

78. In practice, a proxy acts as a protocol break for lower levels of the network stack. This can provide implicit protection against transport layer attacks. It generally does not break the application level. This is why it is important to have a content inspection method which can at least inspect the application layer.

(23)

Chapter 6 - Content Inspection

79. The content inspection control, sometimes part of the proxy server, will scan inbound and outbound traffic to look for potentially dangerous sites or files. 80. There is a lot of potential overlap between this and an Intrusion Detection

System. The key difference is that an IDS should operate on-the-side, detecting and alerting on malicious activity (possibly with a feedback loop to the firewall as part of an IPS) whereas the content inspection device should be inline, selectively allowing or blocking content.

81. A content inspection device would be expected to perform the following functions and the architect should select which functions are required for the specific risks on the network:

 Content inspection and to detect suspicious (malicious) sites and scripts before they are delivered to the user

 URL / IP filtering to block known malicious sites and servers. The most secure configuration is for sites on a whitelist to be permitted and then a warning presented to the user before the site is loaded if they try to view a site which does not appear on the whitelist

 Filtering to block access to sites which may pose a threat to the core network (such as hacking sites or social networks; see section on social networks)

 Antivirus to detect dangerous files. Note that the architect should consider whether host or cloud based antivirus is appropriate. Host based anti-virus may not have all signatures for files. Cloud based antivirus may result in an additional data leakage concern as files will be sent to the cloud AV service

 Prevent unscanned files; some content inspection prodcucts either do not support or can be set to ignore certain files (such as files over a certain size or compressed archives). If a file is not scanned, it should be blocked and the recipient notified

 Detect and block web based command and control traffic from known malware in a similar way to an IDS. If this feature is implemented on the content checker as opposed to a separate IDS, this should include detection of malware beaconing and data exfiltration. When such activity is detected, and alert should be immediately raised with the organisation’s security team as it shows that the network has been compromised

 Enforce data leak prevention controls (see section on data leakage)

 Re-write sites to remove potentially risky (if not actually malicious) content (such as 3rd party advertisements which may have been compromised, JavaScripts, ActiveX etc)

(24)

Chapter 7 - Mail Servers

82. The DMZ mail server acts as a buffer between the Internet and the core network and removes the need for a server in the core network to listen for inbound communications from the Internet.

83. As well as this key design requirement, the device should be able to perform a number of functions (listed below). The architect should decide which of these are required to cover the specific risks to the network:

 Scan incoming email messages for malicious code and attachments

 Filter incoming mail for spam/unsolicited mail

 Block email coming from or being sent to blacklisted mail addresses and servers. The blacklist must be regularly updated. These blacklists will contain spam and malware exfiltration servers/addresses

 Block encrypted attachments (inbound and outbound) which may circumvent other security controls unless there is a specific business need. In the case of an attachment being blocked, it is recommended that a message is sent to the message’s recipient to inform them of the attachment being blocked

 If the mail server is being used to scan incoming files for malicious content, it should not allow unscanned files; some mail servers can be set to only scan files upto a certain size. If this option is used (recommended to avoid possible DoS attacks) and a file is not scanned, it should be blocked

 Implement a data leak prevention mechanism (see data leakage section)

 Implement deep inspection for antivirus, looking into attachments such as zip files or files embedded into an attachment

 Other controls may also be useful based on specific needs

84. The DMZ mail server must be configured to prevent it being used as an anonymous relay node by malicious users on the Internet.

85. The DMZ mail server should silently drop any incoming mail destined to an address which is not on the corporate network.

86. The core network mail server will service internal mail needs as well as Internet originated email. As well as standard security controls such as patching, lockdown and logging, the following controls could be implemented on the core mail server and the link to the DMZ server:

 Classification labelling of emails being sent (both internally and externally)

 Blocking of emails being sent to the DMZ mail server where no classification is specified or the classification is higher than the the accreditation of the lower security network

87. No protocols other than mail should be allowed across the firewall boundary between the core and DMZ servers.

(25)

88. The mail server must keep logs of accepted inbound mail and outbound messages sent. These must be kept for a proportionate period of time to allow security function to retrospectively investigate security breaches and should be sent to a central logging server. The architect should consider whether the mail server informs the user if an outbound mail is blocked or if a mail destined for them which is not considered spam is blocked. This can provide useful feedback to the user.

(26)

Chapter 8 - Client PCs

89. Although ideally dangerous content should have been removed by time data arrives at the client, there are certain security controls which can further reduce the risk to the corporate network by following a defence in depth approach. As such, we would expect client PCs to follow these guidelines

90. Must have all latest operating system patches applied in a timely manner, especially critical security patches.

91. Must have a regularly patched antivirus system running.

92. Guest access via the Internet gateway is acceptable, but must be kept away from the core network and not be via one of the core network client PCs.

93. The rendering of HTML email can increase the risk of malicious content or trackers being including in emails and it is recommended that client only render emails as plain text, not HTML.

94. Encrypted mail attachments increase the risk of malicious content being able to bypass network security controls or classified data being exfiltrated from the network. As such, unless there is a specific business need it is recommended that client PCs are not allowed to send or receive encrypted attachments (this may be by policy) without a specific, authorised business case.

95. The architect should consider the threat posed by scripting and plugin technologies when clients are viewing external websites. JavaScript, CSS3, Scalable Vector Graphics and common plugins all pose an increased risk to the workstation and are known to be exploitable. The architect may wish to consider the browse-down style web access discussed earlier.

96. The architect should balance between business requirements and security and consider the following controls:

 Disabling of all JavaScript and plugins except for an explicit whitelist. This will seriously degrade user experience of web browsing and may result in additional support calls to fix “broken” websites

 Disabling all JavaScript and plugins by default, but allow users (or a subset of specifically trained users) to selectively re-enable them on a site by site basis. This may be done through a browser plugin or by the content filter. Where possible, these actions should be logged

Choice of Browser Technology

97. It is critical that a modern and up-to-date web browser is used that demonstrates the following attributes:

(27)

 Support for modern web standards (e.g. HTML5)

 Actively supported by the vendor/developer and receives regular security patches

 Ability to be configured to receive automatic updates to apply security fixes

 Capable of being centrally managed and configured

 Ability to control use of scripting and plug-ins on a per site basis to allow a richer user experience on more trusted sites than on less trusted ones

 Has a reputation for providing a strong sandboxed environment for rendering web pages

98. Internet Explorer (IE) is used widely across the public sector. The most recent version (currently IE11) is the most secure release to date. It should be noted that the security mechanisms provided by the underlying operating system also play an important role.

99. IE8 is the most recent version of IE that is capable of running on Windows XP, however, on Windows XP the same level of security is not provided to the browser as on later versions of Windows. While XP is now end of life, it is accepted that many public sector organisations are still in the process of migrating off the platform. Therefore, this risk should be considered when designing Internet access solutions.

100. IE6 is not a safe browser to use for browsing the Internet, and therefore it is strongly recommended that IE6 is not used for Internet access.

101. The richness of the browsing on some of more recent browsers can be controlled on a per-site basis. This helps when making risk management decisions on enabling or disabling additional browser features that can help improve the user experience.

(28)

Chapter 9 - Monitoring & Intrusion Detection

102. It is likely that even with the security controls described in this Pattern, the core network will be subject to attack. Protective Monitoring (PM) and Intrusion Detection (IDS) allows you to assess the damage and prevent future similar attacks.

103. The architect may wish to refer to CESG Architectural Pattern No. 1, Audit and Monitoring Across Security Domains (reference [a]), however, in summary, the following key principles should be applied:

 The IDS/PM solution must not in itself present an additional attack vector into the core network; i.e. it must not be possible to bypass other security controls by compromising the monitoring solution. This is only an issue if you have a central monitoring service which receives feeds from multiple devices. In this case, there is generally a one way control between the device generating the IDS/PM feed and the system which processes the feeds

 The IDS/PM solution must be configured or trained as appropriate to allow it to generate useful alerts

 The IDS/PM logs must be reviewed on a regular and timely basis to maximise the possibility of detecting and stopping or appropriately dealing with attacks

 All logs from the IDS/PM system should be sent to a central logging server

 The central logging server must have a one way control between it and the rest of the infrastructure to ensure that a remote attacker cannot take control of the server and alter logs. For OFFICIAL, an appropriately configured firewall is appropriate if logs can be sent to the server using a connectionless protocol such as UDP

(29)

Internet

Decreasing Trust Proxy / Content Filter Client PCs Core Firewall Web Browsing Data Flows Network Connections

Network Tap (One way control implied)

Border Firewall

IDS System

IDS Feed

Possible IPS Feedback

Figure 4 - Example IDS (IPS)

Protective Monitoring

104. Protective Monitoring (PM) is used to monitor the ordinary operation of servers, devices and the network. The following points should be taken into account when designing a PM solution:

 All servers and devices should send their logs to a central logging server where events can be correlated and analysed

 PM solutions exist which can perform detailed analysis of logs to detect suspicious or unusual activity which is worthy of investigation. We recommend that this type of product is used to increase the effectiveness of PM

Intrusion Detection System

105. An Intrusion Detection System (IDS) is used to perform deep inspection of network traffic to identify attacks and malicious data. IDS solutions generally take a tap from a network device or cable to gain an exact copy of the traffic. 106. Smaller or low risk organisations may find that a full IDS is not proportionate to

their risks and threats. In this case, it is recommended that as a minimum, firewall logs are kept for post event investigation and simple rules setup to alert on suspicious events (e.g. outbound connection attempts on ports which have no known use within the organisation).

107. An Internet gateway solution for a large or high profile organisation should have an IDS solution. The following should be applied:

(30)

 The IDS solution should take its network tap from one or more locations which allows it to see all traffic which passes to the core network and which enters the DMZ from the Internet

 The IDS must take a feed which contains the unencrypted contents of encrypted connections such as SSL (unless the proxy has the ability to perform IDS like actions). Giving the IDS a feed containing only encrypted traffic will prevent it from being able to detect suspicious activity

108. In higher risk environments, it is recommended that the IDS be out of line (i.e not part of the standard flow of network traffic), however it may feed back to the border firewall as part of an Intrusion Prevention System (i.e. blocking traffic as a result of an IDS alert).

109. The IDS configuration must be regularly reviewed and updated to ensure that it is still able to detect the latest threats known by the wider security community. 110. IDS logs and full packet captures should be kept for as long as possible to aid

post incident investigations. It is recommended that logs are kept for several months if possible. However it is recommended that advice is sought from the organisations legal team to ascertain if this is acceptable.

111. The IDS should look for unusual traffic flows which may indicate malicious activies. For example:

 Malformed headers

 Request of an HTML page without subsequent loading of resources such as Javascript of images

 Repeated requests to an IP address instead of a domain

 Activity indicative of common malware activity such as fast-flux domains

 Unusual content in HTTP requests (e.g. SQL injection)

112. If an IDS is being used to actively protect the network (e.g. linked to a firewall to create an Intrusion Prevention System), great care should be taken to ensure that conditions cannot arise whereby an attacker performs some action which results in the IPS blocking legitimate connections, effecting service availability. This is more of a concern for inbound connections, but could affect outbound connections in certain situations.

(31)

Chapter 10 - SSL Web Browsing

113. An increasing number of sites require SSL encrypted browsing. This poses a problem for traditional security controls which inspect content as the SSL traffic cannot be checked. Additionally, non-web traffic can be tunnelled over SSL increasing the risk of malware command and control connections remaining undetected.

114. However, technology now exists to decrypt SSL connections and perform standard checks. This is usually done through a man-in-the-middle approach on the connection. It can however place a high load (compared to a standard site) on the proxy server. It also (obviously) breaks the end to end integrity of the connection.

115. The architect should consult with the organisation’s legal team to ascertain how much SSL interception is appropriate (i.e. intercepting SSL for Internet banking sites may not be proportionate).

116. Once this is done, the architect should decide whether business requirements necessitate allowing users to access SSL sites. If they do, the following controls should be applied:

 It should be considered whether all SSL connections must be decrypted for inspection. Certain sites such as trusted 3rd_{parties or banking sites} may be allowed to pass without decryption. The architect must bear in mind that this means the content of web sites and requests will be available in plain text in the lower trust DMZ

 The SSL decryption must happen in such a way and in such a location that none of the other security controls will be circumvented. For example, the content checker requires deep access to the content, therefore the request or response page must be in plain text at this step. The border firewall does not generally need to do deep inspection of outgoing packets and therefore the traffic may be encrypted across this security device

 Protocols tunnelled through SSL must be detected and blocked unless there is a specific business reason. In this case, it is out of the scope of this Pattern, however the general principles of this Pattern should still be applied

 It is essential that the proxy correctly validates the server certificate before generating a certificate to allow the client to connect. Some proxies do not correctly verify the certificate chain and accept an invalid certificate. This results in the user’s browser reporting that the site is safe and secure when in actual fact the certificate issued by the web server is invalid

 Logs should be kept of SSL connections. These should be sent to a central logging server

(32)

Chapter 11 - Data Leakage Prevention

117. As well as protecting hosts on the core network from attack, an Internet gateway for a large organisation should prevent classified data from being released to the Internet either accidentally or by a malicious employee.

118. It should be noted that outbound content scanning is an inexact science and can be subverted by a malicious employee. Additionally, this Pattern does not cover other potential avenues for data leakage such as removable media or printing of data.

119. There are multiple ways of reducing the risk of data leakage. These include:

 Blocking the posting of data to any site

 Automated scanning the content of data posted to sites and disallowing uploads

 A combination of the two

 Automated content scanning of outbound email

 Manual random review of emails

Data Leakage Through the Web

120. Large quantities of data can be transmitted through data sent to websites (POST data) during the use of sites such as forums, social networking or cloud file stores. This POST data may contain sensitive information.

121. Blocking all POST data can have a serious adverse affect on usability, however some proxy software can intelligently allow certain posts (such as allowing search boxes, but disallowing a forum post). However, even this can reduce the user experience of browsing the web.

122. Allowing all POST data will result in an improved user experience. Some proxy software can scan POST data for keywords (such as SECRET). However, this may not stop accidental or malicious posting of classified data to sites such as forums.

123. Manual review of POST data after the event may help detect possible leaks, however will always be severely limited by the availability of IT staff to perform these functions.

124. Using the proxy to detect and block files being uploaded to websites will help prevent large scale accidental or malicious release of classified data.

125. Online storage services such as Dropbox also tend to work either directly through a web browser or via a web based client. The gateway should alert any accesses to these services as sensitive documents may be being uploaded by users either maliciously or because they perceive it as being an easy way to share files with another party. Once documents are uploaded to an online storage service, it is very difficult to guarantee its permanent deletion.

(33)

Data Leakage Through Email

126. As with web, emails can contain sensitive files or free text which is classified. Most mail scanners can provide keyword scanning with some offering more advanced features such as natural language processing and file fingerprinting. Unfortunately none of these techniques are foolproof and will not be able to stop a determined malicious user. Also, false positives (e.g. the word confidential in a mail footer triggering a keyword scanner) can slow down mail delivery and increase the IT support burden.

127. Some products also support scanning of attachments for dirty words, such as looking for headers in PDF or Word documents. Note however that it is unlikely that any product has complete coverage of all file formats in use. The organisation may wish to either block un-scannable files or accept the risk. 128. As with web leaks, a manual process can be employed to randomly review

emails to spot classified data.

129. Although not required under the new protective marking scheme, mail labelling can be useful where accidental disclosure is a concern. Requiring users to add a “Releasable” label or remove a “Not Releasble” label for mails exiting the organisation can be a useful tool. This forces users to consider their actions and stops a recipient inadvertently forwarding a message outside the organisation. The core mail server can then scan the classification and only release mail which is correctly labelled to the DMZ mail server, notifying the users of any rejected messages.

(34)

Chapter 12 - Use of Social Networks

130. Organisations may wish to enable access to social media for a number of reasons, e.g. to provide better communications between the organisation and citizen or to enhance communications between colleagues in other organisations.

131. Each type of access presents different risks and it is anticipated that some organisations will be providing access for different reasons.

Risks of Social Networks

132. Organisations that fail to properly manage and put in place technical and non-technical controls to manage employee access to social media from corporately owned ICT systems increase the likelihood of the following risks being realised:

 The loss of sensitive corporate information (e.g. customer information, financial information and intellectual property either deliberately or accidentally leaked through the use of social media websites)

 The loss of sensitive personal information (e.g. users may be tricked into exposing their own or customer personal information either deliberately or accidentally leaked through use of social media websites)

 Increased instances of malware attacks (e.g. through the import of information from social media websites, from browsing social media websites that have themselves been compromised)

 Denial of the services provided by corporate ICT systems (e.g. as a result of a malware attack)

 Legal and regulatory sanction (e.g. due to losses of sensitive information or the loss of availability of systems and services)

 Increased instances of targeted attacks aimed at the organisation and its employees using information posted on social media sites by employees (e.g. phishing for personal or corporate information)

 Increased instances of employee distress as a result of online bullying and successful social engineering attacks

 Loss of customer confidence (e.g. due to a loss of sensitive information or loss of services)

Mitigations

133. It is impossible to completely treat all of the risks resulting from the use of the Internet including those posed by the use of social media. Therefore organisations need to take a balanced approach to managing the risks and proactively take steps to address them.

134. In addition to the controls already outlined in this Pattern, the following additional controls should be implemented for the use of social networking sites:

(35)

 Ensure that there is a strong business case within your organisation for enabling the use of social media, and that the risks and benefits are clearly understood

 Ensure that the corporate security policy includes instructions for users on the acceptable use of ICT systems for online social networking. Acceptable use policies should include any limitations on the amount of time employees can spend using online social networks and actions they should take should they suspect or realise any security incident as a result of accessing online social networks

Train and Educate All Users

135. All users need to be aware of the risks to themselves and to the organisation from the use of social media. Organisations need to provide guidance on how to protect their personal safety and manage their potential exposure to personal, offensive and defamatory content whilst using social media websites.

136. Users should be aware of the following security requirements as a minimum:

 The application of security and privacy settings

 How to guard against the disclosure of sensitive information about themselves, their employer, other individuals or specific aspects of their role

 How to maintain separate professional and personal personas

 How to represent themselves and the organisation online particularly if they are acting on behalf of the organisation (e.g. users may need to be trained in what information about their job is appropriate to be shared online)

 Not to post sensitive or personal information online, regardless of the privacy settings

 To only form online relationships and links with people they have a high degree of trust in, to be wary of unsolicited contacts and unusual behaviour from existing contacts

 Good practices for staying safe online (e.g. not clicking on links to other websites in order to avoid becoming the victim of phishing attacks and not to follow links provided in emails)

 Good password discipline (e.g. do not use dictionary words or strings of letters or numbers. Do not re-cycle passwords or use the same passwords for multiple online accounts)

 Maintain awareness of the latest attacks and techniques being used by cyber criminals and other Internet attackers (e.g. phishing)

 How to react to and report suspected or actual security incidents including instances of personal harm or distress

 Read and understood the guidance provided in the Home Office published guidance on the use of social media

(36)

Appendix A – Accreditors’ Notes

Key Points

137. If a system claims to follow this Pattern, the accreditor should consider how content is inspected, protocols analysed and connections allowed. They should consider controls implemented and whether they are appropriate for the risks to the organisation.

138. When assessing an implementation, the accreditor should consider specific risks to the organisation and whether the balance between technical controls in the gateway and procedural controls for users is appropriate.

(37)

References

The following documents are available from the CESG website unless otherwise stated, and are the latest versions at the time of publication. If a newer version has been released at time of reading, please refer to the newer version.

[a] CESG Architectural Pattern No. 1, Audit and Monitoring Across Security Domains, Issue 1.1, November 2012.

[b] CESG Architectural Pattern No. 4, Data Import Between Security Domains, Issue 1.0, September 2011.

[c] CESG Architectural Patten No. 14, Data Export Between Security Domains, Issue 1.0, February 2013.

[d] CESG Technical Threat Briefing No. 1, Assessment of Technical Threat, Issue 1.2, December 2012.

[e] CESG Good Practice Guide No. 13, Protective Monitoring for HMG ICT Systems, Issue 1.7, October 2012.

[f] CESG Good Practice Guide No. 17, Client System Security, Issue 1.1, October 2012.

[g] End User Device Security Guidance, CESG, www.gov.uk

[h] CESG Good Practice Guide No. 27, Online Social Networking, Issue 1.3, February 2014.

October 2015 Issue No: 1.1. CESG Architectural Pattern No. 17 Internet Gateways

CESG Architectural Pattern No. 17

Internet Gateways

Architectural Pattern No. 17

Internet Gateways

Purpose & Intended

Readership

Assurance

Summary

Feedback

Contents

Chapter 1 - Scope

Chapter 2 - High-Level Overview

Chapter 3 - Sample Architectures

Chapter 4 - Firewalls

Chapter 5 - Aggregation Point (Proxy)

Chapter 6 - Content Inspection

Chapter 7 - Mail Servers

Chapter 8 - Client PCs

Chapter 9 - Monitoring & Intrusion Detection

Chapter 10 - SSL Web Browsing

Chapter 11 - Data Leakage Prevention

Chapter 12 - Use of Social Networks

Appendix A – Accreditors’ Notes

References