Credential Exposure in a Shared Process Account
An insurer's Blue Prism estate uses a single Windows service account, svc_rpa_shared, for all 20 digital workers across three teams. Credentials for the core policy administration system are stored in a Blue Prism credential store and referenced by name in process logic. During an audit, it emerges that a developer copied a password into a process's calculation stage as a literal string during a hotfix six months ago, and that the hotfix was promoted to production. The same shared account is used for both development and production environments. The audit also found that former contractors retain local administrator rights on two runtime resource hosts.
1. Identify the security control failures and rank them by risk.
Read the worked answer
Four distinct failures are present, and they compound:
- Hard-coded secret in a calculation stage. This is the highest risk. The password is now in the process definition, in version history, in any exported release file, and potentially in session logs. Anyone with design rights or access to the release package can read it. Remediation is not just removing the literal: the credential must be rotated immediately, because it must be assumed compromised.
- Shared service account across environments and teams. A single identity means no separation of duties, no attributable audit trail, and a development fault can affect production. If the account is compromised, all 20 workers and all three teams are exposed at once.
- Development and production sharing an identity. A developer with access to the dev credential can authenticate to production systems. This defeats environment segregation.
- Former contractors with local admin on runtime hosts. Local admin allows credential harvesting, tampering with the Blue Prism service, and log manipulation. This is a standing backdoor.
Ranking: rotate the exposed credential first (active compromise), then remove the stale admin rights (active unauthorised access), then split accounts (structural exposure), then fix the process design (already-covered vector).
2. Design the target credential and identity model, and describe the migration path without disrupting production.
Read the worked answer
Target model:
- One service account per environment per team, named by convention (e.g., svc_rpa_claims_prod), so an incident is scoped to a team and environment.
- All secrets held only in the Blue Prism credential store, referenced by credential name in process logic. No literals in any stage, ever. Add a code review checklist item and a pre-promotion scan for suspicious string patterns.
- Least privilege on the target application: each account gets only the roles its processes need, not a generic admin role.
- Runtime hosts: remove local admin from all non-essential users; contractors' accounts disabled and rights revoked before anything else.
- Credential rotation on a schedule, with a documented owner per credential.
Migration path:
- Rotate the exposed policy administration password now and update the credential store. Confirm no process breaks.
- Revoke stale admin rights on the two hosts; verify the Blue Prism service still starts and workers register.
- Create new per-team production service accounts, grant least-privilege roles, and test with a single worker in a pilot queue.
- Migrate workers in waves, keeping the old account active but unused until the last wave completes, then disable it.
- Remove the hard-coded literal, re-run regression tests, and re-promote through the release process.
- Update the ROM governance artefacts: credential register, access review cadence, and a mandatory secret-scanning gate in release management.