[Security_sig] Re: Departmental questions resolution...

Ed Reed ereed at novell.com
Wed Aug 17 05:44:47 PDT 2005


Discussion on role separation when administration is split between an enterprise network support group (as for an enterprise-spanning directory name server) and local administrators (file, print access controls)...

>>> On Fri, Aug 12, 2005 at  2:48 pm, in message
<20050812184846.GZ7762 at shell0.pdx.osdl.net>, Philip Peake <philip at vogon.net>
wrote: 

>>> Who controls the access control policy?
>>
>> [A]Wide variance. Other servers typically regard departmental servers as
>> potentially hostile.
>> [B]Expected to fall under site- wide security policy, but is
>> likely managed as local departmental server and may have differing
>> policy control.
>>
>> --- > There is a wide variance in the ways access control
>> policies are formed.  Policies are expected to fall under a site- wide
>> security policy, but is likely managed as a local server and
>> may have differing policy control.  Other servers typically
>> regard departmental servers as potentially hostile, due to
>> occasional security policy mishandling on the part of departmental
>> server administration or local policy decisions.
> 
> Yes ... much depends upon the strength/influence of the corporate security
> group.
> 

Agreed - where centralized services (name, directory, authentication, VPN, etc.) are managed by a centralized group of experts (very common for distributed directories like Active Directory and eDirectory), it's common that there be enterprise-defined policies that bound the range of accesses allowed on subordinate / departmental servers.

For instance, control of who may change what tree or global namespace a departmental server resides in is usually NOT left to the local administrators.  Similarly, and for similar reasons, it's unusual for local administrators to have permission to split their local namespace into two or more partitions, or to join them together.  Such namespace topology changing operations are generally reserved to a select group of network administrators because of the adverse effects that can happen if the namespace gets "broken".

This comment is written from the perspective that large organizations are likely to have such a centralized network support group who's job it is to keep the enterprise services (and departmental servers) talking to each other and recognizing each others defined users.

Also, both Active Directory and eDirectory have ways to limit, or filter, permissions inheritance at leaf nodes of the tree, so as to create greater local autonomy when that's desired.

So, don't assume that NIS (the old Yellowpages) or NT/Domains (the old LANMAN technology) is the most common deployed administrative model.  Look instead to the modern enterprise distributed directory environments for guidance along these lines.  They're what Microsoft and Novell customers (who together dominate enterprise departmental server markets) both deliver.



>>
>>> Any separation of duties for sys admin?
>>
>> [A] Very rarely.
>> [B] System level admin, backup admin, file/print admin...these
>>  are typically all the same.  May find the file/print management
>> can (and should?) be done by separate admin role (not system admin).
>>
>>
>> --- >Separation of administrative duties such as file/print
>> administration might be needed, but in practice is rarely used.
> 
> Yes.
> 

No.  See above discussion.  Expect that enterprise managed services (distributed directory, DNS, time, smtp, VPN, routing, etc.) will have very separate administrative boundaries from local departmental servers in the enterprise.

Granted, when there's only one department, or it's operating as an island, the local administrator is god.  But that's not the case in environments that have "Data Center" environments, usually.  By the time you have a few hundred departments, you've got a central support staff responsible for the services that keep things connected.  They delegate access control permissions (only) to local administrators.  They MAY delegate account creation to the local administrator, too, if there's no ERP system (PeopleSoft, for instance) to manage account creations and deactivations.

>>
>>> Is audit important, and what to audit?
>>
>> [A] Audit? what's an audit ??
>> [B] Same as Edge Server.  May contain sensitive documents with
>> restrictive ACLs whose access should be audited.
>>
>> --- >Security auditing is important for:
>> (1) system and application/service login attempts, both successful and
>> failed,
>> (2) security changes made by the system administrator or application
>> administrator,
>> (3) anything else important to the site policy, in particular,
>> Departmental Servers may contain sensitive documents with restrictive
>> ACLs whose access should be audited.
>> (4) IDS style auditing of things like network traffic analysis, or
>> binary/configuration file checksum intrusion detection, the focus being
>> on internal attacks,
>>
>> Note, that although the above items are important to audit, local
>> policy makers or system administrators may not understand the
>> need for auditing or may not have an audit administrator.
> 
> Yes ... but ... much depends upon the sensitivity of the information
> present on, or processed by the server. Highly sensitive data- handling
> servers require much more monitoring/auditing than a server used for
> general purpose work.
> 
> "Departmental server" covers a wide range of uses.
> Most will not require extraordinary monitoring. An NSA departmental server
> may, for example.
> 
> No simple, short answer to this.

The most common audit sort of function I've seen has been password strength checkers, which are hard to do with non-reversably hashed passwords.  Which is why customers have asked for server-based strength checkers to run at password set/change time.

Serious access audits are rare at departmental servers.  But if there are distributed authentication services (as with Active Directory and eDirectory), it's far more likely you'll see a need to roll up such audit events to help track who's been where.

Ed



>>
>>
>> --
>> Mary Edie Meredith
>> Initiative Manager
>> Open Source Development Labs
>> maryedie at hotmail.com
>> 503- 906- 1942
>>





More information about the security_sig mailing list