What have the auditors ever done for us?
Well, apart from the internal compliance, the external independent proof of compliance, and the governance – where would the investor confidence be without the governance, and don’t forget security – they always help with that.
And then there’s all the cleaning up which happens before the auditor’s visit – this clearing the desks always proves useful security work in the long run.
We know from our customer interactions that audits often trigger purchasing our products. Manual efforts are slow, expensive and inaccurate, so tools are desperately needed. We help to answer questions like “When was this password last changed?” and “Who has access to this system?” Both reflect security and compliance requirements. Then there are interesting philosophical thoughts around “Is a compliant system a secure system?” which, in reality, means that a non-compliant system is unlikely to be secure.
To an auditor, a Privileged Access Management (PAM) solution provides the link between individuals and the privileged accounts they use on systems. Where organisations used to use shared accounts such as root and admin, it was near impossible to have an accurate record of who had what access and when. Osirium PAM is a second-generation PAM solution that provides that information.
In this article, we’re going to discuss what PAM holds for auditors: the sort of data that doesn’t go to traditional logs and Security Information and Event Management (SIEM) tools. We’re going to show you how to answer auditor queries using some of the reports and pages from Osirium PAM. A good starting point is to be able to look in both directions – “What privileges does this user have?” and “What users can access this system?” A better way to ask the question is “What roles can users assume on what systems?”
As an overview, we can start with the Management page. It gives us a clear view of how many accounts have been discovered, and how well these are covered in terms of credential rotation? In other words – are your passwords and keys getting changed?
For auditing user privileges, the “user” page and shows the profiles and user groups. Here you can see all the devices that a user could access – and when they last connected. Lower down you’ll see all the devices that they could connect to but haven’t – this could be a latent threat. More of that later.
Now let’s take a look from a device point-of-view. In this example, we have a PBX system (PBX-SSH-NEW).
Under ‘User Access Control’, we can see a list of profiles that this system belongs to, and below a summary of all the people in those profiles along with the access roles or accounts they can use on this system. Once again, on the right-hand side, we can see who has accessed the system and when.
As before, lower down the list, we see who could access this system but haven’t.
The final section shows the account automation activity on this system, and for the auditors, we have the device audit – this checks the accounts on the device and can discover accounts not added by the PAM system since the last audit.
Now we can switch our view to the accounts that have been discovered on this system. In this case, all is good since all the accounts are ‘Known’.
Here’s a more complex example, you can see the known and approved accounts – which tend to be the daemon accounts, but what’s this – a ‘games’ and ‘enzo’ account? Let’s Disable this for safety.
We can look at who is doing the most on our systems. You’ll find this under ‘User Rights Audit’ and then ‘User Engagement’.
There are a table and a graph that shows who accesses systems the most. The next tab along presents the information from a Profile context — which profiles are being used the most. The next is user privilege distribution, which shows the relative proportions privileged accounts.
Analytics is a more complex display, where an overview of periods of activity can be viewed. Here we can filter tasks and connections. Session IPs are useful because you can see who is local and who is remote.
Behaviour Analytics has a few useful items for auditors. These are even more valuable if you know the teams and what to expect. The graphs help see unexpected outliers. In particular, the latent threat page is a good way of seeing who has highly privileged access to systems that they are not using. In fact, Latent Threat is probably the most important factor for an Auditor.
Under Device Access, we get a complete historical overall of all sessions and operations through PAM. This is filterable by user, device and even privilege level. You can see if there is a session recording available, session recording is defined in the profiles.
An invaluable tool when reviewing audit trails and understanding exactly what was being done in any particular session is Session Recording. Whether it’s an SSH, RDP or application session, the user interaction is recorded and stored depending on the organisation’s retention policies. These recordings can be used to investigate incidents, for training or as a record of activity by third-parties.
Reporting via SIEM
SIEM schemes are vital for an organisation to get a full overview of what is happening. Where PAM is concerned, if there is a privileged login to a system that has NOT got a matching event from the PAM system, then this is absolute proof of an unauthorised login. This is where SIEM analysis becomes deterministic rather than probabilistic. Therefore there is an emphasis in the PXM Platform for delivering to SIEM systems in CEF format, and even a connector for Elastic Stack.
Example of good access recorded in PAM and a SIEM tool
Example of bad access – no record in PAM
So, Latent Threat is about what could happen but hasn’t. If it didn’t happen, it wouldn’t be in a SIEM.
So, in conclusion, Osirium PAM delivers rich information to external SIEMs, gives reports that reveal over-privileged users and has session recording. That’s enough well-presented data to keep any Auditor happy.
If you’d like to know more — please get in touch.