Morey Haber, CTO at BeyondTrust, explains the four specific risks or costs tha organisations should consider before deciding if sudo (an open source package designed to provide privileged access included in many Linux distributions) is right for the organisation.
It is always a philosophical debate as to whether to use open source software in a regulated environment. In the case of ‘sudo’ – a package designed to provide privileged access included in many Linux distributions – the debate is whether it meets the requirements of an organisation and to what level it can be relied upon to deliver compliance information to auditors. While every organisation is different, there are four specific risks or costs that you should consider before deciding if sudo is right for your organisation.
Administrative costs
With sudo, you need to run a third-party automation management system (like CFEngine or Puppet) and third-party authentication modules on the box. Furthermore, if you plan to externalise the box at all, you are going to have to replace sudo with the new vendors’ version of sudo. So, you essentially end up maintaining sudo, a third-party management system, a third-party automation system and additionally, may have to replace it all if you want to authenticate against something external to the box.
Another complexity with sudo is that everything is local, meaning it can be extremely time-consuming to manage as environments grow. With sudo, you have to rely on local systems on the server to keep logs, rotate them, send them to an archival environment and ensure that no one is tampering with any of the other related subsystems. This can be a complex and time-consuming process.
Forensics and audit risks
Administrative costs aside, arguably a far greater risk is that of not being able to produce log data for forensic investigations.
There is currently no keystroke logging within sudo and since any logs of sudo activity are stored locally on servers, they can be tampered with by savvy administrators. It also lacks log integrity – no chain of custody on logs – meaning logs can’t be non-repudiated and therefore can’t be used in legal proceedings in most jurisdictions. This is a significant risk to organisations, especially in criminal prosecution, termination, or other disciplinary actions.
Another concern with sudo is that the change management processes can’t be verified. Best practices call for review of change records, and validation that what was performed during the change matches the implementation that was proposed. ITIL and other security frameworks require validation of change management practices, something that sudo cannot do.
Furthermore, there is no session recording with sudo. Session logs are one of the best forensic tools available for investigating what happened on servers. It’s human nature that people tend to be more cautious when they know they can be watched. Finally, there is no segregation of duties with sudo. Most security and compliance frameworks require true separation of duties and using a tool such as sudo just “skins” over the segregation of duties aspect.
All of these deficiencies – lack of log integrity, lack of session monitoring, no change management – introduces risk when organisations must prove compliance or investigate anomalies.
Business continuity risks
By virtue of being open source, there is no indemnification if there is a critical error. Also, there is no rollback with sudo, so there is always the chance that mistakes will bring an entire system down with no one to call for support. Sure, it is possible to centralise sudo through a third-party tool such as Puppet or CFEngine, but you still end up managing multiple files across multiple groups of systems manually (or managed as one huge policy). With this approach, there is greater risk that mistakes will break every system at once.
Lack of enterprise support
Another risk associated with being open source is that there is no official service level for when packages must be updated to respond to identified security flaws, or vulnerabilities. Over the past several years, there have been a number of vulnerabilities discovered in sudo that took as many as three years to patch.
Benefits of using a commercial solution
Although they come at a higher cost than free open source solutions, commercial solutions provide an effective way to mitigate the general issues related to sudo. Commercial solutions usually have a regular release cycle and can typically deliver patches, in response to vulnerabilities, in hours or days from the time the vulnerability is reported.
These solutions provide event logging on separate infrastructure that is inaccessible to privileged users which eliminates the possibility of log tampering. They also provide strong, centralised policy controls that are managed within an infrastructure separate from systems under management; this eliminates the possibility of rogue changes to privileged access policies in server environments. Strong policy control also moves security posture from ‘Respond’ to ‘Prevent’, and advanced features provide the ability to integrate with other enterprise tools, and conditionally alert when privileged access sessions begin, or end.
Conclusion
For organisations that are serious about incorporating a strong privileged access management into their security program, there is no question that a commercial product is better suited than an open source offering such as sudo. Eliminating the possibility of malicious behaviour using strong controls, centralised log file collection and centralised policy management is far better than relying on questionable, difficult to manage controls delivered within sudo. In calculating an acceptable level of risk to your tier-1 Unix and Linux systems, all of these costs and benefits must be considered. If in doubt, remember the old adage – there is no such thing as a free lunch.
