Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
NOTE: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Joined: Mar 14, 2008 Posts: 32 Location: Porto, PO.
Posted: Fri Apr 11, 2008 6:28 pm Post subject: Password management CI ?
Hi all.
I am trying to figure a (secure) way to manage the increasing number of usernames/passwords required for several online services that the organization uses. Do you think that such sensitive information should be recorded within each associated CI or would it make more sense, from a security point of view, to have a separated CI for password management?
Joined: May 21, 2007 Posts: 4 Location: Bradford, UK
Posted: Fri Apr 11, 2008 6:58 pm Post subject:
A couple of things to consider are (1) do you have tiered administration and (2) if you store all the passwords in one place and have a single password to unlock that store, why don't you just have one password for all systems?
If you do have tiered administration whereby the passwords to certain systems should be known only to certain levels of the organisation, some kind of crypt for passwords would be the best idea. I do not favour storage of passwords anywhere, but if you have to (because of tiered administration, changeable staffing or so on), then have a search for some kind of encrypted key management software.
As a sideline, should we call a password management system a PMS?
Joined: Mar 14, 2008 Posts: 32 Location: Porto, PO.
Posted: Fri Apr 11, 2008 7:34 pm Post subject:
Pjgh:
Thanks for your reply.
In small companies, most of the staff has more than one role and corporate operability requires that key information is not held in isolation by staff, so we do have the need to store username/passwords somewhere. This gives flexibility to some operational roles and allows people to substitute one another in case of absence or personnel rotation.
Authentication security must be kept at a certain level, but only to a level where, if needed, someone in the company does have the resources to retrieve the required information to keep things functioning without any dependence on the person who normally owns it. This does not apply to upper management levels, so in our case, tiered password administration is not in place, as I am referring only operational level activities.
PMS sounds nice, though I have no knowledge of any real “password management system”…
regardless of where you store it you need to be sure that only those that should have acces to the password are the only ones with acces to get the relevant passwords.
If you add them as CI's is the system secure enough for no one else to gat at the data i.e. can the fields be accessed by reporting tools, views, filters, direct database reads etc.
I don't think a general CMBD would have as much focus on password integrity and encryption methods as other more specalised password store applications. However you could include a password store application as part of your CMDB structure.
Just a consideration. _________________ Mark O'Loughlin
ITSM / ITIL Consultant
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Fri Apr 11, 2008 10:03 pm Post subject:
Hi,
should not the CMDB just record who is the authority for the password?
Or, perhaps The CMDB should only note that password controls apply to the CI; a separate password management procedure would specify the arrangements for control of and access to passwords.
[sorry for the edit; I missed out a semi colon.] _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Joined: Mar 14, 2008 Posts: 32 Location: Porto, PO.
Posted: Fri Apr 11, 2008 10:39 pm Post subject:
Diarmid, I'll tend to agree with your approach.
Assuming that the passwords are stored in a dedicated application as part of the CMDB structure, there could be indeed a password management process involved which would define the steps for control, access, and modifications of all this authentication data. This would take care of the security question, which would be left to a more specialized and secure infrastucture.
Nevertheless, as to CIs & Changes are concerned, perhaps these passwords would have to be a property of each “online authentication”-related CI (i.e. be referred as “existing in the PMS ).
Would you other itilers go that way?
Joined: Sep 16, 2006 Posts: 3590 Location: London, UK
Posted: Fri Apr 11, 2008 11:01 pm Post subject:
Arrgh
one thought
There should be standard password for the following types of access
read only
special accounts like for services/applications that are automated
admin
system override
for all manners of equipment - servers, etc
for each class of equipment.. for example
unix servers - there should be one password used to login into the unix servers as system admin / root
there should be one account / password set for read only
there are tools that will manage the password / accounts. i aint no sys admin any more so i dont know the name
the entire set up should not be in the standard available area of the cmdb
in addition, the password file shouldbe reviewed monthly and changed on a regular basis as well as announced
the use of FOBs - RSA tokens, tacacs, SSH - etc - should be part and parcel of the process
each environment needs to develop along the same lines how accounts/password with admin rights are handled
in addition,thought must include how to gain access when the password mgmt system isdone
in order words dont use the tool to screw u out of the system
read this carefully
I keep my house keys in a lock box.
I have a key to the lock box.
I keep the key in a safe place. my wallet
I keep the lock box in a safe place so I put the lock box in the house.
Now I cant get to the lock box because it is the house and in the lock box are the keys to the house.
I lose my wallet. now the house is safe and secure. _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
In my workplace, CyberSecurity requires one username/pw per person per system or application (except, of course, those "backdoor" usernames like admin). If you and I both need access to an app, you get a username and I get a username. The passwords are not stored anywhere else. If I forget or (fat-finger my pw three times), I request a reset - no one could retrieve it.
That said, our home-made CMDB has an area that contains the employees and their usernames who have "elevated privileges" on a CI (not run-of-the-mill usernames). It does not include passwords. Very few people can access that information.
Joined: Mar 14, 2008 Posts: 32 Location: Porto, PO.
Posted: Thu Apr 17, 2008 8:25 am Post subject:
rpmason:
Thanks for your feedback. Actually, we do not store "user passwords" for our internal system either, the request for a reset is the way we do it.
The difficulty lies in controlling the existence of every authentication information for third-party systems that can be critical to specific business functions (e.g. accounting) and for which sometimes only a particular user has knowledge of.
Say for eg. a public entity such an IRS online form, in case that accountant leaves the company she either has to pass on her online-irs user/password to another person or the pwd must exist, stored somewhere under lock and key, that should only be accessible to upper accounting management to retrieve/modify/erase in order to provide the same accessibilty for the third-party site to the new accountant.
I don't think that relying on online pwd reminders services ("lost your pwd, please send profile details to retrieve bla bla") is really a professional or manageable option.
Furthermore, if it was about a couple of profiles that wouldn't be such a problem, but as the IT manager I get that weird "feeling" that a lot of my users create a myriad of specific authentication profiles for which nobody else is aware of and then, one day, their chief officers might well enquires about a way for IT to rimiraculously retrieve the user/pwd, probably expecting that IT always has "records" of everything, even about what's outside our own system.
I have given some thought to this, and to some extent, I think that IT must have some of theses records in place, at least for the most critical processes, providing that security is well thought out and correctly in placed. That's when config.mgmt and the CMDN come to mind.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum