Re: Philosophy of DMZ

[Daniel Adinolfi <dra1 () CORNELL EDU>]

On Apr 19, 2005, at 18:11, Barros, Jacob wrote:
> We have some here of the impression that anything in the DMZ is a
> 'sacrificial lamb'.  This new solution is mission critical to the
> institution.  Can you quell the nay-sayer's fears?  Any best practices
> you can reference?

Jacob, et al.,

A DMZ should not be considered a sacrificial lamb.  Instead, it should
be considered a zone of control that has a unique set of requirements.
Each zone of control in your environment (different server areas, staff
nets, student nets, wireless, etc.) have different requirements.  If
you mix these zones, the lowest common denominator becomes the security
policy for all of them.  Instead, if you partition your network by the
security requirements demanded by the data resources on those networks,
you can create customized policies that affect the networks
specifically.

For a simplistic example, consider an environment where you have
servers with sensitive information that no one outside your network
needs access to and servers with data that the public need access to.
The security policy for the former will be much more strict than the
policy for the latter.  The former may require dual factor
authentication for access, very strict firewall rules, more extensive
auditing of network and systems activity, etc.  The latter requires
much more access and will include far more audit information, which
would be unmanageable if monitored.

If you separate these environments, you can apply your policies without
compromising the security of the more sensitive data while not making
the public data inaccessible.

This way of thinking comes in very handy when considering the types of
data we need to protect on campuses: FERPA, GLBA, HIPAA, etc.
Departments have servers that handle both legislated data and
non-legislated data.  If you separate these types of data, you can
apply policies much more easily.  This data-centric model is the core
of many of our information security efforts at Cornell.

Also, one can partition based on other factors, such as the users
(e.g., staff vs. students) or access requirements (does anyone really
need to hit your printers from off-campus?).

So, the traditional idea of "DMZ vs. not DMZ" is a bit obsolete.
Instead, partition your network and systems based on their security
requirements and implement the technology to satisfy those requirements
for each partition.

Feel free to contact me if you have any questions.

-Dan
_________________
Daniel Adinolfi, CISSP
Senior Security Engineer, IT Security Office
Cornell University - Office of Information Technologies
email: dra1 () cornell edu   phone: 607-255-7657

**********
Participation and subscription information for this EDUCAUSE Discussion Group discussion list can be found at 
http://www.educause.edu/groups/.