MUSC Internet Firewall Policy
$Id: firewall-policy.html,v 1.9 2001/09/26 17:26:12 gadsden Exp $ I. Purpose and Scope
MUSC's Internet Firewall is an important element in the overall security of MUSC's campus network. The Internet Firewall restricts MUSC's Internet traffic in specific ways, and it allows MUSC to analyze its Internet traffic in specific ways. Combined with other, complementary security controls, the Internet Firewall can protect MUSC's information assets from some of the security threats associated with MUSC's connection to the Internet. In addition to preventing some Internet security problems, the Internet Firewall improves MUSC's ability to detect and respond to any Internet security problems which do occur.
This Policy explains the role of the Internet Firewall in contributing to the security of MUSC's data network. It highlights where complementary security controls are needed. It covers the responsibilities of both network administrators and end users, and the consequences if responsibilities are not met.
This Policy applies to all components of the MUSC data network and to all of their authorized users, both local and remote.
II. Principles
MUSC's students, faculty and staff all benefit from their ability to access Internet resources with a minimum of restrictions. Teaching, learning, research and service would all suffer to some degree if Internet access were too much restricted. At the same time, MUSC has significant information assets entrusted to its care. MUSC has both legal and ethical responsibilities to protect these assets, whose confidentiality, integrity, and availability would be threatened if the assets were too little protected from Internet intrusions.
MUSC's Internet Firewall is a security control, whose goal is to reduce the risks, inherent in exposing MUSC's network to the Internet, to a level which MUSC can tolerate. The Internet Firewall must achieve this goal at the lowest possible cost, with the least possible intrusiveness and inconvenience to the network's authorized users, and with the least possible interference with the ability of MUSC and its individual units to efficiently meet their strategic objectives.
III. Default Policies for Outbound and Inbound Connections
An outbound connection is one which is initiated from inside the MUSC network. An inbound connection is one which is initiated from outside the MUSC network. Policies distinguish between outbound and inbound connections. Both outbound and inbound connections are network conversations or data flows between two network nodes, one inside the MUSC network and the other on the Internet, outside the MUSC network. In both types of connections, packets typically flow in both directions. The key distinction is where the conversation is initiated.
Internet servers (computers which accept inbound connections from the Internet) are exposed to a higher risk of intrusion than are computers which do not provide Internet services. Therefore, MUSC's Internet Firewall implements a Perimeter Network, which is a special subnet where all servers which accept inbound connections from the Internet must reside. Conceptually, MUSC's Internet Firewall divides the world into three layers. From outermost to innermost, the three layers are:
- Internet, Internet2 and other external IP networks
- Perimeter Network
- Internal Network
By enforcing a degree of separation between the servers on the Perimeter Network and the computers on the Internal Network, the Internet Firewall helps to prevent intruders from gaining access to computers on the Internal Network. For example, while a Web server on the Perimeter Network is exposed to a relatively high risk of intrusion, the separation between the Perimeter Network and the Internal Network, provided by the Internet Firewall, mitigates the risk that an intrusion of that Web server could be leveraged to gain unauthorized access to any sensitive administrative and patient care systems, which are located on the Internal Network.
A. Outbound Connections
Outbound connections are generally permitted by the Internet Firewall. Reason: The benefits realized from internally-initiated communications justify the risks assumed.
IP packet headers (source and destination addresses, source and destination ports, byte counts, timestamps) for all outbound connections are routinely logged by the Internet Firewall. Reason: While MUSC's users have a certain expectation of privacy when communicating over the network, MUSC is nevertheless accountable for all Internet traffic originating on its network, and must be able to investigate Internet misuse originating on its network. The logging of packet headers represents a balance between privacy and accountability.
The University reserves the right to log and inspect the full contents (packet headers and data) of any outbound connections which are involved in a violation of MUSC's information security policies. Any such inspections will be conducted in accordance with MUSC's defined information security and computer use policies, and in a manner that protects the privacy of authorized MUSC users to the extent possible. Reason: MUSC has both legal and ethical obligations to protect the security of its own information assets, and to prevent its network from being used to attack others.
B. Inbound Connections
Communications initiated from sources on the Internet to destinations on the Internal Network are never allowed. (Any system which accepts inbound connections from the Internet must reside on the Perimeter Network, not the Internal Network.)
Inbound connections from the Perimeter Network to systems on the Internal Network must be minimized.
All Internet servers located in the Perimeter Network, and any internal systems with which they initiate connections, must be hardened against known vulnerabilities. Reason: Internet servers are exposed to a much higher risk of intrusion than normal systems. They require a correspondingly higher level of resistance to attack.
All Internet servers located in the Perimeter Network must implement adequate security controls (e.g., encryption and authentication) to prevent unauthorized access of any sensitive data which they transmit over the Internet.
Any Internet server located in the Perimeter Network, and any internal system to which it initiates connections, must transmit, in real time, a specified subset of its system event logs to an MUSC logging facility. Reason: Internet servers are exposed to a much higher risk of intrusion than normal systems. They require a correspondingly higher level of attention.
IP packet headers for all inbound connections are routinely logged by the Internet Firewall. Reason: MUSC must be able to detect and respond to attempted intrusions into, or other unauthorized use of, all systems on its Internal Network.
The University reserves the right to log and inspect the full contents (packet headers and data) of any inbound connections which are involved in a violation of MUSC's information security policies. Such inspection will be conducted in accordance with MUSC's defined information security and computer use policies, and in a way that protects the privacy of authorized MUSC users to the maximum extent possible. Reason: MUSC has both legal and ethical obligations to protect the security of its information assets.
IV. Exceptions to Default Policies
A. Internet Firewall Rule Requests
The system administrator of a server located on (or to be located on) the MUSC Perimeter Network may request a Firewall "Rule" to allow inbound connections from the Internet to a specific (set of) service(s) on his server. Likewise, the system administrator of a server on the Internal Network may request a Firewall Rule to allow inbound communication from one or more systems on the Perimeter Network to his server.
The term "target server" will be used below to refer to the server which the requested Firewall Rule will allow inbound connections to reach, whether from the Internet to the Perimeter Network, or from the Perimeter Network to the Internal Network. In either case, the request must document the following:
System Administrator -- name, department, title, etc.
Request type -- Internet->PerimeterNet, or PerimeterNet->InternalNet
Firewall Rule specifications -- specific set(s) of protocol(s)/port(s)/direction(s) being requested, and the specific initiator and target IP address(es) if known
Target Server specifications -- description of software (operating system, application software, and any middleware) that will be handling inbound requests on the open port(s), including complete software version information
Description of application -- in general terms, what information will be provided to whom, how it will be provided, and why it needs to be provided this way
Justification -- how the requested network service will support MUSC's mission, and the impact on MUSC if the request were denied
Begin Date -- when the Rule should be activated
End Date -- when the Rule should be terminated
Management Contact -- name, title
Emergency Contacts -- names, roles, pagers, etc.
B. Responsibilities of MUSC Network Security
The term "Network Security" is used here to refer collectively to the organizational unit(s) responsible for administering MUSC's Internet Firewall Policy. Specific points of contact are defined in the Procedure companion to this Policy.
Network Security will coordinate the maintenance and publication of technical requirements for target servers, including:
Operating system and service hardening
Specifications for remote logging
Network Security will notify affected System Administrators of changes in MUSC requirements for target servers (e.g. new hardening requirements necessitated by newly discovered vulnerabilities)
Network Security will perform a vulnerability assessment of the target server prior to implementing any approved request. Network Security will schedule this audit with the System Administrator.
If a Firewall Rule request has been approved, Network Security will implement the request, after the target system has passed its initial audit and logging conformance test.
Network Security will perform periodic, unannounced audits of each target server on an on-going basis. Network Security will communicate the results of these audits to the System Administrator.
Network Security will process any changes to a Firewall Rule Request submitted the System Administrator of the target system, and will promptly notify the System Administrator if the changes are so significant that they require a re-approval process.
Network Security will notify System Administrators when approved Firewall Rules are due for renewal, and will process renewal requests when they are submitted.
Network Security has the authority to take whatever steps are necessary to protect MUSC's network in the event of an acute security problem with a target server, including disconnecting the server from the network. If conditions permit, Network Security will make every effort to consult with the designated Emergency Contacts for the affected target system(s) beforehand.
C. Responsibilities of System Administrator
The System Administrator is responsible for meeting the following requirements. The Initial Requirements must be met before Network Security will implement an approved request. The On-going Requirements must be met for the lifetime of an approved and implemented Rule. If at any time, any of the On-going Requirements for a target system are not met by the System Administrator, Network Security has the authority to take whatever steps are necessary to protect MUSC's network.
1. Initial Requirements
Initial Audit -- Network Security will perform an initial vulnerability assessment of the target server. The System Administrator will cooperate with the auditor(s) and will complete any remedial actions specified by the auditor.
Remote Logging Setup -- copies of a specified subset of the target server's event log records will be transmitted in real time to a central logging facility specified by MUSC. The System Administrator will demonstrate his system's conformance to MUSC's remote logging specifications.
2. On-going Requirements
Notification of Changes -- the System Administrator will promptly notify Network Security of any changes to any of the information documented in the Firewall Rule Request.
Notification of Incidents -- the System Administrator will promptly notify Network Security of any security incidents or anomalies involving the target system.
Audits -- Network Security will perform periodic, unannounced audits of the target system on an on-going basis. The System Administrator will promptly address any deficiencies identified.
Timely Response to Vulnerabilities -- if a vulnerability affecting the Rule's target hardware and software is discovered, the System Administrator will apply necessary patches or implement workarounds without undue delay.
D. Approvals
MUSC Network Security has the authority to review, and either approve or deny, all requests for new Firewall Rules.
If a request is approved, the System Administrator of the target system must meet all of the initial requirements outlined in this Policy before Network Security will implement the new Firewall Rule.
If a request is denied by Network Security, the System Administrator has the right to appeal that decision, as described in the Procedure companion to this document.
E. Renewal
All Firewall Rule Requests must be renewed on an annual basis.
Appendix A: Implementation and Migration
When the MUSC Internet Firewall Policy is first instituted, MUSC will have been connected to the Internet for more than 10 years without any formal firewall policies, and without a Perimeter Network. To minimize disruption of existing Internet services, the implementation of this Policy will be phased in.
As soon as the infrastructure which implements the Perimeter Network is established, new Internet services will be implemented on the Perimeter Network, if and only if they conform to this Policy.
Existing services which secure approval under this Policy will be migrated from the Internal Network to the Perimeter Network.
Existing services which do not conform to this Policy, but which are judged to be mission-critical, may also be temporarily migrated to the Perimeter Network if possible, or otherwise accommodated if necessary.