How to audit fat clients?
06-08-2018 08:39 AM
Hi. What if business processes suppose admins to connect to target systems with fat clients and Web Apps. What are the options to record their actions? So far I only have in mind the idea of a dedicated gateway server where all those fat clients are installed and from which admins will have to work.
Admin Desktop (posible accesing from internet) -> CPS -> Gateway Server with all fat clients -> Target Systems.
Are there some more elegant ways?
06-11-2018 12:43 AM
May we have more information on what OS we are working with?
For Windows, we do have screen auditing for each user that login to the machine.
Also are you looking for auditing activity from the targeted server?
Please keep us posted. Thank you!
06-11-2018 09:23 AM
there are two main use cases. first is when admins from local network using fat clients to manage infrastructure (e.g. SCCM, SCOM, Citrix). Si in this case we will have either install agents on their working desktops. second case is a bit harder. Remote users over VPN. and they use Fat clients from their remote hosts to manage target infrastrucutre directly. So here is where the main issue. we cannot uinstall agents on remote hosts. So the onnly options i see it use some kind of RDP gateway. where agent will record.
06-15-2018 01:03 AM
Unfortunately, I don't believe we can have auditing enable on RDP gateway like you mentioned. As we do require agent to be installed on the remote host for auditing to work. Therefore, I believe this would be a RFE for our Dev and PM team to work on.
Hope it helps!
06-15-2018 05:58 AM
Let me elaborate to complement what @IChan means. Let's focus on your basic requirement:
Hi. What if business processes suppose admins to connect to target systems with fat clients and Web Apps.
What are the options to record their actions?
So far I only have in mind the idea of a dedicated gateway server where all those fat clients
are installed and from which admins will have to work. Kind of: Admin Desktop (posible accesing from internet) -> CPS -> Gateway Server with all fat clients
-> Target Systems. Are there some more elegant ways?
When auditing Desktop apps (including the Browser), you have several options with Centrify:
- Gateway-based auditing: Exactly what you described above. It's the same paradigm as password vaults and their ability to provide "jump-box" access. With Centrify, the user visits the CPS portal, accesses a "Secure Workstation or Server" that has all the tooling, and with our service you can get proctored access (e.g. Watch and Terminate) and Recording (via DirectAudit).
This is a perfectly-valid design choice; however, we always have to look at things from a security perspective. The drawback of this design is that it will work as long as:
a) End users are 'disciplined' about accessing the Gateway server (training, cognitive). The issue here is that end users won't always 'do the right thing' because of factors like: accessibility, performance, and preference. The gateway can always be bypassed, the user (if privileged) can install the fat client in their own systems too.
b) End-users may hate the vault product. This is exactly what we hear about some of our competitors (We respect you, but we're coming after you, so keep buying other companies; it's not a question of "if" but "when" we'll take them over technology wise, so keep spreading FUD - we have you where we wanted you ).
c) The "gateway" approach may not even be available - like in a disaster recovery scenario. You must bypass the gateway if there's an infrastructure event that impairs access to the gateway.
The biggest positives about this approach is that it's relatively easy to deploy, and dependign on licensing, it's the most cost-effective way to get this done.
We have work to do! We recognize that today this may not be very optimal and we have capabilities in the pipeline that will make us shine above our competitors because we not only we'll be mastering 'fat clients', but web and mobile apps too. Keep tuned this summer.
- Client-based auditing: In this scenario you use DirectAudit in all systems in scope. While this approach is the most robust one (especially combining it with the approach above), it can be expensive in two fronts (licensing and back-end infrastructure); this is because you have to have DA licenses for all the audited systems and a very robust back-end infrastructure to support the storage, distributed infrastructure and database for the audited sessions.
So, let's recap:
a) For your remote users, your design scenario is correct. I'd add Identity Assurance controls like MFA or conditional access rules to provide additional security controls. This experience will be improved this summer/early fall in CPS.
b) For your local users, note that you can use "selective auditing" which is the combination of a non-audited role (with the login right) and an audited role that contains the desktop or Apps that they want to run with privilege.
This will allow screen auditing only to be turned on when the user is performing tasks with privilege.
I will keep track of this thread and when we are ready to announce some news, I'll update it. Note that we have releases every month.
06-15-2018 07:14 AM
If we have Centrify agent installed on target systems, could we use Direct Authorize Zones feature to limit number of hosts from which one can connect to them? not only RDP, but with any "fat-tool"
06-26-2018 07:49 AM
Let's refine your statement:
If youhave Centrify agent installed on target systems, you can use Direct Authorize Zones feature to limit who can access a system (regardless of their power - you can even stop a Domain Admin).
Notice that the "number of hosts" is more like a network concept. Our zone controls are identity based (more about the who, NOT from "where" or from "which client";
Those controls, although typically recommended by traditional vault vendors, utltimately add complexity and aren't very practical in some scenarios like availability assurance. For example: how can you break/fix a system if it only allows connectivity from some hosts. What if those hosts aren't available as part of the outage.
Another issue with applications is that each app may have a different connectivity method or protocol. We are tied to the Windows, UNIX or Linux methods. In UNIX/Linux, if the app is PAM-enabled, you can control it with DZ, but that's not the case on Windows.
In the next few months you will be pleasantly surprised on some of the changes we have cooking.