Four hidden costs and cyber security risks of sudo

By Morey Haber, chief technology officer, beyondtrust

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 organization, and to what level it can be relied upon to deliver compliance information to auditors. While every organization is different, there are four specific risks/costs that you should consider before deciding if sudo is right for your organization.

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 externalize 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 &  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. Sudo 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 organizations, 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 a 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 log integrity, lack of session monitoring, no change management—introduces risk when organizations 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 and the entire system down with no one to call for support. Sure, it is possible to centralize 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 a 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 (CVE-2013-2776, CVE- 2013-2777, CVE-2013-1776 ).

Unix and Linux systems present high-value targets for external attackers and malicious insiders. Expect to be breached if you share accounts,  provide unfettered root access, or let files and sessions go unmonitored. Gaining root or other privileged credentials makes it easy for attackers to fly under the radar and access sensitive systems and data. And as we have reviewed, sudo isn’t going to help.

In balancing costs vs. An acceptable level of risk to your Unix and Linux environment, consider these 10 questions:

1. How much time are Unix/Linux admins spending just trying to keep up? Can your organization benefit from automation?
2. Are you able to keep up with the different platform and version changes to your Unix/Linux systems?
3. As you grow and more hosts are added, how much more time will admins need to keep up with policy? Is adding personnel an option?
4. What about consistency across systems? Modifying individual sudoers files with multiple admins makes that very Wouldn’t systems become siloed if not consistently managed?
5. What happens when you bring in new or different Linux or Unix platforms? How will that complicate the management of the environment?
6. How critical is it for compliance or legal purposes to know whether a policy file or

Log has been tampered with?

7. Do you have a way to verify that the sudoers file hasn’t been modified without permission?
8. How do you know what admins actually did once they became root? Do you have a command history for their activity?
9. What would it cost the business if a mission-critical Unix/Linux host goes down? With sudo, how quickly could the team troubleshoot and fix the problem?
10. Can you demonstrate to the board that you have a backup if there is a significant outage?

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, centralized 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 organizations that are serious about incorporating 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 behavior using strong controls, centralized log file collection, and centralized 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

About the Author

With more than 20 years of IT industry experience and author of Privileged Attack Vectors, Mr.  Haber joined beyond trust in 2012 as a part of the eeye Digital Security acquisition.  He currently oversees beyondtrust technology for both vulnerability and privileged access management solutions. In 2004, Mr. Haber joined eeye as the Director of Security Engineering and was responsible for strategic business discussions and vulnerability management architectures in Fortune 500 clients. Prior to eeye, he was a Development Manager for Computer Associates, Inc. (CA), responsible for new product beta cycles and named customer accounts. Mr. Haber began his career as a Reliability and Maintainability Engineer for a government contractor building flight and training Simulators. He earned a Bachelors of Science in Electrical Engineering from the State University of New York at Stony Brook.