Date: 01 June 1997
Click here for printable version
Danny Smith
Technical Director
AUSCERT
auscert@auscert.org.au
Copyright © 1997, AUSCERT
Abstract
Security conscious organisations have learned the benefits of protecting
their information processing infrastructure from unauthorised actions by
intruders. This is usually achieved through a variety of security
mechanisms including the use of filtering routers and firewall systems.
Unfortunately, many organisations leave key systems open to attack due to
poor network design. This paper discusses typical scenarios which may
lead to possible compromises, and examines ways to overcome these problems.
Introduction
The concept of a security domain that is introduced in this paper is not
new. Many computer security practitioners have been (either explicitly
or implicitly) using the ideas presented here for many years in protecting
their networks.
What is required by all organisations is a more formal approach to the
definition and protection of the various security domains. Failure to do
this leaves an organisation open to attack and abuse. The purpose of this
paper is to introduce the reader to a more formal concept of a security
domain, how to recognise one, the dangers of sharing two domains of
differing security requirements, and how to design a network to use and
protect security domains.
A brief introduction to the three security requirements is used to provide
a better understanding of the risk assessment process. This process helps
to identify the differing security requirements for different parts of
the information processing infrastructure, and hence to define the security
domains.
Security Requirements
Security is often addressed as three main requirements: Confidentiality,
Integrity, and Availability. It is the breakdown of these requirements
that leads to problems requiring resolution. Loss of confidentiality may
embarrass the organisation, or destroy its credibility. Loss of integrity
may cause the organisation to lose control over its business. Loss of
Availability may limit the organisation's ability to perform its business
adequately, if at all.
Security protection mechanisms are often designed to increase one or more
of these three requirements, usually through security services including
authentication, access control, and non-repudiation.
Security Policies and Risk Assessment
Protecting computer systems against attack is more than implementing a
few simple security solutions. As organisations become increasingly
dependent on their information infrastructures for timely information,
the effect of losing access to that information becomes more pronounced.
Loss of access to the information may be just as devastating to an
organisation as loss of control of it.
Threats to the information infrastructure may take a variety of forms,
including accidental and deliberate threats. In many organisations,
protection has been provided to minimise the effect of accidental threats
such as fire, flood, power failure, or disk corruption. Some organisations
are starting to implement measures to minimise the effect of a deliberate
attack. This is usually achieved through a variety of security mechanisms
including the use of filtering routers and firewall systems.
Often, organisations have implemented these solutions without careful
consideration of a master approach to total security. It does not matter
if corporate information is unavailable due to a lightning strike or a
denial of service attack by an external intruder; the overall result is
still the same.
To provide a more holistic approach to computer security, organisations
must engage in a risk assessment exercise. A detailed description of this
process is beyond the scope of this paper, but the basic mechanisms are
important to understand. Organisations, in general, should perform the
following tasks before deciding what and how many security measures are
required to protect information systems:
- Identify the assets of the organisation that require protection. This
may include physical items such as computer hardware, blank stationery,
backup tapes; non-physical items such as data, software, network access;
and other usually unrecognised important issues such as the organisation's
reputation.
- Place a value on those assets. This will help determine the amount of
security required later.
- Determine what threats these assets may face. What are the attacks or
problems that could adversely affect this asset (deliberate and accidental)?
- Determine the types of vulnerabilities that could generate or cause this
threat. For example, the loss of air conditioning to the computers could
be brought about due to either a compressor failure or loss of power.
Different problems - same result (no air conditioning).
- Quantify the chance of a particular vulnerability actually occurring.
For example, in Brisbane, the threat of a serious earthquake may be
minimal, but the threat of a flash flood or lightning strike from a summer
thunderstorm could be significantly higher.
- By identifying the threats and their likelihood of occurring, and combining
that with the value of the asset, we can quantify the loss we are likely
to experience should that threat actually occur.
This is in essence the risk to that asset. Consider this as a two
dimensional matrix (see Figure 1): cost of the asset on one axis, and
risk of a threat on the other. In the area where there is a high risk to
a high cost asset, solutions should be put into place to reduce the risk
of loss to that asset. In the areas where there is either a low level of
risk to a high cost asset or high level of risk to a low cost asset, the
requirement to reduce the risk is not so clear. In the area where there
is a low risk to a low cost asset, there may be no need to do anything
more and the existing risk considered acceptable.
Figure 1.
- Security measures are implemented to reduce the risk to an asset to
an acceptable level. The more resource spent on security measures, the
lower the risk that can be achieved. The risk can usually never be totally
removed, and a small amount of residual risk is maintained. It is
generally not good business sense to spend more money on securing an asset
against some threat, than the cost of replacing the asset if some loss
occurs.
Security Domains
In this paper, the term Security Domain is used to describe a network of
computer systems that share a specified security level through a common
element. The security domain may not always be clearly defined, and many
security domains may overlap. In general, overlapping two different
security domains is not good practice, and may lead to a weakness in the
security systems.
The boundaries of a security domain can sometimes be difficult to identify.
This is particularly true in client-server applications, where the client
and server are quite a distance apart and the intervening network can be
considered to be secure (perhaps through the use of cryptography).
A more formal model of this concept has been previously described as "rings
of trust". In this model, outer rings contain a lower level of security,
and systems requiring higher levels of security are located inside the
inner rings. To move from an outer ring into an inner ring, extra security
mechanisms are encountered. This model is shown in Figure 2.
Figure 2.
Some easier examples of security domains are any part of the network that
relies on a form of trust relationship for correct operation. For example,
an NFS client expects that its NFS server will supply the correct file
details when requested. Should that server return false data (for example,
indicate a program is privileged when it should not be), then the potential
to compromise the client exists. Since the client and the server must
trust each other, these two machines can be considered to be in one
security domain.
Similar trust relationship protocols exist, such as the X window system
(due to poor authentication, the X server must trust the X clients), the
Berkeley trusted system commands (such as rlogin, rsh, and so on), NIS
clients and NIS servers.
Another example of security domains can be defined by the classification
of traffic that is found on the network connecting computers together.
If a system that requires a higher level of protection is connected to a
network which is accessible to the general public, then an increased
potential for compromise of that system exists. If a network was created
that was restricted to only essential traffic, and this was separated from
the public network, then this could decrease that potential for compromise.
Placing all machines that require general access on one network, and all
restricted machines on a separate network allows the restricted network
to be more effectively protected.
Security Domains by Example
Consider the following example which contains a number of security domains
that require different levels of protection.
A small organisation has a few computer systems. These systems are used
to transact the company's business including storing customer account
details, accessing the latest stock prices, providing computing support
for a small development team, and housing a public web site for clients
to access. This organisation may be protecting some of these systems by
locating them behind a commercially installed firewall system.
A sample picture is found in Figure 3.
Figure 3.
If the web system is located behind a firewall, then traffic from the
public network must be allowed through that firewall to that system. This
may provide one avenue of attack for an intruder.
If the web system is sharing disk space with another system (say a
development machine) via NFS, then these two machines could be considered
to be at the same security level.
If the development team are using NIS to distribute password files, then
each of the systems in the NIS domain could be considered to be at the
same security level.
If they are using the X window system within the organisation or trusted
system commands such as rlogin or rsh, then these systems could be grouped
into security domains due to the potential for an intruder to move from
one system to the next via these services.
If special protection is implemented to prevent a small number of systems
from accessing the global network, then these systems have had a special
security requirement established for them.
The analysis could go on, but it should be becoming clearer that different
systems have different security requirements. Some systems by nature of
their role, the services they run, the protocols they use, or the
restrictions placed upon them have a certain level of security
requirements. Other systems have a different level.
In this example, a problem with the web daemon could allow an intruder to
gain unauthorised access to that system running through the outer firewall.
From there, the NFS, NIS, X, or other relationships may be exploited to
gain further access to development systems, and from there potentially
access to the production systems.
This example demonstrates that different security domains have been
combined on the same network, and this may allow a breakdown in the total
security.
What the organisation needs to do is to examine their systems and operation
to determine how they could group systems, services, protocol requirements,
and restrictions together in the same place (or on the same machine) so
that appropriate levels of security can be applied.
For example, in the scenario above, placing the web daemon behind the
firewall may not significantly increase the security of that daemon as
the general public will still need to be able to reach those services.
Provided that no other services were offered by that system, then it might
be just as easily protected outside the firewall. Moving this system to
outside of the firewall may therefore not significantly reduce its
security. This will allow tighter controls on what traffic must be allowed
through the firewall to be implemented, thus significantly increasing the
security of internal machines.
Using NFS and a web daemon on the same system may also be a problem. The
web daemon is in general a service that requires full public access to be
totally effective, whereas NFS is a trust related protocol that is almost
never used over the wider network. Combining these two protocols together
(particularly where the general public are using one protocol, and we want
to restrict their use of the other) may allow an intruder to gain access
through one protocol, and leverage further access through the second. If
these two services were split into separate security domains (enforced by
filter rules), then the intruder would not be able to exploit a
vulnerability in one service which could possibly be used to gain
additional access through a second service.
If some machines on a network are to be restricted from using the global
network in some way (based upon address filtering), whilst other machines
on that same network are allowed full access, then all it takes is for
the user to change the address of a restricted machine and full access
can be gained. This can be limited through managed hubs and careful
filters, however, this is usually difficult to manage and extremely
inflexible. It is usually a better solution to place all restricted
machines on one network and restrict the entire network appropriately,
and place all unrestricted machines on another network with different
access restrictions. This can become difficult if there are many different
levels of restriction to implement however, this is usually not the case.
Identifying Security Domains
In general, the various security domains and their interaction becomes
clearer after an organisation performs the risk assessment exercise.
During that exercise, the assets and their required protection levels are
identified.
By combining systems and networks together that have a similar requirement
for security into a single place or onto one network, it is possible to
establish an appropriate level of security. This forms a security domain.
If two assets (such as the web pages and the client database) require
different protections, but are located in a single security domain (such
as on the same system or the same network), then a potential for problems
may exist.
Many organisations combine multiple services onto single machines in an
effort to reduce costs. It is imperative that the temptation to combine
services with differing security requirements onto one server is resisted.
Ultimately, it will be cheaper to purchase two servers to split the
services over, than it will be to recover from a major computer security
incident. By careful planning, it is possible to separate services onto
different systems, and combine a range of services with similar security
requirements onto the same system (or within the same security domain).
Combining Security Domains
Once the security domains are identified and the level of protection
determined, the interaction between those domains must be clearly defined
and strictly enforced. This enforcement can be implemented using screening
routers, firewalls, or other forms of boundary protection. For example,
it may be an acceptable requirement that electronic mail pass between
security domains (maybe from a single machine to another single machine)
but that all other traffic is restricted.
All attempts to circumvent boundary protections should be reported and
investigated.
By combining two or more security domains onto a single network, within
a single machine, or failing to adequately separate the security domains,
the effect is to lower the security requirements for each of those domains
to the lowest value in each of the three security requirements;
confidentiality, integrity, and availability.
Many organisations combine different security domains in inappropriate
ways, leaving the organisation open to attack. Using the "rings of trust"
model, the organisation's network may look something like the diagram
shown in Figure 4.
Figure 4.
Identifying the different rings should not be too difficult if some careful
thought is given to the design of the network and the services it offers.
Take care not to trade off one security requirement to satisfy another.
For example, one security domain could be a customer database that is
considered absolutely confidential. Access to that database could be
restricted to a few key personnel only, perhaps from set locations only,
and increased authentication schemes employed to ensure only authorised
access is granted.
Another security domain within the same organisation could be
the anonymous FTP server. This does not require the same level of
protection (in terms of confidentiality, although strict integrity or
availability requirements may still exist), and in general, requires a
much more open access policy for it to function successfully. Since DNS
often has the same security requirements, then placing the publicly
accessible DNS on this server may, at first, appear to a good idea.
If however, the correct operation of the customer database system requires
reliable access to the company's DNS server, then an attack on the DNS
server may cause problems in the operation of the database systems,
compromising the availability of information and seriously impacting the
business. In this example, availability has been sacrificed to improve
confidentiality and integrity.
Examples
The following are real examples where organisations have combined security
domains, and paid the price.
A university department had a single subnet which they shared between
staff systems and a student lab. The IP addresses for the student machines
were blocked at the router to prevent unauthenticated access to the wider
network. The addresses of the staff systems were not blocked. Students
soon learned that if they changed the address of their student system in
the lab to another IP address, they could get full network access. Word
of this spread, and the practice increased. New addresses were discovered
and used, causing staff systems to go offline as their address was
hijacked, and finally when the router address was hijacked, the entire
network failed to operate reliably.
An organisation implemented a firewall system to prevent unauthorised
network traffic into their site. They then allowed in Web traffic, FTP
traffic, ftp-data traffic, telnet, smtp, network time, news, gopher, and
a range of other services to a variety of internal systems. Effectively,
the firewall was nearly useless.
A university had a public access library catalog system connected to a
main backbone network where significant levels of traffic traversed. The
system was compromised and a password sniffer successfully captured
hundreds of passwords very quickly.
An organisation failed to filter NFS traffic at their router. This allowed
an intruder to gain access to the systems through a NFS vulnerability,
and the intruder then used this access to gain deeper penetrations into
the organisation.
A research institution protected their supercomputer from public access.
Unfortunately, they did not also protect the front-end computer systems
adequately. An intruder compromised the front-end systems, and from there
gained access to the super-computer.
A government department had many levels of trust relationships between
many computers within their organisation. They were not connected to the
Internet, so it was assumed they could not be attacked. The intruder
accessed one system via a modem, and from there managed to compromise a
significant portion of the network within hours.
An Example Solution
The diagram in Figure 5 shows an organisation that has performed their
risk assessment, and designed a network according to their needs (this
does not mean that this network will be suitable for all organisations!).
In this example, the organisation has a world wide web and ftp server
available to the general public, a highly protected production network
for transacting business, a development network for designing and testing
new software, and an infrastructure network (such as DNS) that both the
production and development networks can share. This means that the
production network is not relying on information that is sourced via the
development network, nor is it required that the development network access
the production network for infrastructure support. In addition, the public
network supplies infrastructure support to the general public that is
updated from the internal network regularly.
Figure 5.
Conclusion
By recognising computer systems, applications, or network services that
have a set requirement for security, it is possible to apply appropriate
protections. Combining two different levels of security requirements
lowers all security domains to the lowest common security level,
effectively reducing the security for many domains.
By separating the different security domains into different parts of the
network, they can be protected to an appropriate level which greatly
increases their security, and can assist the prevention of "domain jumping"
by intruders to gain deeper and more serious penetrations into the
organisation, or to seriously impact the organisation's access to their
information processing infrastructure.
|