Re: security stances --- starting point for generic security poli cy

[Adam Shostack <adam () homeport org>]

Do you know what your partner's security policy is?  How much time and 
effort do they spend on enforcement?  Who else is linking up with them 
in this fashion?  Most managers go white with fear when they discover
that the remote party can't answer these questions to assess risks.
(Note: If you can't verify the answers to these questions, you are in
fact unable to demonstrate how this link is different than simply
linking the public internet past your internal security permiter.)

Adam




On Tue, Feb 02, 1999 at 03:09:05PM -0600, Perry, David wrote:
|       What is your opinion on the use of IPsec VPN tunnels extending
| into the innermost security perimeter from external business partners?
| For example in the medical field there may be an internal system
| containing patient information that a third-party managed care company
| must access, but we don't want it accessable by the general public,
| therefore we don't want to place this service in the DMZ.
| 
|       Thanks,
| 
|       David Perry
|       SRA International
| 
| 
| > -----Original Message-----
| > From:       Bennett Todd [SMTP:bet () newritz mordor net]
| > Sent:       Friday, January 29, 1999 2:56 PM
| > To: Firewall Wizards List
| > Subject:    security stances --- starting point for generic security
| > policy
| > 
| > 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.

-- 
"It is seldom that liberty of any kind is lost all at once."
                                                       -Hume