Or more accurately, ‘Separating SysAdmins from Credentials’. The PxM Platform is designed with the assumption that endpoints are compromised, and people are phishable. Therefore, from the outset, we decided that credentials should never pass through end points or be revealed to humans (except in breakglass).
You can think of this as a 'credential-injecting proxy'. This means that credentials only travel between our PxM platform and the end device.
People have identities, accounts on systems have roles. That's the difference between an "identity management tool (IAM)" which confirms that a person is who they say they are compared to a "privileged account management" tool that controls what that person can do by assigning that person a "role."
It's important to know which identity used which role, on which system, and when. The PxM Platform implements privileged account management policies through Profiles, which map Identities through tools and tasks to roles on systems.
Unlike other 1st generation privileged account management (PAM) solutions which are complex and expensive to install and maintain, Osirium’s 2nd generation PxM Platform is simple for customers to deploy and use. With a freshly installed PxM Platform you can onboard and provision accounts from ID to role mapping in 8 minutes. Within 12 minutes you can give a third-party organisation access based purely on identity.
The third-party will never see or have access to the role account credentials. This means you can use a PxM Platform to provide immediate value whilst on the larger journey of Organisational Privileged Access Management.
We've long realised that security is a never-ending journey, and that our customers have to start somewhere. Before they switch on the powerful features of the PxM Platform they need to build up trust in what we do. This trust needs to span from the CISO and Security Architect through to the Operations Managers and SysAdmins on the ground. This is where Account States delivers. You can use the platform in 'neutral'.
You can tell it about role accounts and their credentials (passwords and keys) and give them the state 'known'. This means that your users can gain access to these role-based accounts through profiles without knowing the credentials.
Once you're confident here you can switch to the 'managed' state (on a per account basis). Now the platform will engage the ECPLM for scheduled and event driven changes to the passwords or keys.
The PxM platform is in essence an Identity IN - Role OUT system. Therefore the quality of identity proof is crucial for highly secure operations. Multi-factor Authentication (or MFA) adds an extra level of verification to incoming identities and may be provided by an identity and access management system.
MFA generally works based on something you know, something you've got, or something about you. Authentication services can either be handed off to Active Directory or defined as a series relationship. For example, a user can be identified either locally or by Active Directory and then through an additional MFA stage such as Google Authenticator.
To maintain consistent operations there are times when systems can and cannot be accessed for changes. The PxM Platform applies these at a Profile level. To help improve the experience of SysAdmins and DevOps, the PxM client will show a countdown for each device that has time-limited access.
They will see time counting down to the window that allows access and, if connected, they'll see the countdown to the end of the window. To account for global operations, the times are always presented in the local time zone where the PxM Client is running.
As an extra level of security and convenience, Profiles can be set to check for Change Tickets. When a connection or task is requested through the Profile a request dialog for a Change Ticket is presented. The supplied ticket can then be checked against products like ServiceNow for both being valid and open.
Once the connection or task starts the PxM Platform can log this against the ticket - thus saving time and effort for your staff. This feature also supports 'Emergency Tickets' that will always be valid and open. Operations made against Emergency Ticket are logged at an alert level.
Sailpoint is an important product for reporting and management of user privileges. We've implemented a bi-directional integration with Sailpoint. This reports all the policies set by Profiles along with user and group membership of those profiles. We also listen to Sailpoint for user provisioning requests. Sailpoint can define a new user along with PxM Platform Profile memberships.
A MAP server is a Windows environment that is under the authentication and application control of the PxM Platform. It uses RDP application windows to render the windows on the application on the MAP server to desktop of the user. This means that the user does not need to install 'Thick Clients' or legacy applications, in particular the dependencies for those applications. It's all about the known vulnerabilities of old applications and their dependency frameworks.
Now you can have these applications running in a safe environment, locked down, away from the user's desktop and email/web applications. There's no chance of cross infection or malware scripting. Just as before, the credentials are limited to the MAP server and never enter the user's domain.
It's really a combination of features that makes the PxM Platform great for this. First, is it's ability to have multiple authentication services, which means that it can hook into the identity providers of major outsourcers or vendors. Now you know that Bob.Smith from FirstOption has arrived, therefore, you can serve the right Profile immediately.
Then there are time-windows, session recording, live session monitoring and admin driven session termination. All these add up to safe Third Party relationship.
Since the PxM Platform cannot be bypassed the Policy is absolutely enforced. It also further means that if a device syslogs a login for which there is no matching Osirium syslog, then there is absolute proof that this is malicious.
Unlike simple password vault based solutions, since the credentials never enter the user’s realm they cannot be used to make connections to other systems. Even if all systems use the domain administrator account the PxM Platform profiles define who can use this account and on what systems.
The concept of meta data and meta data searching runs deep through the platform. It's main function is to give a business context to the user and device objects it manages. This surfaces in great usability for the Sysadmins. For example, in an estate of many thousands of systems it can be hard to remember a device name.
Within the PxM client the connection field is a free text search scheme. So, if our SysAdmin needs to find the Singapore Load Balancer in the DMZ, they may type 'Sing Load DMZ' which will narrow the search in real-time with each character. For reporting and Auditing the meta data is presented as select and sort columns so that you can quickly report on locations, or classes of device sorted by profile and last accessed data.
In the real world of suppliers, outsourcers, mergers and acquisitions it will regularly happen that a device based role account will belong to a different authentication service that the user that needs access to it. Within the PxM Platform we can assign users and devices to their 'home' AD and then use Profiles to create a well controlled mapping between them.
This is really helpful for policy clarity and often significantly more preferable to creating AD domain-domain trust relationships. It's not just AD, we support local, TACACS and radius based authentications. So it's easy to have your Cisco kit under TACACS and your users in AD.
The Osirium Plays Well With program shows you everything we support out-of-the-box. We have a device template repository which for the most part is an XML-based configuration description of how to connect to devices and how to manage role-based accounts. It’s also where the tasks are defined.
Many customers will extend these templates for their own use. The very first 'Osirium Server' was designed for infrastructure management, and as such it was designed for router/firewall/content device management.
Because the Platform does not reveal passwords, SSH keys or API tokens to users under normal operation, it doesn't have to change the credentials after every usage as vault-based solutions do. Now you could define a change after every use policy, but you just don't need to. This means that we know the credential state of our devices on the timeline much better. We can confidently mesh Platforms together and deal with the everyday situations of Devices being restored or replaced from Backup.
The Device Templates define the password lengths and SSH Key Cryptography. For most Unix-style devices this is 128 characters/RSA512. For older windows systems it can be as low as 32 characters. Even at 32 characters our generated passwords show superlative entropy, enough to withstand months of brute-forcing with the finest rainbow tables
The Platform syslogs in CEF format everything it does. Of course, it never logs actual passwords - not even in its own logs. But it will tell your SIEMS when Alice.Smith uses the role 'root' on device 'X'. It tells you when the tasks run, when devices are audited, when anyone runs a breakglass, when users are added or removed.
Now your SIEM can tell you if a device has a login for which there is no corresponding PxM syslog - and that's absolute proof of a policy violation or attack.
This has been a keystone feature of the platform since inception. The key problem with shared accounts is that they can be shared. We've therefore built the platform to prohibit the sharing of inbound identities. This means that if Alice.Smith leaves her desk and logs into the platform from elsewhere, the first instance of Alice.Smith will be forcibly disconnected.
This means single instance ‘in’, and a choice of role-based accounts on the way ‘out’. The feature promotes protection of identity and therefore security, and audit are improved with it.
Since we consider the end-point compromised and public networks insecure, the connection between the PxM Client and the Platform is presented as a 127.x.x.x network projected through an SSL tunnel. This means that should you need to use a Telnet connection to some legacy device, the data from the Desktop to the PxM Platform will be opaque to any attacker. It's even difficult to intercept at the PxM client since we use randomised high number ports for each connection.
By the time any data reaches the network card driver it is already encrypted. The connection from the Platform to the end device will be in the native legacy protocol. You can define extra LAN or VLAN interfaces in the platform to further ensure that legacy protocols are isolated to known secured networks.
We regularly find operational policies that state that whilst connected to one class of device, an operator should not connect to other classes of device. Typically MSSPs will require an operator to work on one customer's systems at a time. The DGS feature can either Block or Warn the operator about existing connections when they select a device of a different class. For larger end users, this could be used to ensure that a DevOp cannot connect to UAT systems whilst being connected to live systems.
On a Profile basis you can control what options an RDP session will get. For example, for third parties you might want to disable disk mapping and the cut and paste buffer. By using multiple profiles, the same user can get different options depending on what role they need to use.
At Osirium we understand that we're delivering a mission critical service. We've seen just about every failure that infrastructure can throw at you. Therefore we've built the Breakglass (AKA Fire Call) methods that you'll need, even if your data centre is flooded out. We've got Breakglass at the blue screen of the virtual appliance. Even if the only thing you've got to start with is a hypervisor and a copy of your PxM Platform you can start recovery. You can contrast this with other products that require an 'Always On instance of MSSQL' before they can even start to install one of their boxes. In our case just a single node is needed - you can restore your domain controllers long before the physical infrastructure is in place.
For scheduled protection we can generate encrypted PDF files and for day to day operations we have 'reveal credentials'. The PxM Platform has the best vault you'll never need. Everything is wrapped up at the SSO and task level. That's why we call it Breakglass - because revealing credentials in our world is definitely not business as usual.
The PxM Platform undertakes scheduled audits of each device. These audits check that the control account is available and working. For devices that allow multiple accounts, a list of all local accounts is retrieved and compared to the previous list. Accounts are categorised as 'Unapproved', 'Approved', 'Known', 'Managed' and 'Fully Managed' depending on the device template and the account database. This quickly reveals new accounts that have been created outside of the PxM Platform's control. This detects attackers creating accounts for their own use.