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

[Ed Reed]

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

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
DCL
member.  Please remind your responders to get back to
security_sig at osdl.org.

Thanks.

-- 
Mary Edie Meredith 
maryedie at osdl.org 
503-626-2455 x42
Open Source Development Labs