Every IT infrastructure is managed by privileged users. Users such as SysAdmins are granted elevated control through accessing privileged accounts to ensure that the uptime, performance, resources and security of the computers meet the needs of the business. Privileged account abuse presents one of today’s most critical security challenges and is increasingly the hacker’s favoured way of breaching your defences so privileged account management becomes a critical priority for IT security teams.
The Osirium PAM solution addresses both security and compliance requirements by defining who gets access to what and when. Find out below about the rich breadth of PAM capabilities that allow Osirium customers ranging from mid-market organisations to divisions of global enterprises to protect their businesses.
Or more accurately, ‘Separating SysAdmins from Credentials’. Osirium PAM 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 Osirium PAM and the end device.
Unlike other 1st generation privileged account management (PAM) solutions which are complex and expensive to install and maintain, Osirium’s 2nd generation PAM solution is simple for customers to deploy and use. With a freshly installed PAM service you can on-board 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 Osirium PAM 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 Osirium PAM 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.
Osirium PAM 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. Osirium PAM applies these at a Profile level. To help improve the experience of SysAdmins and DevOps, the PAM 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 PAM Client is running.
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. Osirium PAM implements privileged account management policies through Profiles, which map Identities through tools and tasks to role on systems.
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 Osirium PAM 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 Osirium PAM Profile memberships.
A MAP server is a Windows environment that is under the authentication and application control of Osirium PAM. 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 Osirium PAM 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 Osirium PAM 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 Osirium PAM 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 PAM 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 Osirium PAM 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 Osirium PAM 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 Osirium PAM will be opaque to any attacker. It's even difficult to intercept at the PAM 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 "break glass" 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 Osirium PAM 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'. Osirium PAM 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 Osirium PAM 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 Osirium PAM's control. This detects attackers creating accounts for their own use..