Generic user account security 2118
jonc101 last edited by
The company I work for has been going through the SOX compliancy program for the past 2 years and I’ve been involved only on the sidelines in some respects. I’ve come across a situation where I feel that our network manager is using SOX as an excuse for not implementing a fix to this problem. Without reading the entire SOX manual I’d like to pose the following and maybe assist in directing me to a solution:
What this problem is, is that we have a set of generic user accounts that are used by multiple people in a warehouse, the accounts are used on PC’s that are used for looking up part numbers and other useful information on a daily basis.
These generic accounts are setup with Domain Guest privileges in Active Directory and as such whenever they log out all changes made to the profile are immediately deleted from the hard drive, this is a feature of ‘Domain Guests’ and you can read about it on Microsoft.com.
The issue here is that whenever they log back into the PC’s their profiles will have to be re-created, all customisations/shortcuts created etc. We use a very old piece of software for viewing drawings which needs to have certain files created in the profile directory (eg; C:\Documents and Settings\User1\Special Directory\Special File.file), this application will not function without the presence of this special file in a particular folder within the users profile. So you can see my problem here, whenever the user logs out, that special folder disappears along with everything else specific to that user. You can see how much of a nightmare this is going to be to setup everything whenever a user logs into the PC. This in itself is NOT a solution.
The solution, according to Microsoft, is to add the users to the ‘Domain Users’ security group in Active Directory. The network manager here says that he does not want to add the users to ‘Domain Users’ because it violates our SOX compliancy, my question is does SOX have anything to do with it in this case?
A generic user account is created on the principle of ‘least privilege’ so if access is not explicitly granted then it’s explicitly denied. I don’t see how having a generic user account is a security hole on a network and how it violates SOX. The user is only granted access to what they need, for everything else they will get ‘Access Denied’ so from an auditing point of view our inherent security should be good enough.
Does this follow best practices? I appreciate any commentary on this subject, and yes I’ve used the search feature on the forum already
harrywaldron last edited by
Hi Jon and welcome to the forums
SOX 404 mandates that management implements controls to protect all automated financial systems. There are no detailed specifics on a situation like this, as SOX 404 is written at a high level and requires internal regulation by the company (with verification of SOX compliancy by external auditing firms). However, COBIT 4 helps provide some SOX IT compliancy guidelines, and could be researched as a possibility.
I agree that your current implementation is cumbersome for users and should be improved. When software resets D-and-S profiles, it requires extra time and customizations desired by the user are reset to factory defaults
While I see no major issues with what’s being proposed, below are some ideas that may or may not be feasible for your environment:
- Move to individual rather than generic accounts . I believe this might be ‘better security practice’ as it establishes individualized accountability and might allow users better individual D-and-S profile controls and customizations. There are no shared passwords and while it’s little more cumbersome handling new employees and terminations – it offers better security. Still, this may not be feasible if there are numerous people, application software compatibility issues, or the environment is too dynamic to implement these controls, etc.
- Evaluate moving to non-password security control systems , like biometrics, smart cards, or two factor authentication
- It might be worthwhile to ‘walk this through’ with either Internal Audit or your external IT auditors to get their input, alternatives, or blessings
kymike last edited by
As I see it, if the purpose of the generic names are just to allow read-only access, then I do not see a SOX issue as data cannot be changed. I could see potential operational control issues if the generic access allowed a competitor to walk in and read confidential information.
This could loosely impact SOX general IT controls over system access, but each company is allowed to set its own level of risk and establish controls that monitor risk at those levels. You need to ask what is the worst thing that could happen if you left the access open to anyone to use under a generic ID. Do you already have controls over who enters the warehouse and would even have access to the terminals? Is the information confidential?
This sounds to me like the risk has not been fully evaluated or there exists another risk that you are not aware of.
missed_shot last edited by
I agree that since the data is only being read that there does not appear to be much risk involved or even if it is not read only, some appropriate level of access could be granted. I agree that it really does not appear to have anything to do with Sarbox.
In my opinion (with my network administrator hat on), the best practice would be to give all individuals their own logon and password. In a business situation under Sarbox (I work at a private company not subject to Sarbox) it would make sense to me that all users have their own logons (i.e. no shared logons). Without hearing directly from the individual that is reluctant to create the accounts, I do not understand the hesitancy.
All that being said, there are always situations that sometimes require a work around as opposed to implementing the most correct/efficient fix. Here are two that may or may not be of value:
a) Don’t have the two ‘guest’ users logout thus eliminating the extra work or logout only occasionally thus at least minimizing the extra work, although I can think of several situations where this might not work.
b) Create a script or batch file that could copy the necessary file(s) automatically. The most efficient place to place the file, you don’t seem to have access to (Active Directory). With any luck, you could have the ‘guest’ users run the batch file themselves after they logon and get you out of the daily hassle.