Malware Protection Std v1-0 0

7/27/2019 Malware Protection Std v1-0 0

1/47

UNCLASSIFIED

UNCLASSIFIED

Technical Standard

Common Standard for

Malware ProtectionPublic 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


2/47

UNCLASSIFIED

Common Standard for Malware Protection

Author: PSN Cyber Team Malware Protection Std v1-0

Page 2 of 47

UNCLASSIFIED

Document Information

Project Name: Public Services Network (PSN)

Prepared By: Richard Keighley Document Version No: 1.0

Title: PSN SOC Delivery Lead Document Version Date: 06/12/12

Reviewed By: Design Authority Review Date: 06/12/12

Version History

Approvals

Crown Copyright 2012

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

Ver. No. Ver. Date Revised By Description Filename

0.1 03/08/2012 Richard Keighley First draft for internal review. PSN P&MP Std v0-1.doc

0.2 10/08/2012 Richard Keighley Revised following PSN comments. PSN P&MP Std v0-2.doc

0.3 17/08/2012 Richard Keighley Revised following further PSN comments and amended to

latest PSN document format.

PSN P&MP Std v0-3.doc

0.4 21/08/2012 Richard Keighley Revised following CESG feedback. PSN P&MP Std v0-4.doc

0.5 19/09/2012 Richard Keighley Revised following PSN-SF review. Patching and malware

protection split into two separate standards.

Malware Protection Std v0-

5.doc

0.6 10/08/2012 Richard Keighley Revised following additional PSN-SF review. Approved by

PSN-SF.

Malware Protection Std v0-

6.doc

0.7 14/11/2012 Richard Keighley Revised following wider PSN review. Malware Protection Std v0-

7.doc

1.0 06/12/2012 Richard Keighley Approved by the Design Authority, unchanged from v0.7 Malware Protection Std v1-

0.doc

Position

PSN Programme Director Craig Eblett

PSNA Operations Director John Stubley

PSN Design Authority John Stubley (Chair)


3/47

UNCLASSIFIED



Page 3 of 47

UNCLASSIFIED

Table of Contents

1 Introduction ................................................................................................................................. 4

1.1 Purpose and Scope ........................................................................................................... 4

1.2 Document Structure ........................................................................................................... 41.3 Disclaimer .......................................................................................................................... 5

2 PSN Context ............................................................................................................................... 6

2.1 Overview ........................................................................................................................... 6

2.2 Compliance Management .................................................................................................. 6

3 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


4/47

UNCLASSIFIED



Page 4 of 47

UNCLASSIFIED

1 Introduction

1.1 Purpose and Scope

This document identifies the baseline common requirements and provides related good practiceguidance 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 publicsector 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 befollowed 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.


5/47

UNCLASSIFIED



Page 5 of 47

UNCLASSIFIED

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.


6/47

UNCLASSIFIED



Page 6 of 47

UNCLASSIFIED

2 PSN Context

2.1 Overview

In the Public Services Network (PSN) vision, there will be a single logical network of networks, witheach 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 createefficiencies 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 hencethe 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).

Figure 1: PSN Compliance Context

Other organisational security

requirements (e.g. MOD, NHS)

HMG SPF

Requirements (incl. BCS)Consumer/

Service Provider

ICT system/

service

Complies with

Central Government

Community (typicallyIL3 and above)

PSN Codes


7/47

UNCLASSIFIED



Page 7 of 47

UNCLASSIFIED

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.

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

COMPLIANCE

ASSESSMENT

PSN

Consumers /

Service

Providers

PSN Code

Template

PSN Technical

Standards

REQUIREMENTSDEFINITION,

CONTEXT,

SUPPORTING

GUIDANCE &

EXPLANATION


8/47

UNCLASSIFIED



Page 8 of 47

UNCLASSIFIED

3 Malware Protection

3.1 Introduction

This section defines the common standard and related good practice guidance for malwareprotection 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 propagatefurther 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].


9/47

UNCLASSIFIED



Page 9 of 47

UNCLASSIFIED

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, persistentattackers (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 informationintegrity;

use malware to deny the services provided by the ICT system to authorised users, for

example by:

o Flooding the network with network traffic (e.g. bandwidth exhaustion), thereby

restricting access to legitimate users;

o Disrupting a service by making multiple requests thereby denying access to legitimate

users;

o Disrupting configuration information, e.g. routing information to a service or network;


10/47

UNCLASSIFIED



Page 10 of 47

UNCLASSIFIED

o Causing an application on a web server to fail or become unstable;

o 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 byredirecting 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.
http://www.cpni.gov.uk/Documents/Publications/2010/2010019-Phishing_pharming_guide.pdfhttp://www.cpni.gov.uk/Documents/Publications/2010/2010019-Phishing_pharming_guide.pdfhttp://www.cpni.gov.uk/Documents/Publications/2010/2010019-Phishing_pharming_guide.pdf


11/47

UNCLASSIFIED



Page 11 of 47

UNCLASSIFIED

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].

Figure 3: Potential malware delivery mechanisms and vulnerabilities

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);

Removable

Media

Connection of

Equipment /

End User

Devices

Systems and Applications

Email

Web

Other business

communications

channels

Patching and

Release

Management

File formats& types

AccessControl

Applicationdevelopment

Configuration

Attachments

Phishing /

Social

Engineering

Maliciou s web

site

Web site

attacks

Collaboration

toolsIM / Social

media

Streamed

media

RSS feeds

Physical access

*

*

*

*

****

**

**

Potential malware

delivery mechanisms*

*

*

*

*


12/47

UNCLASSIFIED



Page 12 of 47

UNCLASSIFIED

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 embeddedinto 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.

3.3.3 Physical Access

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 walledgarden 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 andfolder creation, updates and changes to registry settings and backup and remove temporary files


13/47

UNCLASSIFIED



Page 13 of 47

UNCLASSIFIED

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


14/47

UNCLASSIFIED



Page 14 of 47

UNCLASSIFIED

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

mail 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.


15/47

UNCLASSIFIED



Page 15 of 47

UNCLASSIFIED

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 importantto 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.

Systems and Applications

File formats& types

Access

Control

Application

development

Configuration


16/47

UNCLASSIFIED



Page 16 of 47

UNCLASSIFIED

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 introductionor 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 supportingfeatures. 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.


17/47

UNCLASSIFIED



Page 17 of 47

UNCLASSIFIED

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.

Figure 5: Malware Protection

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.

Potential Security Controls

Governance

Compliance Requirements

Policy /

procedure(s)

PSN Conditions

Security

awareness

Patching &

vulnerability

management

Malware

Incident

management

Removable

MediaNetwork

Protection

Connections

Gateways

Email

Web

Other

Systems, EUDs

& Applications

Quarantine

Systems

Supplier

management

Physical

Protection

Mobile Code

Sheep Dip

systems

Sandboxes

Access control

AV products

Configuration

lockdown

Secure

development


18/47

UNCLASSIFIED



Page 18 of 47

UNCLASSIFIED

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 active content / mobile code;

o macros;

o personal end user devices (including smartphones and PDAs);

o 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 Cond it ions:

(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 theselection 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.


19/47

UNCLASSIFIED



Page 19 of 47

UNCLASSIFIED

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.1Sheep Dip System), before

being introduced into an organisations ICT environment.


(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 Anti-

Virus scanning, ideally via a standalone virus checker before being introduced to the PSN

environment.


20/47

UNCLASSIFIED



Page 20 of 47

UNCLASSIFIED

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

3.4.5.1 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.



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 serverdevices that they provide. This should ensure that components are configured and hardened to


21/47

UNCLASSIFIED



Page 21 of 47

UNCLASSIFIED

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 Xsuppliers/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 atwww.cpni.gov.uk.

US National Security Agencys (NSAs) security configuration guides (see

http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/index.shtml).

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 atwww.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 atcsrc.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 atwww.sans.orgor can be found at

www.cpni.gov.uk/advice/cyber/Critical-controls/.

The following additional controls should also be considered for systems and EUDs:
http://www.cpni.gov.uk/http://www.cpni.gov.uk/http://www.cpni.gov.uk/http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/index.shtmlhttp://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/index.shtmlhttp://www.cisecurity.org/http://www.cisecurity.org/http://www.securityforum.org/http://www.securityforum.org/http://www.securityforum.org/http://csrc.nist.gov/http://csrc.nist.gov/http://csrc.nist.gov/http://www.sans.org/http://www.sans.org/http://www.sans.org/http://www.cpni.gov.uk/advice/cyber/Critical-controls/http://www.cpni.gov.uk/advice/cyber/Critical-controls/http://www.cpni.gov.uk/advice/cyber/Critical-controls/http://www.sans.org/http://csrc.nist.gov/http://www.securityforum.org/http://www.cisecurity.org/http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/index.shtmlhttp://www.cpni.gov.uk/


22/47

UNCLASSIFIED



Page 22 of 47

UNCLASSIFIED

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.

o 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 definewhat 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 thathas access to PSN services/networks.


(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


23/47

UNCLASSIFIED



Page 23 of 47

UNCLASSIFIED

(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 (seehttp://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. Theiruse 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;
http://www.virusbtn.com/vb100/indexhttp://www.virusbtn.com/vb100/indexhttp://www.virusbtn.com/vb100/indexhttp://www.virusbtn.com/vb100/index


24/47

UNCLASSIFIED



Page 24 of 47

UNCLASSIFIED

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.



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:


25/47

UNCLASSIFIED



Page 25 of 47

UNCLASSIFIED

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.




(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 controland testing. All code should be properly tested before introduction into operational ICT


26/47

UNCLASSIFIED



Page 26 of 47

UNCLASSIFIED

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]




3.4.6 Network Protection

3.4.6.1 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 specificbusiness 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
http://www.owasp.org/http://www.owasp.org/http://www.owasp.org/http://www.securecoding.cert.org/http://www.securecoding.cert.org/http://www.securecoding.cert.org/http://www.securecoding.cert.org/http://www.owasp.org/


27/47

UNCLASSIFIED



Page 27 of 47

UNCLASSIFIED

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

patched 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).


28/47

UNCLASSIFIED



Page 28 of 47

UNCLASSIFIED

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 whenthey 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.


(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.


29/47

UNCLASSIFIED



Page 29 of 47

UNCLASSIFIED

(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 shallimplement an equivalent level of protection at the end point



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.




3.4.7 Quarantine Systems

3.4.7.1 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.


(MAL.3) 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 PSNenvironment.


30/47

UNCLASSIFIED



Page 30 of 47

UNCLASSIFIED

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 sacrificialcomputer 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.

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 shouldconsider 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:

Asset

Inventory

Patch /

Vulnerability

Identification

Assessment Deployment

Change management / release management processes


31/47

UNCLASSIFIED



Page 31 of 47

UNCLASSIFIED

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 currentthreats 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).




(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 i