Shared Passwords 1932
nilesh last edited by
From SOX point of view, how critical is the case if the super admin account is shared between 2 persons?
What if there is technical limitation of system to create a individual user with super admin rights?
Even if system supports facility to have individual super adm accounts, should individual account be created or not?
What if in 2 people, one is backup of another?
kymike last edited by
It is critical that passwords are never shared. With shared passwords, you never know who actually logged in to the system to perform a function.
If the ability exists to set up individual super admin users, you should do so immediately. If this is not allowed by the software, you need to put some pressure on the software company to make it an option and you need to identify compensating controls around this shared access.
calvin last edited by
Agree with Kymike 100%. %0AIf the systems doesn’t provide the functionality of individual IDs then some compensating controls needs to build around the ID provisioning and usage. Some of them are%0A1. Usage - Logging and review of the activity by the shared ID.%0A2. Regular change of password especially when the team member leaves the team.%0AThis all stands true even if the other person is a backup.%0ACalvin
Albie last edited by
I would even go a step further…
Password security should be classified as a Risk that is carefully mitigated by a Control under COBIT and/or SOX.
nilesh last edited by
Thanx everybody for your comments.
Now if i create user X with admin rights who will be responsible for daily activities and give his manager admin rights in the situation when user X don’t turnup so in such case Manager will review the activity log of user X correct? But i want to know what would be frequency of such review and justification on review frequency?
Hi Nilesh and welcome
You’ve already received excellent advice and maybe these links may also help:
Please paste to browser and add www
google.com/search?hl=en-and-q=administrator passwords best practices
google.com/search?hl=en-and-lr=-and-q=SOX administrator passwords
ADMIN passwords should be complex in nature, rotated on a periodic basis, and changed when an ADMIN leaves. As master domain/root passwords must be known in some cases to Tech Support or ADMINS, good policies are also important (including annual signing of agreements with the security policy). ADMINs should use their own accounts where possible also and use the shared master ADMIN accounts only when it’s necessary (for accountability as shared above).
With respect to monitoring, this is usually done by the core security team and audit. Unless the ADMIN’s manager is a ‘true working manager’ they most likely won’t be involved in technical reviews of event or other security logs. However, they might become involved in a review if a security incident occurs (e.g., misue of the ADMIN privileges). Monitoring should be part of the on-going responsibility of the security staff (although realistically this often gets put on the backburner for more critical on-going needs).
While controls and monitoring approaches will vary from organization to organization, companies should thoroughly analyze and research these privileges balancing security controls with the need for the ADMIN staff to be productive and responsive when these privileges are required.
joms last edited by
After reading this post it brings a question to mind. Our IT department requires us to e-mail our password to them (or him, it is a single guy). He does not allow us to change our own password. I do not agree with doing it this way and think we should be able just to change them on our own. (XP pro workstations with active directory on Advanced Server 2003) He states that it is company policy although he can not provide that in writing to me. Also, he carries around everyones passwords on a spreadsheet in his wallet. I have seen him several times logging on to peoples workstations using their username and password, not his or an admin logon. He claims that he needs to do this for access to the computer, which I do not understand. Also, he has RealVNC loaded on each machine and actually caught him logging on to my workstation from home using RealVNC one evening while I was at work late.
Now my question. Being and IT person at another location I know this is not common practice, nor should it ever be done. Is there some place in SOX that says this can not be done. I feel very uncomfortable with him having that type of access and possiblity putting me in a very bad spot.
Please let me know what you think about this and also if there is anything I can do to prevent this. Idealy I would like to find something in the Sarbanes-Oxley Act that prevents this, as he blaims everything he does on Sarbanes Oxley.
kymike last edited by
There is nothing in this act that would forbid this. The act does not contain specific guidelines for controls. It requires companies to adopt an accepted control framework to use, which would include COSO and the somewhat related COBIT (IT controls).
This certainly should not be occurring. It is a violation of all internal control rules. He should not be able to log in to the system as anyone other than himself. I would take this one up the ladder to ensure that it gets resolved ASAP.
Our IT department requires us to e-mail our password to them (or him, it is a single guy). He does not allow us to change our own password …
Hi Joms and welcome to the SOX forums
Having an IT security background, I agree with everything you and Kymike shared. I’d clearly vote for the more traditional frameword for password management and change procedures.
This may or may not specifically violate SOX 404, which in essence requires management oversight of the IT based financial environment. The details of SOX 404 would not state this specifically. Although, COBIT 4 might provide guidance (as it’s commonly used as a means for gauging SOX 404 security controls by external auditors). Based on what was shared, I don’t see how any auditor who knew of this practice would approve it wholeheartedly.
Sometimes, you have to compromise on what you can or cannot achieve in the area of security. For example, I’ve seen cases where developers might need to access network drives on another seldom used Windows domain. Even there, a help desk approach for password resets was be used, when the passwords expired (and the developer couldn’t login physically to the domain to perform the reset, as their workstation wasn’t authorized as a member of the domain). If there operational hinderances, then better tools or improved procedures are needed for a more secure password change environment.
he carries around everyones passwords on a spreadsheet in his wallet. I have seen him several times logging on to peoples workstations using their username and password, not his or an admin logon.
Whether this is specifically SOX 404 related or not, it clearly violates many security best practices. Concerns include:
- How secure is the transmitted email (e.g., is it encrypted, does it travel in clear text, who has access to the email servers, the list goes on …)
- How protected is the Excel spreadsheet? (both electronically and physically at his desk)
- Even from a SOX perspective, I see where this more as a violation than a security solution. As a risk management concern, you do not want ID/password information to reside in an easy-to-read format, as he or anyone with the spreadsheet could login as a financial ‘power user’ in an UNCHECKED fashion.
- The admin should never login under anyone else’s ID other than their own, without explicit permission by the user in order to test something out.
- Usually VPN ‘best practices’ are to notify the target users when accessing someone else’s PC. The admin should not be able to access any PC in a sleath manner without user permission to do so. For example, HR or financial users may be doing something sensitive. Also, if someone logs in unannounced they could even impact what the user is doing causing them to loose the work that was in process at the time.
- You can probably search these forums with the keyword of ‘excuse’ and you can see almost anything can be done in the name of SOX (in fact, over or unnecessary compliance is why SOX has been so costly for organizations).
- To use some classical audit terms, there needs to some ‘separation of duties’ and ‘balance of power’ related to one person having this much authority.
RECOMMENDATION: As Kymike wisely recommends, I’d recommend fixing these issues, perhaps through escalation concerns of these to your management. Personally, I see enough risk here to say that the current approach is NOT SOX compliant. Certainly, internal or external auditors will find this and ‘score Audit points’ big time if this is discovered. So it’s best to fix it the right way internally first through research and better security practices.
The admin is most likely highly ethical and trustworthy. I’m guessing that the setup was for perhaps even some valid technical issues, where a workable solution was implemented, but not the most secure way. Still, what ever the technical issues are, your company should spend USDUSDUSD to better protect your financial environment and network infrastructure.
For example, if it’s folks accessing a secondary domain issue (as shared at the end of the 1st quote), then by all means register the workstations, provide users with ID/password accounts, and move to a more secure approach. Without getting too technical, multiple domains can also be trusted in a ‘forest’ approach. I also like 2-factor solutions like Secure-ID or Cryptocards which can create a more trusted signon environment than passwords. Those are some of the ideas you might look at.
Having been a network admin in the past, maybe an improved security approach will also allow the admin to do more meaningful things in their job than user and password management. Good luck on this
joms last edited by
[quote='harrywaldron] The admin is most likely highly ethical and trustworthy. I’m guessing that the setup was for perhaps even some valid technical issues, where a workable solution was implemented, but not the most secure way.[/quote]
This is the part that actually started a lot of the problems. He is actually a 22 year old ‘kid’ just out of tech school. Some refer to him as the ‘self appointed boss’. We are actually a very large TV station and he has got to the point that he can make our local managment believe anything. I have asked to see some of these policies in writing but he never can produce anything. I was also told directly from him ‘DO NOT contact any upper management about these problems’. I am planning on putting together a formal email and sending it to our IT department in New York. (We are in South Dakota) Anyways, I just wanted to cover my bases to make sure is isnt an actual policy and that he is just feeding everyone around here a line of BS. He told me that I will be ‘betting my job’ if I contact upper management about polices and those are to be handled locally.
As most Admins are trustworthy, my general comments were more in giving the ‘benefit of the doubt’. Personalities aside, you all do need a better system. The admin is most likely very talented but all of us are human and prone to mistakes - even highly skilled individuals He may need some focused training in security to better see the risks (e.g., easiest is not always best when it comes to security and you don’t want too much control with one individual in any very important business function).
If I were a SOX auditor, I’d be at least writing up comments for improvement related to current practices. I may be wrong, but I’d even suggest a ‘failing grade’ on SOX 404. This is based on the aforementioned concerns shared earlier, as I see major IT risks related to securing financial systems from outsiders plus possible internal risks (if the solitary controlling admin went to the ‘dark side of the force’).
Even if this were to pass the scrutiny of SOX 404, I still see issues from a General security controls perspective. For example, below are a few more questions:
- what if the young ‘whiz kid’ left the company?
- Who backs up the admin when they are out of the office?
Having worked a decade previously in IT security and a lot with auditors, there’s definitely a need to resolve these issues.
Good luck and I hope you all can come to a good and even peaceful resolution
denniskf01 last edited by
I think that if this passes SOX 404 compliance then there would be a huge problem. The entire ACT was drafted to prevent instances of fraud and general misuse of information. This situation clearly is a circumstance where neither management or audit (internal or external) should approve.
In a transaction environment, one person can log on as any user, complete an entire transaction and is also the person who is responsible for the maintenance of the information? If phrased in this manner with even a generic description of SOX should be sufficient for any intelligent person to conclude that these are poor practices.
But, what do I know… I am only a lowly CPA, CISSP.
Hi Dennis and welcome to the forums
I agree with your assessment and hopefully controls have been improved as recommended in all of the replies. As external auditors would provide a neutral and unbiased assessment, this situation should be discovered based on checklists that explore password management controls (e.g., many external auditors use COBIT and COSO as gauges for assessing SOX 404 compliancy).
No one should be able to theoretically perform start-to-finish transactions in an unchecked manner. In theory, this particular ADMIN could even use other accounts besides his own to do so, as he owns the password management and reset function as well. While it’s very likely this would not occur, lightening does occasionally strike if folks don’t perform the proper ‘due diligence’.
Youngsta last edited by
Kymike is right 4 sho
MartyG last edited by
To get around the issue of shared accounts we have begun using a product called ‘Unlock Administrator’. Once the system is logged into using a generic username and password it is locked in the standard Windows fashion and the system is set to lock when the screensaver is activated as well.
This program allows you to select which users are able to unlock the system using their own Windows domain credentials. A log of when the system is locked and when and by whom it is unlocked is kept in a protected file as well as a Windows Event. Users don’t have read or write access to this file. This way we have complete knowledge of who used the account and when. Everyone uses their own password and no password needs to be shared.
Hope someone else finds this useful as well.