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

Transcription

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

2 Architectural Pattern No. 17 Internet Gateways Issue No: 1.1 October 2015 Crown copyright CESG shall at all times retain Crown.

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 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. Identifying the role of and requirements placed on each component of the Architectural Pattern 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 s 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 enquiries@cesg.gsi.gov.uk Page 1

4 Contents Chapter 1 - Scope... 4 Business Scenario... 4 Pattern Overview... 4 Risk Table... 4 Assumptions... 6 Standards and Guidance... 7 Chapter 2 - High-Level Overview... 8 Principles... 8 Generic Architecture... 9 Chapter 3 - Sample Architectures Overview Use of Centralised Gateways Governance Web Browsing Key Components Security Controls Expected Security Controls Security Considerations Alternatives Browse Down Internet Access File Transfer Internet Key Components Other Non-Interceptable Protocols (SSH / VPN / Remote Desktop Access) Chapter 4 - Firewalls Function Chapter 5 - Aggregation Point (Proxy) Chapter 6 - Content Inspection Chapter 7 - Mail Servers Chapter 8 - Client PCs Choice of Browser Technology Chapter 9 - Monitoring & Intrusion Detection Protective Monitoring Intrusion Detection System Chapter 10 - SSL Web Browsing Chapter 11 - Data Leakage Prevention Data Leakage Through the Web Data Leakage Through Page 2

5 Chapter 12 - Use of Social Networks Risks of Social Networks Mitigations Train and Educate All Users Appendix A Accreditors Notes Key Points References Glossary Page 3

6 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 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. Page 4

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 2 Malicious code which has managed to exploit a client device attempts to beacon or exfiltrate data to a command and control server 3 An containing a malicious file is sent to the user 4 An attacker attempts to directly exploit the core mail server 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 The clients restrict execution of scripts and plugins to reduce the attack surface for malicious content to exploit The gateway receives regular blacklist updates and blocks requests to known bad sites The gateway inspects traffic and attempts to detect known malware command and control traffic The IDS / PM system detects unusual traffic flows and raises an alert to the security team The gateway only allows outbound connections on ports and protocols which support a specific business requirement The mail server rejects encrypted file attachments and filters potentially dangerous file types as well as scanning the incoming mail for viruses The client device is locked down to reduce the risk of malicious code being able to execute or persist The border firewall blocks all non-mail ports Remote servers which are deemed to be trustworthy may be compromised and serve exploit code which is then executed by the client Malicious content making use of zero-day vulnerabilities or exploit packing may not be detected Modern malware often rapidly changes command and control servers and domains to evade this type of blacklisting Some malware may obfuscate its C&C traffic to evade this detection Heuristic detection is inexact. Some malware traffic may not get flagged as suspicious. Malware may disguise its traffic to look like legitimate business traffic Signature based anti-virus is often defeated by modern malware packers increasing the risk that the malicious file is delivered to the user Malicious code may be able to exploit vulnerabilities in the device, gaining execution There may be an unknown or un-patched vulnerability in the core mail server which allows an attacker to send a specifically crafted to exploit the server. This risk is considered minimal at this impact level Page 5

8 ID Risk Architectural Control Residual Risk 5 Classified data is maliciously or accidentally sent from the core network to the Internet Assumptions 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 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 servers as well as manual review and release can help to detect accidental or malicious release of data from a user Table 1 Risks, Architectural Controls and Residual Risks More specialised (possibly targeted) attacks may be able to fool the Layer 7 device 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 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 Page 6

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 Page 7

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 Page 8

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 ) 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. Page 9

12 Core Network Core Firewall Aggregation Point Tunnel Termination Content Inspection Untrusted Network Border Firewall Tunnel Rebuild IDS / IPS Gateway Zone 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: Figure 1 - High Level Principles 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 Page 10

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 is addressed to someone that actually exists in the organisation before forwarding it. Page 11

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 Page 12

15 components are configured. Component configuration is discussed in the following sections. Core Network DMZ External Network Web Browsing Internet Client PCs Core Firewall Proxy / Content Filter Border Firewall Network Connections Decreasing Trust Data Flows 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) 38. In addition, for the high risk scenario, we consider the following additional cases: Page 13

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) Page 14

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 Page 15

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). Page 16

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 60. As well as web browsing, an Internet gateway may be asked to handle traffic destined for or received from the Internet. This paper considers the provision of OFFICIAL from the core network to endpoints on the Internet. As with file transfer, the principles outlined in Internet browsing apply equally to this architecture. Core Network DMZ External Network Internet Mail Server Core Firewall Mail Relay Border Firewall Decreasing Trust Network Connections Data Flows Key Components Figure 3 - Internet 61. The key security components for providing two way 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 to and from the Internet. Scans incoming for malicious links, and attachments. Silently drops mails not destined for known internal addresses Page 17

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 Page 18

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. Page 19

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. Page 20

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) Page 21

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 messages for malicious code and attachments Filter incoming mail for spam/unsolicited mail Block 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 . 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 s being sent (both internally and externally) Blocking of s 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. Page 22

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. Page 23

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 can increase the risk of malicious content or trackers being including in s and it is recommended that client only render s 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: Page 24

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 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 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. Page 25

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 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 Page 26

29 Core Network DMZ External Network Web Browsing Internet Client PCs Core Firewall Proxy / Content Filter Border Firewall IDS Feed Possible IPS Feedback IDS System Decreasing Trust Network Connections Data Flows Network Tap (One way control implied) Protective Monitoring Figure 4 - Example IDS (IPS) 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 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) An Internet gateway solution for a large or high profile organisation should have an IDS solution. The following should be applied: Page 27