Since releasing our Privileged Behaviour Management module, we’ve had plenty of great customer feedback. The module can be used to show aspects of business behaviour that highlight which parts of your operations are a good case for Privileged Task Automation.
In this blog we’ll show how driving the data streams that our PxM Platform creates through Elastic Stack is a great way of building audit and data visualisation. You can also check out the How-To video for more information.
Different strokes for different folks
It’s obvious really, but different customers want different types of information. Whilst security information is a common factor, it’s all the business-related aspects that differ. For example, Managed (Security) Service Provider customers (M(S)SP’s) have a completely different view to large end users. So far it seems that the mid-range market is happy with the reports generated by the PxM Platform:
|Perceived Importance||M(S)SP||Large End User||Banking and Insurance|
|Identity Security (Own Staff)||100||100||100|
|Identity Security (Client Staff)||80||0||0|
|Outsourcer Security||90||100||n/a (tends to be 1:1 supervision)|
|Who used what role||20||50||100|
|Who ran what task||5 (although many tasks)||20||100|
|Most popular task||100||50||20|
|Who has long-running sessions||20||50||100|
|Who accessed a ‘sensitive’ system||80||100||100 (or more than!)|
|Where did an identity come from||5||70||100|
Of course, all of these have to be considered along with data volume. M(S)SP’s have staggering volumes of data, whilst Banking customers quite often have a small data set that they care about very much.
Where all this data is kept and how it is processed is important. The PxM Platform is keeping people and their endpoints separated from passwords by creating proxy sessions. A typical deployment may see an Osirium PxM server handling 500+ proxied sessions. Other than for security reasons, these sessions should not be interrupted or impeded by slow analytical operations.
Internally, the PxM Platform code uses a multiple priority queue system to ensure that the most urgent and important tasks complete first. Elastic Stack can be thought of as an open source SIEM. We’ve got one step further and made a specific Log Stash interface for Osirium, which will create a table of devices and identities of people that have accessed them. Using a heat map style visualisation we get:
This shows who is working on what; because we know what jobs our people do we can quickly see that everything is in order. For example, we can see that our ‘OpenVPN Server’ is taking a lot to manage. In our case, we know that this is down to new starters and optimising routes.
Below is the long-running session display:
In this example, the user ‘Andy Harris’ is the worst culprit. Once again business knowledge is important. Our previous telecoms provider was having issues with dropped IAX calls, not a good situation for our internal sales team! In the period above we were trialling two different suppliers. The user ‘Andy Harris’ had pages open monitoring each of the trunks and dealing with the inevitable “why is this trunk using this CallerID”. (In these TPS and GDPR days, your CallerID is important, and providers go to great lengths to ensure that you can only set CallerIDs that belong to your organisation).
The long-running session display above took about 10 seconds to render on an Elastic Stack system running in a meager resource pool. It examined data over the last 15 days and pulled together a lot of session data related to HTTPS. HTTP/HTTPS is an atomic protocol and therefore a long-running session has to be determined by events such as ‘login’ and ‘logout’.
The beauty of Elastic Stack is that it is under your control, it runs in a separate VM in a separate resource pool. So if you are an M(S)SP, you can give it plenty of resources and get it to reason over years worth of data. If you’re an end-user or in Banking, you can allocate modest resource. Of course, something to bear in mind is that big data means big storage. We generate about 1GB a day across our UK development team (which includes Product Support and DevOps).
Our development team recently got it’s first dedicated data scientist. He is already making great strides in our use of Elastic Stack. Watch this space for an update video in the coming months…