How Secure are Your Systems?

March 7, 2011
80 Views

 

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).

You may be interested

Care On The Road: How Telemedicine Can Reach Truck Drivers
Mobile Health
13 views
Mobile Health
13 views

Care On The Road: How Telemedicine Can Reach Truck Drivers

Larry Alton - August 21, 2017

Telemedicine is considered a powerful tool for individuals living in rural areas, far from adequate services or in need of…

Where Is The Balance? Pushing Back Against Consumer Health Tech
eHealth
3 views
eHealth
3 views

Where Is The Balance? Pushing Back Against Consumer Health Tech

Larry Alton - August 18, 2017

When Republican Congressman Jason Chaffetz glibly remarked that Americans struggling to afford insurance should choose between that and their smartphones,…

What to Look for in Patient Solutions Software
eHealth
365 views
eHealth
365 views

What to Look for in Patient Solutions Software

Robert Cordray - August 17, 2017

The medical sector is one area where technology has had a significant impact, largely by providing tools that simplify many…