[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