Cloud security principles
The UK's National Cyber Security Centre (NCSC) publish guidance to buyers of cloud systems on what organisational, physical, logical and operational principles should be present to ensure the system can be run securely relative to the sensitivity of the data that will be processed by the system. This document is IIZUKA's response to those principles in relation to Case Manager.
Case Manager Data Flow Overview
Case Manager is a cloud based solution comprising a range of elements through which data flows. The diagram below shows a high level view of the architecture and the flow of data between those elements:
Case Manager Data Overview
Cloud Security Principle 1: Data in transit protection:
User data transiting networks should be adequately protected against tampering and eavesdropping.
Implementation Approach
• TLS (Version 1.2 or above)
• IPsec or TLS VPN gateway
Assurance Approach
A penetration test is performed against the Case Manager service at least annually by an independent CREST approved organisation. This test includes an evaluation of the TLS configuration. All physical hosting providers are certified to ISO27001 and ISAE 3402.
Cloud Security Principle 2: Asset protection and resilience:
User data, and the assets storing or processing it, should be protected against physical tampering, loss, damage or seizure.
2.1 Physical Location and legal jurisdiction
Implementation Approach
· Known locations for storage, processing and management
The service and all associated data for UK customers are stored and processed within the UK at multiple AWS data centres around London. The service and all associated data for customers in other regions is stored and processed within their local AWS region as follows:
Customer Country AWS Region Comments
Australia Australia
Canada Canada
New Zealand Australia AWS NZ is now available and migration to this region is under consideration
The service for all regions is administered remotely from the IIZUKA office located in Birmingham, UK.
The service is governed by the laws of England and Wales and contracts with all sub-processors include GDPR compliance clauses. The customer is defined as the Data Controller and retains all the rights to, and responsibility for, data uploaded to the service. Beyond that required to provide and support the service, IIZUKA and its subcontractors do not further process, aggregate or sell user data or metadata uploaded to the system except as required by law. This includes a restriction on using the data to train third-party AI models.
Some subcontractors may have parent companies or subsidiaries in other countries and in rare cases may be compelled by the laws of those countries to release data stored by the system to local law enforcement, normally in support of international organised crime, national security, and terrorism investigations. AWS state
if we receive a law enforcement request, we will challenge law enforcement requests for customer data from governmental bodies where the requests conflict with law, are overbroad, or where we otherwise have appropriate grounds to do so. We also provide a bi-annual Information Request Report describing the types and number of information requests AWS receives from law enforcement.
2.2 Data Centre Security
Implementation Approach
• Conforms to a recognised standard (ISAE 3402)
All AWS data centres feature comprehensive physical and environmental controls and are certified to ISAE 3402. These controls are audited at least annually. A full description of the controls can be found at https://aws.amazon.com/compliance/data-center/controls/
2.3 Data Encryption
Implementation Approach
• Physical access control
• Encryption of physical media
• Infeasibility of finding a specific customer’s data on physical devices
All database and server storage devices are physically protected from unauthorised access with robust access controls attested to by ISAE 3402 SOC2 reports. Furthermore, all customer data is protected at rest using AES-256 encryption. The dedicated encryption keys are stored in the AWS Key Management Service using hardware modules certified to FIPS 140-2 level 3 and cannot be extracted or moved off-site, even by AWS staff.
Binary file uploads to the service are individually encrypted using AES and the keys stored within each customer's system ensuring isolation and preventing leakage between tenants.
In the rare cases where physical media is required e.g. importing a large amount of existing data into a system, the storage devices will be encrypted and controlled according to our ISO 27001 procedures or as agreed with the customer. The data will be retained for no longer than is needed for the purposes of data import and subsequently any devices used will either be returned to the customer, securely wiped by full re-encryption, or physically destroyed as required.
2.4 Data sanitisation and equipment disposal
Implementation Approach
• Explicit overwriting of storage before reallocation
• Destruction of encryption keys
• Physical destruction of media
• A recognised standard for equipment disposal is followed (ISO27001)
• A third party destruction service is used
Our hosting provider, AWS, asserts that all storage volumes are wiped before any reuse and all persistent storage devices are physically destroyed at end-of-life. As an additional protection, all data is encrypted by an IIZUKA-specific key that is not shared with any other party. Any customer-specific data encryption keys are destroyed once they are no longer required.
Any portable storage device used by IIZUKA in the process of onboarding or off-boarding data will have been encrypted using a unique key. If the device is not physically destroyed (through a suitably certified third party onsite destruction service) or returned to the customer as part of the process, then when it is no longer required the key will destroyed and the device immediately reformatted and re-encrypted with a random key prior to reuse.
At contract termination, the customer will be given 30 days to download a copy of their data (if not already exported by a bespoke offboarding agreement), which will be supplied in a commonly used digital format, for archiving or importing into a replacement system. Once downloaded, or after the 30 day period has expired, IIZUKA will destroy all customer data within 60 days using one or more of the techniques described above. This time period allows for customer data that may be contained within shared backups to be rotated or otherwise expunged from any managed service used by the application.
2.5 Physical resilience and availability
• SLA
Case Manager offers a 99.5% availability SLA, a 1 hour recovery point objective and a 4 hour recovery time objective i.e. in the case of an adverse event affecting application availability or data integrity, the system will lose no more than 1 hour worth of data from immediately prior to the event and will be restored to operation within 4 hours of the event occurring.
The following describes the measures currently taken to satisfy these requirements. IIZUKA reserves the right to modify these measures as it sees fit, without the need to consult with customers, providing the updated measures support the above objectives.
• Geo-redundancy: At least 2 copies of all persistent customer data will be retained in geographically separate data centres within the same hosting region.
• Independent backups: The primary data stores are continually backed up and can be restored to any point in the period from the last 30 days to within a minimum of 1 hour of the event. Backups are retained for 30 days and have a governance policy applied that ensures they cannot be deleted, even by administrative staff. Test restorations are performed monthly to ensure our RTO targets can be met.
• High Availability server configuration: The system is able to survive the failure of a single component without adversely affecting the availability or integrity of the data through the use of multiple instances of that component spread across multiple geographically separate data centres.
• Self-healing resources: The system can identify degraded resources and automatically replace them without human intervention.
• Cold-standby server configuration: For system components that are unable to support high availability, a pre-configured standby server in an alternate data centre can brought online rapidly in the event of failure
• Infrastructure As Code (IaC): The entire hosting configuration is declaratively described in code which can be used to rapidly rebuild all or part of the hosting environment in the event of failure with minimal human input.
• Testing: Components of the hosting environment are routinely created/restored, configured, destroyed and tested as part of normal operation of the environment satisfying all requirements for BC/DR testing.
The main data processing takes place in 3 substantially independent logical data centres ('availability zones') geographically distributed around the London area such that an event affecting the availability or integrity of one data centre is highly unlikely to affect another, yet still being close enough to allow real-time data replication. The system can run from any and all of these availability zones and transition between them without downtime. Due to UK-only data residency requirements, the data is not replicated outside of the London region. In the unlikely event of a total outage of the London region then the system and its data will not be accessible until AWS service has been restored. If any components of the system are impaired after restoration then the backups and IaC can be invoked to rapidly repair the system.
The system has been engineered so that normal maintenance tasks and upgrades do not affect system availability. Where there are exceptions to this, wherever possible the maintenance will be scheduled outside normal working hours and customers will be provided with sufficient notice.
DDoS protection is in place (see principle 11).
Cloud Security Principle 3: Separation between users
A malicious or compromised user of the service should not be able to affect the service or data of another.
The application is hosted on the AWS public cloud and uses the hardware and software virtualisation features of that platform. This provides complete isolation at the compute, storage, and network layers ensuring no other user of that cloud can access the resources of the application. IIZUKA follow the guidance contained in the AWS Shared Responsibility Model to ensure a secure configuration.
Additionally, all persistent storage is encrypted at rest using a dedicated encryption key (see principle 2) ensuring it cannot be read by any other party.
Within the Case Manager system, each distinct tenant is assigned a unique identifier used to partition data storage and processing from other tenants. The main body of data is stored in a segregated database schema only accessible to that tenant and protected by a per-tenant database account. Binary file attachments are individually encrypted before being uploaded to an object store which is shared between tenants. The encryption keys are stored within the tenant's database ensuring that no other tenant can decode it.
Development, testing and production environments are logically segregated by using isolated processing, storage, networking, and least-privilege security roles. This ensures data cannot inadvertently transfer between environments.
The whole system is subject to an annual external independent penetration test to verify our controls and configuration.
Cloud Security Principle 4: Governance framework
The service provider should have a security governance framework which coordinates and directs its management of the service and information within it. Any technical controls deployed outside of this framework will be fundamentally undermined.
IIZUKA operates an Information Security and Quality Management System certified by an independent UKAS accredited body to ISO 27001 and ISO 9001. The scope of certification includes all activities associated with the development and operation of the Case Manager service. These standards require us to implement a system of risk-assessment, monitoring and continuous improvement to our information security and quality controls. Our certificate number is 11520 and can be verified at https://www.alcumus.com/en-gb/certification/customer-area/certificate-checker/
The Technical Director is the board-level individual responsible for ensuring ongoing compliance.
IIZUKA are also certified to Cyber Essentials Plus and the controls required to meet this standard have been implemented within our ISO 27001 policies. Our certificates can be reviewed by searching for 'iizuka' at https://iasme.co.uk/cyber-essentials/ncsc-certificate-search/
Cloud Security Principle 5: Operational security
The service needs to be operated and managed securely in order to impede, detect or prevent attacks. Good operational security should not require complex, bureaucratic, time consuming or expensive processes.
Vulnerability Management
Policies and procedures are in place to ensure timely detection and remediation of vulnerabilities in both first-party and third-party components. Industry news, blogs, threat intelligence and related resources are used to ensure the controls applied to the system remain relevant and fit-for-purpose.
Vendor and independent vulnerability announcement lists are actively monitored. All available critical OS and application updates are tested and installed as soon as possible, and always within 14 days of release. AWS remain responsible under their shared security model for applying all necessary updates to the hardware and networking platforms that underpin our service.
Tools are used as part of the application build process to inventory versions of third-party components used within our software and check against databases of known vulnerabilities. These reports are fed back into the software development process for remediation.
AWS provide a service named AWS Config which periodically takes a snapshot of the configuration of the infrastructure and can compare it to various best-practice standards in order to find potential weaknesses and vulnerabilities. We use this to regularly evaluate our configuration against the CIS, IAM, S3 and 'Well Architected Security' conformance packs and make corrections in accordance with our risk management criteria.
Protective Monitoring
Under the AWS shared security model, AWS have sole responsibility for protecting the underlying cloud platform itself including hypervisors and low level network security. They have a comprehensive compliance programme and offer a number of third-party attestations on the adequacy of their controls which are available on request.
IIZUKA have the responsibility for ensuring that our usage of the platform is secure and we have taken the following steps to ensure logs are collected, stored and processed at multiple levels within the service to give our operations full visibility of activity within the components that make up the service:
The AWS control plane usage is logged through AWS Cloudtrail and continually monitored for suspicious activity by AWS GuardDuty and custom alarms.
The network perimeter is guarded by a web application firewall with tuned rules to automatically block high risk requests and report on lower risk suspicious activity that may require further investigation. These rules are continually reviewed and updated as new threats emerge. Network flow logs are retained for all internal and external traffic including both allowed and denied traffic
Each of our small number of VMs has file integrity monitoring which is reviewed daily for evidence of intrusion but we generally prefer the use of immutable Docker images and serverless code.
Internal application logs and metrics are routed into a central log aggregation and analysis tool with dynamic reporting and graphing for visualisation of application activity and to aid in investigation of application faults or suspicious activity.
Application-level activity audit logs (including successful and unsuccessful authentication events) are reviewable and reportable through the application interface itself.
Incident Management
A documented Incident Management process exists as part of our ISO 27001 ISMS. This assigns priorities and responsibilities upon detection of a possible incident, internal and external escalation paths, criteria and timescales for customer notifications, and procedures for collection of evidence. Pre-planned responses are documented for likely scenarios to ensure rapid containment.
Customers are able to report potential incidents through our support desk and must do so promptly if data breaches are suspected. Customers must ensure that they notify the IIZUKA support desk of any changes to escalation points within their business.
Configuration and Change Management
A documented Change Management process exists as part of our ISO 27001 ISMS. This requires all non-routine changes to internal or application systems to be documented and approved by senior management for security and adequacy before they are implemented. A security and quality risk assessment must be completed for each change.
Asset registers are maintained to track internal information processing assets. Each asset is assigned a owner who is responsible for ensuring all relevant security policies are applied. The application service itself is described using infrastructure-as-code techniques which means that the environment is described formally in a configuration language and is stored under a version control system to track changes. The configuration is then applied to the test and production environments using automated processes. This ensures that all environments remain representative and any configuration drift is rapidly identified and corrected.
Cloud Security Principle 6: Personnel security
Where service provider personnel have access to your data and systems you need a high degree of confidence in their trustworthiness. Thorough screening, supported by adequate training, reduces the likelihood of accidental or malicious compromise by service provider personnel.
IIZUKA understands people are critical to the correct operation of the security policies and procedures that protect the service. If the staff do not conduct themselves in the required manner then the whole system will be weakened and therefore from the very first interview prior to employment through to their eventual departure they are reminded of the expected standards and their continued obligations with respect to information security. New employees must agree to our information security policies which state that failure to comply is treated as a disciplinary offence.
All IIZUKA staff undergo identify, reference and DBS checks as part of the onboarding process, and the majority additionally have HMG SC clearance.
Staff are provided with regular general information security training along with role-specific detailed operational guidance. IIZUKA operates a security education platform which offers best practice guidance on a number of topics, verified with followup interactive testing including phishing simulations.
IIZUKA applies the principle of least privilege to all stages of the application lifecycle and customer data handling. Predefined roles and access privileges to relevant information assets are assigned through our ISO27001 personnel management processes. Privileged access is limited to a small number of highly trusted employees. Each staff member has a unique user account for access to customer systems and their actions are logged and auditable. They are required to keep their account credentials private and instructed not share them with any other person.
A formal leavers procedure ensures all access to data and systems is terminated promptly at the end of employment.
Audit logs are maintained of all access and modifications to the hosting environment, including those by privileged users, and retained for a period of 12 months.
Cloud Security Principle 7: Secure development
Services should be designed and developed to identify and mitigate threats to their security. Those which aren’t may be vulnerable to security issues which could compromise your data, cause loss of service or enable other malicious activity.
Case Manager is developed and maintained in-house by IIZUKA's UK based and vetted development team in accordance with our ISO 9001 and ISO 27001 certified secure software development lifecycle and procedures.
Development, Testing and Production environments are fully separated and all source code is held securely in private version control repositories.
All developments are planned, designed and risk assessed before implementation. All changes are reviewed by senior staff and tested, using dummy data, manually and through our automated testing and continuous integration pipeline prior to acceptance into the codebase.
Third party software or libraries that are utilised by Case Manager are reviewed, risk assessed and maintained to the latest secure version, to protect against the introduction of vulnerabilities. Regular updates are provided to address identified issues, vulnerabilities or threats and deployments to the production environment are automated to enforce security, consistency and auditing.
IIZUKA maintains a secure development culture through regular awareness training, monitoring threat intelligence and an active review culture. Mitigation for the OWASP Top Ten is included in the system architecture and specific training is provided to developers.
Regular automated dynamic security testing is performed against the application to help identify weaknesses before it is deployed to a production environment, and to help identify vulnerabilities to emerging threats in the production application.
An annual penetration test of the production system is performed by an independent CREST certified organisation. An executive summary of the most recent test is available upon request.
Cloud Security Principle 8: Supply chain security
The service provider should ensure that its supply chain satisfactorily supports all of the security principles which the service claims to implement.
IIZUKA performs due diligence on subprocessors it engages in the provision of the service.
IIZUKA ensures that all subprocessor contracts include information security clauses at least as strong as those offered to our customers. This includes ensuring they have security management systems (such as ISO 27001) and policies in place commensurate with the level of access to customer data that they are granted. Subprocessors are only provided with access to the data that they need to fulfil their responsibilities.
As required by GDPR, all subprocessors are declared along with the circumstances under which customer data would be shared with them. If IIZUKA discontinues the services of any subprocessor, their access to customer data is removed.
Cloud Security Principle 9: Secure user management
Your provider should make the tools available for you to securely manage your use of their service. Management interfaces and procedures are a vital part of the security barrier, preventing unauthorised access and alteration of your resources, applications and data.
Case Manager features a fine-grained privilege system to authorise access to application functions. A role-based access control (RBAC) system allows these privileges to be allocated into common groups which can then be applied to users allowing the consistent application of privileges amongst multiple users. Predefined roles with various privilege levels are supplied a standard but variations to these roles are typically identified and defined during the initial requirements gathering process lead by our implementation team to support your particular use cases.
Data records are also protected by a record-level discretionary access control system which can restrict access to individual records based on a variety of criteria including user roles and team membership. Access can also be explicitly denied to a particular user where it might otherwise have been granted for example if there was a conflict-of-interest in a particular case.
Both of these RBAC and record level access control methods work on a deny-by-default principle i.e. no access is possible until a privilege is granted.
The management of users and allocation of user roles is normally delegated to the customer's administrators, while the task of further configuration of the privileges within each role is performed by the IIZUKA service desk under change control.
Cloud Security Principle 10: Identity and authentication
All access to service interfaces should be constrained to authenticated and authorised individuals.
User access to Case Manager uses SAML2 to integrate with your existing corporate identity server such as Entra ID or Google Workspace. This allows the system to inherit any corporate security policies and onboarding/offboarding processes you may already have and use authentication mechanisms with which your users will already be comfortable, without overburdening users with the management of additional logins and passwords.
There are no unauthenticated or public areas of the application. All application access requires a valid user record to be configured within the system.
Machine-to-machine / API access is optionally available to allow customers to integrate Case Manager into custom applications for use in specific use cases not easily supported by the standard web interface e.g. referral forms. These requests are authenticated using the standard OpenID Connect protocol, based on OAUTH2. This allows third-parties to access defined functions and data within the application without the need to reveal any end-user credentials to that system.
The Case Manager service comprises a number of separate components that communicate with each other over private internal interfaces. Where possible, these are authenticated using dynamic IAM role-based credentials which do not require passwords or access keys to be stored in the system configuration. Where this is not possible, static credentials are securely generated and stored, and rotated every 3 months as per AWS-defined best practice, or immediately if there is a suspicion they have been compromised.
Cloud Security Principle 11: External interface protection
All external or less trusted interfaces of the service should be identified and appropriately defended.
Case Manager is a web application available only over the public internet from explicitly defined endpoints. Data is protected in transit using using modern TLS encryption (see principle 1) and strong authentication protocols (see principle 10).
AWS provides tools and services to help protect against DDoS attacks. The system has been configured following AWS best-practice for DDoS mitigation including ensuring that all externally presented interfaces terminate on AWS services specifically designed to mitigate volumetric attacks such as Elastic Load Balancing and CloudFront.
A web application firewall is used in front of the application which can reject hostile application-layer attacks (see principle 5).
As an additional layer of protection, customers can choose to apply an IP allowlist to restrict access from only certain networks.
Protection of the publicly accessible AWS control plane falls under the responsibility of AWS and their own controls and attestations. We have satisfied our own responsibilities under their model by configuring least privilege user access with hardware key based 2FA authentication and maintaining an audit trail of API calls.
Cloud Security Principle 12: Secure service administration
Systems used for administration of a cloud service will have highly privileged access to that service. Their compromise would have significant impact, including the means to bypass security controls and steal or manipulate large volumes of data.
Access to the Case Manager internal administrative interfaces is restricted to a small number of trusted individuals on a 'least-privilege / deny-by-default' basis. Access is authenticated by individually assigned hardware security keys that are extremely difficult to copy or intercept. Change requests must be written, risk assessed and approved for any non-routine modification to the environment.
Access to servers supporting the application is only possible via a bastion host accessible through a VPN. There is no direct access through the public internet to these servers, enforced by multiple layers of network traffic filtering and IP routing controls.
AWS have implemented controls to prevent their staff from accessing data stored on the platform except when duly authorised. To quote their compliance documentation: 'We prohibit -- and our systems are designed to prevent -- remote access by AWS personnel to customer data for any purpose, including service maintenance, unless that access is requested by you or unless access is required to prevent fraud and abuse, or to comply with law', and these controls are verified by independent audits.
Cloud Security Principle 13: Audit information for users
You should be provided with the audit records needed to monitor access to your service and the data held within it. The type of audit information available to you will have a direct impact on your ability to detect and respond to inappropriate or malicious activity within reasonable timescales.
The Case Manager application provides a searchable audit log of all user activity, recording the user's unique identifier, date and time of action, the command issued, and a synopsis of any data changed. A separate security log records all successful and failed login attempts, and account lockouts.
If required, bespoke reports and system dashboards can be provided to satisfy specific audit requirements.
Cloud Security Principle 14: Secure use of the service
The security of cloud services and the data held within them can be undermined if you use the service poorly. Consequently, you will have certain responsibilities when using the service in order for your data to be adequately protected.
Case Manager is a very flexible platform and can be configured in numerous ways. It features comprehensive record-level data access controls allowing 'least privilege' and 'need-to-know' policies to be applied to the data held within. While we provide several pre-built secure configurations suited to certain market sectors, most large implementations will be bespoke to match your existing business processes.
Our expert system implementation team will work alongside your own project team to develop this configuration after which we will agree the data separation and security model, and a set of change and user management procedures to ensure the safe operation of the system. These procedures may delegate certain routine application and user configuration tasks to your internal teams while leaving others under the control of IIZUKA. A suitable role-base access control (RBAC) model will be developed to support this delegation so that only authorised users can make sensitive changes.
Security policies securing access to the system (see principle 11) are enforced by IIZUKA globally and cannot be overridden by tenant or user configuration.