Secure authentication for Robotic Process Automation

Robotic Process Automation (RPA) can automate a range of back-office and administrative functions to free up time. The industry technology used to provide Care Identity Service (CIS) smartcard level security for a robot is still in the early stages. It has several differing options, making the implementation of any solution complex.  

This guide, from the perspective of CIS, looks to provide trusts and other healthcare bodies with information on how to implement an initial RPA solution secured with CIS robot (agent) identities. It mirrors what a number of organisations have currently implemented and has proven to be achievable.

Identities registered solely for RPA use are referred to as non-person specific user profiles. To date, these have been outside of NHS Registration Authority (RA) policy. A new version of the RA policy is expected to be released in September 2024 which will include the essence of this guidance.

Before reading this guide, you should read the wider guidance for designing, delivering and sustaining RPA within the NHS.

Scope

This guidance applies to: 

• both CIS1 Authentication and CIS2 Authentication secured solutions
• only unattended RPA
• the issuing of robot identities
• your technology group (IT department)
• any RPA vendor involved

Guidance principles

The following are the principles that underpin the security of any automated processes:

1. Use APIs first - before considering RPA, see NHS England APIs.
2. Follow the wider NHS England guidance for designing, delivering and sustaining RPA within the NHS.
3. RPA is a risk based activity, that the organisation must define, understand and monitor.
4. Secure the RPA environment (including robot control centre and worker machines).
5. One robot identity per RPA worker machine (whether physical or virtual).
6. Each automated workflow must be understood for risk.
7. Keep an audit log.
8. RPA is evolving quickly - this guidance will regularly be revised to take advantage of higher security solutions.

Organisational readiness

Introducing RPA, changes your organisation's risk profile. Automated processes are capable of accessing and modifying data rapidly at a very large scale, which significantly increases the risk associated with any malfunction, misbehaviour, or malicious use.

When starting the RPA journey it is important to assess a number of areas:

• a full review by the organisation of the existing security controls in place, and changing them where required
• assess if your current risk management (including any clinical implications) support the additional risks for RPA
• the organisation must appoint a Senior Responsible Owner (SRO) who will be held responsible for the actions of the robot

By following the NHS England Checklist for RPA you will:

• understand your new risk position
• be able to sign off what new risks there are
• meet your legal obligations

National Registration Authority (RA) considerations

There are two national authentication services that are covered by the current RA policy:

• Care Identity Service 1 Authentication (also known as legacy authentication, smartcard authentication, or CIS1 Auth)
• Care Identity Service 2 Authentication (previously known as NHS Identity, also known as CIA or CIS2 Auth)

Main considerations

1. How your Registration Authority (RA) function operates.
   Can it deal with the additional robot identities?
   Is there a simple process for password changes?
2. Incident handling.
   The appropriate information security and RA reporting must be adhered to (including https://www.dsptoolkit.nhs.uk/Help/29)

Workflows

Workflows define what robots do to automate your process, and will have different terms depending on the software or platform you have chosen.

Independent of which tool you use, you should:

• analyse each automated workflow, undertaking an appropriate risk assessment
• have a formal, audited, change control processes, which should also review risks for changes to the workflows
• ensure tasks such as creating users and assigning positions are not done via RPA as this could allow a compromised account to create new compromised accounts that are harder to detect. RPA is not permitted to automate RA functions
• only a limited number of approved staff are able to modify the RPA. System (technical) administrators should not automatically have permission to change the workflows, unless they are also part of that formal change process
• review your changes with any third parties that your automating changes might connect with, to ensure there are no downstream risks exposed

Securing your robot identities

Once your RA has created the robot identity:

• the robot credentials must be placed into a secure vault only readable from the environment running the RPA process
• a specific RPA server must be bound one to one with the identity
• make sure that the principle of least privilege is adopted in terms of both access and permissions for the robot
• administrative access to the robot must be strictly controlled, ideally, no more than 2-3 individuals should be granted administrative access

Runtime and securing your automation cluster

Running the robots securely is complex, but there are a few terms that help split the problem up:

Automation cluster

This is made up of :

• Robot (RPA) control centre - which manages how many robots are running and their configuration
• Robot (RPA) server - alternative names: "Virtual Machine (VM)", "device", "robot endpoint"  

Robot - some common terms

"digital worker", "client", "agent", "bot", "robot identity", "machine user"

The automation cluster must be in a fully secure location. The NCSC provide guidance, as well as standards such as ISO 27001 and Open Identity Connect (OIDC) "confidential client" definition will help you understand how to secure the servers.

Security configuration

The main security that should be in place, is as follows:

1. Domain user accounts, running RPA, must each be restricted to only log on to a single assigned RPA server.

2. The minimum password length for domain accounts running RPA is 25 characters.

Passwords are unique to each account, machine-generated (randomised) and stored in encrypted form in a secure vault.

3. The robot servers, credentials (for example domain passwords), and automation cluster (including any management of domain accounts running RPA) must only be accessible from trusted devices that are dedicated to administration activity.

The devices used for administration must be securely stored when not in use and kept hygienic.

Any non-administration activities such as web browsing / email on these devices must only be conducted on a remote desktop or VM where data flow to the host OS is restricted (‘browse-down’ architecture).

4. The means of access to RPA servers, domain passwords and management systems must also utilise all the following:

• a privileged access management service that enforces multi-party approval
• multi-factor authentication with a password of minimum 8 characters length and no maximum length restrictions
• logging and auditing of access and actions

5. Each account running RPA must be dedicated to a single RPA process and not used for any other purpose.

6. Systems running RPA must not be used for any other purpose.

7. Accounts and systems running RPA must each only have access to the minimum applications and network resources necessary to operate the RPA process.

8. Each account running RPA must only have access to the credentials/authentication token for a single robot user.

9. Credential caching in the operating system must be disabled on any endpoint running RPA.

10. Input of robot user credentials to any RPA system must be supervised, for example by the Local RA Manager.

Your audit logging will be very dependent on the automation tool you use, but at a minimum it should:

• include the data being updated - the trail must be held encrypted and secured
• set a minimum of 90 days for the audit to be held - although that is a decision your organisation must take
• include that the trail must be machine readable, but there is no specific format. For instance, it could be the raw commands of the robot software

The following table sets out, side by side, how CIS1 Authentication and CIS2 Authentication are different in RPA situations:

Secure Robot Authentication (SRA) provides equivalent security to Care Identity Service smartcards, and securely binds (connects) a robot server to a robot identity. This is a target solution to securing Care Identity Service identities for RPA, enabling a true zero trust security model. Read guidance on how you can do this.

This is currently in private beta. If you would like to get involved with the private beta, please complete this form.

Windows Hello provides equivalent security to CIS smartcards, and securely binds (connects) a robot server to a robot identity. This is a target solution to securing CIS identities for RPA, enabling a true zero trust security model.

Guidance will be issued on how you can do this, but it is anticipated that only a small number of RPA vendors will be able to do this. Where this is not possible, the robot MFA using TOTP should be used to improve on any username and password based solutions.

Make sure the following controls are in place:

• controlled access to smartcard location
• smartcards must be series 8 or later
• smartcards, smartcard readers and cabling stored in a secure cage
• cage in a room with controlled access
• only one smartcard per robot
• standardised naming convention and image format for printing on smartcard as specified below
• multiple smartcards may be dedicated to a process for improved capacity or resilience, but each smartcard must not be used across multiple RPA processes

Make sure the following controls are in place:

• no possible means for an administrator to configure the virtual smartcard to be authenticated without the passcode/password being supplied
• 25 character minimum length for the virtual smartcard passcode*
• accounts that do not utilize MFA must change passwords every 90 days
• passcodes must be unique to each virtual smartcard and completely machine-generated (randomised) using a mixture of all supported character types
• each virtual smartcard’s credentials, to be used, must only be stored in encrypted form. It must be in a secure vault, that is only readable from the domain user account that runs the RPA with that virtual smartcard (e.g. Windows includes Credential Manager that would be suitable for this purpose)
• the passcode must not be accessible anywhere else
• each virtual smartcard must be dedicated to a single RPA process and a single domain user account

* The Cyber Essentials (v3.1) requirement for password-based authentication without MFA does not permit any maximum password length restrictions. If the virtual smartcard to be used does not allow a 25+ character password, seek support from your vendor.

Multi-factor Authentication (MFA) using Time-based one time passcode (TOTP) is subject to change as potential solutions are developed and assessed further.

Make sure the following controls are in place:

• 25 characters minimum length password
• passwords must be unique to each robot and completely machine-generated (randomised) using a mixture of all supported character types
• each robot’s password must only be stored in encrypted form. It must be in a secure vault that is only readable from the domain user account that runs that robot (for example, Windows includes Credential Manager that would be suitable for this purpose). The password must not be accessible anywhere else
• the TOTP key must be stored in encrypted form. It must be in a secure vault that is not accessible to the server running the RPA process - the key must only be accessible to the process generating the OTP
• the generated TOTP must only be passed on request to the correct RPA server and this must use a secure transport mechanism

At this time, NHS England will not be carrying out technical assurance of your RPA implementations. This guidance is in place to allow for a risk-based decision to be taken by organisations and their nominated SRO. It does not imply any accreditation/approval/technical conformance certificate) to any third-party solution(s).

Read instructions for Registration Authorities on how to create robot identities (RPA profiles).

You can get support by emailing [email protected].