Neumann SSN Testimony

The Social Security Internet Website:
Technology and Privacy Implications

Peter G. Neumann, Principal Scientist, Computer Science Laboratory
SRI International, Menlo Park CA 94025-3493
Telephone: 1-415-859-2375 (1-650-859-2375 after August 1997)
E-mail to Neumann@CSL.SRI.com; Web http://www.csl.sri.com/neumann.html

Testimony for the House Ways and Means Committee Subcommittee on Social Security,
Social Security Internet site hearing, 6 May 1997, Rayburn B318, 3:00pm
Copyright Peter G. Neumann 1997. Noncommercial and government reuse freely permitted.

ABSTRACT

This document is prompted by the recent on-line availability of the PEBES (Personal Earnings and Benefit Estimate Statement) database system, a Website developed and maintained by the Social Security Administration (SSA) (http://www.ssa.gov). Because of widespread complaints (for example, see [2]), PEBES was removed from the Internet to permit further study of some of the implications. On the whole, the SSA is to be commended for taking the initiative toward making this database available on the Internet, but chided for not having engaged in a public review prior to implementation and deployment. Nevertheless, it is appropriate that the SSA is now submitting to an open review.

This testimony discusses the underlying issues and makes a few constructive suggestions. Section 1 addresses specific questions from the SSA. Section 2 discusses the issues and the risks. Section 3 gives some recommendations, while Section 4 provides a concise summary.

1. SSA QUESTIONS AND MY ANSWERS

For its forthcoming series of Social Security Forums, the SSA has requested brief answers to the following questions. My answers are interspersed; further discussion follows in Section 2.

SSA Q1. In providing electronic services, what information should SSA require from a customer for authentication of identity?

First, let me answer a more important question: What information should not be required from a customer? Easily acquired information such as names, phone numbers, SSNs, and mother's maiden names should not be used for authentication of identity -- although it is of course very useful for identification. Identity and authenticity must not be confused. (See item 2a in Section 2.1 on identity, authentication, and authorization.) Nonspoofable authentication is very difficult to attain; it requires a substantially more secure infrastructure than is currently available or foreseen. A user-designated nontrivial password would be a marginal improvement; however, in the absence of encryption, those passwords would be transmitted in the clear and therefore capturable. In the absence of substantial infrastructural improvements and meaningful authentication, all measures to provide proof of customer identity can be compromised.

Now we can address SSA Q1. A relatively straightforward near-term authentication procedure is proposed in the paragraphs of item 3d in Section 3, requiring a separately obtained confirmation number that must be used in conjunction with the customer password; that approach would be significantly stronger than the existing procedure. In the longer term, when a national certificate service is available and the infrastructure has improved, it would be natural to use some sort of one-time (nonreusable) cryptographically-based token. (See References [4] and [5] for consideration of risks in the infrastructure.)

SSA Q2. Beyond information obtained directly from the customer, what further safeguards should SSA employ to support customer authentication and privacy in electronic transactions? Which safeguards should be employed in the near term, and which in the longer term?

Three additional safeguards are of particularly urgent importance in the near term, relating to accountability (item 3i). The first involves detailed monitoring of all database accesses. The second involves real-time analysis of the monitored accesses to detect nonindividual uses of the database and other potential misuses -- for example, to discover and analyze apparent attempts to access records for different individuals or data collections en masse. The third is to provide even stronger authentication (item 3f), monitoring and analysis of system access (item 3i) by insiders who are privileged to query, update, modify, or maintain the PEBES database and the underlying system -- recognizing that insider misuse is always a serious risk (as noted in item 2g).

Unfortunately, it is often not possible to identify a perpetrator in the absence of meaningful authentication; the perpetrator could be using a faked network identity and a faked net address, possibly even masquerading as a victimized user. However, at least the SSA might become aware of the extent of the misuse, and could consider defensive measures such as further monitoring and pursuit of the offenders. In the longer term, the SSA should actively promote the development of a national public certificate service and a much more robust computer-communication infrastructure, which the SSA should anticipate by planning now to exploit where appropriate.

SSA Q3. Should we reinstate the PEBES online service with minor additions to the safeguards we had in place, should we reinstate it only with fundamental changes to our safeguards, or should we not reinstate it at all?

Clearly, the SSA would like to reinstate PEBES, because of its potential benefits to the SSA. However, the risks to the public must be considered. I believe that PEBES must not be reinstated if only minor additions can be made. I would not recommend reinstatement unless I were convinced that the SSA really understands the risks outlined here, and that it had engineered something along the lines of the much less spoofable authentication scheme noted in my response to Q1 (item 3d), the monitoring and analysis capabilities in my response to Q2 (item 3i), and internal-use controls (item 3f). Fundamental changes are necessary. Minor additions are insufficient to defend against identity fraud and other misuses, with respect to individuals as well as on a massive scale. (See items 2e to 2g on the risks of identity theft.)

SSA Q4. If you believe electronic PEBES should be reinstated, what additional safeguards should we include?

If the SSA believes that what is recommended in my responses to Q1, Q2, and Q3 is worth pursuing, then it must also recognize that those measures (or something equivalent) are by themselves still insufficient -- even if they could be fully enforced. In fact, serious extrinsic risks would remain that cannot be covered by system safeguards. Several procedural safeguards are noted in my response to Q5.

SSA Q5. Because the question of maintaining privacy in electronic transactions has far-reaching implications in both the public and private sectors, what other matters should SSA consider in addressing this major public-policy issue?

The SSA must look broadly at PEBES and related databases. It would be simplistic to place blame on the existence of Social Security Numbers or on the existence of PEBES; the problems are much deeper than that, relating to intrinsic vulnerabilities in authentication and the overall infrastructure, misuses that can occur outside of the scope of the PEBES system, and legal shortcomings (for example). As discussed in detail in Section 2, any such databases will inevitably have some serious misuses; the potential risks are quite far-reaching. SSA employees must understand and anticipate the overall risks that can result from the misuse of SSNs and the misuse of the PEBES data -- in the larger context of identity theft, aggregation of data from other sources, and related problems. In addition, law-enforcement communities must understand the implications of these risks on the victims -- whose tales of woe are often either disbelieved or ignored. All Government employees with legitimate privileged access to PEBES and related systems must be specially trained to resist social-engineering efforts by would-be perpetrators. Explicit codes of proper use must be established for both external users and internal SSA personnel. Legislation must provide stiff penalties for database misuses that violate those codes, and empower compensation for victims of identity theft and other personal intrusions that might result. Although there can be no complete set of countermeasures or checklists, these procedures would help.

The rest of my testimony discusses these issues and recommendations in greater detail.

2. DISCUSSION OF THE ISSUES AND THE RISKS

The primary message of this testimony is that, despite the desire to make information readily available to those individuals directly involved, there are many opportunities for serious misuse of personal information that must be carefully considered. Similar issues have arisen before, as in the case of the criminal-history information that was formerly a part of the NCIC National Crime Information database; the criminal-history data is much more prone to misuse than the more topical NCIC data that needs to be widely available for law-enforcement purposes. However, in the case of PEBES, the application affects every individual in the country much more directly than other databases. Although this document refers specifically to PEBES and certain types of misuses that can result from it, the observations and conclusions here are also applicable to many other databases, both public and private.

Ideally, the World-Wide Web is a very effective way to make public information accessible world-wide. In practice, there are some serious technological and social problems, discussed herein.

In general, most people -- including many professionals and managers -- are oblivious to most of the risks relating to the use of computer systems (see Reference [5]). These risks tend to be dramatically amplified in the on-line world, compared with the paper-based world of a few decades ago. What could previously have been done typically only with some effort by an insider to affect a single individual can now be done with almost no effort on a massive scale to affect an entire population. Furthermore, a perpetrator can operate outside of the country and beyond its legal jurisdiction. The Internet greatly exacerbates the problems because of its almost instantaneous global accessibility, with its serious lack of system and network security, Website integrity, personal authentication, accountability. The entire infrastructure is riddled with risks [4], although many of those risks are routinely ignored by database purveyors. PEBES gives us an opportunity to analyze some of these risks.

2.1. Intrinsic Technological Risks

Various risks arise within the limits of the technology itself.

* 2a. Identity, authentication, and authorization of Website users. We make a careful distinction among the concepts of personal identity, authentication that someone's identity is as claimed, and authorization that permits an authenticated individual to access computer systems and data in some particular way. Identities tend to remain the same over time, whereas parameters used in authentication and authorization may change -- and may actually have to be revoked under certain circumstances. Commonly known information (such as your name) is typically used for identification purposes. Unfortunately, easily acquired information is often also used as a means of authentication, which is an extraordinarily bad practice. For example, unless you have militantly refused to divulge your SSN, it and your mother's maiden name are likely to be available in many places accessible to a would-be impersonator. The latter ``secret'' item is on your birth certificate and is found in publications such as Who's Who. In general, authentication does not prove that someone claiming to be a particular individual is actually that individual. This not only opens up risks of impersonation, but also introduces the problem of repudiation -- namely, that an individual using his or her own identity for authentication may justifiably be able to later claim that it had been someone else.

The Internet does not currently provide any real assurances as to the identity of a person or computer agent accessing a given Website. It is relatively easy for one user to masquerade as another user, and even to appear to be coming from a system other than the one from which misuse originates. Some systems and Web browsers take authentication more seriously than others (for example, using the SSL secure socket-layer protocol), but casual use typically requires no positive authentication. Even if some sort of strong authentication were to be invoked (and many techniques are emerging as less spoofable alternatives to reusable passwords), the typical Website does not enforce differential authorization in the form of selective access controls -- once you are there, you may have implicit permission to read everything that is accessible to any other Web browser. PEBES does attempt to restrict you to accessing your own records, although such controls in similar systems are often subvertible.

* 2b. Integrity of the data and the system. In principle, PEBES is a read-only database where external users are not permitted to modify the information. However, because of the existence of flaws in Webware security and presumed flaws in the SSA operating systems and networking software, that does not necessarily prevent an intruding external user from modifying the data -- for example, by masquerading as an internal SSA employee. Thus, there is the possibility that information on a given Website may itself not be trustworthy, because the Website may have been compromised. Recent attacks on Websites resulted in the disruptive alteration of Web pages developed by the CIA, NASA, the Justice Department, the Air Force, and even the National Collegiate Athletic Association. Subtler changes that are not immediately obvious could be even more insidious than flagrantly obvious spoofs. In addition, malicious alternative sites may be created that act as Trojan horses -- capturing sensitive information, interfering with normal use, or otherwise deviating from expected behavior. For example, promulgation of a false http address such as http://www.ssa.org instead of www.ssa.gov might entrap users into responding to requests for their SSN, mother's maiden name, and other identifying information, and then could redirect their queries to the correct site).

* 2c. Correctness of the data. Various reports suggest that there are many errors in the information in the Social Security databases, although people typically may not discover errors until they retire -- by which time records and evidence necessary to make corrections may no longer be available. Unfortunately, many people assume that ``computers are always right.''

* 2d. Confidentiality of the data. Widespread dissemination of certain parts of the SSN data for a given customer data may lead to misuse in the context of the authentication problems (2a) and the risks of identity theft (2e to 2g). However, it is worth noting that certain high-level Government employees have their PEBES records ``red-flagged'' to make them inaccessible externally; I hope those folks are not the ones who might falsely conclude that there are no significant risks resulting from external disclosure of records! As discussed here, the secondary risks of misuse can be considerable.

2.2. Extrinsic Risks: Misuse Beyond the Computer Systems

Many other risks are outside of the scope of the computer technology, such as large-scale identity fraud, data mining to identify potential targets, and development of commercial database systems that integrate and draw inferences from data across many different databases.

* 2e. Inference and aggregation. Perhaps the most serious risk of a Website containing information on individuals is that this information can be used for purposes other than those for which it was intended. Furthermore, information from different databases may be easily combined to provide detailed information about individuals that may be misused to the detriment of those individuals, either by further computer manipulation or by ``social engineering'' -- getting people to do what they are not supposed to do by exploiting partial knowledge and clever subterfuges. Although individual data items may not appear to be sensitive, their aggregation may provide opportunities for attacks on particular individuals or on large groups of people. (There are also risks of annoyance such as apparently legitimate creative scams, or being flooded with unwanted solicitations.)

* 2f. Identity theft. An important type of misuse derived from the collection of personal information involves theft of one's identity and other forms of malicious masquerading. For example, knowledge of your Social Security Number (SSN) and mother's maiden name is often sufficient for someone else to dishonestly access and manipulate your financial accounts, and to obtain credit cards and loans in your name. There have been numerous sometimes very agonizing cases of identity theft. (Recall the cases of Terry Dean Rogan, Richard Sklar, Teresa Stover, Clinton Rumrill, and Charles Crompton (see Reference [5]), and the more recent cases of Kathryn Rambo and Caryl Fuller [3]. For example, Rambo's masquerader acquired a $35,000 sports utility vehicle, a $3000 loan, new credit-card accounts, and a rented apartment in her name. (These cases are summarized in the on-line Risks Forum Digest, volume 19 no 05. Additional problems with identities are summarized in the Risks Forum Digest, vol 18, no 91.) In other cases, life savings and all social security benefits have been lost. Perhaps the most tragic is that once this has happened to you, your life may have been permanently altered; efforts to regain your credit rating and your sanity may be very difficult.

* 2g. Misuse of SSNs. SSN misuse is apparently an art form. 550 felonies involving SSN misuse were reported in approximately the first half of 1991, a sudden considerable increase over earlier years [1]. The problems seem to be growing rapidly since then [3]. To give just a few examples of fraudulent SSN misuse, a woman dunned for back taxes discovered that her SSN was being used by 12 other people; another person found someone had opened up 16 credit cards in her name and charged $10,000; another person claiming her own unemployment discovered others had beaten her to it using her SSN [1]. SSN misuse can be done by outsiders and insiders; it transcends the issues raised by PEBES. A notorious case of insider misuse involved several SSA employees who sold SSA information (including SSNs and mother's maiden names of more than 11,000 people) to a credit-card fraud ring, which then used the information to activate newly issued Citibank credit cards that had been stolen. (See the on-line RISKS, vol 18, no 02.)

* 2h. Uniqueness of apparent identity. The SSN has a major intended benefit in that a correct SSN is expected to uniquely identify an individual (or, in the case of an EIN, a corporate entity). Note that the reverse is not generally true, because some individuals have multiple SSNs, or no SSN at all. Also, some SSNs are fraudulently obtained.

* 2i. Allocation of SSNs. There are various cases in which the same SSN has been allocated to or used by different people. In one case, two women with almost the same name and birthdays in the same month were given the same SSN, which was discovered only when one of them was dunned for back taxes on their combined income ([4], p. 196).

3. WHERE SHOULD WE GO FROM HERE?

It is essential to accept the fact that there are no easy answers. However, here are some fairly specific recommendations that could help significantly.

* 3a. The identity-related risks of information systems must be recognized and assessed realistically. Identity fraud is becoming very easy to perpetrate, very profitable, and very difficult to prevent (let alone to detect) until it is too late. The ready availability of SSNs and other personal information greatly increases the risks in the absence of people who understand the risks. Confusion or ambivalence over how vulnerable SSNs are also adds to the problem.

* 3b. Using SSNs for authentication as well as identification is an enormous mistake. SSNs are certainly useful for identification, and can even help avoid problems resulting from accidental misidentification. However, when required to be presented as a means of authentication, they are too easily misused.

* 3c. It is in general wise to plan on open access for Government databases rather than restricted access, whenever the other risks can be controlled. However, the risks of inference, aggregation, and misuse must be addressed explicitly rather than ignored. In particular, the only practical strategy regarding SSNs is to assume that they are public, and to establish strong restrictions on how they may be used with stringent penalties for misuse. Nevertheless, whenever any data sensitivity is present, authorization to access records should be restricted to those authenticated users who actually need such access. Furthermore, it is unwise to assume that unprivileged (e.g., external) users cannot find a way to gain the access permitted to privileged (e.g., internal SSA) employees, or to assume that privileged users are all impeccable.

* 3d. In the short term, any attempt to resuscitate PEBES should include nontrivial user passwords that are assigned by the SSA more or less randomly and distributed securely to individuals. In addition, the SSA must find some way of preventing masqueraders from requesting address changes for other people -- which is relatively easy today, through either the postal service or the SSA.

My colleague Lauren Weinstein (Moderator of the Privacy Forum Digest, which exists in part under the auspices of my ACM Committee on Computers and Public Policy) suggests a relatively simple multistep approach that could help reduce misuse. A person requesting access to the database via the World Wide Web would be asked to provide an existing identifier, but would not be granted access to any data during this initial authentication session. Secure-sockets mode would be required for all Web transactions to prevent interception. During this initial session, the SSA Website would generate and display a random confirmation number to be used in future sessions. It would also generate a random password, which would be sent in a sealed envelope by postal mail to the user's established address. The password would never be displayed via the Web, and the confirmation number would not be sent through the mail.

After receiving the password via postal mail, the customer could then routinely use that password in conjunction with the confirmation number to access the server for database queries or other operations. The use of the confirmation number would make the password of little use to anyone else receiving the mail. The password would be sent only to the user's address of record in the SSA database; specification of or changes to the address would not be permitted through the Web site during the authentication session, and in subsequent sessions would require both the confirmation number and the password. Additionally, notice of any change of address should be mailed via the USPS to both old and new addresses.

Although this procedure is not completely foolproof, it could dramatically reduce misuse. Although the initial establishment of each user's authorized account would take a few days of elapsed time, subsequent accesses would be instantaneous with minimal involvement of SSA human resources, with lowered risks to each individual, and greatly decreased opportunities for large-scale misuse.

* 3e. In the more distant future, our computer infrastructure must become more secure (for digital commerce, if nothing else), and some sort of national public certificate authority must be instituted (more or less invisibly). When this occurs, it would be the basis for some form of one-time password such as supposedly nonforgeable cryptographic authenticators, and significantly better authentication could become ubiquitous. Privileged access, selective write-access controls for SSA employees, selective read access only to properly authenticated users, and nonbypassable audit trails would then be much easier to enforce, and misuse might be easier to control.

* 3f. In addition to stronger authentication for customers, even stronger authentication is recommended for privileged users with permission to modify the database or to access it globally. Cryptographic or biometric authenticators (e.g., fingerprint or handwritten signature) might be appropriate for any privileged accesses above and beyond individuals accessing only their own records.

* 3g. People should be given the option to have on-line access disabled completely (thereby denying access to masqueraders and to themselves).

* 3h. We must develop a more meaningfully secure infrastructure. The present infrastructure is very weak with respect to security and integrity. Authentication and accountability are fundamental to digital commerce and governmental uses of computer-communication technology, and must be pursued more vigorously. If such solutions were more widely available, they could contribute to an amelioration of the identity theft and general misuse problem -- as well as the SSA database risks. (Again, see Reference [4].)

* 3i. Good accountability requires at least two capabilities. The first involves detailed monitoring of all attempted database accesses, in terms of who made the access, what query (or update) was initiated, what data was accessed, or what type of failed access resulted in cases where either the authentication or the authorization barred access. System staff personnel with permission to update the database should be subjected to stringent authentication and detailed monitoring. Accountability is also necessary for all status changes -- changes of user address and changes of system authority. The second capability involves real-time analysis of the monitoring results to detect and analyze suspicious uses of the database -- for example, to discover immediately unauthorized attempts to access records for multiple individuals. Unfortunately, accountability may be very weak in the absence of strong user authentication. For example, a perpetrator masquerading as another user or using a faked net address may be very difficult if not impossible to identify and prosecute. However, such real-time analysis could at least alert the SSA to ongoing misuse, whereupon the SSA could consider alternatives such as carrying out finer-grain monitoring, or decommissioning the system.

* 3j. PEBES should detect repeated unsuccessful access attempts, and have the option of disabling all accesses to that record after several failed attempts. That option could be turned off if system administrators detect a massive denial-of-service attack attempting to block everyone from the system.

* 3k. Attempting to detect misuse is much less satisfying than having a policy for authentication and authorization that can be properly enforced. Unfortunately, today's infrastructure does not permit such a policy to effectively control usage. Also, external misuse cannot be adequately limited by internal controls.

* 3l. As SSNs are increasingly exhausting the 9-digit limit, randomly generated numbers are more likely to be valid. Adding redundancy to the SSN itself (for example, through a check digit as used in credit-card numbers) could somewhat reduce mistakes resulting from mistyped or misread digits. This, however, would do very little to increase security, just as the check digit on credit cards does little to prevent fraud. Similarly, it would not eliminate the use of bogus SSNs.

* 3m. All in all, there are very considerable risks to individuals and to Government stability. The Social Security Administration problems raised by PEBES are merely the tip of an enormous iceberg, although they are very significant in their own right. Any measures to resolve the SSA problems must also take into account the broader issues relating to the need for open Government information via the Internet and the risks that ensue -- as well as the risks of not having open information.

* 3n. Various legislation is being contemplated. For example, Senators Dianne Feinstein (Dem., California) and Charles Grassley (Rep., Iowa) have introduced legislation (S 600) that would bar commercial use of Social Security numbers (including by state motor-vehicle agencies) and make it illegal for credit bureaus to disseminate Social Security numbers, unlisted phone numbers, birthdates, mothers' maiden names, and other personal information. It would also enable offended parties to collect civil damages. In the House, Congressman Paul E. Kanjorski (Dem., Pennsylvania) has submitted legislation that would create a Commission on Privacy of Government Records and ban Social Security or Internal Revenue Service records from being posted on the Internet without an individual's written permission (Washington Post, 17 Apr 1997). Although any legislation must be reviewed carefully for loopholes and side-effects, it is essential that some such legislation be passed. In the absence of a sufficient infrastructure, taking no action at all would be insufferable.

* 3o. Good cryptography is needed -- both for authentication and for confidentiality in transmitting passwords (not to mention the user data). Existing U.S. cryptographic policy is therefore a relevant factor [6]. Although the existing export controls do permit strong cryptography to be exported if it cannot be used for anything other than authentication, in many systems it is difficult if not impossible to ensure that such cryptography could not be used as encryption for secrecy; thus, the export controls and associated difficulties in integrating cryptographic solutions into systems tend to have a chilling effect on cryptography used for authentication as well as for privacy. As a consequence, effectively authenticated use of databases such as PEBES may be further hampered by delay in the development a national public-authentication infrastructure -- which is already hindered by these controls.

4. CONCLUSIONS

In conclusion, I believe that the dramatic increase in the open use of Internet-accessible databases and Websites -- both Governmental and private -- is generally very beneficial. However, some of those databases (and PEBES in particular) have the potential for seriously increasing the risks of identity theft and related misuse. The technological alternatives suggested here are quite realistic -- better authentication, authorization, and accountability for both insiders and outsiders, use of secure browsers, and eventually the use of a public-key certificate infrastructure.

* 4a. Risk awareness. Despite the massive size of the SSA organization, many of its employees will have to be cognizant of the risks and exert the vigilance necessary to avoid them. The law-enforcement community will need to recognize the risks (in several cases, victims of identity theft have been further victimized by unknowing police actions) and help in achieving remedial measures. In addition, the populace at large must become better aware of these risks and their implications.

* 4b. Risk assessment. Attempting to quantify the risks associated with systems such as PEBES is itself a risky business. Quantitative risk assessment is very much like statistics -- you can prove anything you want, depending on your assumptions and skill. (For example, see [5], pages 255-257.) On the other hand, I strongly urge Congress to commission a non-SSA oversight group (such as the Government Accounting Office) to conduct a comprehensive qualitative risk assessment for PEBES that takes into account all of the factors discussed in this testimony (and others I may have omitted). Superficial analysis might conclude that a few individuals losing a little privacy is not a sufficient risk to warrant the measures that I have recommended. However, a deeper analysis might conclude that the risks affect not just a few unfortunate victims of identity theft or financial fraud, but wide-spread coordinated and well-organized extrinsic misuse that is vastly greater than generally recognized and could indeed affect the national infrastructure. Even with such a risk analysis, we may have to endure a few highly visible massive misuses for this conclusion to become evident; it often takes a major disaster affecting important people.

* 4c. Seeing the big picture. Focusing too much on the database information itself is a mistake -- the real problems arise because of the many ways in which that information can be misused. Risks of information misuse represent a fundamental problem that cannot be avoided by restricting the use of SSNs for identity purposes, but that can be greatly reduced by avoiding the use of SSNs and related common knowledge for authentication purposes. PEBES is not intrinsically bad; however, as it is presently implemented, its use is an open invitation to misuse, particularly in the absence of a meaningfully secure infrastructure.

* 4d. Technology. The SSA (as well as other state and Federal government agencies) should be extremely cautious when deploying databases such as PEBES, and should make a much greater effort to understand the risks summarized here. There are no easy answers; there is no simple way to make PEBES widely available without encountering the risks outlined here, given the vulnerabilities in today's technological and social infrastructure. At the very least, identifying information such as SSNs should be avoided as a means of authenticating identities (item 3a and 3b, above), and SSNs should not be assumed to be secret (item 3c). PEBES and any other database systems contributing to the identity-theft problem and related misuse should provide nontrivial individual authentication and selective authorization (as discussed in items 3c through 3g), generally improved computer-communication infrastructure (3h) including good cryptography (3o), thorough monitoring and accountability (3i), real-time detection of potential misuse (3i), and reaction to systematic attacks (3j).

* 4e. Legislation. Explicit policies must define unacceptable misuse of information -- for example, associated with SSNs and PEBES -- and thoughtful legislation must provide stiff penalties and unwaivable tort-law protection (see item 3n). However, making something illegal may not be a sufficient deterrent if the infrastructure is incapable of providing adequate internal and external controls and positive identification of culprits.

PEBES must constrain access so that individuals can access only those data items for which they have a direct need to know. Suitable technology and administrative controls must be in place to minimize the likelihood of unacceptable risks, particularly those caused by other individuals (some perhaps acting remotely, outside of local jurisdiction). Ideally, those controls must not be intrusive. If acceptable controls cannot be implemented effectively, and if the risks outweigh the benefits to the populace at large, then the entire concept is flawed and the system should not be deployed. The Social Security Administration has an vital challenge get it right. I believe Congress must play a strong role in overseeing that process. Finally, although this document has focused on PEBES, my testimony is applicable to many other applications in which authentication, authorization, accountability and operational procedures can significantly decrease the risks of misuse.

REFERENCES:

[1] Yasmin Anwar, ``Thieves Hit Social Security Numbers; Fouled-Up Benefits and Credits'', San Francisco Chronicle, 30 August 1991, A1. The entire copyrighted article is in the on-line RISKS, vol 12, no 20, on the same date, reprinted with permission.

[2] Simson L. Garfinkel, Social Insecurity: Few key bits of info open Social Security records, USA Today, 7 April 1997. The entire copyrighted article is in the on-line Risks Forum, vol 19, no 5, 7 April 1997 (ftp://ftp.sri.com/risks/risks-19.05 and http://catless.ncl.ac.uk/Risks/19.05.html), reprinted with permission.

[3] Ramon G. McLeod, ``New Thieves Prey on Your Very Name; Identity bandits can wreak credit havoc'', San Francisco Chronicle, 7 April 1997, A1.

[4] Peter G. Neumann, Security Risks in the Emerging Infrastructure, Written testimony for the U.S. Senate Permanent Subcommittee on Investigations of the Senate Committee on Governmental Affairs, 25 June 1996. See Security in Cyberspace, Hearings, S. Hrg. 104-701, 1996, pages 350-363, with oral testimony included on pages 106-111. ISBN 0-16-053913-7. (http://www.csl.sri.com/neumannSenate.html)

[5] Peter G. Neumann, Computer-Related Risks, Addison-Wesley, 1995. ISBN 0-201-55805-X. (See http://www.csl.sri.com/neumann.html for a few errata.) This book should be read by everyone who is not yet convinced that computer-communication systems and the people who use them do not always behave the way they are expected to.

[6] Cryptography's Role In Securing the Information Society (a.k.a. the CRISIS report), Final Report of the National Research Council Cryptographic Policy Study Committee, National Academy Press, 2101 Constitution Ave., Washington, D.C. 20418, 1996.

Note: http://www.csl.sri.com/~risko/risks.txt gives the latest issue of the ACM Risks Forum (including subscription information); back issues are at http://catless.ncl.ac.uk/Risks (with a search engine) and ftp://ftp.sri.com/~risks (/i for vol i less than 19).

PERSONAL BACKGROUND

I have been involved with the U.S. Government in different technological contexts for many years, including research, development, consulting, and advising, on subjects related to national security, law enforcement, air-traffic control, and NASA. (My first computer-related job was for the Navy in the summer of 1953, almost 44 years ago, programming an IBM Card-Programmed Calculator.) I have long been concerned with security, reliability, human safety, system survivability, privacy, and human well-being as they depend on computer-communication systems and networks, as well as with how to develop systems that can dependably do what is expected of them. For example, I have designed operating systems and networks, secure database-management systems, and analysis systems that seek to identify abnormal and dangerous patterns of behavior. I have also been seriously involved in identifying and preventing risks. Some of this experience is distilled into my recent book, Computer-Related Risks (Reference [5]).

I am a Fellow of the American Association for the Advancement of Science, the Institute for Electrical and Electronics Engineers, and the Association for Computing (ACM). My present title is Principal Scientist in the Computer Science Laboratory at SRI International (not-for-profit, formerly Stanford Research Institute), where I have been since 1971 -- after ten years at Bell Telephone Laboratories in Murray Hill, New Jersey. I have doctorates from Harvard and the Technische Hochschule, Darmstadt, Germany (the latter obtained while I was on a Fulbright from 1958 to 1960). For 2.5 years (1994-96) I was on the Internal Revenue Service Commissioner's Advisory Group, where I addressed primarily privacy and security issues. I served on an expert panel for the House Judiciary Committee Subcommittee on Civil and Constitutional Rights (1987-1989), evaluating risks in law-enforcement database systems at the request of Congressman Don Edwards. In other activities, I was a member of the National Research Council committee (1994-96) studying U.S. cryptographic policy [6] and on an earlier study of the same subject sponsored by the ACM U.S. Policy Committee (USACM), of which I am a member. I was a coauthor of an earlier report of the National Research Council (1988-90), Computers at Risk. I am chairman of the Association for Computing (ACM) Committee on Computers and Public Policy (CCPP), and Moderator of its widely read Internet Risks Forum comp.risks).

This position statement has been reviewed by the USACM and CCPP members; I am very grateful to them for their suggestions. Although they have expressed strong support for this document, it must be considered as representing my own views and not those of SRI or the ACM.

 

 

Related Documents


Related Articles

Global Technology Policy Newsletter – March 2017
ACM PUBLIC POLICY HIGHLIGHTS ACM provides independent, nonpartisan, and technology-neutral research and resources to policy leaders, stakeholders, and the public about public policy issues, as drawn from the deep technical expertise of the computing community. Apply for the new A ...Read More

  • (Posted on 12-Mar-17)
  • ACM Joint Task Force on Cybersecurity Education Grabs Spotlight at U.S. Congressional Hearing
    The ACM Joint Task Force on Cybersecurity Education seized the spotlight during a congressional hearing on “Strengthening U.S. Cybersecurity Capabilities” on Capitol Hill on February 14, 2017. The hearing before the House Science, Space, and Technology Subcommittee on ...Read More

  • (Posted on 18-Feb-17)
  • Global Technology Policy Newsletter – February 2017
    ACM PUBLIC POLICY HIGHLIGHTS ACM seeks to educate policymakers, the computing community, and the public about policies that will that foster and accelerate innovations in computing, computing education, and related disciplines in ways that benefit society. ACM Statement on U.S. E ...Read More

  • (Posted on 12-Feb-17)
  • ACM Sponsors Data Sciences Education Roundtable at the U.S. National Academies of Sciences
    ACM is sponsoring a new 3-year initiative by the National Academy of Sciences on data science postsecondary education. A series of roundtable discussions will bring together representatives from academia, industry, funding agencies, and professional societies to explore the trans ...Read More

  • (Posted on 17-Jan-17)
  • Global Technology Policy Update – December 2016
    ACM PUBLIC POLICY HIGHLIGHTS Cybersecurity Education and Research in Europe – The ACM Europe Policy Committee released a policy white paper “Advancing Cybersecurity Education and Research in Europe.” Committee Chair Fabrizio Gagliardi recently presented the find ...Read More

  • (Posted on 12-Dec-16)
  • Global Technology Policy Update – October 2016
    ACM PUBLIC POLICY HIGHLIGHTS Computer Science Education and Research in Europe – ACM Europe Policy Committee members will be attending the European Computer Science Summit in Budapest, Hungary on October 24-26, which features programs on the challenges and opportunities in ...Read More

  • (Posted on 09-Oct-16)