[Security_sig] Fwd: [dcl_tech_board] [REMINDER] Security Assumptions

Lynn de la Torre ldelatorre at osdl.org
Thu Oct 14 11:07:38 PDT 2004

These 5 requirements are excellent! I think that this is a good start on
a DCL profile, as far as I am concered. 
On Thu, 2004-10-14 at 07:33, Ed Reed wrote:
> Well, I had this dandy note summarizing the requirements I think DCL
> has,
> but my dog ate it - errrr, rather Snickers was rubbing his muzzle on
> the
> on/off switch of the power strip into which my computer was plugged,
> which
> is pretty much the same thing....<sigh>
> JD, Clyde - are either of you "DCL members"?  I get the mailing list
> notes,
> but don't track the discussions that much, unless they're
> security-related,
> and don't know what constitutes "relevant member feedback".  Attached
> are
> a couple of mail notes I've sent commenting on the Security
> Assumptions
> (also attached) that have been passed around.
> My take on the "Security Assumptions" is this - that they're
> self-contradictory,
> fuzzy, and addressed to the DCL members who "just want to know
> what to build" without having to think about how or why security
> matters.
I agree. My attempt to update the assertions was to address exactly that
point and drive discussion towards something that is much clearer.
> That's a useful function, and I appreciate the effort that Mary Edie
> put into creating them for that purpose.
> I belive these Assumptions have been worded to try to flush out a
> discussion 
> as to whether mandatory policy support is required, as I think it is,
> to harden
> the DCL platform.
> These are a non-exhaustive list of security requirements I think a DCL
> operating system has, and why:
> 1) separation of administrative duties, because even administrators
> authorized to perform SOME administrative duties should not HAVE to be
> authorized to perform ALL administrative functions;
> 2) least-privilege integrity protections, because WHEN applications
> break, 
> whether through code bugs, administrative error, or malicious attack, 
> there is NO REASON the broken application should EVER be able to
> damage
> anything it wasn't allowed to update, modify or delete in the first
> place;
> 3) local and perimeter network firewall protections, because it's just
> common sense to limit exposure to network attacks on ports and
> protocols
> you're not SUPPOSED to be using, so you can concentrate on defending
> against attacks on the protocols and ports you MUST use;
> 4) assume that ANY user may be hostile, because commercial systems
> simply don't have the luxury of relying on hiring practices that
> perform
> in-depth background checks on employees and customers, like the US
> DOD does when THEY are comfortable using non-mandatory security
> policy systems.  AT THE VERY LEAST, DCL systems must defend against
> amateur (cracker/hacker) attacks of the sort popular with virus and
> worm writers, meaning buffer overflow and cross-site scripting
> attacks.;
> 5) assume that MOST administrators can be trusted, but without
> background
> checks, that they SHOULD NOT be trusted without limits to their
> authority on production DCL systems performing mission critical,
> customer
> privacy related, or financial reporting functions.  Arguably, data
> center
> operators who fail to provide adequate controls (either technical or
> non-
> technical) in this regard may be failing to meet, for instance, SEC 
> Sarbanes-Oxley requirements to assure that financial systems are 
> protected from access or manipulation by insiders.  Consider all the 
> administrators of a DCL system who have the ability to view and/or
> modify general ledger reports and data - 
> * anyone with root privs,
> * anyone with database installation/modification privs, 
> * anyone with database administration privs, 
> * anyone with financial applications administration privs, 
> * anyone with general ledger application administration privs, 
> * anyone with print queue administration privs,  if reports are queued
>     to disk where they can be viewed or modified before printing, 
> * anyone with backup/restore privs, if tapes can be mounted on test 
>     or other machines
> * anyone with access to the backup tape vault, if tapes can be mounted
>     on test or other machines, if the backups aren't password or
> otherwise
>     encoded against unauthorized uses
> * anyone with web services admin privs, if they can intercept
> transactions
>     or make duplicates of reports or screen shots accessed through the
>     financial applications portal
> * anyone who can create accounts with root privs on the system or
>     database or financial applications
> * anyone who can change passwords on a root account or dba account, or
>     in the financial applications (think help desk operators)
> Repeat the same list for material information about sales,
> extraordinary
> expenses, bonuses, payroll, customer credit cards, healthcare and 
> so forth.
I agree. I think you will find some variations on this theme depending upon
the industry. However, using financial data as the initial analysis is a
good starting point.
> Small shops, with single system administrators, have no choice.  But
> the Data Center Linux target is, I think, aimed at enterprises with
> raised-
> floor data centers, implying institutional support for information
> systems
> and requirements for information assurance.  Folks who are likely to
> NEED to have business continuity policies in place, for instance.
> The question is, what requirements does DCL have to support technical
> mechanisms to control these things, and what assumptions does DCL make
> about non-technical controls that must be in place to avoid disclosure
> or modification of material financial information outside of policy?
> Ed
> >>> Mary Edie Meredith <maryedie at osdl.org> 10/13/2004 1:13:12 PM >>>
> Just a reminder - today is the day the feedback is due for the
> Security
> Assumptions.  As far as I can tell, nothing has been received from a
> member.  Please remind your responders to get back to
> security_sig at osdl.org.
> Thanks.

More information about the security_sig mailing list