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..
No Lateral Movement
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.
Multiple Active Directory Domains
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.
Extensive Range of Device Support
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.
Enterprise-lass Password Lifecycle 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.
One Identity Instance Only
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.
Legacy Protocol Encapsulation
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.
Device Group Separation
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.
Granular RDP Control
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.
Multiple "Break Glass" Methods
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..
Web Single Sign On