UNCOMMON CORRELATION LIMITED

Data Mesh SaaS Implementation - Design and Delivery

Implement a data mesh in dynamically provisioned, vendor-agnostic, well-governed, hybrid clouds, using SaaS or open-source offerings. Achieve auditable, and sovereign, control over your domain data by implementing the four principles of the data mesh: "domain-driven ownership of data", "data as a product", "self-serve data platform" and "federated computational governance".

Features

• Cloud and SaaS vendor agnosticism
• Hybrid cloud SaaS deployment
• Unconstrained flow of data
• True data sovereignty
• Authoritative data governance
• Distributed by default
• Rapid delivery
• Domain control
• Data as a primary concern
• Domain evolution

Benefits

• Protection against vendor lock-in
• Achieve best VFM for compute tasks
• Standardise definitions of data in flight for agility and resilience
• Secure access to all data via RESTful API ensures ownership
• Tamper-evident, distributed, recording of system activity for absolute integrity
• Mitigate risk and evade attack by removing vulnerable centralization
• Surpass expectations at a fixed price
• Encapsulate your domain in software to reduce processing problems
• Better data and tooling to empower domain experts
• Prevent spiralling costs when your domain or its data changes

£0.05 a gigabyte a month

• Education pricing available

Service documents

• Pricing document

  PDF

• Skills Framework for the Information Age rate card

  PDF

• Service definition document

  PDF

• Terms and conditions

  PDF

Request an accessible format

If you use assistive technology (such as a screen reader) and need versions of these documents in a more accessible format, email the supplier at gary.stevens@uncommoncorrelation.co.uk. Tell them what format you need. It will help if you say what assistive technology you use.

Framework

G-Cloud 14

Service ID

399897171771035

Contact

Gary Stevens
07309205105
gary.stevens@uncommoncorrelation.co.uk

Service scope

• Software add-on or extension: No
• Cloud deployment model:
  • Public cloud
  • Private cloud
  • Community cloud
  • Hybrid cloud
• Service constraints: None
• System requirements: Linux Operating System

User support

• Email or online ticketing support: Email or online ticketing
• Support response times: Within 2 hours during business the business week: 0800-1800, Monday to Friday. Within 2 hours of the start of the business week if the question is raised over the weekend or a bank holiday.
• User can manage status and priority of support tickets: Yes
• Online ticketing support accessibility: WCAG 2.1 AAA
• Phone support: Yes
• Phone support availability: 9 to 5 (UK time), 7 days a week
• Web chat support: Web chat
• Web chat support availability: 9 to 5 (UK time), 7 days a week
• Web chat support accessibility standard: WCAG 2.1 AA or EN 301 549
• Web chat accessibility testing: None - we use Matrix.
• Onsite support: Onsite support
• Support levels: We only have one level of support. Our team members are all technical experts, and are all available to our clients to interface with directly.
• Support available to third parties: Yes

Onboarding and offboarding

• Getting started: We supply hands-on training and mentoring directly from our team of experts, which can be delivered on-site or remotely, as the client prefers. Full documentation is provided as standard, covering fundamental technology specifications, as well as end-user 'how-to' guides, and decision records and explanatory materials covering the 'why' of our services and software.
• Service documentation: Yes
• Documentation formats:
  • HTML
  • PDF
• End-of-contract data extraction: All data, all developed IP, and all pass-through-IP, is fully owned by the client at all times during and after the contract. They can extract data from our systems at any time, in bulk, over the API in an automated fashion, with or without support from our team.
• End-of-contract process: There are no additional costs for ending the contract, nor are there any additional costs for service sun-setting or data extraction.

Using the service

• Web browser interface: Yes
• Supported browsers:
  • Microsoft Edge
  • Firefox
  • Chrome
  • Safari
  • Opera
• Application to install: No
• Designed for use on mobile devices: Yes
• Differences between the mobile and desktop service: We implement proper progressive enhancement on all interface features, starting with mobile by default, upward through viewport sizes / devices.
• Service interface: Yes
• User support accessibility: WCAG 2.1 AAA
• Description of service interface: Depending on client choice, we offer service interfaces via the web, over API, and through CLIs.
• Accessibility standards: None or don’t know
• Description of accessibility: Dependent on implementation. Web interfaces will be accessible to WCAG 2.1 AAA where browsers have implemented the specifications.
• Accessibility testing: Recorded end-user testing against user stories, against a red-amber-green scoring matrix of achievement of objectives.
• API: Yes
• What users can and can't do using the API: All system elements, and all data, are fully exposed to all create, edit, retrieve, and delete, (CRUD), operations, through an API conforming to the Richardson Maturity Model for RESTful (Representational State Transfer) interfaces, including the constraint of Hypertext as the Engine of Application State (HATEOAS).
• API documentation: Yes
• API documentation formats:
  • Open API (also known as Swagger)
  • HTML
  • Other
• API sandbox or test environment: Yes
• Customisation available: Yes
• Description of customisation: We practice an augmented, rigorous, methodology based on the 12 factor app principles. This means that our systems are loosely coupled, and all aspects can be dynamically configured, by authenticated users at the appropriate level. User authorization levels are client-specified, in the systems themselves. Full training is given.

Scaling

• Independence of resources: Dynamic scaling of consumption of compute resources is across data centres / clouds / sites and is protected from the consumption of other clients. Generally speaking, we do not share resources between clients.

Analytics

• Service usage metrics: Yes
• Metrics types: As service metrics, including data such as uptime, or user access, are treated in our system as data, they are available over the API, or exposed in a web dashboard or CLI polling the API.
• Reporting types:
  • API access
  • Real-time dashboards

Resellers

• Supplier type: Not a reseller

Staff security

• Staff security clearance: Conforms to BS7858:2019
• Government security clearance: Up to Developed Vetting (DV)

Asset protection

• Knowledge of data storage and processing locations: Yes
• Data storage and processing locations: United Kingdom
• User control over data storage and processing locations: Yes
• Datacentre security standards: Complies with a recognised standard (for example CSA CCM version 3.0)
• Penetration testing frequency: At least every 6 months
• Penetration testing approach: Another external penetration testing organisation
• Protecting data at rest:
  • Physical access control, complying with CSA CCM v3.0
  • Physical access control, complying with SSAE-16 / ISAE 3402
  • Physical access control, complying with another standard
  • Encryption of all physical media
  • Scale, obfuscating techniques, or data storage sharding
  • Other
• Other data at rest protection approach: Hardware keys, LUKS, SSH, GPG, encrypted key managers (like KeepassXC), distributed workflows to reduce data aggregating in central servers / clouds.
• Data sanitisation process: Yes
• Data sanitisation type:
  • Explicit overwriting of storage before reallocation
  • Deleted data can’t be directly accessed
• Equipment disposal approach: Complying with a recognised standard, for example CSA CCM v.30, CAS (Sanitisation) or ISO/IEC 27001

Data importing and exporting

• Data export approach: All system elements, and all data, are fully exposed to all create, edit, retrieve, and delete, (CRUD), operations, through an API conforming to the Richardson Maturity Model for RESTful (Representational State Transfer) interfaces, including the constraint of Hypertext as the Engine of Application State (HATEOAS). Users therefore query the API to receive all data on the machine they issued the query from. Support is available at no extra cost.
• Data export formats:
  • CSV
  • Other
• Other data export formats:
  • JSON/JSONSchema
  • HTML (as per the strict definition of REST)
  • GeoJSON (where geospatial data)
  • CBOR/CDDL
  • GRPC
  • Protobufs
  • SQL/SQL dumps
  • Plain text files (for example: for logs)
  • Any other open source standard or potocol on request
• Data import formats:
  • CSV
  • Other
• Other data import formats:
  • JSON/JSONSchema
  • GeoJSON (where geospatial data)
  • RDF (or associated languages)
  • CBOR/CDDL
  • Protobufs
  • Any other open source standard or protocol

Data-in-transit protection

• Data protection between buyer and supplier networks:
  • TLS (version 1.2 or above)
  • IPsec or TLS VPN gateway
  • Other
• Other protection between networks: SSH, GPG, hardware keys, one-way bastion architectures.
• Data protection within supplier network:
  • TLS (version 1.2 or above)
  • IPsec or TLS VPN gateway
  • Other
• Other protection within supplier network: SSH, GPG, hardware keys, one-way bastion architectures

Availability and resilience

• Guaranteed availability: We practice a 99.999% uptime target. Downtime is refunded by writing off the time taken by our team to resolve the downtime.
• Approach to resilience: All our software and systems apply 'who, what, how' recording approach against all create, retrieve, update, and delete, (CRUD) events by, all users and integrations. This data is replicated, hashed for tamper-evidencing, and encrypted. Our software and systems operate in a load-balanced, distributed-by-default, configuration.
• Outage reporting: The services precise outage reporting configuration is set against users' needs. We make available this data across dashboards, replicated logs, APIs, and email and SMS alerts, where appropriate.

Identity and authentication

• User authentication needed: Yes
• User authentication:
  • 2-factor authentication
  • Public key authentication (including by TLS client certificate)
  • Identity federation with existing provider (for example Google Apps)
  • Username or password
  • Other
• Other user authentication: SSH, GPG, multi-factor authentication, hardware keys
• Access restrictions in management interfaces and support channels: Beyondcorp / zero-trust access control lists (ACL), hardware keys, multi-factor authentication
• Access restriction testing frequency: At least every 6 months
• Management access authentication:
  • 2-factor authentication
  • Public key authentication (including by TLS client certificate)
  • Identity federation with existing provider (for example Google Apps)
  • Username or password
  • Other
• Description of management access authentication: SSH, GPG, multi-factor authentication, hardware keys, zero-trust / beyondcorp access control lists (ACL).

Audit information for users

• Access to user activity audit information: Users have access to real-time audit information
• How long user audit data is stored for: User-defined
• Access to supplier activity audit information: Users have access to real-time audit information
• How long supplier audit data is stored for: User-defined
• How long system logs are stored for: User-defined

Standards and certifications

• ISO/IEC 27001 certification: No
• ISO 28000:2007 certification: No
• CSA STAR certification: No
• PCI certification: No
• Cyber essentials: No
• Cyber essentials plus: No
• Other security certifications: No

Security governance

• Named board-level person responsible for service security: Yes
• Security governance certified: No
• Security governance approach: We divide our security governance into two: per-project and whole-company. All projects face unique, and relative, risks. Therefore, we design and implement an appropriate security governance framework, policy, and practice, for all of our projects. This is designed and implemented in partnership with our client, and training and documentation is provided. At the company level, security governance is a top-level priority, the design, implementation, and execution of which is made the personal responsibility of all team members. Our overarching principles are zero-trust, many-eyes, private-by-design-and-by-default, and distributed-by-default. More information on these is available freely on request.
• Information security policies and processes: As per our position on security governace, our information security policies and practices are divided into two: per-project and whole-company. Our overarching principles are zero-trust, many-eyes, private-by-design-and-by-default, and distributed-by-default. All team members at all levels are given training to identify risks, and action them. All risks identified are logged and triaged appropriately. Equal weight is given to risks with a low probability of manifestation to those that are high where the outcome state is the same degree. Our treatment applies the same to near-miss and speculative events and risks. All risks and events are recorded in a tamper-evident manner, and are passed up to the senior responsible officer.

Operational security

• Configuration and change management standard: Conforms to a recognised standard, for example CSA CCM v3.0 or SSAE-16 / ISAE 3402
• Configuration and change management approach: All of our source code, and documentation (for the source code and for wider concerns), is tracked in the version control system, git. All changes, no matter how trivial, are subject to a rigorous peer review process. Furthermore, we use an internal protocol, which operates similar to a context-free-replicated-data-type, or a blockchain, to provide immutability and tamper-evidencing to the most critical of governance data. Changes are assessed against a number of properties, including but not limited to: supply chain attacks, large software-bill-of-materials dependency attacks, cryptographic flaws, vendor lock-in attacks, etc. More information freely available on request.
• Vulnerability management type: Conforms to a recognised standard, for example CSA CCM v3.0 or SSAE-16 / ISAE 3402
• Vulnerability management approach: Our first principle is that all software, and all interfaces to and between software, present a threat. Potential threats are assessed at all levels of our services, from 'bare metal and silicon', up the software stack to end-user interfaces and APIs. All threats are analysed according to our risk methodology (described above). We patch our software and services immediately a threat is registered - regardless of manifestation - as part of our continuous integration practice. We identify threats and risks through channels such as NCSC, NIST, MITRE, and the open source community. We identify and mitigate novel, hitherto undocumented threats.
• Protective monitoring type: Conforms to a recognised standard, for example CSA CCM v3.0 or SSAE-16 / ISAE 3402
• Protective monitoring approach: All our software and systems apply 'who, what, how' recording approach against all create, retrieve, update, and delete, (CRUD) events by, all users and integrations. This applies to failed and successful log-in / connection events. This data is replicated, hashed for tamper-evidencing, and encrypted. Our software and systems operate in a load-balanced, distributed-by-default, configuration. both potential compromises, and manifest risks / incidents, are mitigated immediately as part of our continues delivery and risk management methodology. All activity is carried through to our internal 'lessons learned' process.
• Incident management type: Conforms to a recognised standard, for example, CSA CCM v3.0 or ISO/IEC 27035:2011 or SSAE-16 / ISAE 3402
• Incident management approach: Our principle is that 'all team members can stop the production line', meaning that any issue or incident can be raised by any team member, which is immediately prioritised in our continuous integration workflow. This means that incidents and issues get found and fixed immediately. This principle extends to our clients and their users. The means of reporting is implemented on a per-project basis, and can be through means such as telephone, email support, a ticketing system, API, etc, as appropriate. Post-fix, all incidents are treated with a lessons learned analysis.

Secure development

• Approach to secure software development best practice: Conforms to a recognised standard, but self-assessed

Public sector networks

• Connection to public sector networks: No

Social Value

• Social Value:

  Social Value

  Fighting climate change

  Fighting climate change

  We use the standard carbon accounting concepts of 'operational carbon' and 'embodied carbon' to base decisions of product acquisition and transport / logistics. We implement a near-far policy, where products and services are analysed against their procurement from local suppliers. Where local suppliers cannot meet the needs as judged by the non-temporal and non-spatial properties of the target product or service, then the scope of supplier review is broadened progressively until a suitable option is found. For a case in point: UK-manufactured ARM boards are chosen in preference of equivalent devices from international vendors.

Pricing

• Price: £0.05 a gigabyte a month
• Discount for educational organisations: Yes
• Free trial available: No

Service documents

• Pricing document

  PDF

• Skills Framework for the Information Age rate card

  PDF

• Service definition document

  PDF

• Terms and conditions

  PDF

Request an accessible format

If you use assistive technology (such as a screen reader) and need versions of these documents in a more accessible format, email the supplier at gary.stevens@uncommoncorrelation.co.uk. Tell them what format you need. It will help if you say what assistive technology you use.