[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
Ed,
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
> DCL
> member. Please remind your responders to get back to
> security_sig at osdl.org.
>
> Thanks.
More information about the security_sig
mailing list