How Secure are Your Systems?

I spend a lot of time talking with CEOs, CIOs, and other senior executives about what HIPAA security and HITECH privacy policies really mean. I hear a lot of naive talk about how systems are secure because “we use SSL encryption” or “we’re secure because we have a firewall”. Anybody who’s been security and privacy work for more than a few months would know how false those statements are.

I spend a lot of time talking with CEOs, CIOs, and other senior executives about what HIPAA security and HITECH privacy policies really mean. I hear a lot of naive talk about how systems are secure because “we use SSL encryption” or “we’re secure because we have a firewall”. Anybody who’s been security and privacy work for more than a few months would know how false those statements are.

Security (whether it’s for HIPAA, HITECH, or banks) starts with secure operating systems, databases, and other infrastructure elements like proxies and firewalls and the depth of security is really controlled by system admins. Your systems are only as secure as the servers and firewalls they are sitting on so you have to ask yourself: “what have my system admins and security people done to secure my infrastructure?”.

Let’s start with a relatively simple question that all CIOs should know the answer to — who has access to root permissions on UNIX / Linux server or “Administration” role in a Windows server across the enterprise? If you don’t have an easy answer  to that, then no amount of paper policy will make you HIPAA compliant.

All servers require a super user or privileged account to do some of the most important activities like installing applications, creating file systems, and other mundane but important and sometimes dangerous tasks. If you have a policy of sharing a single account (like root in Linux or “Administrator” in Windows) you’ve got serious security flaws. These days proxies and firewalls are often Linux servers as well so your policies about root access are even more important.

One thing security professionals like me suggest is to never allow root logins (or Administrator logins). Instead, use security wrapping tools and policy enforcement where a person logs in using their own credentials and then can do specific actions which are logged thoroughly.

Windows Server 2008 on up has this policy-style security built-in but on Linux/UNIX you should make sure that you use sudo. This past week we saw the release of Sudo 1.8, an important upgrade which brings pluggable policies to this venerable security utility. Here’s a snippet from the announcements at ServerWatch.com:

This weekend at SCALE, Todd Miller introduced Sudo 1.8, a major update that brings “enterprise” features to Sudo that put it on par with proprietary alternatives.

We’re all familiar with the venerable utility Sudo, but its feature set hasn’t kept up with what many companies want for root access control. Specifically, Sudo has lacked support for policy plugins and advanced logging features. There have been a number of proprietary tools that either replace or enhance Sudo for root access control (RAC). But who wants to have to buy an add-on if you can get the features you need as part of the native toolset that comes with your *nix?

Sudo 1.8 brings a plugin architecture, with two major types of plugins: policy and I/O logging plugins.

The policy plugins are designed to control who can do what on the system. You’re probably used to controlling Sudo via the /etc/sudoers. If this works for you, nothing changes. You’ll still be able to use visudo to edit the file and add users, and set policies the way you always have. Otherwise, it’s now possible to write new policies to comply with things like SOX and HIPAA, or tie Sudo into Active Directory for companies that have standardized on that. Sudo will accept only one policy plugin at a time.

The I/O plugins control logging of sessions that take place using Sudo. Sudo has had a “replay” command since 1.7.3, but this release brings much more functionality. Unlike the policy plugin, Sudo can support multiple plugins for I/O, so you could use different I/O policies depending on which users are running Sudo (for example). You can now not only see what commands have been run with Sudo, but also actually replay a session in its entirety if need be (and if you want to log that much).