[Security_sig] Assumptions in english/sysadm speak

[Lynn de la Torre]

On Wed, 2004-10-13 at 12:19, Ed Reed wrote:
> Laughing out loud... 

My point in adding some of the additional statements was to get to clear
requirements statements that security admins can easily agree or
disagree with to drive the real requirements.

So, the fact we could easily disagree with #1 is a good thing :-) 
> Note - if "standard unix-based security techniques will be sufficient
> to
> defend against" hostile users, network attacks, unauthorized users,
> broken applications, cross-site scripting attacks (against backend
> databases), and so forth, where have they been all my life ;-)
If standard unix techniques aren't sufficient (which likely they
aren't), then how would this statement be changed to that would assert
simply which basic techniques would be used to defend a database or
application server from unauthorized use? I'm hoping we can get a clear
statement on this. Would this be a combination of unix-levela and
application level security, for example?
> #3 (authorized admins are wholy trusted) is a reasonable statement,
> but
> leaves open the question I asked of the list earlier, which is - is
> every admin completely trusted not to do anything they're not
> authorized to do?  Or is every admin explicitly authorized to perform
> whatever they want to do?  I don't think that's a real DCL
> requirement...
> I think DCL is MOST likely to require SOME separation of duties among
> administrators of different pieces of the system.  But then, I'm a
> vendor,
> not a consumer, so if you really only require a single root account
> for
> all your administrators,
In a previous list of requirements DCL had reviewed,  there was an
assertion that some type of privilege separation was needeed. It was
driven for the exact reason you listed here, ie for developers, DBAs
etc, especially for installations. But that assertion was 'lost' somehow
in this new list of 8.  I personally agree it should be added back in,
as my own experience indicates that this is needed, but I am not sure
why it was eliminated. 
>  operators, database administrators, web
> server
> administrators and backup folks to use, I guess I've just been wrong.
> 
> #5 is just plain wrong - you can't prevent attacks - attacks will
> happen.
> The question is what will happen when they succeed, and they will.
> Refer to history, at least as far back as the Morris worm.
Same as #1. It would be good to get a clear assertion about the
techniques that would be used.
.
> #5.1 clearly requires some least privilege enforcement outside the
> scope of the broken application - a mandatory policy of some flavor.
> I think it's entirely appropriate.  I'm not convinced that any
> solution
> that doesn't at least do what Immunix' Subdomain does (I don't think
> you have to go so far as SELinux Type Enforcement) will effectively
> defeat escallation of privileges in broken applications that have
> delivered over a root shell.
> 
> #7 and #7.1 seem to be self-contradictory to me.  If the database
> backend in a cluster has to treat the cluster network as hostile,
It does seem like a contradiction. I understand #7 clearly. I thought we
assumed that the database and application servers would be inside a
secured computer room.  So the scope for clusters for right now wouldb
be those types of servers on the cluster. So, I had been tacitly
assuming that the entire cluster of servers would then also be in that
same environment. Pehaps that is a wrong assumption. However, if that is
a good assumption, then I don't understand why the cluster network would
be assumed to be hostile for database and application servers. 
>  then
> it must assume that there may be packet sniffers watching traffic
> between front-ends and the backend database, so the database
> traffic should be encrypted to avoid inadvertent disclosure of
> patient privacy or customer personnally identifying information.
> Never mind credit card numbers.
> 
> Perhaps you mean with #7.2 that the cluster interconnect isn't
> the "untrusted network", but that the public interfaces on the
> cluster may be hostile.  I can buy that.  Hate to think we need to
> encrypt cluster interconnect data at this point...
> 
I was not sure how to interpret #8. I assumed that this meant that the
database and application servers address could be determined based upon
the fact that these servers talk to front-end servers that are exposed.
And if a front-end server was compromised, then it would be important to
secure the back-end server against that.  So, do we add a statement
like: It is common to encrypt data between application and/or database
servers to protect against this, eg. ssh, ipsec.
> Ed
> >>> Chris Wright <chrisw at osdl.org> 10/13/2004 1:12:37 PM >>>
> Bringing this onto the list.
> 
> ----- Forwarded message from Chris Wright <chrisw at osdl.org> -----
> 
> Date: Tue, 12 Oct 2004 17:21:56 -0700
> From: Chris Wright <chrisw at osdl.org>
> User-Agent: Mutt/1.2.5i
> To: Lynn de la Torre <ldelatorre at osdl.org>
> Cc: chrisw at osdl.org 
> 
> Meta-comment...To me, the purpose of these assumptions is to justify
> the
> choice of not requiring Mandatory Access Controls (or even better, get
> everyone to disagree with the assumptions and get them to then decide
> they need MAC).
> 
> * Lynn de la Torre (ldelatorre at osdl.org) wrote:
> > Chris,
> > Here is the message I just told you about.  Please look at my
> revised
> > assertions,
> 
> <snip>
> 
> > I have added some sample interpretations to the assertions to see if
> we
> > can translate a little bit for systems and/or security admins on IT 
> > staff. Do these make sense? Did I state anything incorrect on this?
> > 
> > - - - - - - - - - - - - - - - - - - - - - -
> > 
> > 1) Unauthorized users are completely untrusted. The system should
> defend
> > itself against unauthorized access. Standard unix-based security
> > techniques will be sufficient to defend against unauthorized access.
> 
> In other words, there's no such thing as an unauthorized user.
> 
> > 2) Authorized users are trusted to do only what's authorized. This is
> 
> > well-known and should never overlap with administrative tasks.
> Standard
> > unix-based user definitions and authentication procedures are
> sufficient
> > to ensure that authorized uses of the systems occur.
> 
> It's also likely that the interface is removed from direct access.  So
> the database server is accessed by a program that a) authorized the
> user, and b) fed the database server a request that is highly
> structured
> (only perhaps parameters are controlled by user, like which item is
> being looked up, or whatever).
> 
> > 3) Authorized admins are implicitly trusted. Standard unix-based
> root
> > access is provided to all administrators.  No additional safeguards
> are
> > needed beyond this since there is implicit trust.
> > 
> > 4) Gaining physical access to the system gives same trust as if user
> 
> > were authorized as an admin. The fact that the systems are
> physically
> > isolated in a computer room and therefore tightly controlled
> provides
> > sufficient control against unauthorized access.
> > 
> > 5) The system may be attacked from the network. Standard
> well-designed
> > firewall systems and unix-level security procedures are sufficient
> to
> > prevent attacks.
> 
> This is where I start to have issue.  We should probably take this to
> the list.  It's the slippery slope that points towards MAC, as far as
> I'm concerned ;-)
> 
> >  5.1) Any attack from the network that results in unauthorized
> access
> >  should be stopped (classic example is root shell).
> 
> I'm not sure about this.  Part of the point (as I understand it), is
> that the system is not near the perimeter, so we're saying it has
> controlled access via multiple-tiers of application.  The reason I say
> that, is that generically stopping remote root shell is hard.  Esp,
> with
> only unix permission model.
> 
> >  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.
> 
> What is pseudo-authorized access?
> 
> >  5.3) Some method is in place to mitigate DoS attempts.  This could
> >  include firewalling. 
> > 
> >  5.4) DDoS is a consideration, but not universally needed for all
> > industries/etc.
> > 
> > 6) Security perimiter is installation/application specific. Standard
> > unix-level security techniques are sufficient to set the security
> > perimeter to meet the installation/application needs.
> 
> I don't quite grok this one.
> 
> > 6.1) Systems containing high-value data are protected by their
> > environment.For example,  Applications and/or database servers rely
> > primarily on those software packages to prevent unauthorized access
> to
> > high-value data.
> > 
> >  6.2) Systems which are deployed on the edge may be directly
> >  responsible for their own network perimeter.
> 
> IOW, they are directly on the net?
> 
> > 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.
> 
> This is the question.  Do we consider the database backend as
> vulnerable
> to attacks from compromised front-ends.  If so, it's not much
> different
> from having database on public network (except the attack route
> requires
> an extra level of sophistication).
> 
> >  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
> 
> > servers that touch the public network such as web servers.