Protecting a network boundary is a complicated and ever-changing task. Information monitoring is essential to protect data confidentiality and network integrity. Proper network monitoring occurs through the application of a blend of network perimeter devices and host-based security protections.
In order to assist agencies entrusted with FTI, the IRS has developed the following network boundary security requirements based on the IRS Publication 1075, Tax Information Security Guidelines for Federal, State, and Local Agencies and the National Institute for Standards and Technology (NIST). Additional guidance is derived from the Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs) and the Center for Internet Security (CIS) Benchmarks.
Pub. 1075 outlines the requirements for boundary protection in the System and Communications (SC) family of controls under section 22.214.171.124, Boundary Protection (SC-7). This security control requires that the information system:
“monitor and control communications at the external boundary of the information system and at key internal boundaries within the system.”
These boundaries are referred to for the purposes of this document as managed interfaces employing boundary protection. NIST 800-53 Revision 4 defines these devices to “include for example, proxies, gateways, routers, firewalls, guards or encrypted tunnels arranged in an effective security architecture (e.g. routers protecting firewalls and application gateways residing on a protected subnetwork commonly referred to as a demilitarized zone or DMZ).”
According to Pub. 1075, it is the responsibility of the organization to build effective security controls into their own Information Technology (IT) infrastructure to ensure that this information is protected at all points where federal tax information (FTI) is received, transmitted, stored and processed. This includes the need for the agency to adequately protect their network boundaries wherever FTI is received, processed, transmitted or stored.
Mandatory Requirements for FTI in a Networked Environment
To utilize a networked environment to receive, transmit, store or process FTI, the agency must meet the following mandatory requirements:
1) Controlling FTI Network Communications
The managed interfaces employing boundary protection, such as firewalls, must be configured to specifically address traffic flow to the infrastructure devices involved in FTI data flow and storage. Each protection mechanism and configuration setting must have a specific purpose related to the receipt, storage, processing and transmittal of FTI.
To accomplish this and create an effective “defense-in-depth” security posture, agencies must implement boundary protection devices throughout their system architecture, including routers, firewalls, switches and Intrusion Detection Systems (IDS).
Proper segmentation is essential to ensuring network protection. A “defense-in-depth” security posture must be designed and implemented by the agencies. Per NIST SP 800-41, Revision 1, “Defense-in-depth involves creating multiple layers of security. This allows risk to be better managed, because if one layer of defense becomes compromised, another layer is there to contain the attack.”
An architectural design which includes a very large “flat” network, lacks segmentation and leaves FTI vulnerable to potential compromise because boundary devices are often only placed at the perimeter and must cover a large number of devices, requiring a configuration which allows more traffic than that necessary to receive, store, process or transmit FTI.
2) Protecting FTI from Public Components
Protecting FTI from being accessed by the public or those individuals who do not have a specific need to know must be the cornerstone of the agency’s network security architecture and design. This includes:
- Implementing a screened subnet (DMZ) architecture to provide boundary protection for network segments containing FTI. Any publicly accessible servers used in the receipt, process, transmission or storage of FTI must be placed into an enclave DMZ. This enclave DMZ will act as an inspection point for public traffic and must apply content filtering to inbound traffic, such as through a web proxy, to protect network resource from potentially malicious traffic.
- Network Address Translation (NAT) must be implemented at the public traffic demarcation point on the network. If NAT is not implemented at the agency’s boundary firewall or router then, it must be implemented on each firewall or router that protects network segments that contain infrastructure components which receive, process, store, or transmit FTI. Keeping internal addresses confidential helps to reduce the chances that an attacker will gain a foothold in the network. Through the application of NAT, local area network addresses are obfuscated. Agencies must protect their internal IPv4 or IPv6 addresses through the application of NAT at either the perimeter router or firewall.
- Inbound filtering must be performed to exclude or reject all data packets that have an internal host address.
3) Managing Interfaces Employing Boundary Protection Configuration
When configuring the managed interfaces employing boundary protection, it is important to consider the device’s intended use. Per NIST 800-41 “Use devices as they were intended to be used. Firewalls should not be constructed of equipment not meant for firewall use. For example, routers are meant to handle routing, not highly complex filtering, which can cause an excess burden on the router’s processor.”
The devices used to provide security must have as its primary purpose security activities, such as providing data confidentiality and integrity, identification of vulnerabilities and defense against the compromise of FTI by adversaries.
Firewalls and Intrusion Detection Systems (IDS)
The agency’s managed interfaces employing boundary protection must deny network traffic by default and allow network traffic by exception (deny all, permit by exception). All remote traffic must migrate through a managed interface. Firewalls shall be configured to prohibit any Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) service or other protocol/service that is not explicitly permitted (i.e. “deny-by-default”). For each permitted service, the following information shall be documented:
- Service allowed (including TCP or UDP port number),
- Service description,
- Business case necessitating the service and
- Internal controls associated with the service.
Inbound services shall be prohibited unless a valid business case can establish their necessity. Inbound services shall provide strong authentication using one-time or session passwords, challenge and response protocols, digital signatures or encryption.
Approval to use these services must not be granted unless it can be demonstrated that the selected firewall configuration provides adequate security. Screening routers (if used as a firewall component) shall have the capability to filter based on TCP and UDP ports as well as IP addresses and incoming network interfaces.
4) Monitoring FTI Network Communications
The agency must monitor communications that occur at the host level and implement protection mechanisms which are specifically tailored to the infrastructure components which receive process, transmit and store FTI. This must include some type of host-based protection mechanism, which both protects and takes action to prevent harm on the host; a Host Intrusion Prevention System (HIPS) is an example of one such mechanism.
Host Intrusion Prevention System (HIPS)
Employing a HIPS is especially important for hosts which may be located behind a firewall which is more permissive than is required for that particular server. A HIPS detects actions as they occur and can take action to prevent damage and potential information disclosure on the system where they are installed (the host), unlike an IDS which alerts, but does not reactively respond.
Installation of a Host Intrusion Protection System (HIPS) HIPS on each server which stores, processes, receives or transmits FTI allows for more granular and specific protection. Current HIPS typically employ behavioral and signature analysis, giving agencies a dynamic layer of security protection, which “learns” and responds to host-specific traffic and events as they occur. This can reduce system administration time and costs because static rules do not need to be adjusted in response to constantly emerging threats.
Additionally, the host is better protected against malware and other software-based network threats which would not necessarily be identified by another managed interface employing boundary protection because the HIPS analyzes normal traffic for the host and creates a protection profile based on this information.
Agencies must configure the HIPS to specifically address each host that receives, transmits, processes and stores FTI. This includes documenting the baseline HIPS settings, and any deviations necessary to maintain normal business operations. This documentation must include a listing of suspicious events that the HIPS is monitoring and preventing. All HIPS must be able to perform the following functions:
- Record information about events,
- Notify security administrators if activity is observed that meets the “undesirable events” threshold and
- Produce reports.
NIST SP 800-94 outlines the security capabilities for HIPS. HIPS installed by the agency to meet this must capture the following information for each suspicious event observed:
- Event/ alert type,
- Rating (priority, severity, etc.),
- Event details- IP host and destination and port and
- Prevention action taken and whether it was successful or unsuccessful.
HIPS can respond to suspicious events in a variety of ways, but the HIPS employed by the agency must be able to respond to suspicious events in one or more of the following ways:
- Stop the attack. This could include terminating the network connection, and blocking access to the target.
- Alter the security posture of the host. This includes reconfiguration of network devices, and applying patches.
- Altering the attack makeup. This could include removing infected attachments from emails and sending along only the clean content.
Firewalls and IDS
All firewall systems shall enable an audit capability to monitor firewall operation, provide remote notification and substantiate investigations of real or perceived violations of local security policies.
At a minimum, the logs shall track services that are allowed or denied by the firewall, attempted access to network services, rejected source routed addresses, ICMP redirects and any additional system information the local security officer deems relevant.
The firewall syslog (or comparable) logs shall be reviewed regularly (recommend weekly) and retained for at least 7 years. All firewall consoles shall be located in a physically secure area and require technical controls equal to or exceeding the minimum security requirements specified in Pub. 1075.
If any agency firewall protects infrastructure components that receive, transmit, process or store FTI are accessible from the Internet, they must provide an intrusion detection capability that provides real-time alerts when an attack or attempt at bypassing system security occurs and appropriate action taken. This capability must be implemented and incorporated into the agency’s incident response policies and procedures.
Any and all firewall and IDS alerts must be written to local and remote consoles and acknowledged by an administrator and the alerts and corresponding acknowledgement must be logged.
As agencies look to consolidate resources and information systems, it is important to maintain a strong defense-in-depth posture with virtual networking interconnections (such as virtual switches or vSwitches). As with physical infrastructure, virtual servers that serve a public facing function (such as a web or application server) must be segmented from internal-facing servers. FTI nodes must also be separated from non-FTI nodes within the virtual network.
Recommended Requirements for FTI in a Networked Environment
Additionally, the IRS Office of Safeguards recommends the following security requirements be implemented by agencies:
1) Place infrastructure components which are involved in the receipt, processing, storage, or transmission of FTI on a separate vLAN.
- Publication 1075 (PDF), Tax Information Security Guidelines For Federal, State and Local Agencies
- NIST SP 800-53 Revision 4, Recommended Security Controls for Federal Information Systems and Organizations
- NIST SP 800-41 Revision 1, Guidelines on Firewalls and Firewall Policy
- Internal Revenue Manual Part 10 Security, Privacy and Assurance
- NIST SP 800-94 Guide to Intrusion Detection and Prevention Systems (IDPS), February 2007
- CIS Benchmarks