IRS Could Fix User Portal Problems More Quickly, TIGTA Says

The Remediation of Configuration Weaknesses and Vulnerabilities in the Registered User Portal Should Be Improved

July 18, 2018

This report has cleared the Treasury Inspector General for Tax Administration disclosure review process and information determined to be restricted from public release has been redacted from this document.

Redaction Legend:

2 = Law Enforcement Techniques/Procedures and Guidelines for Law Enforcement Investigations or Prosecutions.

10 = Trade Secrets or Commercial/Financial Information

Highlights

Final Report issued on July 18, 2018

Highlights of Reference Number: 2018-20-036 to the Commissioner of Internal Revenue.

IMPACT ON TAXPAYERS

The Integrated Enterprise Portal (IEP) — Registered User Portal (RUP) is a web-enabled, electronic commerce infrastructure to provide secure, browser-based application services for tax practitioners and taxpayers to access IRS systems. Because sensitive tax information traverses through and resides on the IEP-RUP, the IRS and its web-based infrastructure are an attractive target for hackers. Configuration weaknesses and vulnerabilities in the IEP-RUP environment unnecessarily expose taxpayer data to unauthorized access and disclosure.

WHY TIGTA DID THE AUDIT

This audit was initiated to determine whether the IRS's IEP-RUP offering external web services to the public is timely patched and remediated when vulnerabilities or misconfigurations are identified.

WHAT TIGTA FOUND

The IEP-RUP infrastructure is owned and operated by a contractor for the Enterprise Operations organization's Enterprise Technology Implementation Division. TIGTA determined that the vulnerabilities and misconfigurations on various hardware, virtual machines, and software within the IEP-RUP were generally remediated. Specifically, our analyses of configuration and vulnerability scan reports found * * * 2 * * *
(* * * 2 * * * percent) of * * * 2 * * * high-risk configuration weaknesses identified by * * * 2 * * * scans and * * * 2 * * * (* * * 2 * * * percent) of * * * 2 * * * critical and high-risk vulnerabilities identified by * * * 2 * * * scans were remediated.

However, TIGTA remains concerned that the IRS has not timely remediated configuration weaknesses and vulnerabilities. For example, TIGTA found that * * * 2 * * * percent of high-risk configuration weaknesses identified by * * * 2 * * * scans were remediated after 30 calendar days. * * * 2 * * *, although there was reference to the 30-calendar day requirement for configuration weaknesses that were documented and managed to ensure that they were eventually resolved.

TIGTA also found that the contractor had an inventory list of the physical and virtual hardware and operating software in the RUP. However, the inventory list was not always accurate and complete.

WHAT TIGTA RECOMMENDED

TIGTA recommended that the Chief Information Officer establish * * * 2 * * *; ensure that the Cybersecurity organization performs follow-up validation on all corrected configuration weaknesses; comply with required processes to document, manage, and eventually resolve vulnerabilities identified by the contractor; update policies to use established processes that are consistent with required time frames; ensure that the contractor performs, at a minimum, an annual reconciliation of the IEP inventory; and ensure that the Cybersecurity organization includes the component inventory as part of its annual security assessment of the IEP-RUP.

The IRS agreed with eight of the nine recommendations, although it did not completely respond to two of the eight recommendations. The IRS plans to validate that the vulnerabilities have been remediated, review monthly status reports, and meet with stakeholders. The IRS also responded that it developed guidance for handling scan results and updated the patch management plan. The IRS partially disagreed with one recommendation. Our comments about the IRS's partial disagreement with our recommendations are discussed in the report.

---

July 18, 2018

MEMORANDUM FOR
COMMISSIONER OF INTERNAL REVENUE

FROM:
Michael E. McKenney
Deputy Inspector General for Audit

SUBJECT:
Final Audit Report — The Remediation of Configuration Weaknesses
and Vulnerabilities in the Registered User Portal Should Be Improved
(Audit # 201620007)

This report presents the results of our review to determine whether the Internal Revenue Service's (IRS) Integrated Enterprise Portal–Registered User Portal offering external web services to the public is timely patched and remediated when vulnerabilities or misconfigurations are identified. This audit is included in our Fiscal Year 2018 Annual Audit Plan and addresses the major management challenge of Security Over Taxpayer Data and Protection of IRS Resources.

Management's complete response to the draft report is included as Appendix V.

Copies of this report are also being sent to the IRS managers affected by the report recommendations. If you have any questions, please contact me or Danny R. Verneuille, Assistant Inspector General for Audit (Security and Information Technology Services).

---

Table of Contents

Background

Results of Review

Appendices

Abbreviations

CMDB	Configuration Management Database
FISMA	Federal Information Security Modernization Act
IEP	Integrated Enterprise Portal
IRM	Internal Revenue Manual
IRS	Internal Revenue Service
NIST	National Institute of Standards and Technology
POA&M	Plan of Action and Milestones
* * * 2 * * *	* * * 2 * * *
RUP	Registered User Portal
SLO	Service Level Objective
TIGTA	Treasury Inspector General for Tax Administration

---

Background

A vulnerability in the context of cybersecurity refers to a flaw or weakness in a computer system that, if left alone, could be exploited¹ or triggered by a threat source. Generally, a vulnerability can arise in two ways. First, a manufacturer may identify the flaw or weakness within its own product and will release a security patch to fix the vulnerability. Second, a security vulnerability can result from a misconfigured or inadvertent change to a system setting that causes an unintended weakness in the system.

The impact of vulnerable systems has been well documented in the last few years. For example, in October 2016, a National Security Agency official remarked that the high-profile Government hacks to which the National Security Agency has responded, including the cyberattacks on the Office of Personnel and Management and the White House, occurred because the adversary took advantage of poorly secured and poorly patched systems. Once the adversary got inside, he or she elevated his or her privileges and then moved to mission objectives, which ranged from stealing data to destroying it. This risk is heightened for externally facing systems that are accessible to the public via the Internet.

To minimize the exposure of these vulnerabilities, organizations should implement vulnerability management practices designed to proactively mitigate or prevent the exploitation of system vulnerabilities. This process involves the identification, classification, remediation, and mitigation of various vulnerabilities within a system. Vulnerability management is part of the larger cybersecurity risk management framework recommended by the National Institute of Standards and Technology (NIST). The June 5, 2014, updated version of NIST Special Publication 800-37² provided guidelines for applying a six-step Risk Management Framework to Federal information systems. The intent of the common framework is to improve information security, strengthen risk management processes, and encourage reciprocity among Federal agencies. The six steps include security control assessments, information system authorization, and security control monitoring.

According to NIST guidelines, information systems are in a constant state of change, with upgrades to hardware, software, or firmware and modifications to the surrounding environments where the systems reside and operate. A disciplined and structured approach to managing, controlling, and documenting changes to an information system or its environment of operation is an effective security control monitoring program. Strict configuration management and control processes are established by the organization to support such monitoring activities.

The Internal Revenue Service (IRS) continues to demonstrate its commitment to broaden taxpayers' access to secure digital services (in order to provide better assistance to those seeking to comply with the tax laws) by providing one-stop, web-based services for the general public, Federal agencies, and tax professionals from multiple channels. The IRS offers external web services for the public and employees through the Integrated Enterprise Portal (IEP). The IEP was designed to be an innovative and cost-effective system that would provide a fully scalable, managed private cloud capability to the IRS, enabling one-stop, web-based services for internal and external users. The IEP has four portals:

• The Public User Portal, IEP-IRS.gov, allows unrestricted public access to nonsensitive materials and application forms, instructions, news, and tax calculators. No authentication is required for access to any materials on the IEP-IRS.gov.

• The Registered User Portal (RUP) allows registered individuals, third-party users (collectively, “partners” — registration and login authentication required), and other individual taxpayers or their representatives access for interaction with selected tax processing and other sensitive systems, applications, and data.

• The Employee User Portal allows IRS employee users to access IRS data and systems, such as tax administration processing systems, financial information systems, and other data and applications, including mission-critical applications. Registration and authentication are required for access to sensitive and mission-critical applications.

• The Transaction Portal Environment provides the essential security and technology components required for secure structure data exchange between the IRS and the Centers for Medicare and Medicaid Services.

The IEP is a contractor-owned and managed service by * * * 10 * * *)³ for the Enterprise Operations organization's Enterprise Technology Implementation Division. The division leads the implementation and operations of enterprise technology programs, including third-party managed services. In addition, the division provides sustaining operations and enhancement support of portal components within the development, test, and production environments.

In its September 2015 Performance Work Statement, the contractor committed to operating the security program in accordance with the six-step Risk Management Framework except for the information systems authorization step, which the contractor stated is an IRS responsibility. The contractor established a Continuous Monitoring Plan that includes a mechanism to update its patch management plan, scan for vulnerabilities, and maintain secure configurations.

This review was performed at one of * * * 10 * * * offices and the Enterprise Operations organization's Enterprise Technology Implementation Division in Lanham, Maryland, during the period August 2016 through December 2017. We conducted this performance audit in accordance with generally accepted government auditing standards. Those standards require that we plan and perform the audit to obtain sufficient, appropriate evidence to provide a reasonable basis for our findings and conclusions based on our audit objective. We believe that the evidence obtained provides a reasonable basis for our findings and conclusions based on our audit objective. Detailed information on our audit objective, scope, and methodology is presented in Appendix I. Major contributors to the report are listed in Appendix II.

Results of Review

Based on our analyses of two different types of vulnerability and configuration scan reports, we determined that critical and high-risk vulnerabilities were generally remediated on hardware,⁴ virtual machines, and software⁵ in the IEP-RUP environment. Specifically, we found that the contractor had remediated 1,127 (91 percent) of * * * 2 * * * high-risk vulnerabilities identified from * * * 2 * * * scans and * * * 2 * * * (* * * 2 * * * percent) of * * * 2 * * * critical and high-risk vulnerabilities identified by * * * 2 * * *,⁶ scans. We also found that the contractor had implemented an automated patching process.

However, we identified two areas of improvement needed to ensure that the IRS's IEP-RUP is protected against the exploitation of unpatched vulnerabilities and misconfigurations.

• We had concerns over the length of time for vulnerabilities to be patched and configuration weaknesses to be remediated in the IEP-RUP environment.

• While the contractor maintained an inventory list of the hardware and software in the IEP-RUP environment, we found that the inventory list was not always accurate and complete.

Failure to keep operating systems and application software patched and configured securely is one of the most common issues identified by security and information technology professionals. Security weaknesses within the environment could allow hackers to disrupt communications with users, alter or destroy sensitive data, or gain unauthorized access to other agency resources. Because sensitive tax information traverses through and resides on the IEP-RUP, the IRS and its web-based infrastructure are an attractive target for hackers. Vulnerabilities in the IEP-RUP environment unnecessarily expose taxpayer data to unauthorized access and disclosure. In addition, an inaccurate and incomplete inventory of components means the contractor may not be aware of (and therefore cannot fix) vulnerabilities that exist in the IEP-RUP environment.

Network and System Scans Identified Configuration Weaknesses and Vulnerabilities on Network Devices and Servers That Were Not Remediated and Were Not Timely Corrected

* * * 2 * * *,⁷ * * * 2 * * *.

* * * 2 * * *

* * * 2 * * *	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
* * * 2 * * *	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
* * * 2 * * *	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
* * * 2 * * *	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
* * * 2 * * *	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *

* * * 2 * * *. * * * 2 * * *,⁸ * * * 2 * * *.

For the RUP environment, * * * 10 * * * prepared and the IRS agreed to implement the IEP Continuous Monitoring Plan, dated April 8, 2016. This plan provided an effective approach to update the security patch management plan, scan for vulnerabilities, and maintain secure configurations and the overall secure posture of the IRS IEP. Specifically, it instructed the contractor to follow the Plan of Action and Milestones (POA&M) process when potential system weaknesses or deficiencies were identified. The POA&M is used to document and manage the issue and to ensure that it is eventually resolved. The IEP Continuous Monitoring Plan further states that the remediation time frame for the POA&Ms that have been identified is the same as those in Figure 1. The POA&M is closed when the IRS approves it after the contractor has provided supporting artifacts, such as updated documentation, screenshots, and reports, verifying that proper remediation steps have been taken and appropriate changes have been put in place.

The IEP Continuous Monitoring Plan also references service level objectives (SLO) as pertinent to the success of IEP security. These SLOs are directly associated with and affected by the continuous monitoring program and are reported directly to IEP stakeholders. For security configuration compliance and security vulnerability remediation, the SLOs have been set at a compliance score of * * * 2 * * *.

* * * 2 * * *,⁹ * * * 2 * * *.

* * * 2 * * * configuration scan results showed that high-risk configuration weaknesses were not always remediated and were not always timely corrected

We reviewed the contractor's * * * 2 * * * Configuration Compliance reports from February 2016 through May 2017 and identified a total of * * * 2 * * * high-risk configuration weaknesses. * * * 2 * * *. We found that * * * 2 * * * (* * * 2 * * * percent) of * * * 2 * * * high-risk configuration weaknesses were remediated by the contractor. Conversely, this means that * * * 2 * * * (* * * 2 * * * percent) high-risk configuration weaknesses were not corrected as of May 24, 2017. Further analysis showed that these * * * 2 * * * configuration weaknesses * * * 2 * * *. Figure 2 shows a description of the vulnerability types along with the number of occurrences and the date they were first identified.

Figure 2: Unique High-Risk Configuration Weaknesses Identified in the * * * 2 * * * That Were Unresolved As of May 2017

Number	Date the Configuration Weaknesses Were First Identified10	Description of the Unique Configuration Weakness	Number of Occurrences
1	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
2	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
3	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
4	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
5	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
6	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
7	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
Total			* * * 2 * * *
Source: Treasury Inspector General for Tax Administration's (TIGTA) analysis of * * * 2 * * * Configuration Reports from February 2016 through May 2017.

The Cybersecurity organization's April 2017 annual Security Assessment Report of the IEP that was conducted from October 5, 2016, through January 11, 2017, identified * * * 2 * * *. Of the remaining * * * 2 * * * types, * * * 2 * * * was not found in the Cybersecurity organization's results because the date (March 22, 2017) was outside the review period. We believe * * * 2 * * * was due to the IRS's sampling methodology. The Cybersecurity organization recommended that the IRS's authorizing official ensure that configuration settings are configured to the most restrictive mode, are enforced, and are documented for all system components. The Cybersecurity organization also recommended ensuring that all vulnerabilities identified by policy checkers are reviewed, analyzed, and appropriately addressed in accordance with IRM 10.8.1, Information Technology Security, Policy and Guidance.

* * * 2 * * *, we found a POA&M that was created on May 8, 2017. However, the POA&M was closed on May 23, 2017, showing that the weaknesses were closed because of an approved risk-based decision that establishes a minimum baseline requirement of a * * * 2 * * * percent compliance level with no high-risk or critical findings. To support the closure of the weakness, the contractor was to provide the risk-based decision document with a * * * 2 * * * Configuration Compliance report showing that the contractor met or exceeded the * * * 2 * * * percent compliance level with no high-risk failing checks. * * * 2 * * *, we were unable to locate the required POA&Ms.

We reviewed the February and March 2016 * * * 2 * * * Configuration Compliance reports and determined that the contractor did not meet the SLO of * * * 2 * * * percent. For April and May 2016, the SLO did not apply because of * * * 2 * * *. For June 2016 through April 2017, the contractor met the SLO; however, we identified high-risk failed configuration weaknesses. Therefore, the risk-based decision should not have been applied, and the POA&M should not have been closed.

After we provided our findings to the IRS and the contractor in July 2017, the IRS authorized the retraction of the risk-based decision document, and the POA&M was listed as “in-progress” in the Department of the Treasury's management system.

Management Action: After the completion of fieldwork, the contractor's employees provided evidence that they had corrected all * * * 2 * * *. According to the contractor, * * * 2 * * * were now compliant with the configuration setting requirements. Because the corrections were provided to us after the end of our fieldwork, we did not verify that the configuration weaknesses were addressed * * * 2 * * *. The Cybersecurity organization's Security Risk Management office conducts periodic risk assessments of agency operations or assets and should include the verification in its next periodic assessment of the IEP.

For the * * * 2 * * * high-risk configuration weaknesses * * * 2 * * * that the contractor remediated, we found * * * 2 * * * ( * * * 2 * * * percent) high-risk configuration weaknesses that were remediated within 31 to 447 calendar days.¹¹ These servers support IEP-RUP applications, e.g., Modernized Electronic Filing and Foreign Account Tax Compliance Act,that taxpayers and tax practitioners use to obtain and transmit tax return information. Figure 3 shows the range of calendar days for the vulnerabilities.

Figure 3: High-Risk Configuration Weaknesses * * * 2 * * * That Were Not Remediated Within 30 Calendar Days

Range in Calendar Days to Remediate Identified Weakness	Configuration Weaknesses
* * * 2 * * *	* * * 2 * * *
* * * 2 * * *	* * * 2 * * *
* * * 2 * * *	* * * 2 * * *
* * * 2 * * *	* * * 2 * * *
* * * 2 * * *	* * * 2 * * *
Total	* * * 2 * * *
Source: TIGTA's analysis of * * * 2 * * * Configuration Reports from February 2016 through May 2017.

* * * 2 * * *. In addition, the fact that the contractor closed the * * * 2 * * * weaknesses in less
than * * * 2 * * * calendar days of the date we conducted our analysis and brought the high-risk configuration weaknesses to its attention sheds additional light on the length of time it takes to close high-risk configuration weaknesses during its day-to-day operations.

When we discussed our concerns over the length of time it took to remediate configuration weaknesses with the IRS and the contractor, * * * 2 * * *. We referred them to the contractually bound IEP Continuous Monitoring Plan, which was created by the contractor and signed by the IRS in April 2016, for reference to the timeliness criteria and its applicability to configuration weaknesses and the POA&Ms. Upon reviewing the plan, the IRS and the contractor stated that the remediation time frame was an error and they would remove the remediation time frame reference.

* * * 2 * * *.

* * * 2 * * * vulnerability scan results showed that vulnerabilities were * * * 2 * * *

From the contractor's * * * 2 * * * vulnerability scan results for October 2016 and February 2017, we identified * * * 2 * * * systems and system components, e.g., hypervisors, firewalls, and embedded systems, that were scanned in both reports. For these * * * 2 * * * systems and system components, the scan reports presented information on * * * 2 * * * vulnerabilities, i.e., critical, high-, medium-, and low-risk severity ratings, of which * * * 2 * * * (* * * 2 * * * percent) were remediated. Figure 4 provides the remediation status of the vulnerabilities by severity rating.

Figure 4: The Remediation Status of * * * 2 * * * Scanned Vulnerabilities by Severity Rating for October 2016 and February 2017

* * * 2 * * * Scan Vulnerability Severity Ratings	Vulnerabilities	Count and Percentage of Vulnerabilities Remediated		Count and Percentage of Vulnerabilities Not Remediated
Critical	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
High	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
Medium	* * * 2 * * *	* * * 2 * * *	* * * 2 * * **	* * * 2 * * *	* * * 2 * * *
Low	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
Total	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
Source: TIGTA’s analysis of Nessus scan results for October 2016 and February 2017.

While the contractor can improve on its overall *2* percent remediation rate, we found that the remediation rate for the critical and high-risk vulnerabilities was at *2* percent (* * * 2 * * * ). The remaining * * * 2 * * * vulnerabilities were not corrected in the **2** calendar days between * * * 2 * * *. We used the date the October 2016 * * * 2 * * * scan was completed and the end of the * * * 2 * * * scan in February 2017 to compute the number of calendar days the * * * 2 * * * vulnerabilities had not been remediated because the first date each vulnerability was identified and actually remediated were unknown, with the exception of those addressed later in this section.

Initially, we focused our attention on the * * * 2 * * * critical and the * * * 2 * * * high-risk vulnerabilities because of their severity rating. * * * 2 * * *

• * * * 2 * * *

• * * * 2 * * *

• * * * 2 * * *

The * * ** 2 * * * critical-severity vulnerabilities that were not remediated were reevaluated, and the severity ratings were changed to medium and low. When we presented our audit results to the contractor, the contractor explained that the * * * 2 * * *-identified critical-severity vulnerabilities were reevaluated using the Cybersecurity organization's* * * 2 * * *, and the severity ratings were changed to medium and low. The matrix consists of seven questions that the contractor answered about each of the vulnerabilities based on the contractor's knowledge of the actions needed to protect the systems and its components. The seven questions included the following three:

For each question, a numeric rating range between one and 10 was considered to determine the overall severity rating. At the completion of our fieldwork, the contractor shared its answers, and we determined the numeric ratings based on the contractor's answers for each severity rating that was changed. We did not conduct a comprehensive and detailed review of each of the answers and the numeric ratings. Regarding the **2** vulnerabilities:

• * * * 2 * * *.

• * * * 2 * * *.

• * * * 2 * * *.

* * * 2 * * *.

* * * 2 * * *.

We reviewed the April 2016 security patch management plan and did not find the agreement the contractor referenced regarding the reevaluated vulnerabilities. Because we concluded that the * * * 2 * * * scan vulnerability rating of critical was still applicable to * * * 2 * * *, due to the lack of historical evidence to support the contractor's reevaluated rating, * * *2 * * *.

While we agreed with the reasoning for changing the severity ratings * * * 2 * * *, we have concerns with the remediation process that was used. * * *2 * * *.

* * *2 * * *.

During our review of the August 2016 through May 2017 Vulnerability Assessment Reports, we noted that the vulnerability was reclassified from open to a POA&M. We researched the Department of the Treasury FISMA [Federal Information Security Modernization Act of 2014]¹² Inventory Management System and did not find a POA&M for the vulnerability. Because vulnerability assessment reports show that the vulnerability is open to a POA&M, we believe one should be created or the contractor needs to create a risk-based decision because of the recurring vulnerability. In addition, while it is concerning that reports shared with the IRS are incorrect, we have an additional concern that the attention to the accuracy of the reports may be minimized because of the lower severity rating.

The * * *2 * * * high-risk vulnerabilities that were not remediated were reevaluated, and the severity ratings were changed to medium and low. For the * * *2 * * * vulnerabilities found on both the October 2016 and the February 2017 scan results, with the oldest vulnerabilities dating back to March 2013, we believe they should have been resolved long before February 2017. These * * * 2 * * * vulnerabilities stemmed from six unique vulnerabilities.¹³ The largest group, consisting of * * * 2 * * *(* * * 2 * * * percent) of the * * * 2 * * * vulnerabilities, were related to * * * 2 * * *. * * * 2 * * *. Figure 5 presents information on all * * * 2 * * * vulnerabilities, including the descriptive name of the vulnerability, the date it was first identified, and the * * * 2 * * * identification number for the vulnerability.

Figure 5: Details About the * * * 2 * * * High-Risk Vulnerabilities Identified by the * * * 2 * * * Scan That Were Reevaluated to Medium- or Low-Risk

Number	Date the Vulnerabilities Were First Identified14	Nessus Identification Number	Descriptive Name or Description of the Unique Vulnerability	Vulnerabilities
1	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
2	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
3	* * * 2 * * *15	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
4	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
5	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
6	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *	* * * 2 * * *
Total				* * * 2 * * *
Source: TIGTA's analysis of the October 2016 and February 2017 * * * 2 * * * vulnerability scan results.

When we brought the * * * 2 * * * high-risk vulnerabilities to the attention of the contractor and the IRS, they explained that the * * * 2 * * *-identified high-risk severity vulnerabilities were reevaluated using the Cybersecurity organization's * * * 2 * * *, and the severity ratings were changed to medium and low. The contractor used the same seven questions presented earlier in this report to determine the overall severity rating. At the completion of our fieldwork, the contractor provided us with its answers, and we determined the numeric ratings based on the contractor's answers for each severity rating that was changed. We did not conduct a comprehensive and detailed review of each of the contractor's answers and the numeric ratings. For the numeric ratings we did not agree with, we would have selected a higher numeric rating or there was insufficient information available to assess the rating.

• * * * 2 * * *

• * * * 2 * * *

• * * * 2 * * *

• * * * 2 * * *

• * * * 2 * * *

• * * * 2 * * *

* * * 2 * * *, which resulted in *2* vulnerabilities, the contractor resolved the vulnerabilities in May 2017. However, the contractor took 223 calendar days from the time the vulnerability reappeared to the date the contractor stated that it resolved the vulnerability. We reviewed the October 2016 IEP Vulnerability Assessment report and found the following explanation on the delay in resolving this vulnerability: * * * 2 * * *. Although the contractor noted in the Vulnerability Assessment report that * * * 2 * * *, the contractor did not provide a* * * 2 * * * for our review.

While we generally agreed with the reasoning for changing the severity ratings for the remaining five unique vulnerabilities previously discussed, we have concerns with the remediation process that was used.

• * * * 2 * * *.

• * * * 2 * * *.

• * * * 2 * * *.

• * * * 2 * * *.

Lastly, we are concerned with the timeliness to remediate the vulnerabilities, the oldest of which was initially discovered in March 2013. While the contractor provided some * * * 2 * * * and we observed a reference to a POA&M, the contractor did not account for the length of time spent remediating these vulnerabilities.

From the aforementioned Vulnerability Assessment reports for the months of October 2016 and February 2017, we found the following explanations in the October 2016 report * * * 2 * * *. In July 2017, we presented our concerns to the IRS regarding the processing of * * * 2 * * * vulnerabilities, specifically, the IRS's involvement in the internal risk-based decision process. The Enterprise Technology Implementation Division Director stated that the IRS receives the internal * * * 2 * * *, and that they are reviewed annually and are * * * 2 * * *.

While the IRS and its contractor continue their efforts to protect and provide access to systems that store and process taxpayer information through the IEP-RUP, our audit identified areas that should be improved in configuring systems, timely patching identified vulnerabilities, and following established procedures for monitoring and tracking security weaknesses. Failure to properly configure system components to the most restrictive settings compromises the security posture of the system that can lead to unauthorized access, increased vulnerability to attacks, and unauthorized data sharing and data exploitation, all of which compromise the integrity, confidentiality, and availability of the system.

Recommendations

The Chief Information Officer should:

Recommendation 1: Establish a policy for the contractor that * * * 2 * * *. In addition, correct the POA&Ms remediation time frame in the IEP Continuous Monitoring Plan that references the * * * 2 * * * and * * * 2 * * * schedule in * * * 2 * * *.

Recommendation 2: Ensure that the Cybersecurity organization validates that the contractor corrected the * * * 2 * * * weaknesses and that the servers are compliant with the configuration setting requirements during its next scheduled assessment.

Recommendation 3: Ensure that when the contractor identifies potential system weaknesses or deficiencies from the * * * 2 * * * scans, the contractor complies with the POA&M process to document, manage, and eventually resolve the vulnerability. This process should also be used when the contractor meets the 90 percent SLO. For the * * * 2 * * * scan deficiencies, ensure that the contractor is more compliant with the * * * 2 * * * schedule outlined in * * * 2 * * *.

Recommendation 4: Ensure that the contractor creates and maintains documentation of its * * * 2 * * * vulnerabilities in which the contractor provided us an incorrect * * * 2 * * *. In addition, ensure that, before the * * * 2 * * * *.

Office of Audit Comment: The IRS's response did not address the * * * 2 * * * vulnerabilities for which the contractor provided TIGTA an incorrect * * * 2 * * *. When we followed up and requested the correct * * * 2 * * *, the IRS could not immediately provide the information and stated it plans to add the requested information in the Department of the Treasury Joint Audit Management Enterprise System when it closes the planned corrective action for this recommendation.

Recommendation 5 : Ensure that a risk-based decision is prepared for IRS approval for the * * * 2 * * * (because its severity rating is critical) as well as for * * * 2 * * * . For the * * * 2 * * *, ensure that the contractor's technical team remediates the vulnerabilities as suggested by the industry leader (* * * 2 * * *).

Recommendation 6: Ensure that the Enterprise Technology Implementation Division conducts a review of all internal risk-based decisions to ensure that: 1) at least a * * * 2 * * * exists for the vulnerabilities; 2) the * * * 2 * * *; and 3) the * * * 2 * * * accurately reflect the type of vulnerabilities that the technical team is addressing.

Recommendation 7: Ensure that the contractor provides an accurate accounting of the status of vulnerabilities in reports that it shares with the IRS.

Improvement Is Needed to Ensure That the Information System Component Inventory Is Accurate and Complete

The contractor is contractually obligated to maintain an Information System Component Inventory, which includes physical servers, network devices, and virtual servers. The * * * 2 * * * for the IEP requires the contractor to maintain a perpetual inventory of IEP components within the Configuration Management Database (CMDB). Additionally, the IEP inventory is to be * * * 2 * * * to the IEP environment take place. The inventory is to include the following items:

• * * * 2 * * *

• * * * 2 * * *

• * * * 2 * * *

• * * * 2 * * *

• * * * 2 * * *