Re: Looking for consesus

["Waller, Michael A. (HSC)" <Michael-Waller () OUHSC EDU>]

This would apply internally as well. We're a pretty broad institution
and I certainly don't know all the relationships within and between the
various departments. If I were an insider bent on nefarious deeds, I'd
find that document to be pretty interesting. It would certainly give me
a lot more insight into the structure of the university than I would
need.

Mike Waller   CISSP
Information Technology, Information Security Services
The University of Oklahoma Health Sciences Center

-----Original Message-----
From: David Gillett [mailto:gillettdavid () FHDA EDU] 
Sent: Thursday, August 03, 2006 10:28 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Looking for consesus

  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*.