The States of Jersey Security Standards exist to protect customer information from improper use. Any States project that involves the use of data needs to provide evidence that is has met the following standards.
1. Security by design
Services will be designed and built with security requirements covering confidentiality, integrity, and availability considered from the first stages of the design process. This will continue through to implementation and operational use.
Security will be designed on the basis that the service will be attacked, and will seek to minimise the chance of success.
2. Defence in depth
Layered security should be deployed such that if an attack causes one security mechanism to fail, other mechanisms should still protect the system. This should not simply introduce costly redundancy (for example, having two or more technical controls performing the same security service). Rather the defence-in-depth model should provide complimentary services that interlock and overlap.
3. Recognition that it is no longer a question of if your preventative security controls will be breached, but when
The number of successful security attacks is increasing in line with the complexity of systems and their interactions. It is no longer sensible to concentrate solely on preventative measures, or to weight the security solution toward these. Equal consideration needs to be given to minimising the impact of an attack and implementing recovery mechanisms, and to ensure these are documented and tested regularly.
4. Traceability and justifiability
All security design decisions should be clearly understood and mapped against business requirements, such that each requirement can be traced through to security controls, and each security control can be traced back to a business requirements.
5. Least privilege
Confidentiality and integrity will be protected through access controls to systems, services and information, and their deployment and maintenance enacted only by personnel with a recognised level of security.
By default, users and processes should only be allowed to access systems, services and information for which they have a business need.
6. Detection
Services will be designed to detect any security breach and report it as soon as it is identified. This will include unsuccessful attempts (such as a large number of failed login attempts, or the use of invalid certificates). Typically this would be Security Information and Event Management (SIEM) software.
7. Minimise the system elements to be trusted
Hardware, firmware, and software should be designed and implemented so that a minimum number of system elements need to be trusted in order to maintain protection. All user input from online applications should be treated as untrusted, with functions implemented on the server to validate the input. This can further be enhanced by implementing local system firewalls.
8. Reduce risk to an acceptable level
All threats should be recognised and clearly understood. Corresponding security risks should be appropriately managed using an established risk management framework such as ISO27005. This is both for the project, and for the services and solutions it delivers.
Elimination of risk is not always cost effective. Risks should be analysed to understand the material or reputational impact they will cause, and mitigating controls properly evaluated to determine their effectiveness, and any residual risk remaining.
The cost of any vulnerability being exploited should always be measured against the cost of any controls to remove or reduce it.
9. Design for availability and resilience
Services should be resistant to attack, remain available, should limit damage, and should recover rapidly when attacks do occur.
10. Compliance and standards with best practice
Services and suppliers should be certified as compliant with a recognised standard, such as:
- ISO27001
- IASME Governance Standard
- Cyber Essentials
or have undertaken an external audit or assessment, such as:
- SAE16 SOC 1,2, or 3
- ISAE 3402
or be able to demonstrate following security best practice, such as:
- RESILIA Cyber Security Best Practice
- Cloud Security Alliance Guidance
Legal, regulatory and contractual requirements must be adhered to where relevant, such as:
- PCI Data Security Standard, for payment card details
- Data Protection directives, for personal information
11. Security of data
Levels of security will be appropriate to the sensitivity of the data being protected, and of its value to the business. The classification of the Data must be registered with the SIRO for inclusion on the Information Asset Register.
Data that is personal in nature must always be kept confidential, both in transit and at rest. The cost of protecting other data should reflect the value/cost to the business of the data being compromised. Integrity of data in transit and data at rest must be guaranteed.
Where data is stored in the cloud, encryption of this data should always be considered.
Cryptographic security components (such as digital signing and encryption algorithms, certificate standards, and key lengths) must conform to those published as part of eGov standards.
12. Security of communications
All communications endpoints must be authenticated between services. Where sensitive data is transmitted, the data should be encrypted. End-to-end protection of data should be considered for sensitive and high value data.
13. Authentication
Services must establish a user's identity and credentials prior to access to that service. Multi-Factor Authentication (MFA) must be used for systems holding sensitive data. Where passwords are relied upon, the service must follow a password policy appropriate to the value of data being protected. As a minimum users must be required to authenticate with a unique username and strong password before being granted access.
14. Security domains
Separate security domains with separate privileged access accounts should be utilised to segregate data with different levels of sensitivity (e.g. to segregate public from private content). This segregation applies to both systems and personnel who have access to them.
Both internal and external threats will be considered in security architectures.
15. Security audit
Services will maintain an audit log of service interactions including details of the calling process which must be available on demand.
16. Incident management
Security Incidents will be treated with a high priority and with clearly understood processes and escalation points identified. Any known, anticipated or arising information risk or other incident impacting information security that can be seen to directly or indirectly affect the system in scope, its operation or reputation shall be promptly notified to the States of Jersey through agreed contractual channels.
Details of any Security Incidents suffered in the last three years and how they were managed should be used to evidence this.
17. Configuration management
The configuration and operation of security controls will be applied consistently, every time.
18. Security assessments
Technical security assessments, including vulnerability assessments, penetration testing, ethical hacking, social engineering attacks and physical attacks, should be performed as part of an assessment regime including after changes to infrastructure.
19. Physical Access Controls
Where the systems or components of the system are hosted externally, the supplier should be able to articulate their level of physical access control to systems in scope.
20. Training and awareness
Where the systems or components of the system are accessed from external parties the supplier should be able to demonstrate that all personnel complete an information security awareness training programme.
21. Continual improvement
Vendors must actively demonstrate that security forms an important part of their continual improvement processes. Vendors should actively review, maintain and improve the security of the service(s) they offer as part of this process.
22. Recruiting and vetting
Where a supplier is processing personal information, States of Jersey requires assurance that the integrity and reliability of the persons employed to collect, manage and process personal information can be demonstrated through a bespoke supplier specific background check regime or recognised national or industry recognised vetting structure.
23. Secure software development
Building security into software products is an essential part of the software development lifecycle. Software developed for, or deployed on States of Jersey systems must follow industry recognised secure software development best practices and the States of Jersey guidelines. Vendors must be able to demonstrate that they have a policy in place which establishes the minimum practices required in order to ensure secure code is developed and implemented on all States of Jersey Systems.
24. Malware protection
Recognised industry standard malware protection software must be installed on all in scope systems and have engine updates applied rigorously.
25. Patch management
In order to resist low-level cyber-attacks, States of Jersey mandates that all in scope systems must be able to limit vulnerability by use of patch management regime.
26. Boundary firewalls and internet gateways
Firewalls or similar devices must be installed at the boundaries of the networks in scope and be configured and managed in line with States of Jersey security standards.
27. Data residency and processing beyond the borders of the European Economic Area
In line with Jersey Data Protection Law (2005) - Principle 8, there must be no transfer, processing or storage of personal information to, or by countries outside the European Economic Area (the EU member states and Iceland, Liechtenstein and Norway). This also includes countries which do not fall into the group of countries which the European Commission consider as adequate with regard to principle 8.
28. Privileged access control
Privileged access management is an essential component of a defence in depth security strategy. In scope systems must be able to demonstrate how privileged access control is managed.
29. Client segregation
Where systems and services are used by the States of Jersey and other organisations in a shared service model, there must be a clear demonstrable separation between the States of Jersey data and other clients where shared storage and processing systems are utilised.
gov.je