security stances --- starting point for generic security policy

[Bennett Todd <bet () newritz mordor net>]

I just wrote this up for a friend, figured I'd circulate it here and see if
any of you folk have anything to add.

-Bennett

Security policies need to be set to reasonable tradeoff points in the balance
among security, implementation cost, functionality, and convenience.

Factors included in choosing the tradeoffs include the cost factor of risk
(how expensive will a given breach be) and functionality needs, which will
vary from one organization to another and within an organization.

They will also include the intrinsic security or lack thereof in various
protocols, and the historical record of specific implementations and the bugs
they have had. As a specific example of that last, it has not been formally
proven that it is impossible to write a web browser that can run applets
without security problems; however, every implementation of applets in a web
browser to date has had severe security problems.

While details of precise policy needs will vary from one setting to another,
certain broad generalizations apply, which usefully define baseline security
stances. These are "favourable plateus" in the multi-dimensional tradeoff,
places where the security achieved is good for the cost and inconvenience
incurred and the functionality forsaken.

Specifically, for high-security machines, the starting point for a security
stance would be

        inbound and outbound proxied SMTP email, possibly logged, possibly
                with content scanning, possibly restricted

        outbound-only http downloads, and ftp downloads using the http proxy,
                both with applet stripping in the proxy

        if neeed, specific, carefully-restricted ssh tunnels from authorized
                users inside to specially designated machines in the DMZ (the
                next network out in the layered security)

All machines inside this innermost security perimeter are totally unreachable
via direct IP connections from the outside, and their only communications are
proxied on the firewall, hence it's practical and appropriate to use RFC 1918
"private" addresses for them (10/8, 172.16/12, or 192.168/16).

Another very typical security stance is found in the DMZ areas in a typical
firm, or the bulk of the machines in an internet service firm. Here, the
individual hosts have to be directly exposed to the internet to perform the
functions for which they exist; they are there to provide public service. To
improve their security at a minial cost, they should live on network segments
that aren't shared with any other machines with different security needs (for
a diverse population of servers this may mean a separate router port for each
server). The router should impose screening rules of two valuable sorts.
First, it should prohibit traffic at the port level except for designated
services. E.g. a public web server may only need to be accessible via tcp/80
(HTTP); if so, that constraint can be enforced by the screening router at no
additional cost. The second sort of screening rules enforce IP address use; a
screening router is in a position to impose rules guaranteeing that no host
outside the screened net can forge source IP addresses of machines inside the
protected net, and pass the forged packets in through the screening router;
likewise, no host inside can assume the identity of a host outside. Machines

placed into this screened subnet should be configured as strictly as possible;
they should only run daemons for services which are required to perform their
business function, and if some such daemons (typically syslog for example) are
only needed by local clients and should not be accessed remotely, that
restriction can be reinforced by filtering software running on the server
(e.g. ipfw, or ipfilter). For machines in this screened net, if network remote
access is required for administration and maintenance, that should be
delivered via strongly protected protocol like ssh, permitted (by the
screening router, as well by the protocol's own crypto keys) only from
designated admin workstations, and ideally those machines would be inside the
high-security (proxy-only) net described above.