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 federal tax information FTI and compliance with Publication 1075, Tax Information Security Guidelines for Federal, State, and Local Agencies (Pub. 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 FTI. Additionally, implementing operational security procedures will help agencies meet IRS reporting requirements which include completing the Safeguard Security Report (SSR). The computer security controls outlined in the Section 4 of Pub. 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 these Safeguarding requirements have a significant advantage when it comes to integrating security into IT operations. The recommendations outlined here are 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 Security Report (SSR) 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 SSR is a record of how FTI is processed by the agency; it states how it is protected from unauthorized disclosure by that agency. The agency shall update and submit the SSR annually to encompass any changes that impact the protection of FTI. 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. IRS also requires internal inspections to be conducted by the recipient agency. Their 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 SSR (see Section 2.D.3 – Internal Inspections and On-Site Reviews). 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 three-year review cycle for all local offices receiving FTI. 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 Pub. 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 document. 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. Examples of 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. Examples of host configuration compliance tools include ThreatGuard Secutor Prime 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 Pub. 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. 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: monitor for new vulnerabilities, flaws and patches, identify vulnerable systems and prioritizing system patching activities, perform testing of patches for effectiveness and potential side-effects before deploying to production and 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 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 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 Pub. 1075, unauthorized inspection or disclosure of FTI, including breaches and security incidents, must be reported to the 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 correlating findings from multiple assessment sources will help to achieve operational security through improved remediation and reporting. The schedule to updating the POA&M is up to 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. Resources Publication 1075, Tax Information Security Guidelines for Federal, State, and Local Agencies PDF Office of Safeguards Reporting Improper Inspections or Disclosures NIST SP 800-30, Risk Management Guide for Information Technology Systems PDF NIST SP 800-40, Revision 3, Guide to Enterprise Patch Management Technologies PDF NIST SP 800-53, Revision 5, Recommended Security Controls for Federal Information Systems and Organizations PDF NIST SP 800-61, Computer Security Incident Handling Guide PDF Microsoft Security Response Center U.S. Computer Emergency Readiness Team
