[Security_sig] Security Assumptions
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
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