Sequestered Solutions Alaska, LLC

801 B Street, Suite 100

Anchorage, Alaska 99501

FUNDAMENTALS
of
SYSTEM PROTECTION

SUMMARY
At the most-basic level, the only security principles that have lasted are:
• Simplicity, and
• Layering

At the next level, come the desirable actions:

• Access Control
• Accountability
• Audit Trails, and
• Data-Labeling

When one has the task of hardening (in the security sense) an information system, the
usual approach is to do the following, in order:
1. Sequester The System, Usually Behind A Firewall,
2. Limit The Services Operative On The Protected System,
3. Harden The Services That Must Be Operative, And
4. Harden (Or Replace) The Operating System, And Then
5. Assume That The System Is Actively Malicious, And Further Sequester It.

When these actions are properly completed, the potential damage from the system’s
possible malicious actions can be minimized, if not eliminated. Also, in general, when
these actions have been completed successfully, the system usually becomes enough
less attractive to attackers that the attackers often leave the system alone.

Of course, all information security is predicated on the adequacy of the physical and
personnel security implementations for the system in question.

BACKGROUND
Fundamentally, the only two security principles that have survived the test of time are
Simplicity and Layering. Simplicity, because it is essentially unarguable that if one
person cannot understand the security of a system, that system is not secure. There
has never been a known exception to this statement. Also, as a practical matter, it is
much simpler to configure, maintain, and understand a simpler system, and it is often
easier to understand the data generated by such a system. Layering because – in an

907.868.8678 voice 907.868.8678 fax www.sequesteredsolutions.com

ideal implementation – the security system can be engineered to require multiple,
synergistic failures before the overall system will have failed (i.e., that the system will
have allowed access or other privileges to an unauthorized user.)

Experienced attackers usually “break” or “break-into” an information system using one

of – or some combination of – three methods:
1. Causing a [relatively] large, complex software system to do something its
designers did not intend
2. Exploiting the interface between two [relatively] large, complex software
systems, or
3. Using “Social Engineering” to exploit a human being with some kind of legitimate
access to the target system

In general, all of these exploits attack violations of the principle of simplicity. All are
usually very effective; the choice of attack method is usually a matter of using outside
information or simply selecting which method – or combination of methods – seems
easiest at the time of the attack.

At a broad level, almost all of the defense or hardening techniques for an information
system involve some aspect of the strengthening of Access Control, Authentication,
Audit Trails, or Data Labeling. When all of these techniques work as designed, the
system is relatively secure against common attacks. Of course, there remain attacks
that exploit implementation failures, systemic failures, and errors in system design.
Historically, attacking a large, well-understood system has been a matter of finding
flaws in design, then finding areas where these flaws are compounded by flaws in
implementation. Again, most of these errors are failures of simplicity.

HARDENING INFORMATION SYSTEMS

While an enormous amount of research has gone into the details of hardening an
information system, the overall approach to hardening has remained remarkably stable
over the history of computer security, as a security discipline. This approach consists of
a sequence where the system is isolated as far as possible, the important parts of the
system are strengthened, and the resultant system is considered to be malicious. The
actual sequence of actions is detailed in the rest of this section.

This segment of this paper assumes that the system to be protected is networked with
other systems, and maybe connected to an outside environment, such as an internet,
or the Internet.

1. Sequester the System, Usually Behind a Firewall

As an implementation of the principle of layering, one often separates and layers the
exterior security functions into one system (usually one or more firewalls,) and a second

Page 2 of 5
system (the system being protected.) The useful, non-security functionality of the
overall system resides in the system being protected. The protected system is said to
be “sequestered” in the sense of being isolated, but with certain exceptions. For
example, a web server generally must be exposed to its intended user community, but
there is no reason to expose the web server to other user communities, nor is there any
reason to expose the web server to requests for services other than those specifically
required for web service. Both these sequesterings are usually implemented first in a
firewall. Of course, it may be impossible to effectively separate user communities
without allowing some access to the web server. Many web servers are initially
accessible by anyone on the Internet, but only those who can log in can go further.

2. Limit the Services Operative on the Protected System

As an implementation of the protected system’s contribution to the layering of the
overall implementation, and as a way of further simplifying the protected system, the
available services on the protected systems should be limited as far as practical. To
continue the example from the previous section, there is usually no reason for a web
server to also offer “file and print sharing.” These services may be useful to the
system’s owners, but making these services available also opens up significant avenues
of attack from the web server’s user community – that is, the actual user community
that can get access to the server; not necessarily the user community that was
intended when the system was set up and configured. Patently, there are examples for
almost any combination of services, but the principle is clear – at every level of the
system, one should not have any services available that are not necessary for the
authorized users of the system.

The previous paragraph implies that dedicating a system to a single service – or very
small number of interrelated services – is feasible. The usual argument against this
singularity of services is economic. If the hardware cost or other environmental costs
mandate that a single piece of hardware be used for multiple services – perhaps
services that are antagonistic in the security sense – it is usually quite feasible to use
virtual machines on that hardware. Each virtual machine would be limited to a smaller
user community with the appropriate access controls for that virtual machine. Many
common operating systems allow – or will soon allow – many virtual machines on a
single hardware platform. The slight increase in hardware requirements for virtual
machines is overwhelmed by the reduced vulnerability of the overall system, the
reduced consequences of the security failure of any of the virtual machines, and by the
dramatic simplifications in software maintenance of the individual virtual servers and
services.

3. Harden the Services That Must Be Operative

On any operating platform (i.e., on any hardware / operating-system combination,)
there are usually many variants of any given service software. Each of these variants

Page 3 of 5
will likely have a particular combination of speed, vulnerabilities, capabilities, and/or
ease of use. A technical, security, and management decision needs to be made as to
the acceptable tradeoffs between these elements. The unfavorable elements should be
removed from the platform. In this way, it is readily possible to get a higher level of
available security than is provided in the default installation of the operating system. Of
course, any service that is not needed should be made infinitely hard – that is, not
available at all.

As the system is put in production and maintenance, it is, of course, critically important
that whatever server software is used be continually kept up to date with security
patches and other security enhancements. As more-secure alternatives become
available, the technical, security, and management decision on which server software to
use should be revisited.

4. Harden (Or Replace) the Operating System

In a similar way to hardening the application server software, the operating-system
software should be hardened as much as possible. Essentially all operating systems can
be configured in various ways to control their performance. Many – if not most – of
these configuration decisions affects the system’s overall level of security. Most
available operating systems have commercial or US Government recommendations on
the appropriate configuration options.

It is often feasible to replace the default operating system with a simpler alternative.
To continue to use the previous example, almost all web pages can be provided using
the Apache web server running on a Linux platform. At the moment, there are many
fewer published, successful attacks on the Linux/Apache environment than there are an
the IIS/Windows environment. In addition, most open-source operating systems are
designed more modularly and with cleaner interfaces, so understanding of the system’s
source code is easier. Of course, the term “open-source” also means that the operating
system’s source code is readily available for review.

5. Assume That The System Is Actively Malicious, And Further Sequester It.
When all other steps have been completed, it is prudent to assume that the system is
still actively malicious, and to act accordingly. For example, the DOE Weapon’s
Laboratories were the first to formalize the assumption that “any machine that runs
user code is assumed to be malicious.” While this assumption is usually not true, it
does dramatically minimize the resulting consequences when the assumption is true.

Over the last three decades when this assumption has been used at these Laboratories,
the author is not aware of any technical failures in these networks that resulted in the
loss of protected information – all losses have been the result of human or procedural

Page 4 of 5
failures. In addition, the incremental costs of implementing this assumption have been
lower than anticipated.

Further sequestration of the system may involve physical or electronic isolation (such as
on an isolated network segment,) or it can involve more-complex separations. Again
using the web-server example, one could let the server access only a protected,
separate copy of a database, while only a different, secure machine can be used to
update the database. Further, one could provide a cryptographically verified copy of
the server software and of the database, periodically verify the information’s integrity
(much as TripWire does,) and reload the verified data whenever it is improperly
changed. This minimizes the effect of any intrusion. Admittedly, this kind of
verification is not trivial to set up and may be time-consuming, but it is well understood;
it does work; and it does minimize consequences and significantly lower the
unavoidable risks of running an accessible system.

About Sequestered Solutions Alaska, LLC Security

SSA principals and staff have over 50 years experience in providing Information Security
services for the US government, state and local governments, and a myriad of
commercial entities spanning the business landscape from banking, healthcare, legal,
manufacturing, education, technology, oil & gas ,and e-commerce enterprises. SSA
currently has staff with Top Secret and DoE Q clearances and the ability to engage
other security cleared individuals.

For more information, contact Dr. Lara Baker at (907) 868-8678 or visit our website at
www.sequesteredsolutions.com

Page 5 of 5