United States GAO General Accounting Office Washington, D.C. 20548 Accounting and Information Management Division B-283132 July 2,1999 Information Policy and Technology Branch Office of Information and Regulatory Affairs Office of Management and Budget Subject: Information Technolom: Comments on ProDosed OMB Guidance for ImDlementinP: the Government ParJerwork Elimination Act This letter is in response to your request for comments on the Prososed OMB Procedures and Guidance on ImDlementina the Government Paperwork Elimination Act (GPEA). We support the stated goals of the draft guidance and appreciate the difficulties in developing practicable guidance for agency managers to implement these goals. We concur with your approach of determinin g the internal controls based on a risk assessment. However, we believe that additional guidance is needed to help the agencies determine the risk assessment methodology. Specifically, we suggest that you (1) require a quantitative as well as a qualitative risk analysis as part of any risk assessment process and (2) provide additional information to help agencies properly consider the implications that historic wealmesses in agency internal controls have had on data integrity during the risk assessment process. The enclosures to this letter provide our detailed comments and suggestions for improving the proposed guidelines. Enclosure 1 provides specific comments and suggestions on risk assessments, enclosure 2 provides specific comments and suggestions on individual sections, and enclosure 3 contains suggestions for improving the implementation guidance by defining certain key terms. ditional information, I can be reached at (202) 5124415. ’ Director, Computers and Information Technology Assessment Enclosures (3) GAO/AIMD-99-228R Comments on OMB’s Proposed GPEA Guidance Enclosure 1 Better Guidance Needed for Risk Assessments The sections discussing the risk assessments would benefit by clarifying the risk assessment definition, discussing the effects of breakdowns in general ADP controls on data integrity, and providing a framework on how risk assessments should be prepared. These are discussed below. Risk Assessment Definition Needs Clarification Part I, Section 2.c., states that a risk assessment is required and is used to develop baselines and verifiable performance measures that track the agency’s mission, strategic plans, and tactical plans. Normally, a risk assessment is used to determine the risks associated with a given project, the probability that a given risk will occur, and the impact of those risks that do materialize. This analysis is then used to develop a risk management plan which identifies the techniques, if any, that will be used to mitigate each risk. Normally other documents in the project life cycle are used to (1) map the project to an agency’s mission, strategic plans, and tactical plans and (2) specify the baselines and performance measures that will be used to evaluate the program. We would suggest revising this section to state that a quantitative and qualitative risk assessment must be performed’ on the proposed electronic records project and include (1) the risks associated with the project, (2) the probability, if available, of the risk materializing, and (3) the potential impact if a risk does materialize. This section should also state that once the risk assessment is completed, a risk management plan should be prepared and properly maintained to manage the risks that were identified. Risks Associated With Breakdowns in General ADP Controls Part II, Section 6-d., discusses the need to carefully control the access to electronic data to ensure that no one can alter the received data. It also notes that the data may be needed many years after the transaction itself took place. Theoretically, it would be possible to maintain the necessary data integrity using any of the electronic signature techniques identified in section 5 if properly implemented and, depending on the electronic signature technique, accompanied by the appropriate general computer security controls. However, in the electronic world, because of the difficulty in detecting unauthorized modifications to electronic data2 the only practical way that current technology can ensure that no one will be able to alter an electronic transaction, or substitute something in its place, without detection is to require the use of self-authenticating electronic signature techniques. Self-authenticating electronic signature techniques link the data to the electronic signature in such a manner that if the data is altered, the signature is invalidated during the electronic signature verification process. We suggest that OMB, for the present, require the use of self-authenticating electronic signature techniques when the risk assessment identifies the need for them. Examples of technologies, properly implemented, that can conceptually produce self-authenticating electronic signatures ‘This is consistent with An Introduction to Commuter Securitv: The NIST Handbook, Special Publication 80042. *A paper document allows certain forensic tests, such as chemical analysis, to determine if an alteration has occurred. These tests cannot be duplicated on the electronic data unless the data is linked to the signature in such a manner that a change to the data invalidates the signature. Page 2 GAO/AIMD-99-228R Comments on OMB’s Proposed GPEA Guidance Enclosure 1 include voice prints, symmetric key cryptographic systems using a technique commonly referred to as key notarization, and public/private key cryptographic systems. We believe that the guidance, as currently drafted, does not provide sufficient detail for agencies to understand and evaluate the risks associated with trying to securely maintain electronic data when the electronic signature is not directly linked to the data. As noted in our recent update on the high- risk issues facing the federal government,’ our reviews of computer security across the federal government have disclosed disturbing wealmesses that make it easier for individuals and groups to intrude into inadequately protected systems and use such access to obtain sensitive information, commit fraud, or disrupt operations- Examples include the following: In May 1998, we reported that the Department of State’s information systems and the sensitive data they maintain were vulnerable to access, change, disclosure, and disruption by unauthorized individuals.4 In addition to recommendations to correct individual deficiencies, we recommended that the agency strengthen its management structures for planning and implementing its information security program. In September 1998, we reported that weaknesses at the Department of Veterans Affairs placed critical operations, such as healthcare delivery, benefit payments, and life insurance services, at risk of misuse and disruption. We recommended that the department’s Chief Information Officer correct all identified weaknesses and implement a comprehensive computer security planning and management prognxn5 In September 1998, we reported that our review of two cases of Air Force vendor payment fraud disclosed that computer security weaknesses continued to make the Air Force vulnerable to such incidents. We recommended strengthening operating system controls and assessing the need for stronger controls over user identifications and passwords6 For the last 7 years, the USDA Inspector General has reported serious computer control weaknesses at the National Finance Center, which annually makes over $21 billion in payroll disbursements to about 434,000 employees and about $15 billion in other payments. The Inspector General reported that the center had not ensured that (1) systems security adequately prevented misuse or unauthorized modifications, (2) access to data was needed or appropriate, and (3) modifications made to software programs were properly authorized and tested. USDA has actions planned to correct these serious wealmesses. The practical implication of these weaknesses is that although the agencies may strive to ensure electronic data integrity through system controls, they have failed to achieve the kind of assurance that the draft guidance expects. Although the nature of agency operations and the related risk vary, there are striking similarities in the control weaknesses reported. The most widely reported weaknesses have been ‘High-Risk Series: An UDdate (GAOA-IR-99-1,January 1999). ‘Commuter Securitv: Pervasive. Serious Weaknesses Jeouardize State Dewrtrnent Onerations (GAO/AIMD-98-145, May X$1998). “VA Information Svstems Commuter Control Weaknesses Increase Risk of F’raud. Misuse and Imnrouer Disclosure (GAOIAIMD-98-175, September 23,1998). ’ %inancial Management: Imvrovements Needed in Air Force Vendor Pavment &stems and Controls (GAO/AIMD-9S-274,September 28, 1998). Page 3 GAO/AIMD-99228R Comments on OMB’s Proposed GPEA Guidance Enclosure 1 l poor control over access to sensitive data and systems, such as providing overly broad access privileges to very large user groups, allowing shared passwords and user accounts, and inadequate monitoring of user’s activities; . mitigating and recovering from unplanned interruptions in computer service; . inadequately segregating duties to help ensure that people do not conduct unauthorized actions without detection; and l not preventing unauthorized software from being implemented. We also noted in our report that security risks to government computer systems are signiscant and growing and that agencies have not responded to audit findings with enough attention to the systemic problems. The threats to data integrity caused by these weaknesses are hard to quantify, and agencies may not even know if they have been attacked. In 1996 we testified that the Department of Defense’s computer systems are being attacked every day. Although Defense does not know exactly how often hackers try to break into its computers, the Defense Information Systems Agency (DISA) estimated that as many as 250,000 attacks may have occurred in 1995. (Currently, DOD estimates that about 500,000 attacks occur annually.) An equally worrisome finding noted in our testimony was that DISA conducted internal tests to help it quantify system vulnerabilities and found that it could successfully penetrate Defense systems 65 percent of the time. Not all hacker attacks result in actual intrusions into computer systems; some are attempts to obtain information on systems in preparation for future attacks, while others are made by the curious or those who wish to challenge the Department’s computer defenses.’ Some attacks on DOD’s computers have had very serious results. Hackers have stolen and destroyed sensitive data and software. They have installed “backdoors” into computer systems which allow them to surreptitiously regain entry into sensitive Defense systems. They have “crashed” entire systems and networks, denying computer service to authorized users and preventing Defense personnel from performing their duties. We pointed out in the testimony that an attack on the Air Force’s laboratory in Rome, New York, demonstrated how easy it was for hackers to gain access to our nation’s most important and advanced research and how diflicult it is to value and apprise the information contained in a system. Although linking electronic signatures to the data contained in government systems using self authenticating electronic signature techniques does little to protect the network against hacker attacks that cause a loss of data or services, the linking is a very good technique to help ensure that system data integrity has not been compromised or at least identify the records that were changed. For example, if an unauthorized user obtains access to an electronic report that does not use self- authenticating electronic signature techniques and changes the data, it is very diff?cult to determine if an alteration occurred. However, if self-authenticating electronic signature techniques are properly implemented and used, then by simply validating the electronic signature, the agency can identify if any records have been altered. In other words, electronic signature techniques that link the electronic signature to the data in such a manner that if the data are changed, the signature is invalidated during the signature verification process, can help mitigate the weaknesses in the general computer controls discussed above that plague many federal computer systems and compromise data integrity. ‘Information S~CLU&V:Commuter Attacks at Dewrtment of Defense Pose Increasing Ris!q (GAO/T-AIMD-96-92, May 22,1996). Page 4 GAO/AIMD-99228R Comments on OMB’s Proposed GPEA Guidance Enclosure 1 Implementation Guidance Needs to Provide a Framework to Evaluate Risks to Data IntetiW Part II, Section 3., outlines three categories of risk factors and how to synthesize them when planning and implementing electronic signature or recordkeeping systems. However, this section does little to explain the logical steps necessary to assess the risk associated with a given system and ensure that the system is available, reliable, survivable, and secure. We believe that it would be useful to revise this section and provide the framework of analysis that should be used to build the systems envisioned by this guidance. Examples of areas that should be revised include the following: The introduction states that “[e]lectronic signature technologies can offer degrees of confidence in authenticating identity greater even than the presence of a handwritten signature.” Although this is true, the draft does not provide the necessary information to properly evaluate the statement. It does not state that because electronic records have risks, such as modifying data from a remote location, that are not present in their paper-based counterparts, such techniques are necessary to provide the same overall assurance that the data integrity has been maintained. The categories in Part II, Section 3.a., are prefaced with the statement that each category is vulnerable to different security risks. However, in the material that follows these categories, it appears that although the risk factors differ, all but one transaction type (transactions between a federal agency and member of the general public) should be considered low risk. The support that was used to make the risk assumptions in this section is unclear. For example, the draft guidance states that Ymnsactions between a regulatory agency and a publicly traded corporation or other known entity bear a relatively low risk of repudiation or fraud.” Part 11,Sections 3.b. and c., outline five categories each and state that each category is vulnerable to different security risks. However, these sections do not provide any guidance on how an. agency should evaluate the risks associated with these categories or the types of risks associated with each. Part II, Section 3.d. I., states that the agency should perform a qualitative risk analysis in order to determine the electronic signature technologies and management controls that are best suited to minimizing the risk to an acceptable level while maximizing the benefits to both parties involved. While qualitative analysis is important to making an informed decision, quantitative analysis is also an important indicator since it produces an evaluation that can be used by third parties, such as OMB and the Congress, using fact-based methodologies. If an agency does not have enough information to perform a quantitative analysis, then it does not have enough information to evaluate the reasonableness of the qualitative analysis. Also, we are concerned that agencies may not provide the rigor necessary to evaluate the risks associated with the project if a quantitative risk analysis is not performed. l Part II, Section 3.d.2, discusses using the past history of fraud risk and states that careful analysis of those risks should be used to help determine the electronic signature alternative that is needed. History has shown that risks associated with automated systems may vary significantly from those found in the paper-based counterparts. Therefore, effective risk analysis programs (1) identify the risks associated with the system being developed, (2) quantify the probability of the risk materializing, and (3) quantify the effect of the risk if it does materialize. . Page 5 GAO/AI&ID-99-228R Comments on OMB’s Proposed GPEA Guidance Enclosure 1 l The opening statement in Part II, Section 3.d.4., states that electronic authentication may strengthen signature validation. It is unclear how electronic authentication can strengthen the signature validation process. Rather, it appears this example demonstrates how the electronic signature is generated by using numerous items to help authenticate the signer. Although it is unreasonable to expect that all risks associated with a given system can be identified and quantified before a system is implemented, it is important to have an effective methodology that identifies the unique risks associated with a given approach. We suggest that this section be revised to state the framework that agencies should use to determine controls needed to ensure that the system is available, reliable, survivable, and secure. Adopting the . following three-step approach would provide practical guidance, while allowing agencies a great deal of flexibility to develop systems that meet their business needs. l Prepare a quantitative and qualitative risk assessment based on the system requirements that (1) identifies the risks associated with the system being developed, (2) quantifies the probability of the risk materializing, and (3) quantifies the effect of the risk if it does materialize. o Develop and maintain an effective risk management plan that identifies the techniques, if any, that will be used to mitigate the identified risk. l Ensure that the control techniques identified in the risk management plan are properly implemented. An agency could assess its controls annualIy as a part of its Federal Managers’ Financial Integrity Act review process. It would be very useful to have OMB request an agency, such as NIST, that has computer security expertise to prepare guidance for agencies to use in preparing the risk assessment and risk management plan. For example, a list of standard risks that should be considered in the risk assessment process and techniques that can be used to mitigate those risks would reduce the amount of effort each agency would need to spend to develop its risk documents. Although the agencies would need to ensure that the unique risks associated with a given project were identified, they would not have to spend time “reinventing the wheel” to ascertain the standard risks and identify acceptable techniques to mitigate them. Rather, agency officials could make a decision on whether a standard risk was present in their system and focus their efforts on determining whether (1) it needed to be mitigated and (2) the standard control techniques identified in the standard guidance are adequate and/or any additional controls may be needed. Page 6 GAO/AIMD-99-228R Comments on OMB’s Proposed GPEA Guidance Enclosure 2 SDecific Comments on Individual Sections In reviewing the draft guidance, we also noted areas that could use additional clarification or could be added to improve the usefulness of the document. These include 0 clarifying the information in the section that discusses electronic signature technologies, l discussing the importance of general computer controls and the impact weaknesses in these areas can have on data reliability, a providing additional guidance relating to audit trails, l involving the Inspectors General in system design and development efforts, l improving the summary of procedures checklist, and 0 including a discussion on the unique factors associated with federal government automation efforts that should be considered when agencies automate their systems. Our comments and suggested changes are discussed below. Clarification Needed in Section Discussinn Electronic Sknature Technoloties The section heading in Part II, Section 5, states that it contains an overview of electronic signature technologies. This section would benefit from a lead-m that discusses the risks associated with electronic signature techniques which do not produce self-authenticating electronic signatures to help agencies develop the risk assessments called for in other sections of the draft guidance. One risk that appears to apply to all of these technologies is the risk of capturing the authenticating information and resubmitting it to gain unauthorized access. In some cases, the material provided in this section does not make this risk obvious. Examples include the following: l The discussion on personal identification numbers and passwords states that the authentication process should be encrypted when transmitted over the Internet and this can be accomplished using a technology called the “Secure Sockets Layer.“. However, this.section does not discuss the risks to the computer server that provides these services and the types of controls that are needed to ensure that the services provide the expected level of assurance. l The section states that forging a digitized signature is more difficult than forging a paper signature since, during the verification process, the digitized signature is compared to a stored image with a technology that is better than the human eye. It also states that the creation of the image helps make it unique because the technology measures how each stroke is made. However, the discussion does not state that if this technology is to provide this degree of assurance, a trusted path7 must exist between the device capturing the digitized signature and the device authenticating it. A statement that the transmission of digitized (not digital) signatures should not be sent over open networks unless they are encrypted would also be a useful addition. The section on biometrics contains this type of statement. ‘A mechanism by which a person or process can communicate directly between two devices or processes and which can only, be activated by the person, process, or module, and cannot be imitated by untrusted software or processes. Page 7 GAO/A&ID-99-228R Comments on OMB’s Proposed GPEA Guidance Enclosure 2 In addition, the discussion of several technologies could be enhanced with some additional material. Examples include the following: l The discussion on symmetric key cryptography in Part II, Section 5.b.l., gives the impression that this technology undermines the cotidence of the signature because the same key is used to generate and validate the signature. While this is a valid point, it would be useful to acknowledge that the effects of this can be reduced through the use of key notarization and provide an example of this technology. We would also suggest using the electronic signature system developed by the Corps of Engineers, which we understand is used by over 10,000 employees worldwide, as an example. l It would be useful to provide additional information in Part II, Section 5.b.2., on the need for ceticates in digital signature systems and a clearer explanation of how a digital signature is generated. We would suggest something like,the following: “Although the private key cannot be deduced from the public key, anyone can generate the necessary public/private key pair. Therefore, a means is needed to bind an individual’s identity to the public key that will be used to validate an individual’s digital signature. This binding is normally performed by using a specialized electronic document, commonly referred to as a certificate, which is signed by the issuer and contains the user’s public key. “A ‘digital signature’ is created during a two-step process. The electronic document is first reduced to a value commonly referred to as a message digest. This message digest is developed using a process that ensures that (1) the digest is unique to that message and (2) it is very dif6cult to generate another message that would generate the same message digest. The system then takes the signer’s private key and creates a unique mark (called a ‘signed hash’ or ‘digital signature’) on this value. “The recipient of the message takes the message and recomputes the message digest and then, using the signer’s public key, verifies the signed hash (digital signature). If these two values agree, then the recipient has reasonable assurance that the document was not altered. Since the private key used to sign the message and the public key used to validate the signature are mathematically linked and unique, only one public key can be used to validate a given signature. Moreover, . . .” l In Part II, Section 5.b.2., a statement is made that the “reliability of the digital signature is directly proportional to the degree of confidence one has in the link between the owner’s identity and the digital certificate, how well the owner has protected the private key from compromise or loss, and the cryptographic strength of the methodology used to generate the key pair.” These are very good points, and additional information would be beneficial to help explain the importance of binding an individual to the public key and protecting the private key from compromise. Furthermore, many agencies may not understand the importance of the last part of the requirement that discusses the methodology used to generate the key pair. Although that methodology is important, other factors are just as important. For example, the algorithm selected. for generating and validating digital signatures and ensuring that a given implementation is secure is critical to a secure system. It would be useful if the guidance included a discussion of how acceptable electronic signature systems are built upon standards and technology that are recognized by NIST and independent standards organizations such as the American National Standards Institute (ANSI) and the International Organization of Standardization (ISO). The reliance on NIST would appear Page 8 GAO/AlMD-99-228R Comments on OMB’s Proposed GPEA Guidance Enclosure 2 consistent with the Computer Security Act, which states that MST has the primary responsibility for developing standards for cost-effective computer security associated with systems processing sensitive but unclassified data. History has shown that standards which have not undergone a rigorous standard-setting process may have unforeseen weaknesses and they may result in proprietary solutions. Therefore, it is critical that the standards have a sound basis before they are eligible for adoption. Although the draft guidance states that agencies need to perform a risk assessment before adopting any electronic signature solution, it is unclear whether agencies will have enough information to adequately determine the risks associated with a given industry solution. In our experience, most agencies are not in the business of evaluating products for security weaknesses. Rather, they rely on others, such as independent testing organizations, to validate that a given product complies with standards from a recognized standard-setting body to help reduce the risks associated with acquiring products with unforeseen security weaknesses. Discussion of General Commuter Controls and Repudiation Needs Additional Information Part II, Sections 6.~. and d., discuss data integrity issues and the need to minimize the likelihood of repudiation and the importance of a user not disclosing a personal identification number (PIN) or the cryptographic key used to sign a message. The section also states that if a defendant plans to commit fraud, he or she may intentionally compromise the secrecy of the key or PIN that was used to produce the electronic signature so that the government would later be unable to link the individual to the electronic data. This section needs to be expanded to discuss the importance of considering the system risks that may also affect the government’s ability to (1) cIaim that a defendant maintained sole control over the signature mechanism and (2) protect the government’s electronic signature capability for its transactions. Although Section d. states that the electronic data, after receipt, needs to be carefully controlled, these sections do not discuss the problems that must be addressed when a defendant claims that the system lacks adequate controls to provide the necessary data integrity. As noted elsewhere in our comments, our reviews of computer security across the federal government have disclosed disturbing weaknesses that make it easier for individuals and groups to intrude into inadequately protected systems and use such access to obtain sensitive information, commit fraud, or disrupt operations. It is very possible that a defendant will claim that he or she properly protected the PIN but that because the agency did not have adequate computer security controls, the data were changed after they were submitted by the defendant. While the risk assessment called for in other sections of the draft guidance should address these kinds of issues, it would be useful to highlight them in this section of the guidance and note that they should be specifically addressed in the risk assessment. Additional Guidance Needed Relatina to Audit Trails The discussion in Part II, Section 6.e., requires that the system ensure the “chain of custody.” The material in this section appears to require the use of self-authenticating electronic signatures. Since other sections of the draft guidance do not distinguish between signature techniques, it may be useful to discuss when self-authenticating electronic signatures, rather than other types of electronic signatures, are needed. Page 9 GAO/AIMD-99-228R Comments on OMB’s Proposed GPBA Guidance Enclosure 2 Involvement of Auditors Needed During &stem DeveloDment Efforts Part II, Section 6.g., states that legal counsel should be involved during system design. It is also useful to involve the agency’s inspector general in the proposed system development to ensure that adequate audit trails are incorporated into the system and that the quantitative and qualitative risk assessment is properly prepared. Involving the agency’s auditors would help agency management gain confidence that the system is complying with the OMB guidance and other pertinent requirements. 7Summ Can Be Improved Part II, Section 7., outlines 11 steps that should be taken to comply with the draft guidance. Organizing these steps according to the logical flow that occurs during a system development effort would assist the agencies in complying with the OMB guidance and other information technology requirements. Examples of weaknesses in the current material include the following. Step 1 requires the agency to examine the current business process and identify the existing risks associated with fraud, error, or misuse, as well as customer needs and demands. While identifying the risks associated with the current system may be of some help with the development of the quantitative and qualitative risk assessment, the risks associated with the proposed system need to be identified and assessed in order to perform an adequate assessment. It would appear that the first step should be the development of a concept of operations for the proposed system that describes system characteristics from the user’s point of view.* The draft guidance also does not discuss the process that will be used to identify the agency’s needs. Step 2 states that the agency should consider the risks that may arise. As noted earlier, it would be useful to require that a quantitative and qualitative risk assessment be prepared. After the risk assessment is prepared, a risk management plan needs to be developed, implemented, and maintained. Step 3 requires the identification of benefits. While this is an important function, it is equally important to identify the costs associated with the proposed system. This analysis should be used to help the agency ensure that the proposed system will meet its information technology investment guidelines. Step 4 requires consulting with legal counsel. As noted earlier, the inspector general should also be consulted and these organizations should be involved in developing the concept of operations. Step 5 does not clearly explain what is meant by “each electronic signature alternative.” As noted elsewhere in our comments, the purpose of a risk assessment is to identify the risks associated with a given approach, and the risk management plan identifies the techniques that will be used to mitigate the risks. The risk management plan should quantify the costs and benefits associated with the techniques that are used to address the risk factors. Adopting this approach would appear to address the objective of step 6. “A concept of opkations is used to communicate overall quantitative and qualitative system characteristics to the user, buyer, developer, and other organizational elements. The concept of operations also describes the user organization(s), mission(s), and organizational objectives from an integrated systems point of view. IGuide I EE IConOx) Document, IEEE Std 1362-1998. Mtute of Electrical and Electronics Engineers, Inc.) Page 10 GAO/AIMD-99-228R Comments on OMB’s Proposed GPEX Guidance Enclosure 2 l Step 8 is very important and should be performed early in the process in order to help the project team define the requirements. If the agency is unable to accomplish the needed changes to regulations or policies, then the system may require substantial changes and no longer meet the agency’s information technology investment guidelines. Furthermore, this information is needed to help develop the risk assessment and risk management plans. Uniaue Nature of Government ODerations Is Not Discussed Although implementing a system in the federal government is similar to the private sector, some important differences exist. Examples include the following. l “Customers” of a federal agency may not get to choose whether they would like to report to the federal agency. Generally, customers can choose which private sector company they would like to use. Therefore, the benefits associated with customer choice are not present in federal systems. l The risk management decisions made by a federal agency need to include risks that are being imposed on the customer. The risks associated with a system from a federal agency point of view may be entirely different than those from the customer’s point of view. For example, when the Social Security Administration was considering bringing its Personal Earnings and Benefit Statement online, it generally looked at risks associated with unauthorized individuals gaining access to an individual’s records. However, it did not consider the risks to the individual taxpayer of someone using the system to validate critical information that was obtained from a third party. Specifically, an individual who wants to steal another person’s identity may try to validate the target individual’s date of birth and location that were obtained from a third party. Using the Social Security Administration system, the perpetrator could attempt to gain access. If the access was successful, then the individual would know that he or she had the correct data since these two items were used by the Social Security Administration to help authenticate the user. l The federal agency may not be able to make a complete conversion to electronic records even if the legacy process is not cost effective. Federal agencies operate in an environment which may require reporting methods that are based on public policy or other non-economic factors. For example, the public comment process may dictate that a given process be continued even if the proposed system is more cost effective. A section outlining how an agency should address the unique aspects associated with its modernization efforts would be a beneficial addition to the draft guidance. Page 11 GAO/AIMD-99-228R Comments on OMB’s Proposed GPEA Guidance Enclosure 3 Kev Terms Need to Be Defined The following sections discuss the draft guidance’s use of the terms “cost-benefit analysis” and “electronic authentication.” Cost-Benefit Analvsis Part I, Section 2-d., discusses using the cost-benefit analysis to generate a business case and determine a verifiable return on investment to support decisions regarding overall programmatic direction, investment decisions, and budgetary priorities. It also states that the cost-benefit analysis should be used as a guide to select among the technologies under consideration. However, the purpose of the last sentence-which states that the “effects on the public and its needs and readiness to move to an electronic environment are important considerations”-is unclear. Normally, an alternatives analysis is used to help decide which technologies should be used to address a given need, and it is prepared after the system requirements have been defined. The completed alternatives analysis provides the recommended approach that is used to further refine the business case. Although cost-benefit techniques are used to develop the alternatives analysis, other information may be equally important. For example, certain alternatives may not be adopted because they do not comply with the agency’s system architecture requirements. After an alternative is adopted, a cost-benefit analysis is then developed to assess the overall costs and benefits of the project. We would suggest revising this section to clearly state that an alternatives analysis must be performed and that before an alternative has been adopted, a cost-benefit analysis for the project be completed to ensure the project meets the agency’s information technology investment guidelines. Benefits and costs, such as the value of deterring fraud, which cannot be readily quantified, should also be included. Electronic Authentication Part II, Section l.b., combines techniques which, by their design, provide data integrity (e.g., digital signatures) with techniques that only provide user authentication (e.g., user identification codes and passwords). This presentation approach may lead the reader to believe that given technologies and techniques can be used in isolation to provide a specified level of assurance. For example, Section 1-b. states that digitized signatures and biometric means of identification have a greater degree of assurance than user identification codes and passwords. However, the key to whether one technology will provide a higher degree of assurance than another technology is (1) the risk environment and (2) how well the technology is implemented. For example, transmitting digitally signed unencrypted fingerprints over the Internet as a means to identify a person provides little advantage over using traditional passwords and user identification codes since this authentication mechanism is subject to the same type of risk-capturing the authenticating information and then using it later.g This is also true of using digital signatures to identify an individual. If a sound mechanism has not been used to link the actual person to the public key that is used to validate that individual’s identity, then the resulting digital signature provides little assurance of an individual’s identity. PThis should not be interpreted to mean that digitally signed fingerprints cannot be used to provide a reliable means of identifying an individual to a system over an untrusted network. However, each transmission must have some unique information, such as a date&me stamp, to prevent the identification information from being used again at a later date. Page 12 GAO/AI&ID-99-228R Comments on OMB’s Proposed GPEA Guidance Enclosure 3 Very rarely does one specific technology or control technique provide the necessary assurance. In order to authenticate a user, Federal Information Processing Standard (FIPS) 48 outlines the following three basic methods that are available for establishing the identity of an individual: l something KNOWN by the individual (e.g., the traditional user identification code and password approach of gaining access to a system), l something POSSESSED by the individual (e.g., badge and smart cards), and l something ABOUT the individual (e.g., appearance, fingerprints, and voice). Normally, it is recommended by the National Institute of Standards and Technology (NIST) that two pieces of information to be used to identify an individual even if the same method is used for both. For example, many systems require the use of user identification codes and passwords to gain access to the system. Even though this approach uses the “something known by the individual” method of identification, using two pieces of information provides a greater degree of assurance than if only one item were used. Part II, Section 3., gives an example of using at least two pieces of information to identify an individual. It states that although the IRS Customer Service Number (CSN) is not unique to an individual since it is only five digits long, IRS authenticates the filer by using other identifying information, such as the taxpayer identification number. Based on the information provided, it appears that the IRS example uses at least two elements of something the user knows to authenticate the user. In this case, the taxpayer identification number and CSN in combination are unique to the user. This is consistent with the traditional‘user identification code and password- based approaches to granting access to a system. Although it is possible that two individuals may use the same password, the user identification code and password combination should not be the same because system administrators ensure that each individual has a unique user identification code. We would suggest revising this section and stating that various technologies, properly implemented, can be used to help provide the necessary integrity over electronic records and transactions and that a number of control techniques are used in combination to provide the necessary level of assurance. (922271) Page 13 GAO/AIMD-99-228R Comments on OMB’s Proposed GPEA Guidance Ordering Information The first copy of each GAO report and-testimony is free. Additional copies are $2 each. Orders should be sent to the following address, accompanied by a check or money order made out to the Superintendent of Documents, when necessary. VISA and Mastercard credit cards are accepted, also. Orders for 100 or more copies to be mailed to a single address are discounted 25 percent. Orders by mail: U.S. General Accounting Office P.O. Box 37050 Washington, DC 20013 or visit: Room 1100 700 4th St. NW (corner of 4th and G Sts. NW) U.S. General Accounting Office Washington, DC Orders may also be placed by calling (202) 512-6000 or by using fax number (202) 512-6061, or TDD (202) 512-2537. Each day, GAO issues a list of newly available reports and testimony. To receive facsimile copies of the daily list or any list from the past 30 days, please call (202) 512-6000 using a touchtone phone. A recorded menu wiB provide information on how to obtain these lists. For information on how to access GAO reports on the INTERNET, send an e-mail message with “info” in the body to: info@?www.gao.gov or visit GAO’s World Wide Web Home Page at: http&vww.gao.gov United States General Accounting Washington, Office D.C. 20548-0001 II BulkRae. Postage & Fees Paid GAO Permit No. GlOO I Official Business Penalty for Private Use $300 Address Correction Reauested
Information Technology: Comments on Proposed OMB Guidance for Implementing the Government Paperwork Elimination Act
Published by the Government Accountability Office on 1999-07-02.
Below is a raw (and likely hideous) rendition of the original report. (PDF)