The Dual Account model has long been best practice amongst SysAdmins and DevOps. Our blog explores what the model entails, how it helps protect organisations from external threats, and how Osirium PAM can strengthen the approach.
A Dual Account model refers to when a user has two accounts; one for daily use on their endpoints and the other for privileged operations on remote devices, systems and applications. As most malware needs access to a privileged account to embed itself or perform key-logging, the Dual Account model provides added security. The Dual Account model also works at the system audit level by allowing you to see who accessed what and when.
A key weakness of the Dual Account model is that the number of privileged accounts increases, in turn increasing the attack surface and making businesses only one weak password away from a breach. This approach also increases the cognitive load on SysAdmin and DevOps staff, giving them an extra password to remember, record and change.
Osirium has a dual stage approach to integrating Dual Accounts into Privileged Access Management. The first stage is called mapped accounts. Mapped accounts work by automatically mapping an identity like ‘John Smith’ onto an account, for example ‘john.smith_admin’. Osirium PAM changes the password on the ‘john.smith_admin’ account to be long, complex and regularly refreshed. It also checks the inbound identity of John Smith coming from an endpoint. The result is full traceability in systems logs, meaning that all privileged accounts are fully protected.
In general, the privileges of these ‘*-admin’ accounts can be managed in active directory. If there is a lot of them, it can be hard to keep track of individual changes, and this is how over-privileging happens. However, there is a different way that we think is better.
Our approach is to reduce to the absolute minimum the number of privileged accounts in the first place by using generic accounts; one for each role that you need. Organisations should ensure that access to these accounts is solely through . Profiles then match your existing identities onto roles, and access is then controlled along with other conditions such as time windows and change tickets.
As far as the remote systems see, only the generic accounts are being used, so that’s what will be sys logged to your SIEMS. PAM will be simultaneously logging which identities are using those privileged accounts. In any security audit, this gives a much lower set of accounts to track, and you never have to worry about who has access or not. If an identity is removed from PAM, it can no longer use any privileged role.
Remember that both the mapped account and the generic account are never used or have credentials anywhere near the endpoint. They are immune from malware by separation.
By implementing these recommendations, good practice account policy improves the level of control it provides, creating a complete reduction of any attack surface through a reduction in privileged accounts. The audit trail is augmented with full identity along with only other profile metadata such as change ticket references.
If you use the Dual Account model and would like to further improve your good practice, visit the Osirium PAM page to find out more.
Osirium Implementation with Dual Account models