Front cover - IBM Redbooks

138 Lotus Security Handbook
Note: It is theoretically possible on some platforms to provide some level of
service separation in a single host by running the services under different
non-root-privilege accounts. We say separation within a single host is
“theoretically” possible because in reality it is complex to configure properly,
meaning it is prone to errors that can lead to unintentional vulnerabilities. For
example, on UNIX systems it is possible to isolate daemons (background
processes or services) such as bind using chroot; however, if not configured
properly, an attacker may still be able to break out of the “chroot jail” and affect
other parts of the system. A simple Google search on “chroot breaking out”
locates numerous Web articles, such as the following reference:
http://www.bpfh.net/simes/computing/chroot-break.html
We do not recommend using service separation on a single host as a network
security method because service isolation cannot be guaranteed.
The focus of our multi-zoned architecture will be on the placement of servers,
applications, and services to provide separation. As previously mentioned,
determining which zone a server or service belongs in can be based on
sensitivity of data and risk.
The ideal architecture can provide granularity of access to data as dictated by
the requirements of the business application owners. The requirements must be
consistent with corporate security policies. In order to provide granularity,
flexibility, and future extensibility, we need to determine a reasonable number of
security zones we can classify and locate our host systems into. The four
categories, or types of security zones we define in our model are:
1. Internet zone
2. Proxy zone
3. Data access zone
4. Intranet zone
As we define these four types of security zones, note that many of their
characteristics are derived from the connection restrictions we must have for a
given zone type to or from another type of zone. So as we define the zone, we
list some recommended guidelines that we use later for more specific policies for
connecting to the zone. Also note that we use language in our policy guidelines
such as “will have”, not words like “should have”. As you formulate your own
policies, be aware that they must make a clear distinction between what is
permitted and what is restricted, and do not allow critical restrictions to appear as
if they are something optional. In other words, avoid any ambiguous language.