When Dell Software recently surveyed IT professionals responsible for compliance with federal mandates, the results showed that over half of them struggle with these tasks, at least in part because of a reactive stance. Tim Sedlack, senior product manager for Dell Software, after studying the survey results, created a list of tips to help IT organizations take a more proactive approach and avoid mistakes others have made in maintaining compliance and responding to audit inquiries.
The full list, “Tips for Staying Compliant with Federal Mandates,” starts with taking inventory of accounts and access, and then builds a strategy for continuous compliance on that foundation.
I followed up with Sedlack about a couple of points, and he provided very specific examples to help IT groups create their definitions and reduce workloads.
For example, providing auditors with only what they ask for sounds simple, but often turns into a complex set of tasks. First, you must know or clarify what is being requested, and then double-check what you are providing. Does it include additional information that might cause further digging? Don’t cut your own throat, advises Sedlack:
“In this case, you want to ask clarifying questions whenever possible. Is the auditor looking for specific dates, accounts or other resources? You also want to ensure that you do limit the data to exactly what’s asked for – specific groups, users or resources, for the specified time period. Data presented may contain MORE information than the auditor knows is retained in your logs (or third-party auditing tool). Some products provide data such as before and after values of changes; these are great for operational reasons, but extraneous and could be problematic in an audit scenario.”
Sedlack described an instance when one organization gave away more than it had to:
“One situation that an end user shared with me: When the auditors asked for changes to critical groups (who has been added or removed, or where privileges have been changed), the client provided a larger data set with all group changes. What should have happened here is the compliance team should have asked for clarification on the auditors’ definition of what “critical groups” are. In this case, they were looking for key AD groups (like Domain Administrators and Enterprise Administrators), but were give much more data than they originally expected.”
Another area where work can be reduced for the compliance team is in eliminating unnecessary alerts on events and changes that are not actionable. Sedlack had specific advice on how to avoid piling on too many alerts:
“The question I usually ask is, ‘would you mind getting out of bed to address this change?’ I have had clients start by alerting on everything and try to weed out the ones that don’t matter – that just doesn’t work (in my opinion). As you’re combing through things, you’re bound to miss something important and it’s real work to turn enough off until you get to something ‘manageable.’ A good case for NOT alerting is ‘failed access attempt,’ especially to systems that aren’t under regulatory control. I also see people alert on automatic DNS changes, when you can’t really do much (except be aware). It will vary, based on each client’s needs and abilities, but if you remember that first question, it should provide some initial guidance.”