[Security_sig] RE: DCL security feedback

Linda Knippers linda.knippers at hp.com
Wed Oct 13 19:36:28 PDT 2004

The following consolidates feedback from Matt Anderson, Paul Moore
and me.

-- ljk

 > 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.

This should say something like:
Authorized users are trusted to do only what's authorized for that
specific user.  Different users may be authorized to do different
things.  Unauthorized operations should be prevented.

 > 3) Authorized admins are implicitly trusted.

There should be a provision of different levels of administrators
with specific privileges.

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

Do we need to make assumptions about physical security, either here
or with 6.1?  User and admin actions on the system should to be
auditable (is that a missing assumption?) and physical access
to the data center (via card key or whatever) should be logged
at a separate security office.

 > 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.

This assumption isn't very clear.   It could mean that authentication
information provided over the network should be encrypted.  That sounds
reasonable, but it could be read to mean that all network traffic
should be encrypted, which isn't as reasonable.

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

There's probably more than one method, unless "method" here
includes policies, procedures, and tools.

 >  5.4) DDoS, well...


 > 6) Security perimiter is installation/application specific.
 > 6.1) Systems containing high-value data are protected by their
 > environment.

Not sure what the terms "systems" and "environment" means here.
Does this mean that if a computer system contains high value data
that all of its security mechanisms are external to the computer
system itself?  Does the system itself have no role?  That doesn't
seem right.  Or does "systems" really mean an application that's
deployed and the environment is the computer system(s) in which its
deployed?  Or is this really just pointing out that physical
security is important because of assumption 4?

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

Earlier there was a statement that the assumptions apply to 
DB/application servers, not system on the edge, so this assumption
seems out of place.

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

Not sure what "internal network" means here.  Is this the
cluster interconnect, or whatever the cluster members are using
for cluster-specific communication?  If so, then we suggest using the
term "interconnect".  Ideally its at least virtually if not
physically private to the cluster.  Or does it mean any network
that's internal to a data center, which may include cluster nodes
as well as non-cluster nodes?  If that's the case, its not clear
what's special about the system being a cluster.

 >  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.

Right.  A network connected to a cluster member should be protected
just as much as a network connected to a standalone system in a
data center.

 >  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.

A cluster interconnect that isn't private has more issues than can
be solved with cryptographic means.  If its sharing resources such
as bandwidth, its susceptible to problems introduced by whatever
systems or equipment that's sharing the network.  If something
uses up all the bandwidth, then that's like DoS attack on the cluster.

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

So a cluster that is not on the edge but behind the cluster firewall and
the site firewall and in a locked room needs to have public IPs?  It
seems like this one limits the ability to use an application proxy
to sanitize requests.

Re-reading this one, its not clear out what security goal they are
trying to achieve with this statement.  The only one I can come up with
is "don't rely on security thru obscurity" which I agree with, but I
don't see how that translates into routable addresses.

More information about the security_sig mailing list