IRS Logo
Print - Click this link to Print this page

Operational Security Policies and Procedures Technical Memo

Purpose

To provide agencies with a clear understanding of several key operational security functions that should be performed throughout the year to maintain confidentiality of FTI and compliance with Publication 1075. This will also provide examples and resources to assist agencies in creating new operational security policies and procedures or aid with enhancing existing programs.

Introduction

Integrating routine security activities into daily agency operations will help improve the security posture of the agency and assist with meeting compliance requirements at local, state, and Federal levels. It will meet the common goal between agencies and the IRS to safeguard Federal tax information (FTI). Additionally, implementing operational security procedures will help agencies with the effort needed to meet IRS reporting requirements which include completing the Safeguard Activity Report (SAR) and Safeguard Procedures Report (SPR). Current operational security procedures related to safeguarding FTI consists of the SAR process in which agencies provide updates to their safeguarding procedures on an annual basis.

The computer security controls outlined in the current version of the IRS Publication 1075 direct agencies to several key areas which focus on operational security. These areas include, risk assessment, vulnerability scanning/host configuration compliance, patch management, and incident response reporting. Agencies that are compliant with Safeguarding requirements in these areas have a significant advantage when it comes to integrating security into IT operations.

The recommendations outlined in this memo is for all systems that receive, process, store or transmit FTI, including Tumbleweed workstations and server, database servers, application servers, file servers, mainframes, routers, switches and firewalls. However agencies should consider applying the recommendations to all agency IT operations for enhanced security and compliance.

Operational Security and Compliance Activities

Safeguard Activity Report (SAR) / Safeguard Procedures Report (SPR)

IRC Section 6103(p)(4)(E) requires agencies receiving FTI to file a report that describes the procedures established and used by the agency for ensuring the confidentiality of the information received from the IRS. The Safeguard Procedures Report (SPR) is a record of how FTI is processed by the agency; it states how it is protected from unauthorized disclosure by that agency. Annually thereafter, the agency shall file a Safeguard Activity Report (SAR). This report advises the IRS of minor changes to the procedures or safeguards described in the SPR. It also advises the IRS of future actions that will affect the agency's safeguard procedures, summarizes the agency's current efforts to ensure the confidentiality of FTI, and finally, certifies that the agency is protecting FTI pursuant to IRC Section 6103(p)(4) and the agency's own security requirements.

Note: Presently agencies must submit a new SPR before they begin to initially receive FTI, whenever significant changes occur in their safeguard program or every six (6) years. Significant changes would include, but are not limited to, new computer equipment, facilities, or systems.

Another measure IRS requires is internal inspections by the recipient agency. The purpose is to ensure that adequate safeguard or security measures have been maintained. The agency should submit copies of these inspections to the IRS with the annual Safeguard Activity Report (see Section 7.4 – Annual Safeguard Activity Report). To provide an objective assessment, the inspection should be conducted by a function other than the using function. To provide reasonable assurance that FTI is adequately safeguarded, the inspection should address the safeguard requirements the IRC and the IRS impose. Agencies should establish a review cycle so that all local offices receiving FTI are reviewed within a three-year cycle. Headquarters office facilities housing FTI and the agency computer facility should be reviewed within an 18-month cycle, as well as contractors allowed under federal statutes and off-site storage facilities.

Risk Assessments

Performing a risk assessment of the system(s) that receive, process, store or transmit FTI on a periodic basis will improve the agency's ability understand and manage the risk faced to the confidentiality, integrity and availability of these IT assets and the FTI that require protection.  It is important to perform risk assessments periodically due to changes in computer equipment and software, organizational policies, and updated security requirements in IRS Publication 1075.  Existing resources such as legislative, internal, and state-level audits that the agency is already subject to can be leveraged when conducting risk assessments to ensure efficiency and maximum use of agency resources.  The results from these existing reviews that agencies are subject to can be tailored to focus on FTI systems, and agencies are encouraged to submit copies with the SAR as a part of the Internal Inspections process.

Although the frequency of conducting risk assessments is determined by agency policy, the IRS requires this activity be conducted at a minimum of every three years or whenever there are significant changes to the information system receiving, processing, transmitting, or storing FTI.  The triggers for defining what constitutes a major change is discussed later in this memo. NIST Special Publication 800-30 provides the steps recommended for implementing a comprehensive risk assessment process.  NIST also provides an example template Risk Assessment on their website.

Vulnerability Scanning/Host Configuration Compliance

Periodic vulnerability scanning is vital to maintaining security posture and confidentiality of FTI in light of frequent new exploits that are released.  The purpose of conducting vulnerability scans is to uncover exploitable system vulnerabilities such as unnecessary services, open ports, software code flaws, missing service packs or security patches, insecure configuration settings, and potential Denial-of-Service (DoS) vulnerabilities that could be used by an attacker to   gain unauthorized access of FTI.  Many commercial and freeware tools are available for conducting vulnerability scans and compliance validation.

Example vulnerability scanning products include Tenable Network Security Nessus, Application Security Inc. AppDetective, IBM ISS Internet Scanner, and Microsoft Baseline Security Analyzer (MBSA).   Although the frequency of conducting vulnerability scans and the particular vulnerability scanning tool utilized is determined by agency policy, the IRS requires that this activity be conducted at least quarterly or when significant new vulnerabilities affecting the system are identified and reported.

Example host configuration compliance tools include ThreatGuard Secutor Prime (a tool IRS uses while conducting onsite computer security reviews) and McAfee Policy Auditor.  The Office of Safeguards has resources available through its website to aid agencies in conducting compliance validation.   Both the Safeguard Physical Disclosure Security Evaluation Matrix (SDSEM) and Safeguard Computer Security Evaluation Matrices (SCSEMs) that are used to evaluate agency compliance with Publication 1075 during Safeguard reviews are available on the IRS website.  The SDSEM features test procedures related to physical security and disclosure requirements, and the SCSEMs feature IT security test procedures.  As these matrices are the test tools used by IRS staff in conducting Safeguard reviews, they are an excellent resource for an agency to utilize in an operational capacity to maintain compliance.

The IRS strongly recommends agencies test all SCSEM settings in a development/test environment prior to deploying them in operational environments because in some cases a security setting may  impact a system’s functionality and usability. Consequently, it is important to perform testing to determine the impact on system security, functionality, and usability. Ideally, the test system configuration should match the operational system configuration. Prior to making changes to the production system agencies should back up all critical data files on the system and if possible, make a full backup of the system to ensure it can be restored to its pre-SCSEM state if necessary.

Patch Management

Patch management is another integral piece of operational security.  Vendor patch releases serve many purposes such as usability and performance, but more frequently in the current IT environment, many contain fixes and software updates to address newly discovered security vulnerabilities and flaws.  It is important to monitor vendor web sites and mailing lists to identify newly announced security flaws and address them in a timely manner. This security practice not only applies to computers connected to a network but can also impact stand-alone systems given the right conditions.  Therefore, it is necessary to implement a patch management policy and procedures to 1) monitor for new vulnerabilities, flaws and patches, 2) identifying vulnerable systems and prioritizing system patching activities, 3) perform testing of patches for effectiveness and potential side-effects before deploying to production, and 4) deploy patches to vulnerable systems.   Notification may come directly from the vendor or from outside sources. Check with your software vendor to ensure your agency is notified when new patches are released.  Example sources include Microsoft Security Response Center and the U.S. Computer Emergency Readiness Team.  NIST SP 800-40 provides guidance for creating a patch management program.

Incident Response/Reporting

Preventative activities based on the results of risk and security assessments help to lower the number of incidents by security systems, but not all incidents can be prevented. Therefore an incident response and reporting capability is a critical resource for security operations. As required by Publication 1075, unauthorized inspection or disclosure of FTI, including breaches and security incidents, must be reported to the appropriate Agent-in-Charge, Treasury Inspector General for Tax Administration (TIGTA) and IRS Office of Safeguards.  Therefore, it is important to develop and regularly maintain and Incident Response Plan with supporting procedures that include specific procedures for incidents involving FTI.  NIST SP 800-61 provides guidance for developing a computer security incident handling guide. NIST also provides an example template Incident Response Plan on their website.

Plan of Action and Milestones

Vulnerabilities discovered during Safeguard reviews, internal inspections, risk assessments, vulnerability assessments, continuous monitoring exercises, and other security testing should be tracked, maintained, and mitigated using a Plan of Action and Milestones (POA&M).  This includes tracking weaknesses identified through non-Safeguard review security assessment activities including state audits and other internal or third party security assessments. A more robust POA&M management and resolution process that includes correlating findings from multiple assessment sources will help to achieve operational security through improved remediation and reporting.  Updating the POA&M is a frequency determined by the agency but it is recommended to review and make updates to this tool at least quarterly.  An example POA&M template can be found through NIST's website.

Defining Triggers Which Constitute a Major Change

Several activities defined in NIST SP 800-53 are required to be executed as a result of a major change.  A major change can result from changes to organizational policies and procedures and especially changes which impact IT infrastructure and information systems.  It is strongly recommended for an agency to contact the IRS Office of Safeguards prior to implementing a major change to discuss the impact the change may make to safeguarding procedures and to ensure continued compliance with Publication 1075.  It may also be helpful to have design documentation, diagrams, and implementation plans available for review during this dialog.

Below are a few examples of major changes:

  • The process for agency case works changes when field workers and/or facilities are given the ability to access FTI remotely.
  • An agency relocates the Data Center which stores system processing or storing FTI.
  • A significant IT platform change occurs (e.g.  Applications or data storage on a mainframe are moved to a distributed IT environment).  This does not include operating system upgrades (e.g. Windows 2000 to Windows 2003).

References/Related Topics

Page Last Reviewed or Updated: 01-Apr-2014