Modelling access controls in data

IBM have developed and open sourced parquet modular encryption which allows encryption of individual columns in a Parquet (columnar) database. We need to be able to model this so that it can be demonstrated in the CyberKit4SME research project.

We can already model the benefits of columnar encryption for datbase operation. The fact that the data is encrypted is handled via the usual model, which means threats prevented by encryption will be blocked. The downside is that query processing is far slower, since it involves decryption of any data that must match terms in the query. Parquet modular encryption is represented as an extra control that blocks this 'overload' threat when triggered by the use of encryption - so it is 'encryption with far lower overheads'.

IBM are now also using columnar encryption to restrict access to specific fields in data tables in Secure Data Services (SDS), also developed in the CyberKit4SME research project. The consumer process can query the data, but gets output in which each field is encrypted using a different key. The consumer process can then access fields for which they have the key.

Key management for this (between the database and consumers) can be handled by the application itself (presumably registering keys as data is added to the database), or by a service such as Hashicorp vault which issues keys based on the consumer role. Authentication can also be is handled by a service, e.g., Keycloak.

What this means is that the key management service controls access to individual data fields.

To model this properly we should extend the domain model as follows:

[x] Add an asset type representing a data field, which can be present in regular Data assets.
[x] Add threats involving unauthorised access to or use of specific fields, including inference attacks, which are blocked by field-level obscuration controls, one of which uses cryptographic obscuration.
[x] Add new relationships for key management services. Currently we have only one such relationship (to another service to which the key management service controls access). We will need relationships to Data and/or the new Field assets.
[x] Add new threats representing the effect on those Data/Field assets should the key management service be compromised.

The first two of these steps was prototyped in the PRiAM project, but in an old (v5) branch of the domain model. Automatic merging of those steps is not possible, but we should start by adding them manually.

Spyderisk / domain-network

Modelling access controls in data #39