Hello, and welcome, everyone, to the deep dive session on alerting, analytics, and working with your PAM data in general. This will include controlling the activities within the session and also looking at what can trigger alerts or other proactive actions while finishing off with a demonstration on the previously discussed topics. With this know-how, we want to help you to be able to address security needs in a proactive instead of a reactive manner and to show you how well Safeguard integrates into an enterprise environment.
Safeguard for Privileged Sessions is delivered as a hardened appliance that is built upon a proxy technology. It is deployed between the client and the server, thus ensuring that a direct communication is not possible, because the clients, as displayed visually, are communicating with the session appliance, and the session appliance opens up the rest of the communication to the most critical systems of you or your customers. This is something you can imagine as a friendly man-in-the-middle.
This technology has multiple benefits. First of all, it helps the user acceptance by being client agnostic. This means that every client is allowed to be used as long as the communication goes through one of the supported protocols. And also, on the service side, you don't have to install any agents, which does not only benefit you from an operational standpoint, which saves you from deploying, maintaining, and updating such agents, but it's also useful from a security standpoint, because if the auditing of the systems depends on the auditor's systems, that is a security risk and poses trustworthiness questions, in any case.
Apart from being within the connection, I want to show you the five major features of Safeguard for Privileged Sessions. Safeguard for Privileged Sessions offers you a toolset to ensure that connections to your mostly critical systems are as secure as possible, even though we are talking about highly-privileged users. The first, and most important, one is the transparency which is offered by recording every user activity within the remote sessions. And this recording includes the complete communication between the client and the server, stored in a compressed tamper-proof binary format which can be encrypted-- even with certificate pairs-- so that both private keys need to be available to make the recorded data visible. And it can be also digitally signed or timestamped by an external timestamping authority.
Apart from recording the user's activity, Safeguard is also able to monitor what's happening within the session. This includes, only the right commands executed, are only the right actions happening? And it also includes an analysis of the user's behavior with the analytics component. We will talk about the monitoring options in a second.
The best auditing solution is only worth as much sense you can make out of the data. So with Safeguard for Privileged Sessions, we built in an easy replay method which offers you a video-like replay on all the session activity, which is renderable as a video. Everything else can get exported as a pcap, or transferred files can also easily be exported right from the Safeguard Desktop Player. But in general, the video-like replay offers you a way to easily understand what your privileged users are doing without the need of diving deep into a capture of the network data.
But how do you decide what to look at-- what replay? For the decision making process of what to look at more closely, we included a search interface where you can easily search for the usual suspects-- like username, like connection time, like protocol-- but also for anything which appeared on the session in a free-text form.
You're probably thinking right now-- free-text form? But there were also graphical protocols on the previous slide, where we looked at what protocols Safeguard can deal with. Yes, you are correct. And we solved this challenge by including an OCR-- an optical character recognition engine-- right into Safeguard to scan even the graphical recordings and make it available for an easy search.
And of course, these search results can also be included in the reporting module of Safeguard, which can generate it on a daily, weekly, monthly basis. And it includes not only details about your PAM deployment, but also the big picture about the user's activities. And this can be also used to decide where to drill down more closely-- where you need to put your focus at.
I promised you that we will have a deeper look into the monitoring and controlling options of Safeguard-- first of all, with a look at the granular access control capabilities. This means that you can control, even on a building-block level, which user groups, at which time, are allowed to connect to the systems and whether you want to record it or not. So with that, you can achieve a really deep granularity without sacrificing the comfort of the proxy-based approach.
The next major topic will be the real-time preventive capabilities of Safeguard. SPS is able to block and alert you on the command level in text-based protocols or on the application level in graphical protocols. It does that by scanning the commands or screen content in SSH or Telnet, or by performing a real-time OCR on the window titles in graphical protocols like RDP, ICA, or VNC. If there is a match, you can either generate an extra log entry, which you can forward to your SIEM or your log management tool and trigger actions there, or you can directly get alerted via email or SNMP by SPS. And in the worst-case scenario, you are able to terminate the session before real damage occurs.
Last, but not least, let's talk about analytics. Analytics is important, because this component of Safeguard enables you to avoid dealing with rules but instead looking at the user's behavior and compare that to some already established historical data. The behavior analytics module of Safeguard collects old footprints of the privileged users that can be collected, be it based on the proxy logs, be it based on the session activity itself. And once this has been collected, it's building up the baseline based on machine learning, so each algorithm defines what the normal baseline-- the normal behavior-- looks for that user.
And once these baselines exist, it usually takes some time for learn, depending on how active the privileged users are. Then, it can identify unusual events and risky behavior-- anomalies-- in as close to real time as possible, thus helping you to find the needle in the haystack-- to be prepared for attacks that you don't even know about today.
You probably look at this slide and think, what has a keyboard has to do with analytics? What does the phrase "hello world" have to do with this PAM session? We are not at a developer 101 deep dive. Trust me, the biometrics is really important to be looked at in detail. Because we realized that there are two major situations-- apart from the admin with a hangover who had one beer too many the evening before-- where the biometrical footprint tells an important story.
First one is the pretty obvious one-- identity theft. If someone manages to steal my credentials to impersonate me, he will still never be able to impersonate my biometrical footprint. That's the obvious case. But the other situation where biometrics is important is if I want to do something with my legitimate privileges-- with my legitimate access-- which I'm not supposed to do, especially if I know that my activities are recorded, and everything I do might be reviewed by someone. I want to disappear as quickly as possible and leave as least traces as possible. And this will be instantly visible in the matter of how I type or how I interact with the mouse.
Oftentimes, when we're talking about analytics, one of the first questions we are asked is, what about false positives? Because people know the standard ways of a rule-based ruleset, where just because someone logs in a bit earlier than he should, it instantly generates an action task for the security team to review. This is not the case with the intelligent machine-based analysis of Safeguard. Because Safeguard looks at the user's behavior in context, the overall session score gets generated based on the individual scores of the different algorithms. And as a result, just because one aspect of the session is unusual, if everything else checks out, then the overall score will be relatively low.
Imagine a time when we will be able to travel again, and you are spending three weeks in a different time zone, and once you return to work, you log in at 4 AM. In a ruleset-based alerting system, you would have a false positive. But if you access the same systems, type in the same way, issue the same commands-- just because the login time is earlier than normal, and just because the login time algorithm has a higher score, because it's unusual-- if everything else gives a low score, the overall score most probably won't reach the threshold for an action item to be created with the security team.
And now, let's get through demonstration part of this deep dive session. In this recording, we will see that the attacker will be opening up an SSH session using a hijacked account, and he will do some activities while the security team is trying to figure out what he's doing. So he logs in using the account Bob, and then checks if he is the only user on the system. And indeed, he is the only one who is logged in as root. Then, he is looking for a logging engine, and since he got the information that this is a database server, he is trying to log into MySQL database, and he is successful with that.
Instantly, as soon as he discovers the ecommerce table, he will check the details of that. And you see, in parallel, in the Safeguard Splunk app, the number of critical sessions has been risen, because the score of the session is that high. You see that the hacker finds user data, credit card data, email addresses, and luckily, this data is protected by Safeguard. And you'll see instantly as the security team goes on to the session details that the different algorithms are showing highly unusual activities.
So the security guy, since he knows that Safeguard protects the critical data, because he has configured in that way-- he wants to understand the activities of the hackers better, and therefore decides to follow the activities in real time. So now, you will see, in parallel, what the attacker is doing and what the security team sees.
So as soon as the attacker tries to dump the data-- which, on its own, isn't that bad, as long as he's unable to copy it-- he will try to understand which data the attacker wants to copy and where to. And the scp command is blocked by the real-time preventive capabilities of Safeguard, thus ensuring that the attacker is never able to copy the captured data outside of the system, and he's unable to continue his work.
If the security team will look into the details, you see the individual scores of the algorithms that, together, create the overall score and help to better understand what was unusual-- what caused this really high score. And combine that with the SIEM integration, the alerting, and the real-time preventive capabilities-- you have an overall secure system when it comes to the activities in your infrastructure with your privileged accounts.
Thank you very much for your attention today. I really hope you enjoyed the content of this session, and I really hope that you have an amazing time at vUNITE 2020.
16:21
