[Security_sig] Security Assumptions

Chris Wright chrisw at osdl.org
Wed Oct 27 22:21:25 PDT 2004

Re-posting Ed's list.  Any one take issue with these?

  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?

More information about the security_sig mailing list