Decision Maker

The Quest for Compliance

• By Don Jones
• 04/01/2010

Welcome to Redmond magazine's newest column, directed at IT decision makers and influencers. Each month, I'll look at some of today's trickiest IT problems, and help you devise strategies and tactics for addressing them in your organization. The idea is to help make you a smarter decision maker, better equipped to evaluate existing and new technologies for their ability to help meet your business needs.

I'm a Jeep fan. Right off the lot, they're great vehicles for many purposes: Cruising down a beach, bumping over a dirt road or guzzling some gas on the highway. But even though they're good all-purpose vehicles as they are, plenty of people find the need to customize them using third-party accessories: Winches, snowplows, rescue equipment, taller tires -- the list goes on and on. I can even recommend some good catalogs if you're a fellow owner.

Windows Server is actually kind of similar. It's a fantastic all-purpose computing platform, but nobody at Microsoft is crazy enough to believe that it can do everything that every business needs. That's exactly why third-party software vendors exist: to help fit specific business needs that are too specific to be included by Microsoft in the general server product. You'll hopefully understand that, when I say, "Windows native capabilities don't really meet the needs of companies facing common compliance requirements," I don't mean that in a negative sense. I'm not sure any of us would want Microsoft to build Windows Server for specific compliance scenarios, because there's no company in the world that's subject to every possible scenario.

When I say "compliance," by the way, I'm talking about industry and legislative security requirements like Sarbanes-Oxley (SOX), Payment Card Industry Data Security Standard (PCI DSS) and others such as the Health Insurance Portability and Accountability Act (HIPAA), the Gramm-Leach-Bliley Act, the Federal Information Security Management Act and more -- and that's just in the United States. I've been working with a half-dozen clients who are all dealing with compliance, most of them specifically concerned with PCI DSS. All of them started out trying to achieve compliance by using Windows native capabilities, and all of them eventually wound up on the phone with me when they couldn't get Windows to do exactly what they needed. All of them, so far, have learned that Windows wasn't designed to meet what is essentially a niche set of requirements, and so they've all had to learn about what capabilities would need to be provided by some kind of third-party, bolt-on solution that supplements Windows native capabilities.

If you find yourself in a similar situation, you'll be glad to know that almost all of the common industry and legislative rules boil down to an extremely similar set of technology features.

Build Islands
First, figure out which bits of data in your environment are actually subject to the compliance effort. For HIPAA, that'll be patient records; for PCI DSS, it'll be credit-card holder information like card numbers and billing addresses. Segregate that data into an "island," meaning a dedicated database, file server, SharePoint site or whatever. Doing so means you'll only have to deal with compliance within that island, rather than trying to bring every file server, database and whatnot into compliance. Eventually, you may want your whole enterprise to fall under the same security rules, but islands are an efficient way to get the necessary data protected quickly.

Access and Accountability
Windows is perfectly capable of securing your data properly: Windows native security is some of the most granular and flexible of any modern OS. However, what Windows can't do is easily show you who has access to what; nor can it show you who has had access to something in the past. For that, you're going to need a third-party access-management product. Vendors like Quest Software, NetWrix, CA and others play in this space. Look for tools that allow you to define security based on users' job titles or roles, and that also automatically enforce that security as well as reporting on changes to it. A single solution should cover security for Active Directory, SQL Server, Exchange Server (especially non-owner mailbox access), SharePoint, file servers and any place else that you keep sensitive data.

Securing the data, and being able to report on access permissions past and present, is half the battle. The other half is auditing what people actually do with their permissions. You might think that Windows native auditing would do the trick -- and you'd be half right. The native Windows event logs have two major issues: They're not centralized, and they're not tamperproof. Administrators can clear them too easily, leaving no trail. You need something that will centralize events in near-real time, copying them to a secure database that administrators can't wipe out on a whim. Microsoft Audit Collection Service is a good start; the native event forwarding isn't, simply because it's too difficult to take administrators out of the loop. Third parties offer agent-based and agentless event-collection products, some of which work with and enhance the native event logs. Other products eschew the native logs in favor of their own auditing capabilities. Do some product evaluations to find one you like.

You're really going to need a third-party solution, and grabbing one with the right capabilities will let you achieve compliance with relative ease. Look for one that has built-in reports specific to your compliance needs, such as SOX or PCI DSS -- you'll save time when you don't have to create reports. And don't blame Windows for not being all things to all people: The beauty of Windows is that you can bolt on additional capabilities that meet your specific needs.