What is security policy?
- high-level statement of beliefs, goals, & objectives &, general means for attainment for protection
- set at a high level, what is desired to be achieved, and does not specify “how” to accomplish the objectives
Why is security policy needed?
- to ensure money is spent in an appropriate manner to deliver expected outcomes
- infrastructure increasingly connected & accessible, hence more prone to manipulation & destruction
- crucial decisions and defensive action must be prompt and precise
- a security policy establishes what must be done to protect infrastructure
Secure by design principles (10)
minimise attack surface establish secure defaults Principle of least privilege - only allow minimum access necessary Principle of defence in depth - multiple controls that approach risk are preferable Fail securely Don't trust services Separation of duties Avoid security by obscurity keep security simple Fix security issues correctly
Blackett review recommendations
• Improving awareness
Recommendation 1 Operators of CNI should review their reliance on GNSS, whether
direct or through other GNSS-dependent systems, and report it to the lead
government department for their sector. The Cabinet Office should assess overall
dependence of CNI on GNSS.
- Recommendation 2 Loss or compromise of GNSS-derived PNT should be added to
the National Risk Assessment in its own right, rather than as a dimension of space
weather alone.
• Addressing vulnerabilities and threats
- Recommendation 3 The Department for Digital, Culture, Media and Sport (DCMS), with
Ofcom, should continue to address the risk of interference to GNSS-dependent users,
including CNI, in allocation of radio spectrum to new services and applications
- Recommendation 4 DCMS should review, with Ofcom, the legality of sale, ownership and
use of devices and software intended to cause deliberate interference to GNSS receivers
or signals – to determine whether the Wireless Telegraphy Act 2006 requires revision. - Recommendation 5 CNI operators should assess – with guidance from the National Cyber
Security Centre (NCSC) and the Centre for the Protection of National Infrastructure
(CPNI) – whether they need to monitor interference of GNSS at key sites such as ports.
Where operators do monitor, data should be shared with the relevant lead government
department.
• Improving resilience
- Recommendation 7 The existing cross-government working group on PNT should be put on a
formal footing to monitor and identify ways to improve national resilience. It should report to the
Cabinet Office, which can coordinate necessary actions among departments.
- Recommendation 8a Procurers of GNSS equipment and services for CNI applications – with
guidance from the relevant lead government department and organisations such as NCSC and
CPNI – should specify consistent requirements encompassing GNSS and PNT system issues of
accuracy, integrity, availability and continuity, as well as requirements specific to the immediate
equipment, system and application. - Recommendation 8b Government should ensure that, for GNSS and PNT equipment, a
coordinated approach is taken to performance standards, terminology, validation criteria,
independent testing and evaluation procedures, and the accreditation of test facilities. It should
work with industry, trade associations, accreditation bodies and organisations that develop and
set standards. - Recommendation 8c Government should adopt a facilitating role to ensure that legislation and
regulations relevant to PNT and GNSS are appropriate and proportionate, and that due
consideration is given to the needs of different sectors. - Recommendation 9 The Department for Business, Energy and Industrial Strategy, in
partnership with Innovate UK & the cross-government working group on PNT, should map PNT
testing facilities & explore how industry and critical services can better access them.
Preparing for the future
- Recommendation 10 Growing demand for time and geo-location create opportunities for the
UK to leverage its academic and industrial expertise in these areas. UK Research and
Innovation should invite the research community and industry to develop proposals to
achieve greater coordination among existing centres of excellence.
• Mitigating dependence on GNSS
- Recommendation 6 CNI operators should make provision – with guidance from NCSC and
CPNI – for the loss of GNSS by employing GNSS-independent back-up systems.
Principles of Security policy (6)
reflect widest security objectives
Enable the business of related entities
Risk management is key with appropriate owner
Account for statutory obligations and protections
Enable right attitudes and behaviours
Polices and processes for reporting issues/incidents
SecPol document components (9)
Development trade off (detailed vs brief)
Dependant on - size, services, tech, money (and other resources) available
Purpose
Scope
Background
Policy statement (overarching principles)
Enforcement
Responsibility
Related documents
Elements of good policy (13)
Clear, concise and realistic
defined scope and applicability
Consistent with other policy/guidance
Open to risk based change
Identifies areas of responsibility for users, admin and management
Sufficient guidance to develop procedures
Balances protection with productivity
How incidents are handled
Has an SRO
Flexible and adaptable to tech and procedural change
Involves relevant stakeholders
Doesn’t impede business on mission/goals
Provides organisation with assurance and acceptable protection from external and internal threats.
Sec by Des - attack suraface
reduce nodes available to an attacker to enter a building/system
Sec by Des - Secure defaults
Default is a secure experience with the user reducing their security if allowed
eg password aging and complexity as default
Sec by Des - Least privilge
where need to know exists - eg a CEO probably does not need to access all the HR files
Sec by Des - defence in depth
add layers of validation and control
e.g. 2 factor authentication
Sec by Des - Fail securely
ensure that systems are not set to allow failure into admin roles etc
Sec by Des - don’t trust services
Check what data is being requested and used by external parties
e.g. reward schemes
Sec by Des - Separation of duties
Fraud control approaches such as requestors cannot sign for assets, approvers cannot be requesters etc.
Sec by Des - avoid sec by obscurity
nearly always fails, using other principles to ensure the security is generated, not through obscuring code (and generally fails poorly)
Sec by Des - keep sec simple
Attack surface and simplicity go hand in hand
