Scottish public sector cyber resilience framework v2.0

Section 2 – How to use the Framework

Continuous improvement cycle

16. The framework is designed to assist organisations as part of a wider continuous improvement process.

17. Each PSO will have specific individual functions and services, and the controls within the public sector cyber resilience framework (PSCRF) will need to be interpreted in this organisational context. However, this section presents aspects of general guidance that can be applied to any PSO.

Scope

18. Whole organisation: the PSCRF controls apply across the whole organisation and, as indicated by the duty areas, are not just the responsibility of the technical teams or it department.

Individual services: specific services delivered by a PSO may be individually accredited to specific standards. If this is the case, then these accreditations can be recorded in the response to sub-category “1.4 regulatory compliance”. The associated compliance documentation or certificate would provide evidence to any subsequent audit.

Bring your own device (BYOD): if personal devices are permitted and used to access the corporate network, information, data or services; these are in-scope of the PSCRF and any subsequent audit.

Supply chain: the controls detailed across category “3 supplier management” apply to all suppliers involved in the delivery of key or critical digital services upon which the organisation relies on to function. This extends to any services delivered by another PSO, which should be treated as a supplier. When arrangements between PSOs are described as partnerships or shared services, the primary criterion for determining the supplier is payment. Do the parties jointly pay a third-party supplier; or does PSO 1 pay PSO 2 for services? In the latter case PSO 2 should be considered as a supplier for the purposes of the PSCRF.

Definitions

19. Policy: controls in the PSCRF often refer to a “policy”; in this context a policy is a corporate document not a technical configuration (e.g. Windows 10 group policy). A screenshot of a software configuration may be used as an example of evidence of a policy being adopted; however this does not represent or replace a formal policy document for the purposes of the PSCRF.

20. Cloud-based services

These definitions are those employed by the national cyber security centre (NCSC)^[3].

• Infrastructure as a service (IaaS): the cloud provider delivers virtual servers and network equipment that, much like physical equipment, are configured and managed by the applicant. Examples of IaaS include Rackspace, Google Compute Engine, or Amazon EC2.
• Platform as a service (PaaS): the cloud provider delivers and manages the underlying infrastructure, and the applicant provides and manages the applications. Examples of PaaS include Azure web apps and Amazon Web Services Lambda.
• Software as a service (SaaS): the cloud provider delivers applications to the applicant, and the applicant configures the services. The applicant must still take time to ensure the service is configured securely. Examples of SaaS include Microsoft 365, Dropbox, and Gmail.

21. The cloud security alliance cloud controls matrix controls^[4] have been incorporated into the PSCRF sub-category “3.5 security in cloud services”. These employ three abbreviations:

• CSP: cloud service provider
• CSC: cloud service customer
• SSRM: (shared security responsibility model) which is an allocation of responsibilities for the implementation of a given control between a CSP and a CSC.

Which tier?

22. All organisations should achieve tier 1 controls as a minimum. These include the requirements for compliance with cyber essentials and the UK GDPR ICO-NCSC security outcomes.

23. The controls within tier 2 should be adopted if any of the following apply:

A) the organisation falls within the scope of the definition of an operator of essential services within the network information systems regulations

B) the organisation collects, stores or otherwise processes highly sensitive data; or has operational functions or networks that require additional security. Table 1 offers some guidance in this regard.

C) the organisation voluntarily seeks to adopt a more developed security status or posture.

24. Table 1: PSCRF tier 2 adoption criteria guidance.

Organisations should self-evaluate whether the data, functions or networks they employ require additional security in which case the additional controls of tier 2 would apply. The examples shown below are not prescriptive but are for illustrative purposes only.

25. Table 2: PSCRF summary of control numbers by domain, common category and tier.

Key performance indicators (KPIs)

26. Organisations may wish to use the status of compliance with the PSCRF controls as the basis of KPIs. Note that metrics in themselves are not KPIs (this is a common misunderstanding). Metrics are useful measures, but a KPI has a target that the organisation wishes to achieve. Such targets are helpful in defining the common question “what does success look like?”.

27. Key criteria using the PSCRF that could be adopted are:

• Overall compliance against the selected tier.
• Category compliance percentages.
• Sub-category compliance percentages.
• Number of controls within the selected tier achieved.

For example; an organisation may wish to apply a “60-60-0” KPI, which is defined as:

• A minimum overall compliance of 60%.
• Over 60% of the sub-categories have a compliance of 60% or more.
• There are no sub-categories with a compliance less than 30%.

A capability to set targets in this manner is built into the self-assessment spreadsheet.

28. PSOs should not use the overall compliance figure in isolation. This can lead to false assurance as it can obscure areas of significant risk and non-compliance. Of arguably greater significance is a status in which there are no sub-categories with a compliance less than 30% and ideally none with a status of less than 10%. This more risk-focussed approach will provide a more meaningful analysis of the cyber risk exposure of an organisation than an overall compliance figure could provide.

How to demonstrate compliance

29. Whether compliance is evaluated through self-assessment or a formal audit, it is helpful for the organisational analysis to have a consistent approach across duty areas. Staff unfamiliar with assessing compliance or preparing for an audit should adopt the “WHOS” approach as guidance:

1. What?

What is the organisation’s policy and approach to this control area? This is defined in a formal document which may, for example, be a policy, strategy, or corporate plan.

2. How?

How is this policy implemented? What procedures are adopted to fulfil the organisation’s defined approach? Methods or procedures should be defined in a formal document which could be supported by an operation to-do list or guide.

3. Show.

Policies and procedures are only effective if they are implemented. The final step is to demonstrate that the defined procedures are actively implemented, for example by configuration screenshots; software dashboards; test and vulnerability reports with prioritised actions; system logs, whichever is most appropriate to the control.

Typical policy document areas

30. The content and structure of policy documents varies according to organisational need and house style. However, development of the policies shown in table 3 would fulfil several of the PSCRF control specifications. These are specific policy subject areas; organisations may wish to combine several of these into one document for simplicity.

Acceptable use

Access control

Account management

Anti-malware, vulnerability management

Asset management (hardware)

Backup

Business continuity

Clear desk, clear screen policy

Data retention and destruction policy

Disaster recovery

Encryption / cryptography

Firewall management

Hardware asset register

Incident management & response

Information asset register

Information / data management

Information security

Media management

Password management

Patch management

Penetration test protocol

Physical security

Remote working

Risk appetite

Risk management

Risk register

Secure build (hardware)

Software asset register

Software development

Software management

Supplier management