Things just continue to change. Actually, IT is always changing and always will.

That is part of the fascination and draw for me, and one of the main

reasons I chose this field. Right now,

you’re probably wishing I would pick a topic and run with it; and so I

will.

For the past several years, I’ve been watching varying

levels of user access to electronic data become further and further

scrutinized. The scrutiny comes from IT

managers and, ultimately, CIOs who are responsible for ensuring only those who

need access to sensitive private data have access to it. The direction and push to control who needs

access to what and why, comes from internal and external audits to maintain

compliance with regulatory laws such as Sarbanes-Oxley (SOX) and HIPAA.

Controlling user access to electronic data means a lot of different

things to IT staff working in the trenches every day. It means setting up the proper security

controls when installing new systems, and not leaving the default Windows

permissions to shared folders. Leaving

the Everyone group with full access to a folder does not constitute a good

security plan. Setting up an Active

Directory Security Group for a new system and then adding only those users who

need to use the application as part of their job is a good start. If they don’t need Modify rights to the

directory, only give them Read rights.

These are common sense rules, but it’s amazing how many IT pros get lazy

and leave the default permissions as-is or don’t set up separate AD security groups.

Of course, even those users who do have a justified reason

for accessing a system can abuse their access and violate privacy laws. For instance, a healthcare employee may have

a job that requires occasional access to electronic medical records. Since access is pretty much all or nothing,

they may be tempted to peruse the records looking for patients they recognize

(e.g., friends or family members).

Without justifiable cause for accessing the records, this is a

major infraction and presumably grounds for termination. It is ITs responsibility to put safeguards in

place and to provide checks and balances for this kind of user behavior.

One such mechanism is to utilize Windows Group Policy to

enable object and directory access auditing.

This method is okay and may be the only means available of keeping an

audit trail for certain applications.

But more than likely, an application written within the last few years and

which stores sensitive data will have built-in capabilities for logging/auditing. Many times, power users working as system

administrators will get the responsibility of periodically reviewing these system

audit logs. Knowing who accessed what

and why they accessed it is the goal.

One area of user access control proving to be an issue where

I work is vendor access. Not access to

specific files or servers per se, but VPN account access. Our policy is for each vendor support person

accessing our network to have an individual VPN user account. The reality is one or two support reps

assisting with the implementation get accounts created in their name, and then

the credentials are stored in the vendor’s customer database for use by any

future support person to use. So access

logs aren’t accurate and we really don’t have any way of knowing exactly which

rep connected to the network after all.

But would compliance auditors give good marks to our company

for being able to say we require individual accounts for all vendor support

reps? Yes, but it is more of an empty

fulfillment of the requirements. For

larger vendors with many support reps working various shifts, it’s just not

viable to keep track of another company’s active employee roster. In this case, the more rational approach is

to require the vendor to sign a Service Level Agreement (SLA) specifying they

are responsible for logging each rep that works on an individual support

ticket, and they must be able to provide the access logs at the customer’s

request. This approach, while not

perfect, actually comes closer to accomplishing the goal – knowing who accessed

a system which stores sensitive data.

There are many other aspects and examples to controlling

access to electronic data. I’ve only

touched on a couple, but it all goes back to ensuring sensitive data is

accessible only by the people who need it to do their jobs. As always, let me know your comments and some

of the ways you control access to critical data.