RE: segmentation of DMZs

["Scott, Richard" <Richard.Scott () BestBuy com>]

I am going to ask a philosophical question.


<snip>

When you design a new system you need to ask yourself several questions.
The answers to these questions will help you classify the type system
and information served. Some of the questions might be:  

- Is it confidential, secret, or open to all? 

If your application is a Banking application, for example, there is no
need to host all types of users on the same system since the content
served is with different confidentiality levels ranging from free to
classified. If you put all your eggs in one system anybody from the
Internet will be able to try to compromise your front-end web server. If
you require authentication and provide access only to registered users,
in most cases you will be able to reduce the number of possible attacks
on the front-end server. If the free content will be served off a
different web server which will be physically separated from the web
server serving confidential content, any compromise to that server will
not be a potential risk to the web server serving the confidential
content. 
</snip>

I would say you would need to separate in to functional logical groups the
data that is being hosted.  For example, a compromise of one system should
not compromise the other system that are functionality or organizationally
(business sense) separate.  However, it will be extremely difficult in
securing different classified data on the same application if they are
utilizing the same business operation model for interfacing with the
customer.

Here is an example.

We have a bank system, and we have a possible online banking trading system
that is Internet facing.
The bank system deals with brokerage functionality, the Internet facing
system deals with online trading for customers.  Whilst the brokerage system
deals with significant quality of service requirements, it  may for example,
be a futures and options system, the customer facing one has a lower QoS
expectation and requirement.  So long as the request hits the main system
for trading, the internal system will deal with enforcing the request.

The difference in security requirements is quite obvious, a comprise in the
online system should not lead to a compromise in a high ordered security
system.  (assume simple breach).  The data may in fact be just as highly
classified, but the organizational structure, the applications and risk are
significantly different.  If your web server is compromised, to the extend
that data can be siphoned off, running SSL, to encrypting the data in the
database may not necessarily capture your risk.  The attacker may not have
enough time to access the database system thoroughly, maybe they will, but
for sure they could access the http feeds going between the customer and the
servers.

Thus, it does not matter what classification the data within your
application is, but rather the classification of the system.  If you data is
so highly classified it should not be on a system that has a high risk
factor.  In this example we have two systems, with very much the "same"
data, but the operational requirements are significantly different. 

And hence the philosophical questions.  One should not place such highly
confidential data on a system that is Internet and customer facing?  (This
does not mean one using the Internet as such).  If the ramification of data
and operational unauthorized access is very high, thorough separation is
required, not just risk mitigation.

Since there are a plethora of applications that are Internet facing does
this mean that it is the case that the classification of the data is high,
but the application itself is low?
Are we to expect sensitive data to be at a higher risk?  Should we be
classifying applications irrespective of data?

Thus, do we segment at the physical layer or logical layer?  What are the
essential relationships between the applications ?

Applications consisting of databases, content delivery systems, application
servers and personalization servers to name but a few, all are adding
security to their functionality.
People's view may change as ecommerce security increases in engineering
capacity rather than add on solutions like firewalls and IDS.  Is an
Internet facing venture really as risky as it was ten years ago?

Food for thought.

Richard Scott
INFORMATION SECURITY
Best Buy World Headquarters
7075 Flying Cloud Drive
Eden Prairie, MN 55344 USA

The views expressed in this email do not represent Best Buy
or any of its subsidiaries



_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards