Head of Product Line, CryptoAuditor. Jussi Valkiainen is the head of product line for CryptoAuditor. He has worked at SSH Communications Security for over ten years and has held various positions in R&D, Marketing, and Product Management with increasing responsibility. Enthusiastic about user-centered design, Jussi works with Global 2000 customers to solve their cybersecurity needs and make it easy for security officers to achieve security and compliance. Prior to joining SSH, he worked at Nokia, and wrote user documentation for microwave radios used in GSM and 3G networks. Jussi holds a Master of Science in Engineering from Helsinki University of Technology (Aalto University).
So you have a problem with privileged access? Whether it is your own employees accessing critical production systems on a daily basis, or third-party system vendors who need occasional access to maintain the systems, or whether it is machine identities that use privileged accounts for running automated jobs, the underlying problem is the same: Privileged accounts, exactly because of their higher privileges, present a risk and the access to them needs to be controlled and monitored. This is also mandated by several laws and industry regulations.
Depending on your environment and the accumulated legacy, you may be approaching this problem from two completely different angles:
1. You have already given unrestricted privileged access to the users, and now you need to take that under control with minimal impact to existing processes and workflows.
2. Your users do not have privileged access yet, maybe because you are deploying a completely new environment, and you need a way to grant the access securely yet easily.
In both cases, you probably have some requirements for the solution. Depending on your use case and the regulations you need to comply with, you may want to:
Log and record access to privileged accounts for accountability and later forensics.
Control access to shared accounts by controlling the shared account passwords or SSH keys.
Restrict access based on protocol or channel.
Control commands or actions an administrator can execute in real-time.
Enforce dual control for approving and monitoring privileged connections (also called 4-eyes principle).
Establish a workflow for requesting access to privileged accounts.
Gather analytics on the usage of privileged accounts and provide that visibility to Security Information and Event Management (SIEM) systems.
For addressing these requirements, you have a selection of commercial tools to choose from, or you can even choose to build your own tool.
Looking into commercial solutions, there are highly variable approaches how to meet the requirements. These approaches can be divided roughly into three categories:
Agent-based solutions: An agent component is installed on every target host. The agent is responsible for recording and restricting the commands executed on the target host. Many of these solutions are comprehensive, but extremely time-consuming to deploy and configure.
Jump-host/gateway-based solutions: There is a custom gateway or a jump host, where the user must first log in, and only from that host the user will get access to the target host and the target account. These solutions may be combined with an agent on the target host. They require the users to change their tools and workflows, and can, in some cases, limit the users’ ability to carry out their work normally.
Network-based solutions: The connections to the target hosts are routed through a network device that captures the connections transparently. The target account credentials are inserted into the connection without disclosing them to the users, and the sessions are recorded. The users do not have to change the tools they use, nor does anything need to be changed on the target hosts. A network-based solution is easier to set up compared to a gateway or an agent-based solution. The setup time is reduced even by a factor of ten. Network-based solutions also offer much higher performance than the other solutions. On the other hand, they do not offer as granular control on the privileges on the target hosts as agent-based solutions.
If deploying the solution is complex for your IT security team, it may leave gaps in your defense. Even though it seems like a good idea to enforce strict rules for allowed commands, can you in reality maintain the ruleset? At least you need to allocate personnel to do that. On the other hand, if using the solution is too complex for the users, it will most certainly lead to productivity loss, and may also lead them to seek (unauthorized) workarounds.
SSH communications Security provides a solution called CryptoAuditor to address the privileged access problem. CryptoAuditor is a network-based, inline traffic monitor that decrypts and records the activities of the privileged users without interfering with their normal workflow. There are no agents to deploy; it works regardless of what devices users connect with and what they connect to.
CryptoAuditor is more than a passive monitor; it provides identity-based policy controls that specify where the privileged users can go in your network and which accounts they can access. CryptoAuditor integrates with your Identity Management (IdM) systems, for example Microsoft Active Directory (AD), and stores the target host passwords and keys in a secure vault, inaccessible to the privileged users. It also integrates with Data Leakage Prevention (DLP), Intrusion Detection (IDS), and SIEM systems, enabling real-time detection and prevention of data loss.
CryptoAuditor is truly a plug-and-play solution for privileged access management. By choosing it you will avoid the pain associated with many other solutions.
For more information on CryptoAuditor, please see our datasheet. An evaluation version is available upon request on VMware, Hyper-V, or Amazon EC2 as Amazon Machine Image (AMI).