cesg architectural pattern no. 10 serving web content · page 3 serving web content chapter 1 -...

October 2015 Issue No: 1.1

CESG Architectural Pattern No. 10

Serving Web Content

Architectural Pattern No. 10

Serving Web Content

Issue No: 1.1 October 2015

© Crown copyright 2015. CESG shall at all times retain Crown copyright.

Document History

Version Date Comment

1.0 November 2013 First issue

1.1 October 2015 First public release

Serving Web Content

Purpose & Intended Readership This Architectural Pattern is intended to assist system designers 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 Designer, 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 Pattern describes an architecture for the management and deployment of web content. It will allow publication and maintenance of information online while mitigating many of the commonly associated risks. This Architectural Pattern sets out key principles that help control the risks that are frequently found in serving web content. It is highly recommended that the principles presented in this Architectural Pattern are considered and integrated into the project from its beginning. This document provides only guidance (not mandatory Policy), however in order to claim that you are adhering to this Architectural Pattern all the ‘must’ statements need to be adhered to.

Serving Web Content

Contents:

Chapter 1 - Scope ..................................................................................................... 3

Business Scenario ................................................................................................... 3 Architectural Pattern Overview ................................................................................ 3 Assumptions ............................................................................................................ 6 Policy and Guidance ................................................................................................ 6

Chapter 2 - High Level Overview ............................................................................. 8

Architecture ............................................................................................................. 8 High Risk Environments .......................................................................................... 8 Security Considerations ........................................................................................... 9

Chapter 3 - The Presentation Tier ......................................................................... 11

Function ................................................................................................................. 11 Security Considerations ......................................................................................... 11

Chapter 4 - The Business Logic Tier .................................................................... 14

Function ................................................................................................................. 14

Security Considerations ......................................................................................... 14 Application Layer Firewall ................................................................................... 14 Build the application in line with good security practice ...................................... 14

Chapter 5 - Data Tier .............................................................................................. 16

Function ................................................................................................................. 16

Security Considerations ......................................................................................... 16

Chapter 6 - Content Delivery Network .................................................................. 17

Function ................................................................................................................. 17 Security Considerations ......................................................................................... 17

Appendix A – Accreditors’ Notes .......................................................................... 18

References .............................................................................................................. 19

Glossary .................................................................................................................. 20

Serving Web Content

Chapter 1 - Scope

Business Scenario

1. This Architectural Pattern is intended to enable organisations to manage the risk of serving internally generated web content to the public, while maintaining a high degree of control over the information shared.

Architectural Pattern Overview

2. There are a wide variety of software solutions available for serving web content; these solutions can incorporate a Content Management System (CMS). This Architectural Pattern does not mandate or recommend a specific approach to take when selecting the platform from which to serve their content. Individual organisations are best placed to make this decision based on their specific requirements. CESG may be able to offer advice to public sector organisations if required.

3. An attacker may seek to compromise the Confidentiality, Integrity or Availability of data by targeting the services that serve the information. This Architectural Pattern employs common practices and techniques to help manage the common vulnerabilities and risks of serving web content.

4. By applying the controls detailed in this Architectural Pattern, the risks to the data and the underlying systems can be reduced. The level of control implemented may depend on the assessed level of risk. See HMG IA Standard No. 1 & 2 (IS1 & 2), Information Risk Management (reference [a]).

5. External resources such as a Content Delivery Network (CDN) may be employed to help the website scale to high traffic volumes. Specific considerations relating to CDNs are discussed in Chapter 6.

6. Websites can serve information from combinations of static and dynamic content based on one or more sources. Please refer to Appendix A – Accreditors’ Notes for guidance on serving information from multiple sources.

Serving Web Content

7. Table 1 below identifies the principal controls and residual risks associated with this Architectural Pattern.

ID Risk Control Residual Risk

1 A threat actor mounts a network level attack on the externally accessible components of the architecture.

The outer firewall (Guard A) limits the attack vectors available against the presentation tier. The firewall constrains requests based on the rules defined for protocols required by the application. All services not necessary for the operation of the web site are disabled. Remaining services are secured to limit the impact of a compromise. The tiered architecture provides layers of defence and limits the impact a single vulnerability will have on the service.

Compromise of the presentation tier potentially provides the attacker the following capabilities:

To intercept and modify all data traversing the presentation tier for all users

To launch a content-borne or network-based attack against the business logic tier

The ability to affect the availability of the site

2 A threat actor mounts a content-borne attack on the web application.

Acceptable content types and format are constrained as follows:

The presentation tier constrains the valid inputs that are accepted by the web application. For example, only the expected protocols, on the required ports are accepted. Expected user input to fields in the web application is validated

The business logic tier ensures that the inputs provided from the presentation tier are valid and logical in the context of the application. For example, only Simple Object Access Protocol (SOAP) messages matching the application

Sanitising content can account for most known content attacks, but there is a residual risk that previously unknown content attacks may prove effective.

Serving Web Content


schema are allowed to pass over the HTTP protocol

The data stored within the data tier is protected by limiting the calls made from the business logic tier. For example, an account is created within the data tier which has access limited to operations necessary to run the application within the business logic tier

3 A threat actor gains unauthorised access to functionality or resources within the service.

Access control is implemented at each layer of the tiered architecture as each tier validates that the request is authorised.

Compromised user credentials will allow a threat actor to masquerade as the user and gain unauthorised access to resources.

4 A threat actor gains access to sensitive information by viewing communication traffic between the user and the server in the clear.

All communications between the presentation tier and the user containing any sensitive data must be protected by suitable cryptography (e.g. TLS version 1.0 or greater with latest patches applied - see TLS VPN Security Gateway, reference [b]).

If the user's machine is compromised, data will still be viewable to the threat actor – see Risk 1 and 7.

5 Services leak information which is used to help an attacker gain an understanding of the configuration of the service which may be useful for further attacks.

The presentation tier limits the information released in error conditions. Reducing the information released with any error messages increases the sophistication required to discover the platform technologies and target their weaknesses. Audit and monitoring of errors and exceptions should be performed. Since communications with the business layer have been created by the presentation tier, they should be

Some information about the underlying service can still be obtained, however advice to minimise this risk is contained below in Chapter 3.

Serving Web Content


predictable; if unexpected behaviour occurs then it may be indicative of a compromised presentation tier.

6 A threat actor mounts a Denial of Service (DoS) attack against the presentation tier.

A content delivery network could be used to increase the availability of the website when under heavy load or DoS attack. CDNs are discussed in Chapter 7. DoS protection may also be available from the service provider. Further effective controls for DoS attacks are discussed in CESG CIATT 2010/01, DDoS -Distributed Denial of Service (reference [c]).

Most DoS mitigation techniques attempt to identify and reject repetitive requests which have similar characteristics. These techniques are often crude and have the potential to be thwarted by more sophisticated DoS attacks.

7 A user’s endpoint is compromised with malware, either as a result of a targeted or untargeted attack.

Since the endpoint is outside of the control of the service, there are no mitigations which can reliably detect or prevent interception of content accessed by the user. It is also difficult to prevent session hijacking attacks where the malware may make additional requests impersonating the authenticated user.

The risk is not mitigated at all by this Architectural Pattern. However it may be possible reduce this risk through the use of Transactional Monitoring. Refer to CESG Good Practice Guide No. 53 (GPG 53), Transaction Monitoring for HMG Online Service Providers (reference [d]) for further information.

Table 1 – Controls and Residual Risks

Assumptions

8. The core network is accredited in line with HMG policy.

Policy and Guidance

9. Specific information on protecting connections to the internet can be found in CESG Good Practice Guide No. 8 (GPG 8), Protecting External Connections to the Internet (reference [e]).

10. Specific information on the range and type of technical threats to HMG ICT systems can be found in CESG Technical Threat Briefing No. 1 (TB 1), Assessment of Technical Threat (reference [f]).

Serving Web Content

11. Specific information on assuring internal ICT systems and services can be found in CESG Good Practice Guide No. 30 (GPG 30), Assurance of ICT Systems and Services (reference [g]).

12. If the web site will be storing or processing credit card data you must implement the requirements found in the payment card industry data security standard (PCI DSS) (reference [h]).

13. Further information on the most common risks to a web architecture can be found in the open web application security project (OWASP) Top 10 list (reference [i]).

14. DoS attacks are discussed in CIATT 2010/01 – DDos – Distributed Denial of Service (reference [c]).

15. Any network based on this Architectural Pattern should also consider the following:

CESG Architectural Pattern No. 1 (AP 1), Audit & Monitoring Across Security Domains (reference [j])

CESG Good Practice Guide No. 13 (GPG 13), Protective Monitoring for HMG ICT Systems (reference [k])

CESG Good Practice Guide No. 44 (GPG 44), Authentication Credentials in Support of HMG Online Services (reference [l])

CESG Good Practice Guide No. 45 (GPG 45), Identity Proofing and Verification of an Individual (reference [m])

CESG Good Practice Guide No. 53 (GPG 53), Transaction Monitoring for HMG Online Service Providers (reference [d])

Serving Web Content

Chapter 2 - High Level Overview

Architecture

16. This architecture allows information held by an organisation to be shared selectively with an external audience. The user interacts with servers in the presentation tier shown in the diagram below. The interaction between the presentation tier and the rest of the network architecture is hidden from the user.

Figure 1 – Typical Web Content Serving Architecture

17. Figure 1 shows a common tiered approach to serving web content. Resiliency and redundancy are not considered here. See HMG IA Standard No. 1 & 2 Supplement, Technical Risk Assessment and Risk Treatment (reference [n]) page 148, Section 14 for information relating to business continuity management. There are many ways to implement authentication within web architectures, and methods vary with different products. Public sector organisations should contact CESG for further advice.

High Risk Environments

18. Where the trusted network contains protectively marked information or risk is perceived to be high, the business logic tier should be separated from the trusted network by hosting it within its own DMZ as shown above in DMZ 2. This prevents a successful attack against the business logic tier from giving immediate access to the trusted network.

19. Where business logic servers are required for the function of the application, it is recommended that separate business logic tier is used to serve internal clients rather than re-using the one used for external clients. Furthermore, functionality relating to the two specific user groups should be split between the internal and external business logic servers where possible. For example, Functionality relating to the editing of a CMS should only be available on the internal business logic server. This ensures a separation between the actions of the trusted internal users and the un-trusted external users. Strict rules relating to the type and direction of traffic can then be applied to guard c. Guard d should be put in place in order to protect the critical services from internal users who could introduce malicious content to the network.

Serving Web Content

20. The internal business logic / presentation servers and the CMS can be hosted on the same servers, and may be part of the same application.

21. Where risk is perceived to be low, depending on the internal separation within the trusted network, it may be acceptable to remove guard c shown above and host the business logic tier within the trusted network.

Security Considerations

22. Where there are separate business logic tiers for internal and external users, separate database accounts (for software components) should be used for database access. The principle of least privilege should be applied to all such accounts, and any others used. Where the threat, impact and requirement for integrity are all low in low threat environments where guard c has been removed. it may be acceptable to share one business logic tier for both internal and external users provided that the application can identify where requests originate from.

23. Each trust domain must be separated from the others with a suitable guard such as a firewall. Depending on the threats identified, the guard may be configured to inspect and allow only well formed traffic required for the correct operation of the web site to transit the device; this will be discussed further in Chapters 3-5. The trust domains do not need to be physically separated; a logical separation is sufficient if the deployment follows the guidance found in CESG Good Practice Guide No. 12 (GPG 12), Use of Virtualisation Products for Data Separation: Managing the Security Risks (reference [o]). The business logic and CMS applications may be physically hosted on the same server or may be a single inseparable application.

24. All servers should be maintained and kept fully patched in accordance with industry best practice, see GPG 8 (reference [e]). The organisation should integrate the maintenance of the web site infrastructure with their existing business processes.

25. In some cases a web application’s presentation and business logic functions are intrinsically linked and it can be difficult to separate them as required in this architecture. When deploying low risk or limited use beta services it may be appropriate to deploy presentation and business logic services together to aid rapid development. In such cases, a proxy server could be deployed in front of the presentation tier and “in line”. The proxy server can be configured such that access is prevented to sensitive application functionality which should only be available to internal users. Additional content inspection may also be used to ensure that requests sent to the application server are well formed and valid. Such a configuration provides some defence in depth and reduces the attack surface exposed on the presentation tier, though it is not a recommended approach for complex or mature service deployment.

26. Audit and monitoring information can be taken from all components within the architecture, but particular consideration should be given to the events generated from the business logic and database components. If designed carefully, the system can provide strong indicators of compromise in the event of non-conformant traffic arriving at the business logic or data tiers. Specific event

Serving Web Content

logging for each component will be discussed in the following Chapters. The consolidation of equipment for management and the processing of audit and monitoring feeds will need consideration in the context of a particular deployment. AP 1 (reference [j]) provides a recommended pattern for the consolidation of audit and monitoring feeds.

27. As the service has no control over external users’ devices connecting to the application, they must be assumed to be compromised. It is very difficult for the service to detect or defend against such a compromise, and all data viewed by the user on their device may be intercepted by malware running on that device. Any malware may also hijack legitimate user sessions to make additional requests from the service as if they were the legitimate user and it is normally very difficult for the service to detect these requests, see GPG 8 (reference [e]) and GPG 13 (reference [k]).

Serving Web Content

Chapter 3 - The Presentation Tier

Function

28. The role of the presentation tier is to:

Authenticate the user (where required – discussed below)

Serve content to the client

Enforce security controls (discussed below)

Terminate the connection between the client and the service

29. Content served may be made up of both static and dynamic content. Typically static content will reside on the presentation servers but may be generated periodically from dynamic data stores.

30. The majority of sites serving web content are information portals where users consume content published by the organisation. In a subset of cases the web site may be used to provide individual services tailored to specific users. To fulfil these services, it is likely that users will need to be authenticated by the site.

31. CESG recommends that public sector organisations consult GDS in order to take advantage of GOV.UK for hosting public content.


32. Users of the service interact with the presentation tier. In order to prevent a successful attack on the presentation tier giving unfettered access to back end systems, the presentation tier servers should be hosted within their own DMZ, bounded by firewalls, as indicated in Figure 1, and should be separate from other layers of the solution. Depending on the risk profile of the environment it may be necessary to physically separate each layer of the architecture. See GPG 12 (reference [o]) for further information.

33. Many of the vulnerabilities associated with the delivery of web content arise from dynamic or interactive features. Consequently is it safer to serve static content.

34. The guard facing the untrusted network must only allow traffic bound for the presentation server and should have rules configured appropriately to limit the type of traffic forwarded to that which is required for the correct operation of the web site.

35. The guard facing the business logic tier must only allow traffic between the presentation tier and the business logic tier and should inspect and only allow well formed traffic while limiting the content types required for correct operation of the web site. Additional rules may be added which allow management of the presentation servers from the trusted network; this is often achieved using a ‘browse-down’ architecture. Public sector organisation can request specific advice from CESG.

36. Logs from presentation servers and any other devices within this layer of the architecture should be gathered in accordance with guidance in AP 1 (reference

Serving Web Content

[j]). Logs should be monitored; invalid requests may indicate an attempt to compromise the devices within this layer of the architecture.

37. The presentation servers must be configured to provide only the services required by the web site. This reduces the attack surface available to potential attackers. Additionally, the functionality of required web services must be limited to only those necessary for operation. For example unnecessary HTTP methods must be disabled as these can be exploited by an attacker and represent a significant security risk.

38. No error messages should be served by the presentation servers which disclose technical information about the service, this helps reduce the information a threat actor can gain regarding the infrastructure and the applications in use within the system. Error messages should allow users to identify and understand application usage mistakes.

39. It is recommended that external-facing presentation servers should not be used to serve internal facing web sites as a compromised external-facing server could then attack internal clients.

40. When conducting transactions which require the passing of credentials or sensitive information such as address details or credit card information, communication between the presentation servers and the client must be secured using TLS (HTTPS). All versions of TLS or SSL protocols earlier than TLS 1.0 (reference [b]) (or higher) should be disabled at the server. If earlier versions of TLS or SSL are supported the risk of compromise of the secure communication is increased. See PCI DSS (reference [h]) for further requirements relating to online payments.

41. Although user credentials are validated at the presentation tier, it is recommended that the user identification is passed to the business logic tier with every transaction to enable actions made by a user at the business logic tier to be authorised, attributed to a session and audited. If client certificates are used to authenticate users (i.e. mutual authentication), the presentation server must confirm that the certificates are valid i.e. they were issued by a trusted authority and have not since been revoked.

42. Validation must take place on all requests from the un-trusted network. Such validation should include checking the validity, structure and content of requests made. Where user authentication is incorporated this would also include the validation of the access token used. For high risk scenarios it is recommended to manage authenticated and unauthenticated traffic through different systems. For example a vulnerability in a public facing feature such as a contact us form could be used to attack a secure section of the same website if both areas are hosted together.

43. Developers should be familiar with common web security issues, such as the OWASP top 10 list (reference [i]) and the OWASP list of useful HTTP headers (reference [p]). Many web servers support a URL format checking component which can be used to ensure requests received by the presentation servers are well formed and conform to the HTTP standard. Further validation should be

Serving Web Content

performed by the presentation server based on expected use of the application; this may involve validating user input against business rules but the specific level of validation undertaken will often depend on the web application in question. The business logic servers must also validate input based on the expected operation of the application; this is discussed in the next Chapter.

44. Many attacks make use of the user’s browser to be successful. The following recommendations are examples of advice which help to reduce available attack vectors:

a. Lock cookies to the IP address of the user accessing the data. When performing sensitive operations an application should use metrics to determine a level of trust for a requested transaction. A change of IP address may be an indicator used to reduce trust and may prompt a further authentication request.

b. Set cookies to the most specific domain possible, i.e. don’t use service.gov.uk if the service is hosted on system1.department.service.gov.uk

c. Set the secure and http only flag on all cookies.

d. Sensitive operations must require users to re-authenticate or undertake another method of assuring identity such as deploying methods to prevent replay attacks.

e. Check the HTTP referrer field for consistency with the expected referrer value.

f. Ensure the life of session cookies is limited appropriately.

g. Ensure the session id is not exposed in the page source.

h. Ensure the X-FRAME-OPTIONS header is set on all pages to SAMEORIGIN or DENY.

45. A Web Application Firewall (WAF) may be introduced in front of the presentation server in order to mitigate most of the common attacks discussed above. WAFs are good at inspecting the content of requests made to a web service and may be used to easily reduce the risk of well known content based attacks. A WAF cannot fully remove the risk of an attack tailored to a specific application. As a result, a WAF should not be totally relied upon to protect the presentation servers, and assurance should be gained in the application running on the presentation servers with regard to user input validation and user authentication.

46. The presentation servers should not send invalid data to the business logic server’s API. Thus, security alerts generated at the business logic tier indicate either a fault, or successful compromise of the presentation tier. This minimises the generation of false positive alerts.

Serving Web Content

Chapter 4 - The Business Logic Tier

Function

47. The functional purpose of the business logic tier is to handle requests for dynamic content from the presentation tier. Where user accounts are required, this tier is typically used to authenticate users and make decisions based on the authentication status of the user.

48. Where dynamic content is not being served or dynamically generated a business logic tier will often not be necessary.

49. The business logic tier handles the interface to the database and validates the requests made by the presentation tier.


50. The following measures are suitable to protect the business logic tier from invalid requests from the presentation tier.

Application Layer Firewall

51. A suitable application layer firewall which understands and examines the protocol used for communication between the presentation tier and business logic tier may be inserted into the path between the two servers. For example if the communication between the two servers is based on XML, a XML Firewall could be used.

Build the application in line with good security practice

52. The business logic should perform sanitisation and validation functions on all un-trusted content received from the presentation tier. Data should be based on expected business function and checked as fully as possible for malicious content. Values passed to the business logic tier must not be directly used within the application and must be first transposed into new variables. Variables used within the application must be strictly bounded and typed to prevent invalid or malicious values passing through the application.

53. The decision to employ either of the measures outlined above will depend on the cost of each for the scenario in question and also the control which the organisation has over the source code of the application. Public sector organisations can obtain further advice from CESG if required.

54. For higher threat scenarios (e.g. situations where the trusted network contains protectively marked data) it may be necessary to host the business logic tier within its own DMZ rather than on the trusted network, as the business logic tier performs sanitisation functions on un-trusted content received from clients. This would prevent a successful attack against the business logic tier directly reaching the trusted network. To achieve this, the servers should be bounded by guards such as firewalls or application aware devices.

Serving Web Content

55. The guard facing the trusted network and the data tier must be configured to only allow traffic between the business logic tier and the data tier and the type of traffic should be limited only to that which is required for correct operation of the service.

56. The user accounts employed by the business logic servers to access the data tier should created with the minimum permissions necessary for the operations being performed. Since the majority of requests sent to the database are likely to be read requests, a database user account with only the minimal permissions required to read those data items should be used. Where write or update access is required to some data items, a similar approach must be taken using a different, but still constrained, user account.

57. By design, the business logic tier should not send invalid data to the data tier. Thus, security alerts generated by the data tier will indicate either a fault, or successful compromise of the business logic tier and/or the presentation tier. This minimises the generation of false positive alerts.

Serving Web Content

Chapter 5 - Data Tier

Function

58. The data tier holds all the information that the web site may wish to display dynamically. It may also hold static content which is updated on a scheduled basis.


59. The data tier must not allow direct connection from the presentation tier. It must only allow constrained commands, preferably only stored procedures or fixed API calls, to be run against the data store by the business logic tier. This requirement can be enforced through the use of well configured access controls and user accounts on the data store. Robust configuration will reduce the effectiveness and impact of successful injection attacks.

60. Where the CMS and the business logic servers are distinct entities they must use separate user accounts on the data store. Their user accounts must only have access to the functionality and data sets required for operation.

61. Default passwords must be changed and the administrator account (often called sa, SYSTEM, admin or root) must not be used by the business logic application. Therefore invalid login attempts to the data store using the default accounts will indicate a compromise and must be investigated.

62. Dynamic SQL queries or API calls should be avoided and where possible precompiled stored procedures or equivalent (such as externalising Hibernate XML queries) should be used to reduce the chance and impact of a successful injection attack. Care should be taken when creating stored procedures or fixed operation routines to validate input. If only stored procedures or equivalent are used additional alerting can be set up to indicate compromise if a dynamic query is run against the data store.

Serving Web Content

Chapter 6 - Content Delivery Network

Function

63. A Content Delivery Network (CDN) can be used to offload client connections to help a site scale to meet high demand. It can reduce the burden on single points of failure e.g. a server or bandwidth limitations.

64. CDNs cache the information served by the web site and allow visitors to view that information without sending requests to the underlying service. This is achieved by registering the DNS entry for the web site as the CDN. The CDN then serves the content to users as though it were its own. Where content has expired or dynamic content is required the CDN will directly query the service and cache the data where appropriate.

65. CDNs are best suited to environments where users of the service all have access to the same static information or where there is only a limited amount of user specific or dynamic content. As dynamic content is often cached by a CDN, organisations need to identify sensitive data and build a caching policy with their CDN provider which is appropriate for their specific use case. Personal data may be cached overseas due to the distributed nature of CDNs, so relevant data protection legislation must be considered.


66. The connection between the CDN and the host organisation’s presentation tier should be locked down such that only the CDN can communicate with the presentation tier. This will help prevent various attacks including DoS and cache poisoning. This lockdown should be undertaken by the Content Service Provider (CSP) within their network.

67. When serving dynamic content over SSL, the CDN provider will need to be given the service SSL certificates, effectively allowing the CDN to impersonate the service. Organisations must gain assurance that the provider will protect the certificates, which if compromised would allow an attacker to decrypt traffic.

68. It is important to note that if the bandwidth of the connection between the presentation tier and the CDN is exhausted, a DoS attack will be possible. For websites where availability is critical, the organisation should consider methods for controlling bandwidth between the presentation tier and the CDN in order to mitigate the risk of DoS. Most CDN solutions can be tuned to maximise performance under high load. Where a high load peak is expected organisations should proactively work with the CDN provider to improve performance both before and after any event. Procedures should be designed and tested to ensure that during any event changes can be made by suitably authorised organisation staff.

Serving Web Content

Appendix A – Accreditors’ Notes

69. Due to the flexibility of web technologies there are several additional architectural configurations that could be used where multiple organisations may publish data to a common website. Specific advice should be sought from the CESG IA Architects team when required.

70. Accreditors will need to consider each approach taken on its own merits and where possible make use of the principles outlined in this Architectural Pattern with their own solution. Where several organisations are sharing the responsibility to host and serve content, each organisation must implement this Architectural Pattern for the whole solution to claim compliance, as an attacker may use a vulnerability in one system in order to access the network of another organisation. Accreditors should seek assurance from each participating organisation.

71. Public sector organisations seeking advice relating to the specific methods of publishing data to a shared website must request guidance from CESG as there are too many configuration options to discuss in this Architectural Pattern.

72. Content management systems like WordPress and Drupal are often used to provide a simple way for users to quickly add and edit content on a website. However, such sites are by default dynamic websites. Accreditors are advised that it is possible to achieve the benefit of flexibility that a CMS provides, whilst reducing the risk, by converting the dynamic content to static content for publishing. There are various plug-ins for many popular CMS systems that provide this ability. Alternatively application designers can design this functionality into their solution.

73. By virtue of the fact that users accessing the service are on the Internet they must be treated as untrusted at all times. Where the identity of a user has been successfully authenticated there is still a residual risk that the computer the user is using has been compromised. Should this occur it is possible that the threat actor behind the compromise will gain access to the resources the user is authorised to view.

74. Even where all controls listed in this document have been implemented there remains a risk that malicious activity may still occur. In scenarios where a high degree of confidence is required it is strongly advised that heuristic checks and behavioural monitoring are undertaken. This will help identify user accounts which may have been compromised. See GPG 8 (reference [e]) and GPG 13 (reference [k]) for further information.

Serving Web Content

References

[a] HMG IA Standard No. 1 & 2, Information Risk Management (UNCLASSIFIED) - latest issue available from the CESG website.

[b] CPA Security Characteristic – TLS VPN Security Gateway – Version 1.0 http://www.gchq/cesg/icweb/iap-mirror/publications/Documents/tls_vpn_security_gateway.pdf

[c] CIATT 2010/01 – DDoS – Distributed Denial of Service – December 2010. Available from the CESG website.

[d] CESG Good Practice Guide No. 53, Transaction Monitoring for HMG Online Service Providers - latest issue available from the CESG website.

[e] CESG Good Practice Guide No. 8, Protecting External Connections to the Internet (Not Protectively Marked) - latest issue available from the CESG website.

[f] CESG Technical Threat Briefing No. 1, Assessment of Technical Threat (UK RESTRICTED) - latest issue available from the CESG website.

[g] CESG Good Practice Guide No. 30, Assurance of ICT Systems and Services (UK RESTRICTED) - latest issue available from the CESG website.

[h] Payment Card Industry Data Security Standard – www.pcisecuritystandards.org

[i] The OWASP Top 10 List - www.owasp.org

[j] CESG Architectural Pattern No. 1, Audit and Monitoring across Security Domains (UNCLASSIFIED) - latest issue available from the CESG website.

[k] CESG Good Practice Guide No. 13, Protective Monitoring for HMG ICT Systems (UNCLASSIFIED) - latest issue available from the CESG website.

[l] CESG Good Practice Guide No. 44, Authentication Credentials in Support of HMG Online Services - latest issue available from the CESG website.

[m] CESG Good Practice Guide No. 45, Identity Proofing and Verification of an Individual - latest issue available from the CESG website.

[n] IS1 & 2 - Supplement - Technical Risk Assessment and Risk Treatment (UNCLASSIFIED) - latest issue available from the CESG website.

[o] CESG Good Practice Guide No. 12, Use of Virtualisation Products for Data Separation: Managing the Security Risks (UNCLASSIFIED) - latest issue available from the CESG website.

[p] OWASP List of useful HTTP headers – www.owasp.org/index.php/List_of_useful_HTTP_headers

http://www.gchq/cesg/icweb/iap-mirror/publications/Documents/tls_vpn_security_gateway.pdf

http://www.gchq/cesg/icweb/iap-mirror/publications/Documents/tls_vpn_security_gateway.pdf

http://www.pcisecuritystandards.org/

http://www.owasp.org/

http://www.owasp.org/index.php/List_of_useful_HTTP_headers

Serving Web Content

Glossary

API Application Programming Interface

CDN Content Delivery Network

CMS Content Management System

CSP Content Service Provider

DMZ Demilitarised Zone

DNS Directory Name Service

DoS Denial of Service

GDS Government Digital Services

HTTP Hyper Text Transfer Protocol

HTTPS Hyper Text Transfer Protocol - Secure

OWASP Open Web Application Security Project

PCI DSS Payment Card Industry Data Security Standard

SOAP Simple Object Access Protocol

SQL Structured Query Language

SSL Secure Sockets Layer

TLS Transport Layer Security

URL Uniform Resource Locator

WAF Web Application Firewall

CESG provides advice and assistance on information security in support of UK Government. Unless otherwise stated, all material published on this website has been produced by CESG and is considered general guidance only. It is not intended to cover all scenarios or to be tailored to particular organisations or individuals. It is not a substitute for seeking appropriate tailored advice.