[Security_sig] DCL security assumptions discussion
Ge.Weijers at Sun.COM
Wed Jul 28 08:08:05 PDT 2004
I'd like to discuss security assumptions for DCL target systems today in
the DCL Technical Board meeting. Below you'll find a number of
assumptions, which are not necessarily correct, but are given as a
starting point. What we need to know about DCL systems to create a
security assessment that is valid for real systems are issues such as:
* are admins on DCL systems trusted?
* does a DCL system take care of its own network security, or do we
assume firewall protection?
* are high-value targets such as customer databases secured by
additional methods (DMZs, IDSes, application-specific proxies)?
Answers to these questions will determine how high we will have to set
the bar for DCL systems.
Below you'll find a list of questions I've adapted from one used to fuel
the discussion during a CGL tech board meeting. I've adapted it somewhat.
Talk to you at 11AM PDT
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
5.4) DDoS, well...
6) Security perimiter is installation/application specific.
6.1) Systems containing high-value data are protected by their
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).
Gé Weijers mailto:ge.weijers at sun.com
Installation and Linux Group Tel: (877)240-7611 x69536
Sun Microsystems, Inc. Fax: (877)240-7611
=== Expressed opinions are my own, I do not speak for Sun ===
More information about the security_sig