The Secret to Server Compliance (Hint: It's Not Sudo)

Having spent many years in the software security space, I’m often reminded of how often the word security is paired with compliance – or even interchanged, as if they’re the same thing. Security and compliance are, of course, different things. Security is about ensuring the safety of a company’s assets, protecting sensitive data, ensuring that it doesn’t fall in the wrong hands. Compliance is about adhering to internal and external policies and controls put in place to ensure that companies are following and meeting governance requirements. Such requirements often circle right back to security: demonstrating that controls are in place to prevent a catastrophic loss. Or, as some put it, compliance equates to proving that security measures are in place and are being followed. And that proof is typically in the form of a passed audit. So, using IT server infrastructure as an example, achieving compliance typically means proving that an IT manager knows who has access to which servers, what permissions users have on each server (particularly privileged users), how such user policies are enforced, and when and why any of these policies change. IT organizations must show that they have controls in place that they routinely test, and failed tests must result in a remediation plan. IT organizations generally feel they have taken the necessary steps to achieve compliance if they’ve adopted a “least privilege” strategy (ensuring that employees have access only to those tasks required to do their jobs and nothing beyond) and are following basic best practices such as ensuring that root passwords are not disclosed. And the belief by some is that the use of sudo meets these requirements. Not so fast. Plenty of evidence exists to show that the audit community is changing its view on sudo. True, sudoer files are user policies defining what users can do on certain servers and usually prohibit the disclosure of the root password. So how is that not employing a least privilege strategy and following best practices? The reason is the difficulty in proving compliance. Seeing how 98% of data breaches come from servers and half of these are caused by insiders, auditors can no longer take an IT manager’s word that their use of sudo is secure and effective. And when the proof is asked for – the record of routine sudoer file privilege checks, the explanation behind why a privilege was added and why, the report showing who has access to what – well, that’s where it all falls apart. The proof, more often than not, just isn’t there. Sudo is just too cumbersome to manage effectively over a large number of servers and there just isn’t enough oversight to prevent tampering or risky policy management. At the end of the day, the secret to server compliance is not really a secret at all. Make the decision to migrate away from sudo to an enterprise-grade privilege identity management system such as PowerBroker Servers and you’ll have all the compliance proof you need.