[Security_sig] DCL security assumptions discussion

Gé Weijers 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
   include firewalling.

   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 mailing list