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,
youre probably wishing I would pick a topic and run with it; and so Iwill.
For the past several years, Ive 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 maintaincompliance 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 dont need Modify rights to the
directory, only give them Read rights.
These are common sense rules, but its amazing how many IT pros get lazyand leave the default permissions as-is or dont 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 inplace 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 whatand 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 vendors customer database for use by any
future support person to use. So access
logs arent accurate and we really dont have any way of knowing exactly whichrep 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, its just not
viable to keep track of another companys 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 customers
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. Ive 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 someof the ways you control access to critical data.