Sei sulla pagina 1di 47

UNCLASSIFIED

Technical Standard

Common Standard for Malware Protection


Public Services Network Programme

Version 1.0 6 December 2012

Prepared by: PSN Infrastructure Security & Cyber Defence Team 3rd Floor, 1 Horseguards Road London, SW1A 2HQ

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

Document Information
Project Name: Prepared By: Title: Reviewed By: Public Services Network (PSN) Richard Keighley PSN SOC Delivery Lead Design Authority Document Version No: Document Version Date: Review Date: 1.0 06/12/12 06/12/12

Version History
Ver. No. 0.1 0.2 0.3 Ver. Date 03/08/2012 10/08/2012 17/08/2012 Revised By Richard Keighley Richard Keighley Richard Keighley Description First draft for internal review. Revised following PSN comments. Filename PSN P&MP Std v0-1.doc PSN P&MP Std v0-2.doc

Revised following further PSN comments and amended to PSN P&MP Std v0-3.doc latest PSN document format.

0.4 0.5

21/08/2012 19/09/2012

Richard Keighley Richard Keighley

Revised following CESG feedback.

PSN P&MP Std v0-4.doc

Revised following PSN-SF review. Patching and malware Malware Protection Std v0protection split into two separate standards. 5.doc

0.6

10/08/2012

Richard Keighley

Revised following additional PSN-SF review. Approved by Malware Protection Std v0PSN-SF. 6.doc Malware Protection Std v07.doc

0.7

14/11/2012

Richard Keighley

Revised following wider PSN review.

1.0

06/12/2012

Richard Keighley

Approved by the Design Authority, unchanged from v0.7

Malware Protection Std v10.doc

Approvals
Position PSN Programme Director PSNA Operations Director PSN Design Authority Craig Eblett John Stubley John Stubley (Chair)

Crown Copyright 2012


The copyright in this document is reserved and vested in the Crown.

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 2 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

Table of Contents
1 Introduction ................................................................................................................................. 4 1.1 Purpose and Scope ........................................................................................................... 4 1.2 Document Structure ........................................................................................................... 4 1.3 Disclaimer.......................................................................................................................... 5 PSN Context ............................................................................................................................... 6 2.1 Overview ........................................................................................................................... 6 2.2 Compliance Management .................................................................................................. 6 Malware Protection ..................................................................................................................... 8 3.1 Introduction........................................................................................................................ 8 3.2 Threats .............................................................................................................................. 9 3.3 Vulnerabilities .................................................................................................................. 11 3.4 Security Controls ............................................................................................................. 17 3.5 PSN Compliance Requirements ...................................................................................... 35 3.6 Recommended Service Provider Requirements .............................................................. 38

Annex A: References and Further Information Sources ................................................................... 41 Annex B: Glossary and Abbreviations .............................................................................................. 43 Annex C: Standards Maintenance .................................................................................................... 45 C.1 Providing Feedback ......................................................................................................... 45 C.2 Change Control ............................................................................................................... 45 Annex D: Key Principles for Patching and Malware Protection ......................................................... 46

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 3 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

Introduction

1.1 Purpose and Scope


This document identifies the baseline common requirements and provides related good practice guidance for implementing malware protection controls by UK public sector organisations. It also includes recommended requirements for malware protection to be imposed on service providers delivering into the public sector. Effective implementation of malware protection controls help to underpin the PSN Security Model [6] and reduce the risk to the PSN community. This is a technical standards document written under the PSN banner, and is intended to support compliance with the corresponding conditions contained in the PSN Code Template [1]. Consequently, the only baseline current requirements mandated by this document are those currently contained in the PSN Code Template, although recommended requirements to be imposed on service providers are also included. The scope of this document is currently limited to those public sector organisations in scope of the PSN programme, but it is intended to be extendable across other public sector initiatives/programmes potentially utilising PSN, including G-Cloud, End User Devices (EUD) and G-Hosting. Much of the guidance is also of direct relevance to those service providers delivering into public sector organisations. Moreover, it should be noted that this standard does not explicitly provide a description of the requirements for those organisations bound by the HMG Security Policy Framework (SPF) [2]; such organisations must still continue to comply with HMG IA Policy, including relevant controls from the Baseline Countermeasure Set (BCS) and supporting CESG guidance publications. Similarly, other community-specific requirements (e.g. JSP440 for the MOD, IGSoC for NHS) should also be followed in those communities in addition to those defined in the PSN Code Template. This document is likely to be affected by the outcome of the Government Protective Marking Scheme (GPMS) Review, with changes to the GPMS due to come into effect by early/mid-2013. This document will be updated after the detailed nature of any such changes has been clarified.

1.2 Document Structure


This document is structured as follows: Section 1 (this section) the introduction; Section 2 provides an overview of PSN and the relationship between this document and the PSN compliance process; Section 3 defines the requirements and associated guidance for malware protection; Annex A the references cited in this document; Annex B abbreviations and glossary of terms; Annex C summarises the PSN standards maintenance process, including how feedback on this standard should be provided. Annex D contains key implementation principles for patching and malware protection.
Author: PSN Cyber Team Malware Protection Std v1-0 Page 4 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

1.3 Disclaimer
Reference to any specific commercial product, process or service by trade name, trademark manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favouring by PSN. The views and opinions expressed within this document shall not be used for advertising or product endorsement purposes. Any party relying on or using any information contained in this document and/or relying on or using any system implemented based upon information contained in this document should do so only after performing a risk assessment (as per the PSN Code Template and ISO/IEC 27001 [21]). It is important to note that a risk assessment is a prerequisite for the design of effective security controls. A correctly completed risk assessment enables an organisation to demonstrate that a methodical process has been undertaken which can adequately describe the rationale behind any decisions made. Risk assessments should include the potential impact to live services of implementing changes. This means that changes implemented following this guidance are done so at the implementers risk. Misuse or inappropriate use of this information can only be the responsibility of the implementer.

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 5 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

PSN Context

2.1 Overview
In the Public Services Network (PSN) vision, there will be a single logical network of networks, with each constituent network operated by a number of different service providers. These in turn will host a range of different services (including PSN Shared Services, PSN Services and G-Cloud Services provided over the PSN) that could potentially serve any user on PSN. PSN extends beyond Central Government with 85% of its potential users from Local Government, the NHS, the education sector, the emergency services and other non-Central Government public sector organisations. It can also include the Third Sector (e.g. voluntary and community organisations/charities) and private sector organisations where they act as agents of government. Under the Government ICT Strategy [3] and delivery of the PSN, it is anticipated that there will be much more automated sharing of information and services than in the past. This will create efficiencies leading to savings for the public sector whilst also providing secure, effective, efficient and reactive services for the citizen. The sharing of information and services brings different threats and opportunities for criminal elements to exploit any vulnerability. Closing down all of these potential avenues would be an extremely expensive process (if indeed achievable) and would be likely to create an environment which would be difficult to use and heavily constrained. Instead the Security Model agreed for the PSN [6] will more effectively manage the risks inherent in the system rather than try to mitigate every risk. A key component in the management of those risks will therefore be the implementation of a baseline common level of security controls with respect to patching and malware protection across the UK public sector and its service providers, and hence the need for this standard. As other Government programmes (e.g. End User Devices (EUD) and G-Cloud) will rely upon PSN for delivery of infrastructure services (e.g. wide area and inter-organisation network provision), this standard defines a common approach to be adopted for those programmes as well.

2.2 Compliance Management


All PSN Consumers (end user organisations) have to comply with the defined PSN Code Template [1], including the Information Assurance (IA) Conditions. This is in addition to any existing sector/organisational requirements such as the HMG Security Policy Framework (SPF) [2] (including the Baseline Countermeasure Set of security controls defined in HMG IS1&2) or NHSs Information Governance Statement of Compliance (IGSoC).
HMG SPF Requirements (incl. BCS)
Complies with PSN Codes

Consumer/ Service Provider ICT system/ service

Central Government Community (typically IL3 and above)

Other organisational security requirements (e.g. MOD, NHS)

Figure 1: PSN Compliance Context

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 6 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

PSN standards, including PSN technical standards, are the source documents for the PSN Code Template. In particular, they: Define, clarify and contextualise requirements documented in the PSN Code Template for a particular technical aspect of delivery (e.g. explaining why they are needed, identifying evidence typically provided or potential types of solution that could be implemented); Provide further detailed technical guidance, advice and explanation on a particular technical aspect of delivery, including typical good practice and reference to further sources of information; The set of documents that define the PSN standards are always aligned with a corresponding version of the PSN Code Template. New PSN standards are developed through consultation, and when approved, cause a new version of the PSN Code Template (including the Annex B control set) to be published.
PSN Code Template

COMPLIANCE ASSESSMENT

PSN Consumers / Service Providers

REQUIREMENTS DEFINITION, CONTEXT, SUPPORTING GUIDANCE & EXPLANATION

PSN Technical Standards

Figure 2: The Relationship between PSN Technical Standards and the PSN Codes

PSN Codes compliance will be performed in accordance with the PSN Compliance document [5]. PSN applicants must be able to demonstrate compliance with all the relevant controls. Assessment of this compliance will be based on the information provided by the PSN applicant and using the issued guidance. There should be no waivers or exceptions to controls but there is leeway in how the requirements could be implemented. To support compliance by PSN consumer organisations, this standard also includes recommended requirements to be imposed on service providers (e.g. in service level agreements or contracts).

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 7 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

Malware Protection

3.1 Introduction
This section defines the common standard and related good practice guidance for malware protection across the public sector. It also includes recommended requirements for malware protection to be imposed on service providers delivering into the public sector (see Section 3.6). It is based largely on advice from CESG (the National Technical Authority for Information Assurance) which is more fully explained in CESG GPG No. 7 Protection from Malicious Code [10] and also summarised in the associated CESG Busy Reader Guide (BRG) [9]. CPNI are also collaborating with the SANS Institute on the development of Twenty Critical Security Controls for Effective Cyber Defense [18]; Control No. 5 (on Malware Defences), some of which is also reflected in this section. Good practice is also described in NIST Special Publication (SP) 800-83, Guide to Malware Incident Prevention and Handling [17]. Malicious code or software (commonly known as malware) presents a significant risk to public sector organisations, their ICT systems and information. Potential attackers can use malware to compromise the Confidentiality, Integrity and Availability (C, I, and A) of an organisations ICT systems and information. Malware can be introduced into ICT systems via applications, network interconnections, removable media and attached devices. Common types of malware include viruses, worms, Trojan horses, logic bombs, spyware, adware, malicious mobile code, root kits, installers and key loggers. Once compromised, systems and applications can be used by attackers to launch and propagate further attacks. Examples of compromised systems are compromised web sites, bots and botnets, backdoors and mass mailers (e.g. spam). Further details on each of the above types are provided in CESG GPG7 (Protection from Malicious Code) [10] and also in NIST SP800-83 (Guide to Malware Incident Prevention and Handling) [17].

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 8 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

3.2 Threats
A detailed consideration of potential attackers (threat actors) and their capabilities is provided in GPG7 [10] and is summarised below. In order to achieve everyday business objectives most public sector organisations have established network connections with their business partners, suppliers and the citizen, in many cases via the Internet. The range of those information exchanges and the technologies that support them provide potential attackers with the opportunity to use malware to attack ICT systems. The most common technology-based business interactions are vulnerable to attack, e.g. e-mail, web browsing, an external facing web site that accepts customer input etc. In addition, the uncontrolled use of removable media and peripheral equipment such as personal end user devices (EUDs) can also increase the level of risk to an ICT system. There is also increase in complicated, distributed malware attacks from highly organised, persistent attackers (known as Advanced Persistent Threats (APTs)), so it is critical to address malware protection as part of an overall defence-in-depth security strategy. Attacks could be perpetrated either directly or indirectly by an attacker. Such attackers could attempt to: Install and execute malware that is intended to leak personal, sensitive, or protectively Marked information; Install and execute malware that is intended to capture passwords or credentials that can then be used to gain unauthorised access to both internal and external systems; use malware to exploit a previously unidentified vulnerability in a device, application or service, before the existence of that vulnerability is known about publicly and before an authorised vendor releases a patch; use malware to exploit a publicised vulnerability which has not been patched or mitigated with other security controls; use malware to gain control or disrupt the services of the computer network from a remote machine; install and execute malware that is intended to adversely affect system or information integrity; use malware to deny the services provided by the ICT system to authorised users, for example by: o o o Flooding the network with network traffic (e.g. bandwidth exhaustion), thereby restricting access to legitimate users; Disrupting a service by making multiple requests thereby denying access to legitimate users; Disrupting configuration information, e.g. routing information to a service or network;

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 9 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

o o

Causing an application on a web server to fail or become unstable; Altering the configuration of network routing devices, thereby making the web server 'unroutable' and appear to be missing to its users;

use malware to compromise a web site that they believe the users of their intended target system will use. When accessed by the user, it could deliver a malicious payload, sometimes known as a 'drive-by attack. An attacker may also use social engineering techniques to gain information about the internal business processes, the organisations network and systems or the users. This information could then be used to target the network connections, e-mail addresses or browsing habits. Some examples of these types of attacks Phishing - These may or may not use malware directly but are attacks that attempt to entice users into divulging sensitive, personal or financial information or login credentials. This may be through requests for information to be provided in direct response to e-mail or by redirecting them to a malicious or spoofed web site that collects personal or sensitive information; Pharming - Similarly to phishing, pharming attacks are primarily concerned with redirecting users to malicious websites either to entice them into giving away personal and sensitive information or to make them vulnerable to any malware hosted on the site to which they are redirected; Hoaxes - These are messages usually circulated by e-mail alerting users to viruses, potential virus outbreaks or computer system vulnerabilities. The majority of hoaxes are aimed at wasting the time of users, system administration and management staff. Hoaxes usually do not contain malware that can be executed. However hoax messages can be considered malicious because in some cases they can communicate convincing guidance for users to change the configuration of the system. This can lead to denial of service or be aimed at preparing the ground for further attacks.

For further guidance on both phishing and pharming see CPNIs document Phishing and Pharming: A Guide to Understanding and Managing the Risks [14] at: http://www.cpni.gov.uk/Documents/Publications/2010/2010019-Phishing_pharming_guide.pdf. The potential vulnerabilities that an attacker could exploit are considered in the next section.

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 10 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

3.3 Vulnerabilities
3.3.1 Overview

ICT systems can be infected by malware through a number of routes as summarised diagrammatically in Figure 3 below and further explained in the following sub-sections. Further detail is available in GPG7 [10].
Patching and Release Management
Email
Attachments

Removable Media

Systems and Applications

Phishing / Social Engineering

* *
* *

Connection of Equipment / End User Devices

Potential malware delivery mechanisms

3.3.2

Removable Media

For the purposes of this standard, removable media is any readable or writeable media that can be introduced to an ICT system to import or export data. These include: All read/writeable optical media (e.g. CD-R/W and DVD-R/W); USB memory sticks; USB external hard and flash drives; Removable Hard Drives (e.g. IDE/SATA); Floppy disks; Backup tapes: Memory expansion and storage cards (e.g. SD and XD, CF);
Malware Protection Std v1-0 Page 11 of 47

Author: PSN Cyber Team

* *

Configuration

** ** *

Web
Malicious web site

File formats & types

Application development

Access Control

Web site attacks

Other business communications channels


Collaboration tools IM / Social media

Physical access

Streamed media RSS feeds

* * * *

Figure 3: Potential malware delivery mechanisms and vulnerabilities

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

Zip and other proprietary disks.

Potential delivery methods include the following: A user copies an infected file from the removable media and executes it; The malware stored on the removable media is formatted to run automatically or embedded into a file that is formatted to run automatically or the removable media itself is formatted to be bootable on system start-up; file types (e.g. .pdf, .doc, .tif) exploit a vulnerability in the application opening the file and loads malware. Physical Access

3.3.3

If users are allowed to connect unauthorised equipment to the corporate networks and systems (e.g. laptops or personal digital assistants (PDAs)) then attackers could infect these systems when they connect to untrusted networks (such as the Internet) and the malware could be propagated to the organisations networks and systems when the device reconnects for the first time. It is therefore important to consider adequate malware protection (or alternative security controls such as a limited access walled garden environment) wherever a Bring Your Own Device (BYOD) model is going to be adopted (see also Section 3.3.4 below). 3.3.4 Connection of Equipment / End User Devices

This is a situation where the equipment to be introduced has been previously infected or compromised and its connection to a larger system or network allows the malware to proliferate. For example, a user has loaded some free software from a PC magazine onto their approved laptop. However, the free software also installed a worm that will actively seek a specific and vulnerable enterprise application. While the laptop is disconnected from the corporate network, the infection has negligible impact. However, on reconnection, the worm will self-propagate around the network infecting other vulnerable systems. The proliferation process would also use a large amount of network bandwidth, thereby reducing operating capabilities. Additionally, organisations should be aware of the risks associated with the connection of other portable electronic devices, for example smart phones and personal digital assistants. These devices have capabilities similar to that of personal computers and laptops in terms of receiving, transmitting and processing information. There are various means by which these devices achieve their connectivity (e.g. wireless, Bluetooth or infrared). Equally, malware could be introduced by connection of infected USB devices that, upon connection, automatically upload and execute code on the host system, for example to provide device drivers. These include USB memory devices and other USB connected devices. 3.3.5 Patching and Release Management

Applications are normally installed from media or downloaded from a secure or reputable web site. Installation programmes that accompany the application then conduct system validation, file and folder creation, updates and changes to registry settings and backup and remove temporary files
Author: PSN Cyber Team Malware Protection Std v1-0 Page 12 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

activities. Malware can be incorporated with the installation programme, as part of the application, or simply copied from the removable media itself. Similarly to installation of applications, the installation of updates and patches could allow the introduction of malware either through updates and patches or those provided on removable media. 3.3.6 E-Mail

Malware can be embedded within e-mail message content or in attached information and files. Users could be encouraged to use embedded links to visit compromised websites and web pages or open embedded or attached content that contains malware which then executes on the user's machine. Successful attacks convince the recipient that the e-mail message and attachments originate from a trustworthy source. They may contain content that is relevant to the individual's role or the work of the organisation (a targeted attack), thus increasing the likelihood that the user will open the attachment and activate the malware. Social engineering / 'phishing' attacks adopt a similar approach where a user is lured into opening an e-mail that they think is authentic and are either asked directly to provide sensitive or personal information or directed to a malicious web site (e.g. 'spoofed' banking web site or other vulnerable website) where their personal and sensitive information is logged as it is input. In some cases, e-mail can appear to be from a known contact but has been sent maliciously, as the contact themselves have been infected. 3.3.7 Malicious Web Sites

The Internet hosts a significant number of web sites that contain malicious and inappropriate content. This is particularly true of sites where visitor-generated content is the underlying principle for delivery of the web site. There is no way to validate the trustworthiness of the content and code hosted by these sites. Therefore uncontrolled access by users to these sites (either deliberately or accidentally) increases the likelihood of being infected by malware. Even websites that are considered reputable could contain poor coding that might provide the opportunity for an attacker to create an apparent presence (e.g. via advertising banners, pop-ups, etc.) that could divert a user to a malicious website or cause malware to run on the users browser or system. Web browsers provide mechanisms to feedback information to web sites visited via web request metadata and browser cookies. Although this facility is provided to assist usability, it can be abused and provide information on the user, characteristics of the host and network they are accessing from and patterns of use. With widespread collection of un-sanitised information this can also provide an attacker with intelligence information regarding an organisation. Systems hosting web sites can also provide information to attackers by the way that they report errors (this information could be useful to deduce the system in use and thus its vulnerabilities). Social engineering attacks could also be used to entice users to visit websites that have been compromised by malware. For example, a user could receive what appears to be a legitimate e-mail from a web service provider with a too good to miss offer. The user is encouraged by the text of the e-mail to follow an embedded link to the website which contains malware that could potentially exploit
Malware Protection Std v1-0 Page 13 of 47

Author: PSN Cyber Team

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

vulnerabilities in the user's system. The user follows the link and malware is then uploaded and executed on the user's system, often without the user knowledge. 3.3.8 Web Site Attacks

Attackers could attempt to insert malware into public sector web sites that provide a service to the citizen. This type of attack is usually possible when the web site accepts uncontrolled input from users. Organisations should consider the risks to the Confidentiality, Integrity and Availability of their web site and any information provided by the citizen which is retained on the website and ensure that appropriate risk management measures are implemented. There are also risks associated with downstream liability and a compromised public sector web site being a staging post for further attacks. For example, if an attacker manages to compromise a public sector website which is then used to propagate malware to other organisations, those organisations could instigate legal action against the public sector organisation as the owner of the web site from where the attack originated. 3.3.9 Other Business Communication Channels

Today's business computing environment provides a number of alternative means to traditional email and web browsing services, by which users can receive and exchange information for business enabling purposes. The potential risks with this type of information exchange are that they may be used to bypass the traditional boundary security controls and so a defence-in-depth approach should be adopted. Examples of these channels are: Collaborative working (chat/white boarding, external hosted/cloud-based storage); Instant messaging (IM) and other related social media (that allow embedded content and file attachments); Streamed media (television/radio/movies/music); Rich Site Summary (also known as Really Simple Syndication or RDF Site Summary (RSS)) feeds.

3.3.10 Systems and Applications 3.3.10.1 Overview

There are a number of vulnerabilities that a potential attacker could also exploit in the configuration and development of systems and applications that could allow them to successfully introduce malware and realise its effects, as shown in Figure 4 below.

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 14 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

Systems and Applications

Configuration

File formats & types

Application development

Access Control

Figure 4: Vulnerabilities in systems and applications

3.3.10.2

Configuration

Default manufacturer settings may not always provide the best defence against malware, as certain protections may be turned off by default to improve usability. Equally, some default settings deliberately provide some measure of protection against malware (e.g. barring access to dangerous file types in later versions of Microsoft Outlook), but if these are turned off, either in an organisation's chosen configuration or because the user is able to make unauthorised changes to such settings, then the affected hosts will be rendered even more vulnerable to attack. Systems that allow uncontrolled access to, and usage of memory by, applications and programs could allow attackers to run or execute malicious commands and code stored elsewhere in memory. For example, where a line of code is inserted into an authorised program or application, this code points to a line or lines of code elsewhere in memory that, when executed conducts a malicious action. Systems that allow code to be executed without authorisation, either manually or automatically (e.g. by browsers or e-mail clients), could allow attackers to introduce and execute malware. For example, an authorised user could introduce malware through installing a compromised screen saver from a CD or one that they have been sent by a friend in a partner organisation by e-mail. The effectiveness of security controls against malware attacks (e.g. AV and IDS solutions) is highly dependent on the timeliness and correctness of security product updates. In addition, it is important to note that AV products are only effective against known malware attacks, although heuristic capabilities can help to detect previously undocumented attacks. Systems and applications that are not locked down, patched or updated against known vulnerabilities could allow execution of malware (e.g. in browsers and e-mail clients). 3.3.10.3 Application Development

Due to failures in, or lack of, quality control of the development process a software developer could insert code into an application that either leads to a 'logic bomb' type attack or provides an alternative access point that bypasses the advertised access control mechanisms; for example, a backdoor.

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 15 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

Poorly developed applications, or those that accept uncontrolled user input, could allow unauthorised access and insertion of code that leads to behaviour or actions that are unintended (e.g. through SQL injection, XSS or buffer overflow attacks). 3.3.10.4 Access Control

Applications and systems that provide user and management interfaces could provide attackers with an entry point by which they can introduce malware. Weak access controls and the lack of, or failures in, access control mechanisms could allow unauthorised or escalated access to systems and applications resulting in the introduction of malware. Escalation is where an attacker will attempt to gain the highest level at privileges possible upon the target system; it occurs when at the outset the attacker has a low level of privileges and he or she uses alternative or other attacks to gain high privilege levels. Uncontrolled or unlimited user access to services (e.g. web and e-mail) that allow the electronic import and export of information, data, applications, programs or code could lead to the introduction or export of malware. Uncontrolled or unlimited user access to host system input / output devices and ports could lead to the successful import or export of malware from removable media or attached equipment (e.g. USB memory stick, CD/DVD ROM drive or PDA etc). Uncontrolled physical access to ICT equipment, including PEDs, could result in the introduction of malware. 3.3.10.5 File Formats and Types

There is no such a thing as a "safe" file format. Current complex file formats provide opportunities for a variety of attacks. Significant risk now comes from what was traditionally thought of as passive data formats such as image files (.jpg, .gif and .png) and more complex, but common, file formats such as Microsoft Office (.doc, .xls and .ppt), OpenOffice (.odf and others), and Portable Document Format (.pdf). Many of these will be automatically rendered by browser or e-mail applications and are routinely exchanged by users. Opportunities for attacks using data files can be grouped into two main categories: Malformed data that causes errors that can lead to execution of code; Business applications that are feature-rich require complex data file formats and supporting features. This complex and rich environment could potentially be exploited maliciously through, for example, malformed and buffer overflow attacks.

Potential attackers can deliver malware to ICT systems by altering files to represent themselves as authorised file types. For example, if an organisations security policy mandates that it shall only accept word processing documents (e.g. example.doc) and the perimeter defences have been configured to examine for authorised file extensions, the attacker could simply change the file extension of the malicious file to match an allowable file type.

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 16 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

3.4 Security Controls


3.4.1 Introduction

Section 3.3 (Vulnerabilities) discussed the various malware delivery mechanisms and areas when an ICT system/application could potentially be vulnerable. This section considers the security controls that should be implemented to address these areas, as summarised in Figure 5 below.

Policy / procedure(s)

Governance

Supplier management

Removable Media Systems, EUDs & Applications


Configuration lockdown

Network Protection
Connections

Patching & vulnerability management

Malware Incident management

Mobile Code

Quarantine Systems
Sheep Dip systems

Physical Protection

AV products Access control Secure development

Gateways
Email Web
Other

Sandboxes

Security awareness

Potential Security Controls


Compliance Requirements
Figure 5: Malware Protection

PSN Conditions

Note that many of these controls are recommendations and guidance only, based on industry good practice; formal PSN requirements are summarised in Section 3.5 (PSN Compliance Requirements) below. They should not be applied in isolation but as part of an overall information risk management strategy. Recommended requirements to be imposed on service providers are also included in Section 3.6 (Recommended Service Provider Requirements). 3.4.2 Policy and Procedures

Organisations should adopt a defence-in-depth approach to the selection, deployment and configuration of malware protection controls, commensurate with the threat and risks to their business.

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 17 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

Organisations should produce relevant security policies, processes and procedures to mitigate operating systems and application vulnerabilities that malware might exploit for any ICT infrastructure component including mobile devices, required to support the business. Policy and controls with respect to malware protection should be proportionate to the risk, i.e. justified by the results of a formal risk assessment as per ISO/EC 27001 [21] (and for those organisations handling nationally sensitive information, HMG Information Assurance Standard No. 1 and 2 (IAS1&2) [8]). An organisation should have defined policy and procedures for malware protection; this may take the form of a single document or separate documents. These should, as a minimum: Identify and assess the risks from malware and services and mechanisms provided by the organisations ICT systems by which malware could be introduced; Identify the security controls that are employed to mitigate and manage these risks, including acceptable use of services and systems; Define the organisations policy on the use of o o o o active content / mobile code; macros; personal end user devices (including smartphones and PDAs); removable media;

Identify associated Incident Reporting and Response plans and processes; The roles and responsibilities for management of anti-virus (AV) solutions; Specify the actions to be taken in the event of malware infection and to subsequently enable recovery from that infection. Relevant PSN Code Conditions: (RIS.1) The connecting organisation shall demonstrate a risk management and standards-based approach to the assurance of their connected network. 3.4.3 Supplier Management

Organisations should ensure that contracts with service providers include clear requirements on the selection and maintenance of the malware defences that support the organisations malware policy (see Section 3.4.2 above). This should include aspects such as: identification of software updates/patches and the timescale for their assessment and deployment into live operation; malware incident management and recovery; vulnerability assessment / malware policy compliance testing. Organisations connecting to the PSN should ensure that their suppliers services are sufficient to manage the risk from malware to their business as well as the risks from connecting to the PSN.

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 18 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

Organisations should ensure that service providers configure their systems to prevent the execution of unauthorised applications or unsigned executable code from systems used to deliver or support services to them. Organisations should ensure that service providers identify to them those services that cannot be protected from malware using an anti-virus (AV) product. When planning to use cloud-based services, consumer organisations should ensure that they understand the differing levels of responsibility for malware protection depending on the type of cloud service that is being procured and ensure that adequate contractual provision is made: For Software as a Service (SaaS), then malware protection should be exclusively the SaaS providers responsibility and out of the hands of the consumer organisation; For Infrastructure as a Service (IaaS), then malware protection is likely to be the consumer organisations responsibility as the consumer is responsible for configuration of the system instantiations; For Platform as a Service (PaaS), there is likely a joint level of responsibility between the consumer and the PaaS provider for malware protection. Recommended requirements to be imposed on service providers are also included in Section 3.6 (Recommended Service Provider Requirements). 3.4.4 Removable Media Controls

Organisations should have a policy for removable media that identifies the risks of using such media and the controls necessary to manage those risks (see 3.4.2 Policy and Procedures). Use of removable media should be limited to those users who require it in support of their business function. Removable media must also be suitably encrypted to protect data at rest and in transit. Any data introduced through removable media should be subject to content analysis and AV scanning, ideally via a standalone virus checker (see Section 3.4.7.1 Sheep Dip System), before being introduced into an organisations ICT environment. Relevant PSN Code Conditions: (MED.1) As part of an overall risk management approach, customers shall have a policy for removable media that addresses the risks of using removable media. (MOB.5) Remote / mobile devices shall employ encryption to protect data at rest and in transit. The cryptography used shall have a suitable level of assurance. (MAL.2) The organisation shall identify and isolate malicious software (at least viruses, macros, dangerous file types, mobile code and spyware) (MAL.3) Any data introduced through removable media shall be subject to content analysis and AntiVirus scanning, ideally via a standalone virus checker before being introduced to the PSN environment.

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 19 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

3.4.5 3.4.5.1

Systems, End User Devices (EUDs) and Application Controls Introduction

Systems, end user devices (EUDs) and applications can present vulnerabilities to potential attackers. These vulnerabilities can be introduced through poor design, development, poor implementation and configuration. This can particularly apply where an organisation decides to implement a Bring Your Own Device (BYOD) environment. A well-designed and implemented system, end user device or application will limit the ability of a potential attacker to introduce unexpected input via interfaces and limit and control access to services and sensitive information. Organisations should identify and isolate malware so far as is practical and possible (i.e. at least known viruses, macros, dangerous file types, mobile code and spyware). This is typically performed through the following controls at a system, end user device and application levels: Configuration lockdown and standard builds (including installing personal firewall/host intrusion detection/prevention on each EUD) see Section 3.4.5.2; Use of AV products (including spyware protection) see Section 3.4.5.3; Access control and accounting see Section 3.4.5.4; Malicious mobile code protection see Section 3.4.5.5; Secure development and testing of systems and applications see Section 3.4.5.6. Where BYOD has been adopted, organisations should ensure that there are adequate controls in place to ensure malware protection, appropriate to the impact level of the environment and level of trust placed in such devices. Where this is not possible, then alternative security controls such as a limited access walled garden environment should be considered, appropriate to the identified risks. Relevant PSN Code Conditions: (MAL.2) The organisation shall identify and isolate malicious software (at least viruses, macros, dangerous file types, mobile code and spyware). 3.4.5.2 Configuration lockdown/standard builds

Organisations should have a configuration lockdown policy for the different components of their ICT environment, including end user/mobile network devices. They should apply appropriate hardening templates to these standard builds as part of a defence-in-depth approach in order to: Install only those software components that are going to be used; Disable all unused services/functions; Configure the component to minimise known vulnerabilities; Prevent unauthorised alteration of the configuration (e.g. by end users). The principle is that if software is not installed in the first place, it cannot be vulnerable. Therefore only software and applications that are really needed should be installed and service providers/suppliers should be required to minimise the software footprint on all client and server devices that they provide. This should ensure that components are configured and hardened to
Author: PSN Cyber Team Malware Protection Std v1-0 Page 20 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

protect against attacks that manage to get past an organisations perimeter and network based defences. This may also improve system performance. Organisations should have a configuration control process in place which prevents unauthorised changes to these standard builds. All changes to standard builds and systems should be formally approved and all standard build documents should be updated accordingly. A lockdown will reduce the attack surface of the component by minimising the user's (and the malicious softwares) ability to change critical configurations and gain access to services that allow execution of privileged commands. A lockdown approach can also control authorised applications and executables, enforce boot sequence control and limit access to I/O devices. Organisations should also consider the use of a recognised lockdown configuration, for example the Government Assurance Pack (GAP) available from CESG or an appropriate alternative (e.g. NSA security configuration guides see below). Note that the GAP is typically only available to Central Government Departments and their agencies, Government Bodies, Local Government, List X suppliers/CLAS consultants and companies which are a key part of the UK Critical National Infrastructure (CNI), with the permission of CESG (see CESG GAP FAQs [13]). Operating System and application vendors often provide useful guidance on how their products can be effectively locked down as well. Vendor websites are a useful resource when locking down or hardening systems. Other sources of lockdown information are listed below: When considering physical and technical security of ICT systems, organisations should use the information provided by the Centre for the Protection of the National Infrastructure (CPNI). Further information is available online at www.cpni.gov.uk. US National Security Agencys (NSAs) security configuration guides http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/index.shtml). (see

The Centre for Internet Security provides a number of benchmarks for various products that are available on the Internet for download. Further information can be found at www.cisecurity.org. The Standard of Good Practice (SoGP) for Information Security provided by the Information Security Forum (ISF) provides further useful information with regard to system lockdown this is available on line at www.securityforum.org. The US National Institute of Standards and Technology (NIST), Computer Security Resource Centre (CSRC) provides useful guidance information when considering secure configurations. These are available online at csrc.nist.gov. The SANS Institute provides useful information security resources including additional information and guidance on security lockdown and system hardening using the SANS Institutes Twenty Critical Security Controls for Effective Cyber Defense [18] (to which CPNI has contributed). Further information is provided online at www.sans.org or can be found at www.cpni.gov.uk/advice/cyber/Critical-controls/. The following additional controls should also be considered for systems and EUDs:

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 21 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

Host Firewall. A host-based firewall provides a protective boundary for the host device (in a similar manner to a network firewall, with rulesets and white/blacklists). It monitors and restricts information that travels between it and its attached network(s). Host Intrusion Detection/Prevention. Intrusion detection/prevention software could be installed on the host to detect and potentially prevent a malware attack. o Host Based Intrusion Detection Systems (HIDSs) will monitor system activity on these hosts and, should unusual activity be identified, an alert will be sent to an audit centre for analysis and response. Some HID solutions include memory firewall type functionality that places limitations on the way system memory is used by applications and programs. It should be considered that the use of intrusion detection and prevention measures could increase the number of 'false positives' detected. This is where legitimate activity is identified as suspicious or nefarious activity and subsequent investigation and reaction could disrupt business operations. Host Based Intrusion Prevention Systems (HIPSs) go a step further by blocking the suspicious activity identified. They do this by not letting the suspicious activity complete its action. It should be considered that the use of intrusion detection and prevention measures could increase the number of 'false positives' detected. This is where legitimate activity is identified as suspicious or nefarious activity and subsequent investigation and reaction could disrupt business operations.

Integrity Checks. Malware will often attempt to or will change the configuration of systems and applications on execution. Specialist process execution arbitration software can be installed onto a host to further restrict the operating system environment. This software should define what software is and is not allowed to run; whitelists are always preferable to blacklists. Thus, if an attack successfully exploits a non-privileged process, the attack will also be confined to this even more restrictive environment. This control is intended to preserve the integrity of systems by preventing the execution or installation of unauthorised code or applications. Where non-organisation-controlled ICT assets are used to access the organisations ICT infrastructure (e.g. an employee using their home ICT equipment or own devices to connect in) then it should be used in accordance with the organisation's remote/mobile working policy and appropriate controls should be implemented in accordance with a risk assessment. The organisation must be able to show appropriate control and management of the technical environment of any device that has access to PSN services/networks. Relevant PSN Code Conditions: (CON.1) Hardware and software shall be locked-down in accordance with the organisations lockdown policy and is part of an overall risk managed approach so that functionality is limited to what is required for the provision or consumption of the PSN service. (CON.2) The execution of unauthorised software shall be prevented (CON.3) Organisations shall have in place a configuration control process which prevents unauthorised changes to the standard build of network devices and hosts
Malware Protection Std v1-0 Page 22 of 47

Author: PSN Cyber Team

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

(CON.4) Users shall use accounts with the least privilege required to perform their roles. (CON.5) Customers allowing active content shall be able to demonstrate that this is done as part of an overall risk managed approach. Therefore risks from allowing Active Content shall be understood and appropriate controls shall be implemented. (CON.6) The customer shall implement controls to ensure that executable content shall not be run without the user's active consent and within the organisation's control. (MOB.1) Any mobile/remote and/or home working solution that accesses PSN services/networks shall be operated in accordance with the organisation's remote/mobile working policy that identifies and mitigates the risks of using mobile/remote access solutions. This policy shall include the adoption of electronic, personnel and physical security measures. (MOB.2) The organisation must be able to show appropriate control and management of the technical environment of any device that has access to PSN services/networks 3.4.5.3 AV products

AV products (including software to detect spyware) are a key defence against malware and all hosts should have an effective form of AV product installed. The Virus Bulletin has carried out independent comparative testing of AV and anti-spam products, and organisations may wish to use a product listed in at least the top 20% of their latest Reactive and Proactive (RAP) tests (see http://www.virusbtn.com/vb100/index). Typically. AV software installed on hosts (servers and EUDs) should scan files on access and scan the file system periodically or on demand, looking for suspicious files. If a suspicious file is identified, it should be quarantined and an alert should be raised. Note however that this may potentially cause performance and integrity issues with some services (e.g. databases). A risk assessment should therefore be conducted for any such service, the performance of which could be impacted by the introduction of on access AV software, Host AV software is typically signature-based, although some products have heuristic capability. This is where AV and web protection products have a capability to detect unknown or 'stealthy' malware attacks or identify unusual behaviour that may indicate that code may be suspicious or malicious. These techniques are prone to triggering 'false positive' alerts that can lead to service degradation or are ignored by security analysts due to the volume of 'false positive' alerts being generated. Their use could introduce an additional vulnerability that an actual attack may be incorrectly interpreted as a 'false positive' and ignored. Signature based AV products are usually only an effective measure against known malware attacks, e.g. common attacks downloadable from the Internet. The traditional scope for an AV product has been broadening in recent years and many AV products now include activities for scanning all content accessed via the web browser (and in some cases even pre-scanning websites prior to the user actually visiting them). AV products should typically: Be procured from reputable vendors with proven track records;
Author: PSN Cyber Team Malware Protection Std v1-0 Page 23 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

Be capable of receiving regular updates to protect systems against new malware attacks; Be configurable to meet the needs of the organisation; Be capable of being managed centrally and as an independent implementation; Be capable of accepting online and manual updates; Have the capability to detect all types of known malware as well as blended attacks; Be capable of detecting suspicious behaviour through heuristic capabilities; Be capable of conducting on access and scheduled AV scans; Be capable of detecting malware on inbound and outbound connections; Be capable of quarantining suspected or infected objects; Be capable of removing infections; Include host firewall and IDS capabilities that are configurable to allow or deny inbound and outbound connections to and from applications and services. Be configured to provide an auditable log of actions and events. Relevant PSN Code Conditions: (MAL.2) The organisation shall identify and isolate malicious software (at least viruses, macros, dangerous file types, malicious mobile code and spyware) 3.4.5.4 Access control and accounting

User access to systems, services and applications should be on the basis of least privilege. This means that access to potentially vulnerable business services (e.g. import and export via removable media, web browsing and external e-mail) should be authorised and limited to users who require it in support of their business function. Relevant security events, including attempted/actual use of these business services, should also be accounted for in accordance with the organisations security policy (see reference to protective monitoring at the start of Section 3.4.9). Organisations should consider use of Discretionary, Role Based or Mandatory Access Control models as appropriate based on the results of a technical risk assessment. 3.4.5.5 Mobile Code Protection

As with any executable code, mobile code (where the same code can be executed on various platforms) can be malicious. Mobile code includes ActiveX, Java, Postscript and other scripting languages. Organisations should have a policy for mobile code (including active content) that identifies the risks of using such code and the controls necessary to manage those risks (see 3.4.2 Policy and Procedures). All mobile code that is imported by any means should be checked for the presence of malware. Organisations should consider the following controls:
Author: PSN Cyber Team Malware Protection Std v1-0 Page 24 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

Mobile code should be executed in a logically isolated environment so far as is practical (e.g. a sandbox see Section 3.4.7.2); Use technical measures on ICT systems to ensure the use of mobile code is managed (e.g. MS Office applications and web browser applications should make use of functionality to manage acceptance of, use of and creation of mobile code); Control the resources that are available to mobile code (e.g. lockdown of systems and lockdown of applications to ensure that applications run in a mode that enforces the principle of 'least privilege') see Section 3.3.10.2; Utilise cryptographic controls to verify and assert a level of trust in the source of the code and to ensure that the code has not been tampered with in transit. This should include the use of appropriate signing and hashing algorithms; Block receipt of mobile code; Prevent the execution of mobile code. Applications such as web browsers and email clients can be configured (ideally hardened as part of an enterprise approach) to permit only the required forms of mobile code (e.g. JavaScript, Active X, Java) that are essential to meeting an identified business requirement and from trusted locations potentially enforced through the application of a white list that limits the websites that can be browsed. In conjunction with the secure configuration of end user devices, the boundary gateways and potentially other points in the security architecture could also be configured to filter web content to prevent mobile code that has not been approved from accessing the client environment. Relevant PSN Code Conditions: (MAL.2) The organisation shall identify and isolate malicious software (at least viruses, macros, dangerous file types, mobile code and spyware) (CON.5) Customers allowing active content shall be able to demonstrate that this is done as part of an overall risk managed approach. Therefore risks from allowing Active Content shall be understood and appropriate controls shall be implemented. (CON.6) The customer shall implement controls to ensure that executable content shall not be run without the user's active consent and within the organisation's control. 3.4.5.6 Secure systems and applications development

All systems and applications should be developed with security in mind, so that they provide appropriate levels of access control, correct information handling, correct handling of exceptions and errors and security of user and administrative interfaces. When organisations are hosting publicly facing web sites, care should be taken to ensure that all malware insertion type attacks (e.g. SQL injection, cross site scripting) vulnerabilities have been considered and mitigated. Secure development practices should therefore be followed, including proper configuration control and testing. All code should be properly tested before introduction into operational ICT
Author: PSN Cyber Team Malware Protection Std v1-0 Page 25 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

environments, potentially utilising formal vulnerability assessments in cases where the code will be accessible to the general public (e.g. on a citizen-facing portal). Potential sources of secure development good practice are: CPNIs Development and Implementation of Secure Web Applications [15] Open Web Application Security Project (OWASP) (www.owasp.org) CERT secure coding standards (www.securecoding.cert.org) ISO/IEC 27034: Application Security [22] Relevant PSN Code Conditions: (CON.3) Organisations shall have in place a configuration control process which prevents unauthorised changes to the standard build of network devices and hosts 3.4.6 3.4.6.1 Network Protection Network Connections

In order to prevent potential attackers from exploiting vulnerable network services to introduce malware to systems or applications, network services should also be limited to those that support the business function. This can be achieved through the use of firewalls and where connections to other networks use of perimeter network security controls should be considered. The principle of least privilege should be followed. Physical access to an organisations ICT connections (e.g. network ports in offices or communications rooms) should be similarly limited so far as is practical to those with a specific business need. Consideration could be given to employing physical port locks or network access control (NAC) mechanisms such as whitelisting network MAC addresses to reduce the risk of unauthorised equipment being plugged into a network. Organisations could further consider employing network separation to partition specific areas of their network to provide both a point where boundary crossing can be accounted for and audited and where perimeter security controls can be utilised to enforce organisational security policy, i.e. to act as a firewall against a growing malware outbreak internally. The following additional controls should also be considered: Network Intrusion Detection Systems (NIDSs) can be placed on the network to monitor network traffic for unusual activity. Reconnaissance activity by a potential attacker may be detected as a precursor to an actual attack. Suspicious activity may be detected when the attack is delivered or after an attack has been successful, for example, when sensitive data is being exfiltrated. Unusual or malicious activity on the network may be detected from changes to baseline user activity. When an attack is identified/suspected, an alert will be raised for analysis and response. A Network Intrusion Prevention System (NIPS) goes a step further by blocking the suspicious activity and may be able to prevent attacks against the internal infrastructure. They do this by

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 26 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

taking a reactive action, such as automatically reprogramming the firewall to block the suspicious network traffic. Note that NIDS/NIPS are primarily signature- based, therefore they will only identify activity that they are configured to recognise as suspicious. 3.4.6.2 Boundary Controls

Appropriate malware protection controls should be in place at all network boundaries on both incoming and outgoing communications, particularly for interconnections between PSN and non-PSN networks/services (see BOU.5). It is important to note that once malware enters a network it often tries to create a connection out to the Internet to exfiltrate information or open up a control channel. It is therefore extremely important to check outgoing data as well as incoming data. Monitoring should also be performed for communications being initiated at unusual times (e.g. outside normal working hours) as well as for instances of encrypted traffic. Ideally different AV products should be deployed at network boundaries to those deployed on internal systems and clients. This helps to enforce a defence-in-depth strategy though having different detection mechanisms in case malware manages to pass through a particular vendor solution undetected. As already stated, there are no safe file formats. Many business applications are feature rich and require complex data file formats which provide opportunities for a variety of attacks. Malformed or misrepresented data or files can cause errors that can lead to the execution of code or exploit unpatched vulnerabilities in applications and operating systems. To manage the risks from malicious import (and potentially export), some form of in-line content filtering capability should be established at network boundary points to help to prevent content based attacks against software applications, the import and export of malicious content attached to emails and inappropriate content. Boundary gateways should be able to inspect incoming and outgoing packets and files and identify malicious content, isolating it as required and alerting the organisations security staff. The management of the filters and the timescales for responding to alerts should be agreed with the service provider and specified in the service providers contract. Content checkers can include the following functionality: AV checks. Quarantining of content that contravenes an agreed rule set. File type checks: these are intended to only allow certain agreed file types to traverse the boundary. Some file type checks might completely break down the file and look for discrepancies in the file format, for example, overly long strings in fields. These types of checks are aimed at attacks where the potential attacker attempts to inject the attack by impersonating a commonly used or authorised file type. A very simple example would be to simply change the extension of an executable file, which contains malware to a commonly used document file extension (some Microsoft Office products try to execute or open files based on the header information in the file, not on the file extension).

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 27 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

Checks for keywords: this is where inbound or outbound content can be checked for certain sensitive (or watchlist) words in accordance with the organisations security policy, e.g. inappropriate content. Checks for sensitive information, e.g. protective markings, descriptors: content checks rule sets may be configured to check for certain information particularly in outbound content to minimise risks posed from data leakage. Checks for malware: checks for known malicious content types. Checks for malicious mobile code: checks for code that traverses the boundary when users are accessing an Internet-based service. The malicious mobile code is accessed when a user browses the compromised web site, and is then executed within the users browser application on their host ICT system. Content checkers should also check information files for hidden malware. Information files can contain hidden information that the user may not be aware of, either when they receive it or when they transmit it via information exchange. For example metadata and file properties, tracked changes, comments, or information that is hidden within the file itself e.g. text that is the same colour as the background (white text on a white background) or extremely small font text that is difficult to see on a normally viewed document. Hidden data could include malware and inbound and outbound exchanged information should be checked for the presence of hidden data and malware. Content checkers can be file-based or proxy-based. File-based content filters would typically be deployed to scrutinise file sharing between two networks, with only files that pass the checks allowed through. In contrast, proxy-based content filters would act as an intermediary between the client and server, allowing it to scrutinise protocols such as HTTP for malicious content in real-time. Consideration should be given separately to using application proxies as well. An application proxy acts as an intermediary between the connecting client and the external service, thereby removing the direct link between the two and adding an additional layer of defence. A proxy server may mask internal addresses and also rewrite the request from the client, either to sanitise it, or to add additional information to the request. The application proxy can also be used to provide application security functionality for example to confirm the correctness of inbound and outbound information traffic. Relevant PSN Code Conditions: (BOU.2) When interconnecting between PSN networks/services and non-PSN networks/services an assured gateway/boundary controls shall be implemented. (BOU.3) Where connecting organisational/non-PSN networks to PSN networks and services at the same impact level/security domain organisations shall consider the risks and implement effective mechanisms for passing data between the boundaries of those domains. (BOU.5) All data traversing to and from non-PSN services/networks to PSN services/networks shall be subject to content analysis including virus checking emails and attachments at the gateway and host.

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 28 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

(BOU.6) Organisations shall filter against a white list of allowed attachment file types. The white list will be owned and managed by the customer and be included as part of the organisation's overall risk management approach. (MAL.1) Firewall and Gateway Servers shall carry out security services to identify malware and vulnerability exploiting code at the gateway. Where encryption prevents this the organisation shall implement an equivalent level of protection at the end point (MAL.2) The organisation shall identify and isolate malicious software (at least viruses, macros, dangerous file types, mobile code and spyware) 3.4.6.3 External Application Controls

As mentioned earlier (see Section 3.3.9 Other Business Communication Channels), other business communications channels could also be exploited to introduce malware into the organisations ICT infrastructure. Suggested malware protection controls for each of the identified areas are provided below (other aspects, e.g. data leakage, are not addressed): Block all access to these services, or at least limit access to those personnel with a legitimate business need. Ensure all content in/out is still scanned as per Section 3.4.6.2 (Boundary Controls) above. Relevant PSN Code Conditions: (MAL.2) The organisation shall identify and isolate malicious software (at least viruses, macros, dangerous file types, mobile code and spyware) 3.4.7 3.4.7.1 Quarantine Systems Sheep Dip System

'Sheep dip' systems provide what is effectively a boundary AV check when importing or exporting information on removable media. Sheep dip systems should be standalone and have no network connectivity, at least to the destination system/network. Transfer from the sheep dip system should be via removable media and air gapped from the destination. Organisations should consider using a different anti-virus product on standalone checkers to that used by the ICT boundary or host systems. All sheep dip systems should be updated when updated signatures become available in an agreed timeframe. To support audit requirements, the system could also request the users name and the reference number of the media being scanned. If any malware is detected then there should be clear instructions to the user on who they should inform and equally what steps the responsible individual should take when dealing with the infected media. Relevant PSN Code Conditions: (MAL.3) Any data introduced through removable media shall be subject to content analysis and AntiVirus scanning, ideally via a standalone virus checker before being introduced to the PSN environment.
Author: PSN Cyber Team Malware Protection Std v1-0 Page 29 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

3.4.7.2

Sandboxes

A sandbox is a quarantined environment where code that has been identified as being potentially malicious can be contained within to prevent it from infecting an organisations wider ICT environment. A sandbox can exist within an application but some organisations create a dedicated environment that has no or highly controlled network connectivity. This can even be a sacrificial computer that can be used to test software or content to ensure that it does nothing malicious. Once inside the sandbox the code can be executed or examined in a controlled manner without the risk of releasing the potentially malicious payload to operational systems. Dedicated sandbox environments can be costly and most require high assurance. Equally, a high level of expertise is needed to make a judgement on whether the content is malicious or not and this would probably be beyond the bounds of many network support authorities. This is a complex area that requires a specialist level of knowledge in order to arrive at a proportionate risk based solution. 3.4.8 Patching and Vulnerability Management

All security products and ICT systems and applications should be regularly patched and updated to prevent known attacks and remediate known vulnerabilities in order to prevent attackers exploiting vulnerabilities that may enable the introduction of malware. The patch management process is summarised in Figure 6 below and discussed in depth in the PSN Common Standard for Patch Management [7]. The key prerequisites are to know what ICT assets there are in an organisations ICT environment and what those assets look like, i.e. what is their configuration and what patches have already been applied to them.
Change management / release management processes

Asset Inventory

Patch / Vulnerability Identification

Assessment

Deployment

Figure 6: Patch Management Process

Some security and business product vendors provide automatic updates to their products. This is a useful service to ensure that protection for ICT systems is up to date. However, organisations should consider the potential vulnerability that may be introduced by automatic update services, for example additional third party connectivity, Denial of Service (DoS) through installation of untested update and introduction of malware through the patch or update itself. Only signed updates to virus signatures from trusted suppliers should therefore be accepted, as this reduces the chance of an AV update being malicious. As part of the standard configuration and control processes a degree of testing should be conducted, preferably on non critical systems first, to ensure that the update does not affect operations. All public sector organisations should be registered to receive vulnerability alerts and other pertinent threat intelligence from reputable sources (see the PSN Common Standard for Patch Management). Such sources include:
Author: PSN Cyber Team Malware Protection Std v1-0 Page 30 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

Manufacturer(s) and vendor(s) of the software used by that organisation; GovCertUK, CSIRTUK or other CSIRTs or CERTs; A public sector Warning, Advice and Response Point (WARP); Online vulnerability databases/services; Specialist security mailing lists. Organisations should ensure that they are aware of vulnerabilities that may lead to the successful introduction of malware. At lower levels of business impact (IL1-2) this could simply be through regular use and monitoring of AV, ICT system and application vendor alerts and websites, and for higher impact levels (IL3 and above) through the addition of initial or ongoing system vulnerability assessments. Organisations shall implement an annual programme of IT Health Checks to validate equipment not provided as part of a PSN service that interacts with PSN services. Organisations should maintain a situation awareness capability so that they are aware of the current threats from malware. In addition to AV and systems/application vendor information, organisations should obtain additional vulnerability information from other parties such as GovCertUK or through membership of a WARP. Organisations should conduct regular checks of ICT systems for unauthorised applications, unauthorised data or unauthorised changes to application or system configuration. Any unauthorised changes should be investigated in accordance with the organisational incident response plans and procedures (see Section 3.4.9). Relevant PSN Code Conditions: (CON.3) Organisations shall have in place a configuration control process which prevents unauthorised changes to the standard build of network devices and hosts (PAT.1) As part of the overall risk management approach taken by customers, the organisation is expected to develop and operate a patch management policy. This shall cover all software (including firmware) and infrastructure hardware used. (PAT.2) Patches shall be applied with minimal delay and audited to ensure compliance with the organisation's policy. (CHE.1) Organisations shall implement an annual programme of IT Health Checks to validate equipment not provided as part of a PSN service that interacts with PSN services. 3.4.9 Malware Incident Management

Protective monitoring is a key security mechanism that should be integrated into an organisations security policy and, therefore, the organisations ICT defence plan. It provides the means to assess the capability of the security architecture to identify and or repel an attack including malware attacks. The logs that are generated can provide vital information in a post attack diagnosis. All critical service hosts, security components and border devices should be capable of producing accounting information to support the requirements of the security policy.

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 31 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

Organisations should therefore apply protective monitoring controls commensurate to their environment and data processing requirements in order to detect and respond to indications of malware infection. (Further good practice guidance on protective monitoring can be found in CESG GPG13 [11].) Organisations should establish incident management plans for reacting to malware infection, containment, remediation, reporting and lessons learned. This should be part of their Business Continuity (BC) and Disaster Recovery (DR) plans. Given that the likelihood of attack from malware is high, it is important that contingency, recovery and forensic readiness plans are also developed and agreed by key stakeholders and communicated to all users. The plans should be reviewed periodically and in the aftermath of an incident. The NIST document SP800-83: Guide to Malware Incident Prevention and Handling [17] provides detailed advice on this process; it is summarised in Figure 7 below. Additional information is provided in CESG GPG24 (Incident Management) [12] and ISO 27035 (Information Security Incident Management) [23].

Preparation

Be prepared to deal with malware incidents Have suitably trained personnel, tools and communications mechanisms Have documented and tested procedures

Detection and Analysis

Make use of malware advisories and vendor alerts Detect and recognise the signs of malware incidents Prioritise incident response identify what needs resolving first

Containment, Eradication and Recovery

Contain the incident stop it spreading any wider (user awareness, automated detection, disabling services, disabling connectivity) Identify the source(s) of infection (forensic capability may be required) Eradicate the infection Recover the affected systems

Post-Incident Activity

Learn from the incident Revise controls to prevent reoccurrence Revise procedures to improve effectiveness

Based on NIST SP800-83: Guide to Malware Incident Prevention and Handling

Figure 7: Malware Incident Management

For malware-related incidents that impact on the PSN the organisation's security officer or senior manager should report incidents to the PSN Security Manager.

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 32 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

Malware-related incidents involving HMG ICT systems should be reported by a senior manager (after potentially consulting with their human resources, press office and legal representatives), to GovCertUK. Malware-related incidents involving HMG cryptographic material should be reported by a senior manager to CINRAS. Relevant PSN Code Conditions: (RES.1) The Customer shall consider the PSN Incident Management process (See guidance notes) in developing and implementing organisational incident response processes. (RES.2) Information, physical and personnel Security Incidents shall be reported through commensurate internal management channels managed by the organisation's Security Officer in accordance with the organisation's incident management policy. (RES.3) For incidents that impact on the PSN the organisation's security officer shall report incidents to the PSN Security Manager and other entities as required such as GovCertUK. CINRAS shall be notified for incidents involving HMG approved cryptographic equipment (PRO.1) Organisations shall apply protective monitoring controls commensurate to their environment and data processing requirements. Good practice guidance can be located in GPG13. 3.4.10 Physical Protection As with electronic connections into an ICT system (see Section 3.4.6.1 Network Connections), physical access to an organisations ICT equipment should be similarly limited to those with a specific business need. When considering physical and technical security of ICT systems, organisations should use the information provided by the Centre for the Protection of the National Infrastructure (CPNI). Further information is available online at www.cpni.gov.uk. Depending on the risk, consideration should be given to physically securing network ports and cable runs to prevent the introduction of unauthorised equipment in order to introduce malware of some kind. 3.4.11 Security Awareness All users of the organisations ICT systems should be educated about the risks from malware and the impact to the business if they do not comply with the organisations malware policies. They should receive appropriate training so that they operate the ICT system(s) securely and have an awareness of the impact of a successful malware attack. They should also understand the consequence of misusing services and systems and fully understand the incident management procedures. The security training and awareness should include: informing personnel about the policies and procedures relating to malware protection (see Section 3.4.2 Policy and Procedures);

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 33 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

advice on the controls that should be followed to reduce the risk of malware infection (e.g. use of removable media, email content, social engineering attacks); and what to do in the event malware is detected or suspected (e.g. actions to be taken by the individual such as reporting the incident) (see Section 3.4.9 Malware Incident Management). Organisations should retain confirmation that users having received this training in order to support investigation and possible disciplinary action should an incident occur, such as where malware has been introduced through deliberate breach of an organisations policy. Relevant PSN Code Conditions: (EDU.1) All employees of an organisation and, where relevant, contractors and third party users shall receive commensurate awareness training and awareness updates in organisational (not central PSN) policies and procedures relevant for their job function. Training shall include elements of physical, personnel and electronic security guidance

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 34 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

3.5 PSN Compliance Requirements


A summary of the compliance requirements relevant to malware protection (as per the PSN Code Template [1]) is shown in the table below.
Cond No Subject PSN IA Condition ISO/IEC 27001 Annex A control

RIS RIS.1

Information Risk Management Information Risk Management User Education User Education

The connecting organisation shall demonstrate a risk management and standards-based approach to the assurance of their connected network. All employees of the organisation and, where relevant, contractors and third party users shall receive commensurate awareness training and awareness updates in organisational (not central PSN) policies and procedures relevant for their job function. Training shall include elements of physical, personnel and electronic security guidance. The Customer shall consider the PSN Incident Management process (See guidance notes) in developing and implementing organisational incident response processes. Information, physical and personnel Security Incidents shall be reported through commensurate internal management channels managed by the organisation's Security Officer in accordance with the organisation's incident management policy. For incidents that impact on the PSN the organisation's security officer shall report incidents to the PSN Security Manager and other entities as required such as GovCertUK. CINRAS shall be notified for incidents involving HMG approved cryptographic equipment Hardware and software shall be locked-down in accordance with the organisations lock down policy and is part of an overall risk managed approach so that functionality is limited to what is required for the provision or consumption of the PSN service. The execution of unauthorised software shall be prevented Organisations shall have in place a configuration control process which prevents unauthorised changes to the standard build of network devices and hosts Users shall use accounts with the least privilege required to perform their roles. Customers allowing active content shall be able to demonstrate that this is done as part of an overall risk managed approach. Therefore risks from allowing Active Content shall be understood and appropriate controls shall be implemented. The customer shall implement controls to ensure that executable content shall not be run without the user's active consent and within the organisation's control

A.5.1, A.7.1, A.7.2 A.8.2.2, A.11.3

EDU EDU.1

RES RES.1

Incident Response Incident Response

A.13

RES.2

Incident Response

A.13.1

RES.3

Incident Response

A.13

CON CON.1

Configuration Configuration

A.12.5.2, A10.1.2

CON.2 CON.3

Configuration Configuration

A.12.5.x, A10.1.2 A.10.1.2

CON.4 CON.5

Configuration Configuration

A.11.2.2, A.11.4.1 A.10.4

CON.6

Configuration

A.10.4

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 35 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection Cond No Subject PSN IA Condition ISO/IEC 27001 Annex A control

CHE CHE.1

Compliance Checking Compliance Checking Patch Management Patch Management

Organisations shall implement an annual programme of IT Health Checks to validate equipment not provided as part of a PSN service that interacts with PSN services. As part of the overall risk management approach taken by customers, the organisation is expected to develop and operate a patch management policy. This shall cover all software (including firmware) and infrastructure hardware used. Patches shall be applied with minimal delay and audited to ensure compliance with the organisation's policy.

A.15.2

PAT PAT.1

A.10.4

PAT.2 BOU BOU.2

Patch Management Boundary Controls/Gateways Boundary Controls/Gateways Boundary Controls/Gateways

A.10.4

BOU.3

BOU.5

Boundary Controls/Gateways

BOU.6

Boundary Controls/Gateways

When interconnecting between PSN networks/services and non PSN networks/services an assured gateway/boundary controls shall be implemented Where connecting organisational/non-PSN networks to PSN networks and services at the same impact level/security domain organisations shall consider the risks and implement effective mechanisms for passing data between the boundaries of those domains All data traversing to and from non-PSN services/networks to PSN services/networks shall be subject to content analysis including virus checking emails and attachments at the gateway and host Organisations shall filter against a white list of allowed attachment file types. The white list will be owned and managed by the customer and be included as part of the organisation's overall risk management approach. As part of an overall risk management approach, customers shall have a policy for removable media that addresses the risks of using removable media. Firewall and Gateway Servers shall carry out security services to identify malware and vulnerability exploiting code at the gateway. Where encryption prevents this the organisation shall implement an equivalent level of protection at the end point The organisation shall identify and isolate malicious software (at least viruses, macros, dangerous file types, mobile code and spyware) Any data introduced through removable media shall be subject to content analysis and Anti-Virus scanning, ideally via a standalone virus checker before being introduced to the PSN environment.

A.10.8.5, A.11.4.5 A.6.2.1, A.10.8.5

A.10.4.1, A10.10.2

A.10.4.1

MED MED.1

Removable Media Removable Media

A.10.7

MAL MAL.1

Malware Protection Malware Protection

A.10.4

MAL.2

Malware Protection

A.10.4

MAL.3

Malware Protection

A.10.4

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 36 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection Cond No Subject PSN IA Condition ISO/IEC 27001 Annex A control

MOB MOB.1

Mobile / Home Working Mobile / Home Working

MOB.2

Mobile / Home Working Mobile / Home Working Protective Monitoring Protective Monitoring

MOB.5

Any mobile/remote and/or home working solution that accesses PSN services/networks shall be operated in accordance with the organisation's remote/mobile working policy that identifies and mitigates the risks of using mobile/remote access solutions. This policy shall include the adoption of electronic, personnel and physical security measures. The organisation must be able to show appropriate control and management of the technical environment of any device that has access to PSN services/networks Remote / mobile devices shall employ encryption to protect data at rest and in transit. The cryptography used shall have a suitable level of assurance.

A.11.7

A.11.7

A.13.2

PRO PRO.1

Organisations shall apply protective monitoring controls commensurate to their environment and data processing requirements. Good practice guidance can be located in GPG13.

A.10.10

Table 1: Compliance Requirements (Relevant PSN IA Conditions for Malware Protection)

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 37 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

3.6 Recommended Service Provider Requirements


It is critical that an ICT service provider delivering into the public sector (the Service Provider) supports the PSN compliance requirements of their client organisation (the Customer) as per the conditions identified in Section 3.5 above. Recommended requirements to be imposed on all Service Providers (e.g. through reference to this document in service level agreements or contract schedules) are shown in the table below. These may need to be amended, depending on the context of the ICT service(s) in scope of the contract.
Ref 1. Requirement Where ISO/IEC 27001-certified ICT services are delivered to a Customer, the Service Provider shall ensure that malware protection is included within the scope of the Service Providers related Information Security Management System (ISMS). The Service Provider shall document and agree with the Customer a malware policy for the ICT service to the Customer. Additional guidance Malware protection should be in scope of the ISO/IEC 27001 certification to ensure that the relevant controls are monitored for continued effectiveness and compliance.

2.

This policy should include aspects such as: identification of software updates/patches and the timescale for their assessment and deployment into live operation; malware incident management and recovery; vulnerability assessment / malware policy compliance testing.

3.

The Service Provider shall use all reasonable endeavours to prevent malware from being introduced into the Customers ICT environment via the ICT service to them.

This should encompass all points of entry and exit into the ICT service to the Customer (e.g. email, removable storage media, connected ICT infrastructure, physical access, software patches/releases, web site). This should be an enduring obligation throughout the term of the contract and in accordance with its defined exit strategy. All AV software should be kept fully up to date, as a default, within 48 hours of release of an update by a vendor. However, as with all software updates/patches, AV updates should also be properly tested before being deployed into a live environment. The AV software should typically: Be procured from reputable vendors with proven track records; Be capable of receiving regular updates to protect systems against new malware attacks; Be configurable to meet the needs of the organisation; Be capable of being managed centrally and as an independent implementation; Be capable of accepting online and manual updates; Have the capability to detect all types of known malware as well as blended attacks; Be capable of detecting suspicious behaviour through heuristic capabilities;

4.

The Service Provider shall use the latest tested versions of anti-virus (AV) definitions available from an industry accepted AV software vendor to check for and delete (or otherwise quarantine) malware from the ICT service to the Customer. (All references to anti-virus shall mean to software or other data intended to detect, prevent and/or mitigate the effects of malware/malicious code).

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 38 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection Ref Requirement Additional guidance Be capable of conducting scheduled AV scans; on access and

Be capable of detecting malware on inbound and outbound connections; Be capable of quarantining suspected or infected objects; Be capable of removing infections; Include host firewall and IDS capabilities that are configurable to allow or deny inbound and outbound connections to and from applications and services. Be configured to provide an auditable log of actions and events (based on a common time source). 5. The Service Provider shall configure its ICT service to the Customer to prevent the execution of unauthorised applications or unsigned executable code from systems used to deliver or support services to them. The Service Provider shall document and agree with the Customer a hardened build / lockdown policy/standard for all ICT components in scope of their ICT service to the Customer. It is intended to reduce the risk of malware infection through the introduction of unauthorised executable code.

6.

This policy should ensure that: Only those software components that are going to be used are installed; All unused services/functions are disabled; The ICT component is configured to minimise known vulnerabilities. Effective implementation of this policy should help to reduce technical vulnerabilities and the potential for malware infection.

7.

The Service Provider shall inform the Customer of any ICT service to them that cannot be protected from malware using AV software or agreed equivalent alternative security controls. If malware is found the Service Provider and the Customer shall cooperate with each other and with any affected other organisations to reduce the effect of the malware and, particularly if malware causes loss of operational efficiency or loss or corruption of the Customers information, assist each other to mitigate any losses and to restore the ICT service to the Customer to its desired operating efficiency. Any cost arising out of the actions of the Service Provider and the Customer taken in compliance with the provisions of Item 8 above shall be borne as follows: by the Service Provider where the malware originates from the ICT service and/or the Customers information (whilst the Customers information was under the control of the Service Provider) unless the Contractor can

Both the Service Provider and the Customer need to understand where there are any potential vulnerability in its malware protection so that they can mitigate those risks accordingly within their areas of responsibility. All affected parties should work together to minimise the impact of a malware incident and restore ICT services to normal operations.

8.

9.

Responsibility for any remedial costs will depend on the original source of the malware infection when entering the Customer/Service Providers ICT environments.

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 39 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection Ref Requirement demonstrate that such malware was present and not quarantined or otherwise identified by the Customer when provided to the Service Provider; and by the Customer if the malware originates from the Customers information (whilst that information was under the control of the Customer). 10. The Service Provider shall notify the Customer immediately upon becoming aware of any actual or suspected breach of security involving the Customers information. Upon becoming aware of any actual or suspected breach of security involving the Customers information, the Service Provider shall immediately: notify the Customer of the incident; take all reasonable steps necessary to: o remedy such security breach; and o prevent an equivalent breach in the future. 11. The Service Provider shall ensure that all of its personnel involved in delivering its ICT service to the Customer have received appropriate security awareness briefings and related security training. All Service Provider personnel should be educated about the risks from malware and the impact to the business (and the Customer) if they do not comply with the malware policy. They should receive appropriate training so that they operate the ICT service securely and have an awareness of the impact of a successful malware attack. They should also understand the consequence of misusing services and systems and fully understand the incident management procedures. There should be a clear rationale for paying for any additional software where it is already available within currently funded software provision. A potential example of this where an additional software package is specified for malware protection even though comparable functionality is already provided within the current operating system. This includes actual or suspected security incidents caused by malware. Additional guidance

12.

The Service Provider shall formally justify where new security functionality is used to replace current security functionality in an ICT service delivered to a Customer, particularly where it adds complexity or cost.

Table 2: Recommended Service Provider Requirements for Malware Protection

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 40 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

Annex A: References and Further Information Sources


The following references are used in this document: [1] [2] [3] [4] [5] [6] [7] [8] [9] PSN Code Template for Code of Interconnection, Code of Practice, Code of Connection HMG Security Policy Framework Government ICT Strategy PSN Document Management and Change Control PSN Compliance PSN Security Model PSN Common Standard for Patch Management HMG Information Assurance Standards No. 1 and 2 (IAS1&2), Information Risk Management CESG Busy Reader Guide (BRG), Protection from Malicious Code

[10] CESG Good Practice Guide No. 7 (GPG7), Protection from Malicious Code [11] CESG Good Practice Guide No. 13 (GPG13), Protective Monitoring [12] CESG Good Practice Guide No. 24 (GPG24), Incident Management [13] CESG Government Assurance Pack (GAP) Frequently Asked Questions (FAQ) [14] Phishing And Pharming: A Guide to Understanding and Managing the Risks, CPNI [15] Development and Implementation of Secure Web Applications, CPNI [16] IT Infrastructure Library (ITIL) V3.0 (see also www.itil-officialsite.com) [17] NIST Special Publication (SP) 800-83, Guide to Malware Incident Prevention and Handling [18] SANS Twenty Critical Security Controls for Effective Cyber Defense [19] TM Forum CyberOps Metrics GB965 Quick Start Guide: Patch Management [20] GovCertUK Top 10 Mitigation Steps [21] ISO/IEC 27001, Information Security Management Systems Requirements [22] ISO/IEC 27034, Application Security [23] ISO/IEC 27035, Information Security Incident Management In addition to the above references, the following web sites are also sources of useful information: CESG, the National Technical Authority for Information Assurance (www.cesg.gov.uk) Centre for Internet Security (www.cisecurity.org) Centre for the Protection of the National Infrastructure (CPNI) (www.cpni.gov.uk), in particular, CPNIs 20 Critical Controls for Effective Cyber Defence (www.cpni.gov.uk/advice/cyber/Critical-controls) and its Warning, Advice and Response Point (WARP) guidance (www.warp.gov.uk) CERT secure coding standards (www.securecoding.cert.org)
Author: PSN Cyber Team Malware Protection Std v1-0 Page 41 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

GovCertUK (www.govcertuk.gov.uk) Common Vulnerabilities and Exposures (CVE) (cve.mitre.org) Open Web Application Security Project (OWASP) (www.owasp.org) Public Services Network (www.cabinetoffice.gov.uk/content/public-services-network) SANS Institute (www.sans.org), in particular, SANSs 20 Critical Security Controls for Effective Cyber Security Defense [18] (www.sans.org/critical-security-controls) and related security configuration guidance Software Assurance Forum for Excellence in Code (SAFECode) (www.safecode.org) Standard of Good Practice for Information Security (SoGP) provided by the Information Security Forum (ISF) (www.securityforum.org) US National Institute of Standards and Technology (NIST) Computer Security Resource Centre (CSRC) (csrc.nist.gov) US National Security Agency (NSA) (www.nsa.gov), in particular their security configuration guides (www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/index.shtml) Virus Bulletin (www.virusbtn.com), including their Reactive and Proactive (RAP) comparison tests of AV products (www.virusbtn.com/vb100/index).

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 42 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

Annex B: Glossary and Abbreviations


APT AV BCS BRG CERT CESG CM CNI CPNI CSIRT CSOC CSRC CSS CVE DN DoS EUD GAP GCN GPG HIDS HIPS IA IAS ICT IDS IGSoC IL IOG ISF ISMS ISO ITIL MHRA Advanced Persistent Threat Anti-Virus Baseline Countermeasure Set (from IAS1&2) Busy Reader Guide Computer Emergency Response Team The National Technical Authority for Information Assurance Configuration Management Critical National Infrastructure Centre for the Protection of National Infrastructure Computer Security Incident Response Team Cyber Security Operations Centre Computer Security Resource Centre UK Cyber Security Strategy Common Vulnerabilities and Exposures Draft Note Denial of Service End User Device Government Assurance Pack Government Conveyance Network Good Practice Guide Host-based Intrusion Detection System Host-based Intrusion-Prevention System Information Assurance Information Assurance Standard Information and Communications Technology Intrusion Detection System Information Governance Statement of Compliance Impact Level Interoperability Gateway Information Security Forum Information Security Management System International Standards Organisation IT Infrastructure Library Medicines and Healthcare Products Regulatory Agency

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 43 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

MOD NAC NHS NIDS NIPS NIST NSA NVD OWASP PM&SA PSN PSNA RAS SOC SoGP SF SP WARP

Ministry of Defence Network Access Control National Health Service Network-based Intrusion Detection System Network-based Intrusion-Prevention System National Institute of Standards and Technology US National Security Agency (NSA) (US Governments) National Vulnerability Database Open Web Application Security Project Protective Monitoring and Situation Awareness Public Services Network PSN Authority Remote Access Services Security Operations Centre Standard of Good Practice for Information Security Security Forum Special Publication Warning, Advice and Response Point

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 44 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

Annex C: Standards Maintenance


C.1 Providing Feedback
Any feedback on this document should be provided by email to the PSN Authority (PSNA) at: psna@cabinet-office.gsi.gov.uk

C.2 Change Control


This standard will be owned and maintained by the PSNA. The sponsor for this document is the PSN Security Forum (PSN-SF). Changes to this standard will be performed in accordance with the PSN Document Management and Change Control document [4]; this process is summarised in Figure 8 below.

Figure 8: PSN Document Management and Change Control Process

Any resultant changes/additions to other documentation (e.g. the PSN Code Template [1]) will be taken into account as part of the review/maintenance cycle for this document.

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 45 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

Annex D: Key Principles for Patching and Malware Protection


Organisations should consider the following ten key principles for patching and malware protection. These principles form the basis for much of the advice in this document. They are based on GovCertUKs Top 10 Mitigation Steps [20]. Organisations may also wish to read the SANS Institutes 20 Critical Security Controls for Effective Cyber Security Defense [18] (www.sans.org/criticalsecurity-controls) for guidance on good practice in other areas of information security and assurance. 1. Patch and update A vast majority of threats exploit vulnerabilities where there is a patch or work-around. To mitigate against this there should be regular monitoring for vulnerability alerts and systematic and regular patching of all aspects of the ICT system, including client operating system, infrastructure firmware and bespoke software applications. Organisations should have a rollback plan when deploying a patch in case it fails. 2. Restrict Administrator Privileges User access to systems, services and applications should be on a least privilege basis. An attacker potentially receives the same access to a system as the account that has been compromised. Therefore, 'admin access' should be used for short-term administrative actions by a select group of individuals and not for day-to-day use by general staff. The select group of individuals with admin accounts should have a normal day-to-day account as well, using the admin account only when required. 3. Malware Protection Anti-malware technology (e.g. an AV/anti-spyware product) is only effective if regularly updated. To ensure a wider coverage of threats, organisations should run a range of products from different vendors throughout their ICT environment, e.g. run a product from vendor 1 on the email servers and product from vendor 2 on the desktop. 4. System lockdown of unnecessary features/applications Systems and their applications should be configured and hardened to protect against attacks. If the functionality is not needed, then either remove it or, at least, disable it. Unused additional features provide unnecessary sources of vulnerabilities to be exploited. Locking down or removing the features helps reduce the overall likelihood that a system could be compromised. 5. Removable Media Control Removable media should be controlled. Not only will Removable Media Control prevent accidental or unauthorised data export, but removable media is becoming one of the more prevalent ways for malware to spread. 6. Application Whitelisting Organisations should whitelist their applications, i.e. only allow access to authorised applications. Only allowing software to run that has been pre-approved greatly reduces the amount of malicious activity that can be conducted.

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 46 of 47

UNCLASSIFIED

UNCLASSIFIED
Common Standard for Malware Protection

7. Audit and Logging Organisations should have protective monitoring in place. A centralised security event management system provides both assistance to an investigation in the event of a compromise, but also the ability to analyse trends and the threat specific to your organisation. 8. Intrusion Detection System (IDS) Organisations should have an IDS in place. An IDS allows an organisation to detect known threats (through signatures) and anomalies (through heuristics) as they attempt to enter and exit its network. Prompt reaction to the detection of these threats can minimise the disruptive influence they may have. 9. Blacklisting (at boundary devices) Organisations should have blacklisting in place at the boundary to their ICT infrastructure, i.e. deny access to traffic from specified network addresses/protocols or particular services. A more active approach than an IDS is to configure firewalls with a set of identifiers, which are blocked from even entering or leaving the network. 10. User Education Organisations should have user security awareness and training in place. Ultimately there is no one piece of technology that can save a network or data, but with good user awareness, social engineering techniques that malware frequently exploits, are less successful and malicious or suspicious activity can be detected long before any technology would on its own.

Author: PSN Cyber Team

Malware Protection Std v1-0 Page 47 of 47

UNCLASSIFIED