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
7/27/2019 Malware Protection Std v1-0 0
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)
7/27/2019 Malware Protection Std v1-0 0
3/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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
7/27/2019 Malware Protection Std v1-0 0
4/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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.
7/27/2019 Malware Protection Std v1-0 0
5/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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.
7/27/2019 Malware Protection Std v1-0 0
6/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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/27/2019 Malware Protection Std v1-0 0
7/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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
7/27/2019 Malware Protection Std v1-0 0
8/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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].
7/27/2019 Malware Protection Std v1-0 0
9/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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;
7/27/2019 Malware Protection Std v1-0 0
10/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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.pdf7/27/2019 Malware Protection Std v1-0 0
11/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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
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*
*
*
*
*
7/27/2019 Malware Protection Std v1-0 0
12/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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
7/27/2019 Malware Protection Std v1-0 0
13/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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
7/27/2019 Malware Protection Std v1-0 0
14/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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.
7/27/2019 Malware Protection Std v1-0 0
15/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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
7/27/2019 Malware Protection Std v1-0 0
16/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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.
7/27/2019 Malware Protection Std v1-0 0
17/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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
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
7/27/2019 Malware Protection Std v1-0 0
18/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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.
7/27/2019 Malware Protection Std v1-0 0
19/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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.
Relevant PSN Code Cond it ions:
(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.
7/27/2019 Malware Protection Std v1-0 0
20/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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.
Relevant PSN Code Cond it ions:
(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 serverdevices that they provide. This should ensure that components are configured and hardened to
7/27/2019 Malware Protection Std v1-0 0
21/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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/7/27/2019 Malware Protection Std v1-0 0
22/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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.
Relevant PSN Code Cond it ions:
(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
7/27/2019 Malware Protection Std v1-0 0
23/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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/index7/27/2019 Malware Protection Std v1-0 0
24/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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.
Relevant PSN Code Cond it ions:
(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:
7/27/2019 Malware Protection Std v1-0 0
25/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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.
Relevant PSN Code Cond it ions:
(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 controland testing. All code should be properly tested before introduction into operational ICT
7/27/2019 Malware Protection Std v1-0 0
26/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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]
Relevant PSN Code Cond it ions:
(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 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/7/27/2019 Malware Protection Std v1-0 0
27/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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).
7/27/2019 Malware Protection Std v1-0 0
28/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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.
Relevant PSN Code Cond it ions:
(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.
7/27/2019 Malware Protection Std v1-0 0
29/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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
(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 Cond it ions:
(MAL.2) The organisation shall identify and isolate malicious software (at least viruses, macros,
dangerous file types, mobile code and spyware)
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.
Relevant PSN Code Cond it ions:
(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.
7/27/2019 Malware Protection Std v1-0 0
30/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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
7/27/2019 Malware Protection Std v1-0 0
31/47
UNCLASSIFIED
Common Standard for Malware Protection
Author: PSN Cyber Team Malware Protection Std v1-0
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).
Relevant PSN Code Cond it ions:
(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 i