The Ponemon Institute and Forrester have both published studies that have raised a lot of attention, and questioned the security of SSH deployments, and both focus on the implementation practices and procedures. The ugly truth is that this vital tool is often little considered in the security plans of many enterprises.
The focus of both of these studies is on SSH key management. This can certainly be a very important topic, especially with a standard/default SSH implementation: if you need to use SSH user-keys for authentication it becomes enabled for all accounts that have access to the system.
Many of our customers do not want people-users to use SSH keys, having deployed OTP solutions for authentication, but require SSH user-keys for application-to-application connections that are automated. Others use SSH keys to resolve the issue of weak passwords over the network.
The big problem here is that the access control, and therefore the system security, is based on local configuration files. SSH user-keys, once enabled for authentication, become an available method for all users allowed access. If a user public-key is on the local system, the local system will allow it to be used for authentication.
This becomes a de-centralized security and administration nightmare.
A solution often proposed is to look everywhere, and on every system, to see where they are and then map how they _could_ be used. Then, take the reams of discovery data and map it against where private keys could initiate connections to systems that have the public keys where they could work.
BoKS solves this problem in a very different way.
Instead of discover-and-remediate, BoKS takes a pro-active approach, allowing the administrator who can use SSH user-key authentication on a system. It even goes so far as to allow the administrator to easily define from-where they key can be used, when it can be used, and what for (SSH, SCP, with tunneling support or without) and more. And to BoKS, user-keys are just another authentication method; these rules can be applied to any supported authentication like passwords or SecurID.
Access control management scratches the surface of SSH security; what about what someone can do once they get there?
Contact us for more information about how BoKS can improve your security, solve your compliance issues, and reduce the cost of administering your Unix/Linux estate.
You may also be interested in: Best Practices for Unix/Linux Privileged Identity and Access Management
FoxT Access Management & Governance solutions complement your existing technologies by adding granular control and enforcement of authentication and authorization policies for both privileged and end users. www.foxt.com/boks