two circular arrows

How to design thoughtful and secure cross domain workflows

Senior technologists, architects, and service designers across government, are at the forefront of creating brilliant public services. They’re implementing robust solutions that protect sensitive information, and ensure efficient and cost effective public sector operations.

A critical component in digital transformation moving forward is the implementation of Cross Domain Workflows (CDWs). These workflows enable secure data exchange between different security domains, such as between a high-side (SECRET) and low-side (OFFICIAL) environment. 

In this blog, we’ll explore some of the more technical aspects of cross domain workflows, focusing on key concepts, outlining some of the cryptographic techniques, and discussing how they can be effectively implemented using modern tools.

Understanding cross domain workflows

A CDW allows for the secure transmission and interaction of data across different security levels. For government agencies, this means gathering data from public-facing, less secure systems (low side) and processing it in highly secure environments (high side). This dual-environment approach helps protect sensitive data from sophisticated cyber threats while maintaining accessibility and usability for necessary operations.

Key concepts and components

To establish a secure CDW, several key components and cryptographic techniques are involved:

Implementing key exchange and encryption

Client-side encryption pattern

On the client side, the Web Crypto API handles key generation, key exchange, and data encryption.

Server-side key management and encryption pattern

On the server side, the Python Cryptography library handles key generation, key exchange, and data encryption/decryption.

Example: Encryption workflow

Let’s illustrate the encryption workflow with a simplified, high-level example.

Key generation

Data encryption

# Server-side Python (simplified)

James Patrick, Zaizi

Security considerations

While implementing CDWs, it’s essential to address several security considerations.

By leveraging ECDH for key exchange and AES-GCM for encryption, cross domain workflows provide a robust framework for securing sensitive government data. As senior technologists and architects, your role in designing these workflows is crucial to maintaining data integrity and confidentiality. By implementing these cryptographic techniques thoughtfully and rigorously, you can help safeguard critical information and ensure that your systems are resilient against sophisticated cyber threats.

Secure service design with CDWs

One of the most critical principles is to ensure that users on their own machines have as few demands placed on them as possible.

Most users lack the expertise to deal with encryption keys or understand complex security protocols. By abstracting technical complexities and minimising the cognitive load on users, we create more secure and user-friendly experiences. This approach not only enhances security but also improves overall user satisfaction.

Minimising user demands is the key to better security

Users should not be burdened with complex security operations. Instead, they should experience a seamless interaction where the underlying security measures are transparent. For instance, rather than presenting a user with a single, large vetting form, we can break down the process into smaller, manageable tasks spread over several days. This method, often called gamification, can improve user engagement and reduce the likelihood of errors or fatigue.

Key Benefits of burden reduction

The concept of information slices

In secure service design, an information slice refers to a discrete, manageable piece of a larger data set. By handling data in slices, we can optimise operational efficiency and security. This approach is particularly useful in environments with varying levels of data sensitivity and access permissions.

Why do information slices matter?

READ: What is a cross domain workflow and why does it matter?

Practical application of cross domain workflows

CDWs are a great example of how slicing information can enhance both security and operational efficiency. In a typical scenario, aggregate data sets are (or should probably be!) maintained on the high side, where security controls are stringent. However, most staff operate on the low side and cannot access high-side environments directly.

Considerate CDW service design ensures we’re not creating more problems than we solve — for example, introducing or maintaining twin IT estates, or increasing the costs of sustaining a service by spreading it across two domains.

Example use case: vetting records

By implementing cross domain workflows, we maintain a high level of security for sensitive information while enabling practical and efficient processing on the low side. This approach ensures staff can perform their duties without unnecessary barriers, all while protecting the integrity and confidentiality of the overall data set.

In designing secure services, it’s crucial to balance the need for robust security measures with the goal of providing a user-friendly experience. By minimising the demands placed on users and leveraging the concept of information slices, we create secure, efficient, and user-centric services. Cross domain workflows exemplify how this balance can be achieved, ensuring that data remains protected while enabling practical and effective operations.

At Zaizi, our mission is to make the UK the best and safest place to live and work. We do this by helping our public sector customers solve complex problems. 

If you want to discuss cross domain workflows, we can organise a transformation day and help you start the journey to more secure, sustainable, user-centric services. 

Digital government is hard, together we’ll succeed.

If you’d like to to talk to James, discuss cross domain workflows or any of the points covered in this blog, please get in touch.

Thanks for joining us! We’ll keep you informed with regular updates.

Sign up to our newsletter

Consent(Required)
This field is for validation purposes and should be left unchanged.