Presented 6 December 1995 at the DECUS U.S. Chapter Symposium in San Francisco, as Session SE020. Last updated 14 December 1995.
Abstract While Mosaic and commercial services have brought international attention to the Internet, many businesses are reluctant to connect. This session focuses on the risks of being connected and how to minimize them. The development of an Internet security policy, as part of an organizations's overall information security policy, and the use of to enforce those polices is described.
Speaker Dr. Stephen L. Arnold is an independent consultant with over 12 years of networking experience on OpenVMS, UNIX, and IBM mainframe and midrange systems. Steve specializes in internetworking, multiplatform electronic mail systems, and directory services.
This is an introductory, management session. The primary audience is managers of technology and technical people. Goals:
Reasons to connect (partial list):
Dangers of connecting (partial list):
The pressure from users, top managers, and technical personal to
connect to the Internet can be unbearable. You need a policy
framework to replace "anything goes".
Steps to Connect to the Internet
Lead with policy; support with technology!
Repeat this planning and implementation cycle at least annually.
Perhaps the most common pitfall is to begin implementing before policy is clear.
Complete Information Security
Network security is only a part of information security. Other parts include:
Security policies are not the only policies you need to safely participate in the Internet. You also need policies for:
Inappropriate use includes misuse of company property, mischarging resources to the wrong account, misconduct, sexual or other harassment, possesion of pornographic materials, gambling, conspiracy, etc.
Policies Versus Implementation
Do not confuse policies with implementation.
A policy might specify "identities of all users accessing our network from the Internet shall be authenticated by a two-factor technique".
An implementation might specify "users requiring strong authentication shall be issued cryptographic security tokens" and go on to specify the brand of token and security server, all their configuration parameters, and the procedures for issuing tokens and training users.
Marcus J. Ranum is the former Digital engineer responsible for the original DEC S.E.A.L. and Trusted Information Systems' Gaunlet firewalls and the T.I.S. firewall tools kit. He suggested these contents for Internet security policies to the firewalls mailing list: "
" In an ideal situation the organization in question will have a clear overall policy for proprietary information management. Internet connectivity (or any other form of connectivity!) should fall under that global umbrella, and not be treated as a special case.
" We've all seen people who are terrified of Internet, but who think nothing of dropping a T1 from their network to a quote service or wire service. All too often, I feel policies are too specific, when they should in fact be general and focused on intent rather than details.
" It's my belief that a well-crafted computer security policy will consist of several things:
" In broad terms, a policy is a set of guidelines in which organizational management states the level of protections it EXPECTS to have provided on ALL mission critical computing resources. The rest, then, are implementation details. The requirements should propagate downwards, and information about how the specific implementation details meet the requirements propagates upwards as far as they need to. In general, though, the organization requirements for protection should apply equally to mainframe access, host access, network access, Internet access, dialin access, and access to trusted or untrusted business partners.
Your policy task force should include empowered representatives from groups responsible for:
Your organization's chief executive officer should understand the importance of the work of the task force and personally charge the task force and ratify its work.
Take technical leadership to devise a balanced
Management understanding and support is essential for the success of a secure Internet connection. Management must:
The right consultant can sensitively train top management in these issues in ways that might be impossible for in-house staff.
Trade-Offs and Risk Assessment
Management must trade off among:
The main tradeoff is between 1 and 2. Use risk assessment to select an optimal solution for your situation.
Risk assessment would be easy if probabilities and costs were known, but they are hard to quantify.
You've lost control of the process when works like "nominal" (risk) and "unacceptable" (hazard) start to be used. Never say "never".
Network or Host Security?
Where will you manage your Internet security?
With Security in Depth, security is managed at every host. While apparently the most desirable approach, it may be unaffordable or impossible to implement.
Some elements of security-in-depth:
In general, security in depth is incompatible with distributed computing!
In a Border Defense, you maintain security at the (logical) perimeter of your network. The main problem with a border defense is that it can be bypassed. Dangers of using a border defense:
For a border defense, you must make policy on what is permitted to pass through the network perimeter. Your default policy is called your security "stance". There are two possibilities:
Unless circumstances force you into it, never use
Given your stance, what are the exceptions? These are the rules that must be frequently reviewed in the light of business and technological changes.
For an "everything prohibited by default" border defense, here is a useful policy starting point for many large businesses:
If you adopt policies as restrictive as this set, you will be under pressure to expand the list of permitted applications.
Demand that users obtain individual, commercial accounts from Internet access providers for their non-business use, such as small business activities, personal correspondence, list participation, and Web surfing.
You will eventually be pressured into supporting:
This session discusses only the TCP/IP protocols, the most common protocols used on the Internet. Others are:
Recommendation: Do not use other protocols through your firewall or over the Internet without adequate in-house expertise. This suggests the policy:
Restriction to TCP/IP applications is a good thing. You're designing a firewall, not an access server!
Many technical managers are sent shopping for firewalls without defined Internet security policies.
The key quality attribute of an Internet firewall is that it cost-effectively implements your policies, now and in the future.
The cost of a firewall configuration should be evaluated on a life cycle basis, as on-going costs will dwarf initial costs.
Firewalls are usually built from:
Bastion host software includes:
Bastion hosts are built to withstand direct exposure on the Internet:
Bastion hosts provide general purpose platforms to run software
that can implement any security policy.
IP routers relay packets between the networks that make up the Internet. Most routers can be configured to provide limited security by dropping ("screening") packets based on source or destination:
Routers provide platforms to run router vendor software to implement security policies that can be enforced by screening IP packets.
A bastion host can support application relays, circuit relays,
and packet filtering in any combination. Routers can only be
Firewall Topologies: Screened Subnet and Bastion Host(s)
The Web version of this presentation does not include figures at this time.
Firewall Topologies: Screened Subnets and Dual-Homed Bastion Host(s)
The Web version of this presentation does not include figures at this time.
For the strongest firewalls, routers are relegated to guarding bastion hosts agains spoofing attacks.
Multiple bastion hosts can be used for:
For operating system, use what you know!
Key factors for choosing an operating system:
Chapman and Zwicky, "Building Internet Firewalls", O'Reilly and Associates, 1995, ISBN 1-56592-124-0, $29.95. (800) 889 8969, facsimile +1 707 829 0104, email@example.com, or http://gnn.com/gnn/bus/ora/item/fire.html.
Cheswick and Bellovin, "Firewalls and Internet Security - Repelling the Wily Hacker", Addison Wesley, 1994, ISBN 0-201-63357-4. $26.95. (800) 824 7799, facsimile +1 617 944 7273, or http://www.aw.com/cp/Ches.html.
Curry et al., Site Security Handbook, For Your Information 8 (currently Request for Comments 1244), 1991. ftp://ds.InterNIC.Net/rfc/rfc1244.txt.
Did you ever offer to give a talk and later discover that there is a definitive work that covers the subject better than you ever could? The Site Security Handbook is such a work!
Garfinkel and Spafford, "Practical UNIX Security", O'Reilly
and Associates, 1991, ISBN 0-937175-72-2, $29.95. (800) 889 8969,
facsimile +1 707 829 0104,
Selected Resources: Mailing Lists
The Internet firewalls mailing list is a forum for firewall administrators and implementors. To subscribe to Firewalls, send "subscribe firewalls" in the body of a message (not on the Subject line) to MajorDomo@GreatCircle.Com. Archives of past Firewalls postings are available for anonymous FTP from ftp.greatcircle.com in pub/firewalls/archive or browse gopher://all.net/11/FireWalls.
A more specialized list is firstname.lastname@example.org. Subscribe by sending mail to MajorDomo@net.tamu.edu. It focuses more on university-specific policies than technology.
The Computer Emergency Response Team provides alerts of
vunerabilities in both vendor and freely available software and
maintains an FTP site:
facsimile +1 412 268 6989, emergencies +1 412 268 7090.
Selected Resources: Sample Policies
For pointers to more information, browse http://www.access.digex.net/~bdboyle/firewall.vendor.html , maintained by Catherine Fulmer, email@example.com.
Remember, the quality attribute of a commercial firewall is how
well it allows you to implement your policy. You must have a
policy before you attempt to evaluate these offerings!
Stephen L. Arnold, Ph.D., President
Arnold Consulting, Inc.
2530 Targhee Street, Madison, Wisconsin 53711-5491
Telephone: +1 608 278 7700
Facsimile: +1 608 278 7701
Back to the Arnold Consulting Welcome Page