home Future Students Current Students Faculty and Staff Business and Community Online Courses
 
Firewall Standard

Scope

These Standards cover the configuration of Metropolitan Community College (MCC) network firewalls and PCI network service requirements.

Purpose

To establish a set of standards for implementing and maintaining secure network firewall configurations. Including but not limited to, defining network security segments or zones with the MCC network and the type and nature of traffic which will be allowed or denied access to those zones. Also, to maintain the stability of the network and increase the security for identified resources.

Roles and Responsibilities

ITS Engineering Staff

  • Installation, administration, and support of firewall equipment and software
  • Keeps PCI network diagrams up to date
  • Keeps PCI firewall, routers and switch patches against critical security patches within one month of release, less-risky changes are installed within 2-3 months
  • As approved by the Director of IT Network Services
    • Perform firewall configuration changes
    • Rule set configuration changes

 

Network Security Engineer

  • Evaluate firewall configuration change requests and forward for approval
  • Evaluate Firewall rule set change requests and forward for approval
  • Documents changes and business justification in the ITS Network Firewall Supporting Documentation
  • Run Vulnerability equipment scans for vulnerabilities prior to ruleset change
  • Run Vulnerability scans after firewall and router changes
  • Quarterly review of firewall configuration, access levels and rulesets
  • Regular review of firewall logs and PCI network components
  • Work with ITS Engineering Staff to remediate any security issues
  • Reports to IT Security Steering committee any non-compliance with the PM or Standard
  • Recommends changes to the firewall PM and standard

 

Director of IT Network Services

  • Reviews firewall configuration recommendation and requests from Network Security Engineer
  • Reviews firewall rule set recommendation and requests from Network Security Engineer

IT Security Steering Committee

  • Approves the updates and changes to the Firewall PM and standard
  • Addresses issues of non-compliance

 

Configuration

Firewalls should be configured to:

  • use stateful inspection
  • provide ingress filtering
  • restrict inbound and outbound traffic
  • not respond to external pings or traceroutes
  • to Network Address Translation (NAT) internal addresses
  • always change vendor-supplied defaults on firewalls, routers and switches
    • including but not limited to passwords
    • Simple Network Management Protocol (SNMP) community strings
    • elimination of unnecessary accounts

For PCI environments:

  • A firewall must exist between any wireless and PCI network blocking any non-business traffic
  • must not allow outbound traffic must have business justification such as access to service provider and merchant bank
  • inbound traffic must have a business justification and only allow services required
  • PCI web servers must reside in a PCI DMZ
  • If a credit card database is implement it must reside in the internal server network
  • PCI servers must use an internal RFC1918 address space

 

Network Security Zones

A set of clearly defined network zones, with different levels of security requirements, built to provide the proper secure levels of network access to the MCC community.

Campus academic network segment

A semi-restrictive group of networks, which contain MCC’s academic network traffic to provide internal and external connectivity to network and server resources as well as the internet.

Server network segment

A semi-restricted network that contains academic and business servers, access from the internet and academic network would be limited to needed services.

Management network segment

A restricted network that contains ITS network devices, such as network firewalls, routers, switches, and managing servers, used in providing and controlling access to MCC’s network.

DMZ

A sub network which contains academic and business servers which provide services over the Internet.

PCI DMZ

This contains the PCI protected systems.  Only traffic that has been business justified will be allowed to enter and leave this security zone.

 

Firewall Rulesets

Inbound Connections

Inbound connections are defined as connections originating from outside the MCC network/firewall and destined for the inside of the firewall. By default the firewall will deny all inbound connections. Rules must be approved and created to allow specific inbound connections. All firewall requests must come from the system owner. To place a firewall request fill out the  ITS network Firewall Change Request Control Form located in the forms bank.

All ports opened must have accompanying justification documented within ITS Network Firewall Supporting Documentation.

Network Firewall Change Control

Network firewall configuration changes must be approved by the Director of IT Network Services. Any change made to any network firewall needs to be documented using the ITS Network Firewall Change Control process.

For any service that needs to be open to the public, MCC requires a vulnerability scan of the server prior to permitting internet access. The server administrator will be required to fix all major and critical security problems before the Network Security Engineer will forward the request for approval.

Administrative Access

All administrative users must authenticate via a unique login. A backup administrator account shall only be used when required for console access.

All remote administrative access shall be encrypted via Virtual Private Network (VPN). Internal access to PCI firewalls, routers, and switches must use SSL or SSH.

Logging

All network firewalls will be configured to use system logging (syslog) to export its log messages to designated syslog servers. Firewalls will be configured to reject all SNMP requests. At a minimum, the firewall log will be configured to detect:

  • Emergencies, such as unusable messages
  • Alert, critical conditions, error and warning messages
  • Logon access and configuration attempts made to the firewall
  • Logs must be offloaded or copied to a secure centralized internal log server
  • Logs must be retained for one year, 3 months must be immediately available

Logging on all network components

All network components in the PCI environment must log:

  • All actions taken by any individual with root or administrative privileges
  • Access to audit trails
  • Invalid logical access attempts
  • Use of identification and authentication mechanisms is logged
  • Creation and deletion of system level objects

Log entries must include:

  • User identification
  • Type of event
  • Date and time stamp
  • Success or failure
  • Origination of event
  • Identity or name of affective component

 

Other requirements of Logging

  • Time-synchronization technology based on a time server which receives time signals from external sources based on International Atomic Time (TAI) or Coordinated Universal Time (UTC) (e.g., Network Time Protocol (NTP))
  • Only individuals with a business need should access time data
  • Any changes to time settings must be logged, monitored, and reviewed
  • Only individuals who have a job-related need can view audit trail files
  • Audit trail files must be protected from unauthorized modifications
  • Audit trail files must be backed up promptly to a centralized log server or media that is difficult to alter
  • Logs must be retained for one year, 3 months must be immediately available

 

Glossary

DMZ

Demilitarized Zone is a firewall configuration for a physical or logical sub network that contains and exposes an organization’s external services to the internet, The purpose of the DMZ is to add an additional layer of security to the College’s local area networks (LAN); an external attacker only has access to the equipment in the DMZ, rather than any other part of the network.

Version

Date

Approver

Change Description

1.0

8/15/2011

Information Security Steering Committee

Initial construction

1.0 8/13/2012 Information Security Steering Committee Annual Review

 

Back to Technology Procedures

Top

 
 
 
Contact Us