Managed Hardware Firewall Guideline

NOTE: The Information Security Office recently updated the UC Berkeley's Data Classification Standard and Protection Profiles for the Campus. These number changes are reflected on this page.

UC Berkeley security policy mandates compliance with Minimum Security Standard for Electronic Information for devices handling covered data.  The recommendations below are provided as optional guidance for boundary defense requirements.

Requirement

Resource Custodians must protect all core systems with a well-managed hardware firewall configured according to the principle of least privileges. These firewall rules must be reviewed annually and updated as necessary.

Description of Risk

Attackers can discover and exploit vulnerabilities in services and applications that do not need to be open to untrusted networks. A compromised system may be able to send confidential data to unauthorized systems.

Recommendations

Firewalls are used to separate networks with differing security requirements, such as the Internet and an internal network that houses devices with covered data, or internal networks that house varying protection levels of covered data, e.g., UC P2 or P3 data network vs. UC P4 data network.  Since one of the primary functions of a firewall is to prevent unwanted traffic from entering a network (and, in some cases, from exiting it), firewalls should be placed at the edge of logical network boundaries.  It’s important to design the network optimally such that the managed firewall is positioned to inspect all incoming or outgoing network traffic.  In the case where multiple entry points (ingress points) allow traffic into the covered network, traffic through each of the entry points should be routed through a firewall (or multiple firewalls) to ensure malicious traffic that would normally be blocked by the main entry point can enter the network by other means.  For additional network architecture design considerations, please refer to the NIST Firewall Guidelines in the Additional Resources section.  

When implementing a managed firewall, resource proprietor and resource custodian should follow the guidance below:

  • Firewall Management

    • All acceptable inbound and outbound traffic flows are cataloged and justified by documented business requirements.
    • All acceptable inbound and outbound traffic flows are reviewed on a quarterly basis to ensure existing firewall rules appropriately map to new or changing business requirements.
    • Any changes to the firewall rules and configurations must go through an established and documented approval process based on clear criteria.
    • Changes to firewall rules and configurations are logged such that such changes can be traced back to the original requests (via a ticketing system, for example).

  • Firewall Access Control - Principle of Least Privileges

    • A default deny rule is set for inbound traffic with explicit allow rules for valid traffic such that only inbound traffic that is necessary for the business operation of the institution is allowed through the firewall.
    • Rules are as granular as possible, i.e., the entire campus network must not be allowed to connect to a device if only a small number of systems actually need to connect.

Non-Host-Based (Hardware) firewall

To adequately protect MSSEI covered data and devices, non-host-based firewalls must be deployed in addition to host-based firewall, which is required by campus MSSND standard.

Whereas host-based firewall is software installed on covered devices, a non-host-based firewall is typically a physical network device designed to act as a stateful packet-inspecting device (i.e., it monitors the state of network connections and rejects packets not matching a known active connection).  A non-host-based firewall provides redundancy in firewall rules so that a mistake that accidentally allows malicious traffic by host-based firewall software doesn’t leave the overall system open.  For example, a covered device using built-in Microsoft Windows host-based firewall may “automatically” be updated to allow traffic by software installers without user interaction, which could leave the covered device vulnerable.  A non-host-based firewall device could provide a second line of defense to mitigate the impact of such misconfiguration.  A non-host-based firewall also segregates the function of logging and controlling traffic flow from the covered device in the event that a covered device is compromised, the hacker would not automatically have access to open up new firewall rules or stop firewall logging.

Campus IST offers a network-based firewall service that can be used to secure covered devices.  If a network segment cannot support a hardware firewall or a network-based firewall is not available, a router/switch with an Access Control List may be substituted.  

In the case of a virtual infrastructure, the firewall may be best situated at a virtual network boundary between two virtual machines (or groups of virtual machines) hosting different protection levels of covered data.  When securing covered devices hosted in the virtual infrastructure, a virtual machine (VM) running a hardened operating system dedicated to the firewall function (also known as a virtual firewall appliance) is also acceptable, provided that the virtual firewall appliance is implemented to provide the security features stated above.  To reduce the risk of a compromised VM using virtualization-layer communication mechanisms to launch attacks on virtual firewall appliance on the same host or even the hypervisor, virtual firewall appliance should also reside in a separate physical host than the covered devices it’s protecting.  

A host-based software firewall solution running on a covered VM is necessary but not sufficient to comply with this requirement (see also MSSND Host-Based Firewall requirement).

Additional Resources

On This Page