These policies, procedures, and related documentation are strictly confidential. The contents of these documents may not be revealed to unauthorized users.
Individual MUSC faculty, staff and students are authorized to access these documents on a "need-to-know" basis. Authorization to access these documents does not imply authorization to share these documents or the information they contain with anyone else, either inside or outside of MUSC.
The MUSC Internet Firewall Policy is documented here.
The MUSC Internet Firewall Procedures are documented here.
The MUSC Network Infrastructure Committee developed the new MUSC Internet Firewall Policy over a period of several months beginning in March 2001. The Policy was finalized and adopted in July 2001.
With the emergence of the Nimda worm on Sep 18, 2001, came a crisis which significantly accelerated the implementation of the new Policy. Within an hour of Nimda's emergence, MUSC's existing border firewall failed under the massive Internet-bound traffic connection load imposed on it by internal servers which had been infected by the Nimda worm. A decision was made to replace the existing firewall with new components which were already being tested and planned for deployment under the new firewall policy. A decision was also made to start with a "clean slate" of firewall rules, rather than to simply re-implement all of the rules from the previous Internet firewall, most of which were no longer relevant to MUSC's current business needs.
As a result of this accelerated implementation, many aspects of the new Firewall Policy have not yet been implemented, and will be phased in over the coming weeks and months. Among these are the Perimeter Network infrastructure, the centralized event logging infrastructure, the process for formally evaluating requests for firewall rules against MUSC business needs, and the process for conducting network security audits of servers for which firewall rules are requested.
There are certain deprecated rules, which were active on the old firewall, which will not be activated on the new firewall, except perhaps in rare cases where there is no practical workaround. These deprecated rules involve the following Internet protocols:
When the Perimeter Network infrastructure is in place, we will begin fully implementing the Firewall Policy as follows. Initially, the Perimeter Network will be empty, and all servers with existing firewall rules will still be on the Internal Network. We will work with the System Administrator of each Server to complete the steps outlined in the Firewall Procedures document, including scheduling of vulnerability assessment and configuration of remote event logging. If and only if these steps are completed, will the Server will be re-addressed onto the Perimeter Network.
Any Server which cannot meet, or whose System Administrator does not wish to meet, the requirements for the Perimeter Network, will not be permitted to continue to accept incoming connections from the Internet. Workarounds for any such cases which arise will need to be identified. For example, a Server on the Internal Network which requires remote administration via ssh, but which for one reason or another cannot or should not be re-addressed onto the Perimeter Network, may need to be reached indirectly, through a Server on the Perimeter Network. It is expected that the new VPN Server, which will be located on the Perimeter Network, can mediate many of these types of connections.
Some current Servers may have split personality problems, which the introduction of the Perimeter Network will reveal. For example, a particular Server might provide Web services to remote users on the Internet, so it must be moved to the Perimeter Network. That same Server might also provide file or database storage services for sensitive internal information, so it must stay on the Internal Network. Since no server can be on both networks, the two services will need to be re-engineered, e.g. distributed onto separate hardware.