Kurt F. Sauer writes:
> It seems to me, though, that there ought to be some method of determining the
> risk associated with fielding a firewall, other than just to say that there
> is a risk of data from a "more sensitive network" flowing to a "less sensi-
> tive" one.
Yes and no. :)
I'd add the caveat that there's a real temptation to attach
numbers or matrices that might carry inaccurate assumptions, and which
can lead to inaccurate conclusions. I'm not slamming anyone here -- I've
caught myself doing this. You know, you're talking with some sultry-looking
mink-coat-wearing russian spy in a sleazy bar and she asks how secure your
firewall is and without thinking, you say, "Oh - probably 90%. I could work
real hard and maybe get it to 95%" It sounds good, but what does it *MEAN*?
I believe that for a firewall, assurance comes from soundness
of basic design principles. In order to have confidence that the basic
design principles are sound, you must be able to describe them clearly.
I believe the clarity requirement implies that the principles must, in
turn, be pretty simple. For fans of the Orange Book, this is a subtext
throughout the document; the software must be designed to work correctly,
to fail safely when it doesn't work correctly, and to have a minimal set
of dependencies for its security. These dependencies must also be
clearly enumerable. In short, it means that you have to be able to make
a good case that the security of your system flows from its being
well-designed, rather than its being a convoluted bodge of special
case rules. It is the difference between a brick (simple, elegant,
robust, works well within its parameters) and sendmail. Unfortunately,
bricks make lousy mailers; what is needed is a mailer with some of
the properties of the brick.
In the past on this list [about a month, maybe 2 ago] I
posted at length about the firewall toolkit and some of the
design rationale behind how it is intended to be employed. I feel
that it's a design that can give you practical high assurance --
while there's no formal model or any of that, you can at least
trace the assumptions, predict what would happen if they were
not true, and make some empirical tests to verify that things
appear to not be broken. I'm an experimental computer scientist,
and here's where I have to (politely) part company with the formal
methods folks, who appear to believe that software can be proven
to be correct. This amounts to proving that software does not
contain an error, which seems to be an attempt to prove nonexistence. :)
So, it's not *formal* assurance, but let me try to describe
the kind of assurance model that would make sense for a simple
high assurance firewall.
Example #1:
Requirement: Internet connectivity with absolute security
against network-based attack.
Implementation: Cut the T1 line with a pair of scissors
Assumptions: Cut T1 wires don't transmit data. TCP/IP relies
on data transmission and cannot work without it.
If there is no TCP/IP traffic to the firewall,
nobody can "talk" to it, therefore nobody can
break into it from over the network.
Test plan: Perform the cut. Examine the CSU/DSU status lights.
Attempt some network activity. Observe error
results.
Possible outcomes:
Outcome A) A reasonable set of practical tests all
indicate that there is no TCP/IP connectivity
to the network. Following our assumptions about
how TCP/IP works, there is no need to test the
implementation of our version of rlogind(8). :)
Outcome B) A reasonable set of practical tests indicate
that some kind of network service is *STILL*
available. Verify that the wire is cut, and if
it is, under our assumptions, start looking for
another wire to cut. Continue cutting wires until
the network activity goes away, then pat yourself
on the back and prepare to be fired.
Outcome C) Something else. Panic, have some coffee, draw
up new hypotheses, and test them.
That was a simple example, and a rather silly one, but hopefully
this seems to make sense. I'll try another one, that has some real world
usefulness:
Example #2:
Requirement: Internet connectivity with high security
against network-based attack. Service to
be provided is SMTP-based Email.
Implementation: Block all traffic between the Internet and
the firewall *EXCEPT* to the mail service.
Implement the mail service on the firewall
so that the mail service cannot be used to
compromise the firewall.
The mail service on the firewall is to be
implemented using a "dumb" SMTP listener
that runs with least privilege, and which
is chroot(2)ed to a group-only writeable
directory on a disk that is mounted for
write. The system/OS disk is mounted in
read-only mode, on a magneto-optical drive
with the write tab physically pulled. No
executables other than the mailer are
on the disk.
Network access to services other than the
mail service is restricted by use of a router
with a set of screening rules that permit only
traffic to/from the firewall, port tcp 25.
Site-specific audit of mail in/out is performed
by an as-yet-to-be-identified process which
may perform additional analysis (as specified
by corporate policy) before marking a message
as deliverable. Deliverable messages are routed
to their next hop by an unprivileged process
that talks client side SMTP.
Residual Risk: The mail service may transport trojan horses
or virusses. This risk cannot be mitigated by
the firewall and remains residual. Recommended
approaches to further reducing risk include
audit trail, user education, and site policy.
Assumptions: The O/S on the firewall's integrity is enforced
by the read-only disk. The in-memory image of
the O/S is enforced by the removal of all
software except for the mailer [talk about
an administrative headache -- we're looking
at a firewall that looks like DOS here...] :)
While the integrity of the mailer software
may be questionable, we attempt to minimize
the implementation, and will perform code reviews
to gain some confidence that it appears correct.
Test plan:
[Here the decision tree gets complex enough
that I'll fold it into the test plan]
Set it up.
From a number of external systems, probe the
network and firewall to see if it is possible
to transmit traffic to a port other than tcp 25.
If possible configure a LAN sniffer to help in
this test. If possible configure audit on the
router. Practical testing continues until we
are reasonably confident that port tcp 25 is
the only one that can get through.
Verify that the O/S disk has no extraneous
material, manually.
Verify that the O/S disk is read-only. Attempt
to create a file. It should fail.
Connect to the mailer and send a piece of mail.
Verify that the mail listener collects the mail.
Verify that the mail listener runs w/o privs --
by practical means; examine the process
table, and instrument the software with
runtime checks.
Verify that the mail listener runs chroot(2)ed
by practical means; examine the location
of a file created in "/" and have an
instrumented version attempt to break out.
Visually review the code as appropriate.
Verify that the site specific audit routines
are being called [they should be self-instrumenting]
Last step: after 6 months you have mail working, then your
boss asks for Xmosaic and NFS. Change your name, and move to the Yukon
and herd kodiak bears for a living instead. :)
mjr.
References:
|
|
