[Security_sig] DCL protection assumptions

Kees Cook kees at osdl.org
Thu Oct 7 12:45:45 PDT 2004


Mary Edie asked me to review these assumptions, but I hadn't seen them 
posted to the security_sig mailing list yet, so here it is....




Assumptions:

Note that these assumptions are not for the edge, but for 
DB/application servers.


1) Unauthorized users are completely untrusted. The system should defend
itself against unauthorized access.

2) Authorized users are trusted to do only what's authorized. This is 
well-known and should never overlap with administrative tasks.

3) Authorized admins are implicitly trusted.


4) Gaining physical access to the system gives same trust as if user 
were authorized as an admin.

5) The system may be attacked from the network.


 5.1) Any attack from the network that results in unauthorized access
 should be stopped (classic example is root shell).


 5.2) Any attack from network that results in pseudo-authorized
 access should be preventable with crypto (stops snooping
 passwords).  However, no protection once keys are lost.


 5.3) Some method is in place to mitigate DoS attempts.  This could
 include firewalling.


 5.4) DDoS, well...


6) Security perimiter is installation/application specific.


6.1) Systems containing high-value data are protected by their
environment.

 6.2) Systems which are deployed on the edge may be directly
 responsible for their own network perimeter,


7) When the DCL system is a cluster, the internal network is commonly 
inside a perimiter of defense (i.e. protected by firewalls).

 7.1) Individual components of a cluster should still consider the
 network as hostile, e.g. database backends should resists attacks
 from compromised front-end systems.


 7.2) Communications between cluster member should be adequately
 protected, e.g. by using a separate network for a HA cluster
 interconnect, or by cryptographic means.


8) The network address or addresses of the DCL system can be known to 
the public network. (for example web/application servers).


-- 
Kees Cook
Core Services
x44



More information about the security_sig mailing list