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.
Key Benefits of Osirium PAM Credential and Account Management
Separate People and Passwords
Or more accurately, ‘Separating SysAdmins from Credentials’. Osirium PAM is designed with the assumption that endpoints are compromised, and people are phishable. Therefore, a key capability of Osirium PAM is that credentials should never pass-through end points or be revealed to humans (except when needed in a “break glass” situation).
You can think of this as a 'credential-injecting proxy'. This means that credentials only travel between Osirium PAM and the end device and never exposed to the risk of users copying passwords to their clipboard or network traffic between the user workstation and target device being intercepted.
Granting just the access needed - ID to Role Mapping
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 roles on systems.
Fast Speed To Value
Unlike first generation privileged account management (PAM) solutions, which are complex and expensive to install and maintain, Osirium’s second 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.
Enterprise-class Account Lifecycle Management
Osirium has long realised that security is a never-ending journey, and that our customers must start somewhere. Before they switch on the powerful features of Osirium PAM they need to build up trust in what it does. 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 start by using the platform in 'neutral' to start capturing privileged accounts. Over time, you can bring those accounts under PAM control by making the role accounts and their credentials (passwords and keys) the state 'known'. This means that users can gain access to these role-based accounts through profiles without knowing the credentials. Eventually, once you can switch to the 'managed' state (on a per account basis) and on to "fully managed" meaning PAM has full control to create, update, rotate and remove the credentials without the human SysAdmins ever having had access to the credentials.
Enhanced Identity Security with Multi-Factor Authentication
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 behanded 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.
Privileged Access Only When Needed - Time Windows
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.
High-availability and Fault-tolerance
As PAM should be the central point through which all access to services and devices is routed (apart from break glass emergencies), the PAM service becomes a critical part of the IT infrastructure, so must always be available to the SysAdmins. Osirium PAM includes clustering of servers as a standard feature. Groups of Osirium PAM servers can be defined so that should one server become available (e.g. through a hardware failure), the PAM service can continue.
It doesn’t require expensive external dependencies such as SQL Server Always On, or complex, dedicated network configurations. It’s also included in the standard Osirium PAM subscription, so it’s to predict and plan future expansion of PAM usage.
Additional Security, Ease of Use Capabilities
Change Management Processes - Change Tickets
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 service desk management systems such as ServiceNow to ensure the request is 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.
Managed Access to Privileged Systems with Map Server
A Managed Application Protocol (MAP) server is a Windows environment that is under the authentication and application control of Osirium PAM. It uses Remote Desktop Protocol (RDP) application windows to render an application’s windows 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.
Once you 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.
Third-party or Vendor Access
It's really a combination of features that makes the Osirium PAM great for this. First, is its 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 First Option 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.
Enhanced Management of Devices with Metadata
The concept of metadata and metadata searching runs deep throughout Osirium PAM. Its 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 a 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 Osirium PAM we can assign users and devices to their 'home' Active Directory (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, Osirium PAM supports local, TACACS and radius-based authentications. So, it's easy to have your Cisco kit under TACACS and your users in AD.
Enterprise-class Password Lifecycle Management
Because Osirium PAM 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. You could define a change after every use policy, but you just don't need to. This means that Osirium PAM knows the credential state of devices. It can confidently mesh PAM instances 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.
Extensive Range of Device Support
The Osirium “Plays Well With” program shows you all systems and devices supported out-of-the-box by Osirium PAM. 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.
Generic templates are available for web-based applications, so just about every cloud application the business needs will be supported.
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.
Web Single Sign On
Since Osirium PAM separates people from credentials, it must understand how to inject usernames, passwords and keys into devices and services with web based front ends. It has a wide range of pre-built drivers for common devices and SaaS cloud offerings. These drivers perform the initial connection to a web page and interact with the forms and JavaScript related to inbound authentication. The PAM architecture makes it easy to quickly add more as required.
Simple Deployment and Management - No Agents Needed
Communication between Osirium PAM and the target devices (servers, databases, network devices, cloud applications, etc.) is via native interfaces or standard protocols. There's no need to install expensive to manage "agents" or "daemons" on the target systems as with some older PAM solutions.
Auditable Least-Privilege
Since Osirium PAM cannot be bypassed, policies are 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.
SIEM Support
The Osirium PAM logs 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, for example, Alice.Smith uses the role 'root' on device 'X'. It tells you when the tasks run, when devices are audited, when anyone runs a break glass, 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.
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 Osirium PAM profiles define who can use this account and on what systems.
No More Sharing of Credentials - One Identity Instance Only
This has been a keystone feature of Osirium PAM 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 Osirium PAM 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
For safety, Osirium PAM assumes all endpoints have been compromised and public networks insecure. The connection between the PAM client and the PAM server 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 Osirium PAM 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
A common operational policy states 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 Device Group Separation (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 Engineer 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 break glass (AKA Fire Call) methods that you'll need, even if your data centre is flooded out. PAM has "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 it's called "break glass" - because revealing credentials is definitely not business as usual.
Device Auditing
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.