Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 58
Continued Review of the Tax Systems Modernization of the Internal Revenue Service: Final Report 5 Security Security is one of the most challenging aspects of the Tax Systems Modernization (TSM) of the Internal Revenue Service (IRS). These challenges result from the following: The IRS wants to provide authorized employees with role-based, need-to-know access to relevant segments of taxpayer and other databases that are distributed throughout the IRS and accessible on-line via networks. The distributed database elements of TSM represent a major change from the current and traditional means of database access by the IRS; therefore, the increased threat and vulnerabilities are not known. There is a lack of industry or government security standards for distributed networks. It is very difficult to develop and enforce an enterprise-wide security architecture because of its technical complexity and a culture of IRS development by autonomous regions. Effective integration of commercial off-the-shelf security products and systems into an enterprise-wide system is a complex undertaking, with no guarantee that the result will provide adequate security. The requisite development skills are in short supply, and the IRS lacks experience in developing and using modeling and simulation tools to evaluate architectural, implementation, and response time impacts of security measures in a distributed environment. In short, TSM is a large, distributed system that would challenge even the best security experts. Unfortunately, current projects are being implemented without an overall enterprise-wide security technical framework, which almost guarantees inadequate support of security requirements. Without immediate, extensive, and effective implementation of the recommendations made in this chapter, the gap between the current TSM security posture and the minimum security acceptable will continue to widen, thus virtually ensuring massive security breeches in the coming years.
OCR for page 59
Continued Review of the Tax Systems Modernization of the Internal Revenue Service: Final Report THREATS AND VULNERABILITIES The IRS appears to believe that its primary threat is from unauthorized browsing of tax returns by employees. This is in part a response to congressional pressure after the IRS discovered and reported previous unauthorized access.1 It is the committee’s opinion that browsing is not the only important threat, nor should it be the primary driver behind security requirements. The threats that the committee believes the IRS needs to design against are the following: Outsiders, including individuals, organizations, companies, and foreign governments that want to obtain confidential IRS taxpayer information and to access control passwords and protocols for the purpose of selling the information, blackmailing taxpayers, causing political embarrassment to the IRS, improving their negotiating position in criminal or civil actions, denying system availability, and modifying or destroying records; IRS employees, contractors, and vendors who are disgruntled or have been bribed to obtain such information for the above-stated purposes; and Some combination of outside and inside collaborators. Until several years ago, all taxpayer data were processed on stand-alone systems and moved physically on magnetic tape. There is no precedent or culture for secure electronic transmission of sensitive data within the IRS. The vision of a completely interconnected network providing access to any and all taxpayer data required for IRS operations is convenient from a business standpoint but ignores the extremely complex security and privacy issues involved. It is readily accepted within the government that the technology to construct and implement large-scale distributed systems connected with local and wide area networks outstrips the technology to secure these networks in a cost-effective manner. A rough rule of thumb is that in a very stringent security environment, at least 1 employee in 10,000 is or can be compromised. With the uncertainties of government employment and the potential for downsizing, a minimal clearance process for IRS employees, and the much greater access to networked systems, the risk of a compromised employee is much higher. Although the committee believes (based on past incidents) that no more than a small percentage of IRS employees will engage in unauthorized behavior, it is the greatly increased vulnerability of a widely connected distributed environment that makes even a handful of malicious or untrustworthy individuals a substantial threat. Furthermore, with the public’s perception of the IRS as an increasingly aggressive arm of the federal government, its systems are major targets for highly skilled and dedicated groups of citizen hackers who see the IRS as a legitimate target for information warfare. The dependence of the IRS upon the public switched network only heightens the threat. There are numerous reported cases of outside hackers as well as telephone company employees actively manipulating and wiretapping traffic and signaling circuits 1 See, Hershey, Jr., Robert D. 1994. “IRS Staff Is Cited in Snoopings,” New York Times, July 19, pp. D1 and D5.
OCR for page 60
Continued Review of the Tax Systems Modernization of the Internal Revenue Service: Final Report both in the long-haul and local networks.2 This threat is exacerbated by the layoffs and lack of job security in most of the local and long-haul telephone companies. Repeated downsizing has helped create a much less loyal work force that is much more susceptible than in the past to wiretapping, eavesdropping, and providing sensitive network and customer information to unauthorized individuals for pay. The conclusion from all of the above follows: The threat to IRS systems and information is much more severe and focused than the threat to most other agencies that process sensitive, but unclassified, information. Hence, the defenses built into the TSM systems must be significantly better than those needed by other agencies. ASSESSMENT OF SECURITY POLICY, REQUIREMENTS, AND ARCHITECTURES The committee endorses the top-down approach that the IRS has taken, starting with security policy, security requirements, security architecture, and specific security design and trade-off evaluation guidelines. It should be recognized that this is a very complex and time-consuming process. However, it is absolutely essential to ensure an enterprise-wide security posture that will implement both privacy and security requirements as the IRS moves from legacy systems (in which sensitive taxpayer data were couriered on magnetic tape) to a fully distributed client-server environment. The IRS resources, both internal and contractor, devoted to security are reported to be approximately 65 staff-years for fiscal year 1995,3 which equates to roughly $4.3 million. This is woefully inadequate for the scope of a major project such as TSM, and the effort needs to be expanded. The approach described in the detailed project documents examined by the committee seems to be that the security features in the commercial operating systems will be adequate. No justification or analysis for this premise was discovered, however. In the committee’s experience, without being driven by an overall detailed security architecture, and without having an evaluation mechanism or metric as to how effective the architecture is and how closely system implementation follows the security architecture, there can be no confidence that adequate security will be achieved. The IRS security policy is adequate, but its high-level security requirements are very general and do not provide any specificity.4 Most of the key security sections in the TSM 2 Goldberg, Carey. 1995. “It’s a Hacker Meeting, So Hide Your Phones,” New York Times, September 3, p. 32. See Quittner, Joshua. 1994. “Kevin Mitnick’s Digital Obsession,” TIME, February 27, p. 45. See also Flannery, Gregory. 1988. “Installer Says Bell Did Massive Tapping,” Mt. Washington Press, October 31, p. 1. 3 These figures are based on a set of written questions that were answered by the Modernization Executive’s office in a memo to the Security Subcommittee dated July 21, 1995. The specific numbers are 65 staff-years of effort at $66,000 per staff-year. 4 Internal Revenue Service. 1994. IRS Security Policy and Its Rationale. Internal Revenue Service, Washington, D.C., August 31. See also Internal Revenue Service. 1995. IRS High-Level Security Requirements. Internal Revenue Service, Washington, D.C., February 28.
OCR for page 61
Continued Review of the Tax Systems Modernization of the Internal Revenue Service: Final Report architecture documents (i.e., Integrated System Architecture and Transition Architecture) are marked “TBD” (i.e., to be determined). Furthermore, committee members could not identify an adequate set of security specifications produced for each project and program. Security pervades all aspects of TSM applications, including client interfaces, database access, data movement, and telecommunications. No overall security model or technical framework for design trade-offs is available. The projects appear to deal with this by saying that the Infrastructure Task Group will provide or create any security feature that is needed. The committee believes that there is little hope this approach will result in anything more than a patchwork of incomplete and inadequate security measures and virtually no privacy guarantees. Without a detailed security architecture driving the infrastructure project design and the application developments, the resulting security approach and implementation will require extensive and expensive corrections in the future. The infamous quote, “We always have time to do it right the second time,” is not applicable here. It takes a greatly expanded scope and effort to translate security policy requirements and architecture into technical specifications for individual projects. Examination of project documentation shows that this area is lacking. Even specific design guidance is frequently marked TBD. Proceeding without security specifications or even security guidance adds tremendous risk to project schedules and their ultimate ability to meet critical security requirements. As an example, the most detailed security document for the Infrastructure Project that the committee has seen is the Version 1 Infrastructure Security Design, dated June 30, 1995. Even this document is too high-level to perform specific project design and coding directly. This design needs to be translated into a software and architectural model, showing interactions between system elements, and then into more detailed design-level elements. The text in this document is a start, but the real security issues emerge only when words are translated into a form and at a level that begin to influence directly the program module design and interfaces. There is no process or mechanism other than individual efforts in the engineering organization to translate high-level security requirements into design guidance or detailed project and program security specifications. The committee is not aware of a well-defined management process to provide the specific security analysis required by the ongoing projects and programs. The IRS answer to this question was that “management mechanisms are being devised in conjunction with a management reorganization currently in progress.”5 This is inadequate, and future security problems are almost ensured if this serious deficiency is not corrected before projects proceed too far. Specific evaluation and simulation tools and metrics are needed to determine security adequacy, as well as the response time and throughput impacts of security measures. To date, no such requirements have been issued. Without up-front analysis and redesign to solve delay problems due to security, the traditional approach has been to disable the security features. Clearly this is unacceptable. One of the few security elements that has been specified is that individual user passwords will be employed with a single sign-on for access control. In the committee’s opinion, given the threat and the large body of evidence of network password theft and 5 Written response from the IRS to questions posed by the Security Subcommittee, dated July 21, 1995. The acting Chief Information Officer indicated in a meeting on November 29, 1995, with the chair and a committee member that a process had been established, but the committee was not able to assess it.
OCR for page 62
Continued Review of the Tax Systems Modernization of the Internal Revenue Service: Final Report misuse, the IRS must adopt a more robust scheme of one-time or variable passwords throughout TSM. Strong authentication is an area in which a number of high-quality software or hardware solutions are available commercially.6 The IRS is using such mechanisms in limited applications, but it should be using them throughout TSM, with even stronger mechanisms employed for system administrators and developers. Such solutions significantly increase a manager’s ability to control access to information by insiders and to decrease the risk of intrusion by outsiders. In addition, an individual user-based authentication scheme provides a much-improved audit trail for investigating potential security violations. The IRS has been urged to take a leadership position with regard to such technology,7 but little substantive progress has been made in that area. Recommendation 5.1. The committee recommends that the overall security design effort, and in particular that on the Infrastructure Project, be expanded immediately and significantly if there is to be any hope of controlling the risk of major security problems. COMMUNICATIONS SECURITY Overall, security cannot be provided adequately by either the current Consolidated Data Network (CDN) system or the forthcoming Treasury Communications System (TCS), the replacement system for CDN. It has been stated that the CDN is the primary vehicle for transmitting IRS data, yet IRS documents have stated that none of the CDN tails (i.e., the circuits between IRS sites and CDN nodes) are encrypted. In addition, it has been reported that even the CDN backbone has had long periods (of the order of weeks and perhaps even months) during which encryption has been “turned off” and the traffic is “in the clear.” TCS will not solve this problem. It has been stated clearly by senior managers responsible for TCS that end-to-end security must be the responsibility of the IRS, which cannot depend on the security services of the TCS to provide adequate confidentiality.8 Hence, full responsibility for the security of traffic when it leaves an IRS site falls on the IRS. Without continuous end-to-end protection of the traffic, security risks are increased greatly. For example, when a user requests remote data, that request is translated into a set of authorizations at the local sites and relayed to the site, or perhaps several sites, at which the data are stored. Someone intercepting that data, either on the unencrypted tails or on the backbone when it is in the clear, could obtain not only the traffic that comes back but also all the access control passwords and authorizations needed to access and retrieve other data. This risk is appreciably higher when switched data or telephone services are used, because any non-IRS access line to such a node may become an entry point for unauthorized connection to the IRS network. Not only does this risk compromise 6 The cost for such a solution is estimated to be less than $5 million for all 56,000 Integrated Case Processing users, based on current product prices. 7 Computer Science and Telecommunications Board, National Research Council. 1992. Review of the Tax Systems Modernization of the Internal Revenue Service. National Academy Press, Washington, D.C., p. 32. 8 Security Subcommittee meeting at U.S. Department of the Treasury, July 18, 1994.
OCR for page 63
Continued Review of the Tax Systems Modernization of the Internal Revenue Service: Final Report the taxpayer data on the return link, but it could also enable an adversary to use the access authorization to retrieve and/or modify additional taxpayer data. Recommendation 5.2. The committee believes that workstation-to-workstation security is ultimately required and recommends that development proceed with this requirement in view. In the interim, however, the committee recommends bringing TSM up only on leased FTS 2000/TCS circuits using site-to-site encryption with strong authentication in all nodes, as an initial mandatory requirement. Only when security with adequate response time has been demonstrated in that configuration should further steps be taken to implement workstation-to-workstation communication over leased lines and, ultimately, over switched data and telephone services. GUIDELINES Since security is a critical aspect of TSM, the committee offers the following specific guidelines to help the IRS focus on the problems at hand. These guidelines are not intended to represent a complete set of the actions required to advance TSM security. Such a list can be determined only through a much more extensive analysis than this committee was able to conduct. The IRS needs to understand, discuss, and analyze the impact of these guidelines on TSM and to develop a complete list of its own. All data in the IRS should be deemed and treated as sensitive but unclassified.9 All information must be protected by the IRS with approved encryption and authentication systems and devices anytime the data are transmitted outside an IRS site. No project should receive approval to go operational if this requirement cannot be met. Within an IRS site, the encryption of data on local area networks could be phased in over time. Any data that pass over the unencrypted CDN tails must be examined for sensitivity. Developers and administrators should reroute sensitive traffic over encrypted circuits, and no further waivers should be granted for any noncompliant CDN security conditions. The following macrolevel security design standards should be used by all IRS, not just TSM, development projects: Incorporate good-quality encryption and key management techniques where confidentiality is necessary. Implement robust access control techniques (i.e., variable or one-time passwords or better) for all IRS employees at workstations, applications, and data-set access points. 9 This term of art is often associated with the Reagan administration’s National Security Directive NSDD145, referring to federal data or information that is considered sensitive enough to require protection against unauthorized access (e.g., for reasons relating to personal privacy) but that is not subject to national security classification.
OCR for page 64
Continued Review of the Tax Systems Modernization of the Internal Revenue Service: Final Report Implement enterprise-wide, secure, and tamper-resistant audit trails for all applications, relying on high-level, logical audit records, rather than low-level physical auditing. The developers that generate the audit trails for a given application should also help develop a tool or set of tools capable of analyzing those data. Institute an extensive and ongoing security awareness, training, and operational program. A comprehensive suite of detailed security design and evaluation models, metrics, and tools should be acquired and put into use as soon as possible on every project. All ongoing projects should be reviewed by using these tools in view of the expanded concept of the threat. Developers should pay special attention to the impact of security access controls on response time and throughput. If the expected delays become too long, designers should redo the architecture rather than eliminate the security. Where an independent analysis of proposed systems indicates that security problems are “too tough” or security solutions are not available in time, alternative network and processing approaches should be selected that are secured more easily and are adequate to ensure security. Any required reductions in connectivity or access should be accepted since these are driving factors in making adequate security difficult or impossible to achieve. CONCLUDING POINTS There is no question that the IRS has made substantive progress in developing a top-down security approach. The issuance of an extensive set of documents is proof of this. The steady expansion of staff-years devoted to security is further evidence of progress. The committee supports this effort. It is the rate of progress that must be accelerated by an order of magnitude. The resources being expended for security— approximately 65 staff-years per year—are inadequate and need to be expanded. Security is an organizational problem. Therefore, the entire IRS management corps must emphasize that security is a key performance criterion for operational acceptance of new and upgraded TSM projects, and that rewards and promotion of key personnel depend on achieving an adequate security posture and meeting security milestones. In short, the IRS should grant no security waivers on operational systems and should reward people when they increase the security of TSM. On the basis of its analysis, the committee believes that the IRS needs to adopt a more comprehensive concept of threat to include skilled hackers, foreign governments, malicious developers, dedicated eavesdroppers, and disgruntled or subverted employees. The committee believes that a handful of untrustworthy people could accomplish significant security breaches unless security measures are designed to counter a comprehensive threat. As the level of connectivity among TSM systems increases to meet operational demands, the security requirements for TSM will increase even more. The IRS must anticipate these requirements and plan now to support them. The security policy and high-level requirements are a good start and should continue to be used as the high-level drivers. However, detailed security requirements need to be determined and driven down
OCR for page 65
Continued Review of the Tax Systems Modernization of the Internal Revenue Service: Final Report to individual projects, to provide all projects with a common set of security components that can be used by developers. The lack of a technical framework and review process for security creates a great risk of one or more disastrous compromises of IRS operations, data, and taxpayer privacy. As stated in Chapter 2 of this report, the IRS must increase the maturity of its development processes immediately, including the methods by which security requirements are promulgated, implemented, and enforced. The security simulation and modeling tools to perform enterprise-wide analysis, detailed security trade-offs, identification and measurement of metrics, and throughput analysis are not available or integrated into the normal security design process. This is a major weakness of the TSM program. These tools are vital to the current and future security success of TSM projects and should be acquired and used immediately. A fixed password access control system for user verification is inadequate and should be replaced immediately by a strong authentication solution, using commercially available products. The IRS must act soon and decisively to prevent serious security problems that easily could undermine all of the other benefits to be provided by TSM.
Representative terms from entire chapter: