Re: Looking for consesus

[David Gillett <gillettdavid () FHDA EDU>]

  It seems to me that such a list would make a very useful map
for anyone planning a social engineering attack, too, since it
gives some pretty good clues about who is likely to be trusted
by whom.

David Gillett, CISSP


> -----Original Message-----
> From: Valdis Kletnieks [mailto:Valdis.Kletnieks () VT EDU]
> Sent: Thursday, August 03, 2006 7:42 AM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] Looking for consesus
>
> On Thu, 03 Aug 2006 09:14:47 EDT, "Chad McDonald, CISSP" said:
>
> > I have been asked to provide realtime information pertaining to who
> > has access to various systems across campus.  We require the data
> > owner to sign off on who has access to the systems, so I was
> > considering publishing on the web a list of names (NOT usernames)
> > correlating to the systems to which they have access.  I
> don't see a
> > need to publish the level of access or any other data than
> system name
> > and user's name.
>
> Bad Idea.
>
> First, you'll find that mapping from "user real name" to
> "userid" is probably totally trivial in your environment, so
> it's just a little bit of obfuscation at best, and is likely
> to cause issues for yourself. The times you're looking at the
> list are almost certainly those exact times when you will
> *not* remember that William J Smith has, for hysterical
> raisins, the userid 'eagle'.  And you will be off on a while
> goose chase for why 'eagle' accessed a database, until you
> find out that Bill is the #2 DBA guy. ;)
>
> Second, unless you *heavily* secure it, the document becomes
> a wonderful roadmap for any hacker that manages to get a copy
> - he then knows that William J Smith has access to
> Interesting Stuff, and if he targets Bill's PC (which is
> almost certainly less well secured than the server with the
> Interesting Stuff), he can (with very high probability) then
> use a trust relationship to get from that PC to the Interesting Stuff.
>
> Third, I sincerely *hope* that your actual business process
> for granting any access that would need to be in this
> database has enough checks and balances that changes are
> relatively infrequent and slow, so "realtime"
> isn't really needed.  "Fast access to a non-stale version"
> should be sufficient - if Bill Smith is a new hire and his
> DBA access went live
> 5 minutes ago, you *should* have known that (and made a note
> of it in the
> database) *yesterday*.