Session Isolation and Recording for a Contractor Population
A logistics company lets 60 third-party contractors (freight partners) connect to internal Linux servers through CyberArk PSM for SSH to run a proprietary rate-quoting tool. Sessions are recorded. Recently: (1) a contractor copied the rate-quoting binary to their own machine over an allowed SCP path; (2) an audit found recordings for 3 sessions were missing because the PSM connector ran out of disk and silently stopped recording while still allowing sessions; (3) contractors share a single vaulted account ratequote because 'each contractor having their own account is too much admin.' Management wants to add more contractors next quarter and asks whether the current model scales.
1. Identify the control gaps revealed by the three symptoms and rank them by risk.
Read the worked answer
Three separate failures, and they compound:
- Shared account
ratequote(highest risk). Every contractor authenticates as the same identity, so the recording and audit trail cannot attribute an action to a person. Symptom (1) - the binary exfiltration - is unattributable: you have a recording but can't say which of 60 contractors did it. This also defeats least privilege: revoking one contractor's access means disrupting all. It's the foundational gap because it undermines every other control. - Recording silently failing while sessions continue (high risk). A PSM connector that stops recording but keeps allowing sessions is worse than no recording - it creates false assurance. Missing recordings for 3 sessions means the control you rely on for (1) was absent exactly when needed. 'Fail-open' on a security control is a design defect.
- SCP exfiltration path (medium-high). The allowed SCP path let a contractor pull the binary. That's a session-isolation / data-transfer policy gap: what file transfers are permitted should be constrained, not incidental.
Ranking: shared account first (it's the root that makes the others unprovable), then fail-open recording, then the transfer path.
2. Design changes so the model scales to more contractors. Address attribution, recording integrity, and data transfer.
Read the worked answer
Attribution: give each contractor their own account mapped to their identity, vaulted and managed by policy - not a shared ratequote. The 'too much admin' objection is solved by automation: onboard/offboard via directory groups and policy, so 60 (or 200) contractors are managed by group membership, not manual account creation. Each session then records who, and revoking one person is a group change, not a shared-account disruption.
Recording integrity: treat recording as fail-closed where feasible - if the connector can't record, it should refuse the session (or at minimum alert loudly and page someone), not silently continue. Add disk-capacity monitoring and retention policies so the connector doesn't fill up, and alert on recording gaps. Management should be told explicitly that a silent recording failure is a control outage and must be treated like one.
Data transfer: constrain SCP/file transfer through PSM policy - allow only the transfers the job needs, block copying executables/binaries out, and log all transfers. Consider whether contractors need shell access at all or whether the rate-quoting tool can be exposed more narrowly.
Scaling answer: yes, it scales - if identity is per-person and managed by group policy, recording is monitored and fail-closed, and transfer is constrained. It does not scale on a shared account: adding contractors multiplies the attribution problem and the blast radius of any single revocation.