Osirium as an Identity Federator

Deploying Identity to all Devices

The identity market has been getting stronger, it needs to get stronger as more and more business functions migrate to the cloud.

At Osirium we often use the phrase “Identity In – Role Out“, by this we mean mapping identities of people to roles on systems, devices and applications. A lot more sensible operational information can be derived if you know Which person done What to Which device When.

If we were to identity enable all the devices in an organisation we’d run into two key issues:

• Cost – mainly in the effort of connecting all the devices to identity services
• Simple embedded devices do not have identity capability

Here we propose that you use Osirium as an Identity Federator. In this deployment, Osirium consumes identities and delivers SSO to role based connections to devices.

Along the way we solve problems like:

• Shared Accounts, some devices can only have a handful of accounts
• Some applications need to be set up by a particular user account that uses applications specific tools.
• How to manage third party access:
• For temporary vendor access
• For short term contractor access
• For long term outsourcing contracts
• Stop users wandering around your system estate

These are significant problems to solve, for example you can provision a third party from your own identity provider and give them time window access to specific devices in your infrastructure in the safe knowledge that the passwords will never be known and that they cannot use the access to wander around your network. Add Session Recording to this and you’ll be able to review what changes they made to your system.

Suppose for a moment that you needed a third party to investigate an issue on a SAN server in your virtualised infrastructure. If that third party was untrustworthy they could simply take copies of all the virtual systems on that SAN. After they’ve finished they would have your VM in their environment and could spin these up in single user mode, extract SAMs and shadow files along with any data available. They could run the SAM’s and Shadows against hashing and brute force tools such as John the Ripper and you’d be none the wiser. Then they’d have legitimate accounts with which to access the live versions of these VMs.

Lets look at the same scenario with Osirium, first our third party would have to use their identity, so we know it was definitely them making the connection. Second, would they take the copies knowing their actions were being recorded? Finally, lets consider that they still took the copies even though they were being recorded. Well, they could still boot the systems in single user mode and they’d still get access to the data on those VMs. However, if Osirium had set the passwords then they would be long and complex, up to 128 characters and properly randomised. Hash lookups and John the Ripper would not be able to return the original passwords, and this represents a huge damage limitation.

‍