Password management CI ?

[cjmt]

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?

Thanks.
Cristiano

[pjgh]

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?

[cjmt]

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”…

[Mark-OLoughlin]

Hi,

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

[Diarmid]

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

[cjmt]

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?

Many thanks.

Cristiano.

[UKVIKING]

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

[cjmt]

Hey Viking, thanks but now you gave me a lot to worry about during the weekend... I guess you even got me to some kind of neurotic state, now...

[rpmason]

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.

[cjmt]

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.

Cheers.
Cristiano