Terminology

• Network and host-based firewalls:

  • Network firewalls filter traffic between two or more networks. There are typically many computers or devices connected to each network.

  • Host-based firewalls provide a layer of software on one computer or device that controls network traffic in and out of that single machine.

• Firewall rules, firewall policy, and the firewall decision-making process:

  • "Firewall rules" are the technical configuration of a firewall. This is also referred to as “firewall policy”, but are referred to here as “rules” to avoid confusion.

  • "Firewall policy" is campus IT policy about the decision-making for firewalls.

  • "Firewall decision-making" selects the firewall rules, and defines operating procedures for managing firewalls.

• Local firewall rules and common firewall rules:

  • Local firewall rules only affect a specific subnet. The rules may be managed and maintained by the network administrator of that subnet, or may be managed and maintained centrally.

  • Common firewall rules affect all subnets on a section of the campus network that is protected by a common firewall. The common rules are maintained by DoIT and the Office of Cybersecurity.

Advisory Group Charter

The Advisory Group Charter is a separate document. The charter and revisions to the charter must be consistent with the Policy and Implementation Plan, and must be approved by the Executive Sponsors.

The Advisory Group members are a mix of subject matter experts and members from representative campus units. The representative campus units should include both larger and smaller units. The larger units should include at least L&S, CALS, and SMPH.

Implementation Stages

1. Initially

   As described in the Policy,

   "The Group will initially advise on the common (shared) network firewall rules and operating procedures that apply to all devices and services on subnets protected behind the Next Generation firewalls."

2. Longer-term

   As described in the Policy,

   “…Longer-term, the Group will advise more generally on the administration, configuration, and operating procedures for network firewalls at UW-Madison.”

Firewall Operating Procedures

The Advisory Group develops and maintains operating procedures for network firewalls at UW-Madison. The operating procedures are subject to review by the Sponsors and Executive Sponsors.

Firewall Administrators

The Advisory Group will advise on the knowledge or training needed by someone serving as a firewall administrator. The Advisory Group will help set criteria to become a Certified Firewall Administrator, and what privileges that conveys.

Special Cases

1. Non-UW-Madison-owned Devices

   Regardless of who owns a device or who manages a device:

   1. Connection of a device to the network automatically makes that device subject to the firewall rules in force at the connection point.

   2. Firewall rule exceptions are granted based upon academic or business need, balanced with the risk posed by the rule change, and the availability of alternatives the meet the need or reduce the risk.

2. While a device is connected to the network, the network access of the device may be blocked or limited if it posses an unacceptable risk. This can be resolved by eliminating the risk, by reducing the risk to an acceptable level, by disconnecting the device, or by making the case that the risk is not, in fact, unacceptable, (i.e. it’s a mistake or a false positive.)

3. The Science DMZ is not affected by the common (shared) firewall rules.

4. Policy and Firewall Rule Exceptions

   Emergency Resolution:

   The operating procedures should include a quick emergency process for resolution of firewall rule exceptions for rules that are interfering with academic or business operations. This should include adjustments requested by faculty and staff, adjustments needed for testing and debugging by local firewall administrators, or other cases not yet identified. There should be a well known contact point to request emergency adjustments.

   Long-term Resolution:

   The general process described below is for finding long-term solutions where there is sufficient time to discuss and plan. It is not intended for use during emergency resolution. The operating procedures may elaborate upon the criteria or process as necessary.

   1. Criteria

      1. Academic or business need.

      2. Additional risk and compensating controls.

      3. Contractual, regulatory, or legal requirements.

      4. Acceptance of liability costs.

   2. Process

      1. Concerns are discussed informally, and resolved if possible.

      2. If concerns are not sufficiently resolved, the unit seeking an exception documents a proposed plan for an alternative arrangement and compensating controls. The unit communicates or meets with the Advisory Group. The situation is discussed, with the goal of understanding and resolving concerns.

      3. If concerns are not sufficiently resolved, the Advisory Group makes a recommendation on the extent to which the proposed plan is an appropriate alternative.

      4. The recommendation is automatically forwarded to the CISO, who may call upon the other Sponsors of the Advisory Group for assistance. The exception will be resolved in some manner. The Sponsors and/or the unit may elect to escalate to the Executive Sponsors of the Advisory Group and/or the Risk Executives of the affected systems.

Assessment

The Office of Cybersecurity will measure the success of the Policy, the Implementation Plan, the Advisory Group, and the operating procedures, and will report these to the Advisory Group and the Sponsors.

The Advisory Group and the Office of Cybersecurity should work together to develop success criteria. Data could include log files gathered by the Next Generation Firewalls or other systems, incident or event tracking, self assessments, surveys, meeting notes, exception requests, or other sources. The original goal is annual assessment, but that could be extended to biennial or triennial assessment.

Contact

Please address questions or comments to cybersecurity@cio.wisc.edu.

References