Date: Wed, 08 Jul 92 16:44:40 EST Errors-To: Comp-privacy Error Handler From: Computer Privacy Digest Moderator To: Comp-privacy@PICA.ARMY.MIL Subject: Computer Privacy Digest V1#059 Computer Privacy Digest Wed, 08 Jul 92 Volume 1 : Issue: 059 Today's Topics: Moderator: Dennis G. Rears Re: SSNs and Social Insurance Numbers Re: Caller ID decision Information Technology Security Evaluation Manual (ITSEM) V0.2 Re: SSNs and Social Insurance Numbers The Computer Privacy Digest is a forum for discussion on the effect of technology on privacy. The digest is moderated and gatewayed into the USENET newsgroup comp.society.privacy (Moderated). Submissions should be sent to comp-privacy@pica.army.mil and administrative requests to comp-privacy-request@pica.army.mil. Back issues are available via anonymous ftp on ftp.pica.army.mil [129.139.160.200]. ---------------------------------------------------------------------- From: rwhit@cs.umu.se (Randall Whitaker) Subject: Re: SSNs and Social Insurance Numbers Organization: Dep. of Info.Proc, Umea Univ., Sweden Date: Sat, 4 Jul 1992 18:56:23 GMT In towers.rn.com!brian@homebase.vistachrome.com (Brian Murrey) writes: >Not sure if this is still true, but at least 7 years ago the ABC part of the >SSN was an indication as to what state the SSN was issued in. I used to do >some skip tracing for a major plastic credit company and we had a sheet that >identified where the first 3 digits belonged. IE: 303 is Indiana, though many >states had 3 or 4 prefixes assigned to them. > >I also remember that there were two or three "special" prefixes reserved for >Railroaders, Government Dependents, and another special group that I can't >remember. Hej: I was a claims rep. for SSA from the 1970's through the mid-80's. We were trained in all this stuff. I can tell you what I recall of the specifics as they are accessible from memory. NOTE: This is the 3rd time I've contributed this info to this group. Is there a FAQ? Should there be one? The points above are vaguely correct. Returning to the coding scheme used in another posting in this thread, i.e.: ABC-DE-FGHI for the 9-digit SSN (I forget the precise nomenclature, so bear with me)..... ABC: This is a block number. It denotes an entire "block" or set of numbers to be assigned. The blocks were originally assigned back in the early days (late 1930's). Additional blocks were opened as they became needed. The originally anticipated distribution of the blocks didn't work out due to demographic shifts (especially migration to the South and West). These blocks are NOT assigned by state. They are assigned by Federal administrative region (specifically the admin. regions delineated for HHS operations -- e.g., NY / Philly / Atlanta / KC / etc.). DE: This is a group number. It denotes a subset of a "block". The groups are not issued in strict sequence. They are issued by odd number 1-9, then by even numbers (10?-98?), then by even (00?-08?), then by odd again (11?- 99?) NOTE: the question marks mean I don't recall the exact "breaks", but the general ordering given is correct. FGHI: This is the individual number. Originally, there doesn't seem to have been any particular issuance sequence in mind -- I assume they were simply assigned sequentially. As of the mid-80's, these last 4 digits were assigned by the SSA central office (Baltimore) and relayed back to the local office where the application for a SSN was filed. The local office didn't (and couldn't) know what the number was to be until notified by central office. NOTES: The block/group combo can tell one the region and locality WHERE THE APPLICATION FOR AN SSN WAS FILED. There is no requirement that you file in your hometown, home state, or whatever. In fact, foreign workers must file for SSNs (to report taxes on US wages), and they do so wherever. This also tells you the region and locality WHERE THE SSN WAS ISSUED. That's it. I am not sure whether the granularity of group numbers could narrow it down to district or precise office. The operations manuals for SSA contain tables showing the regions, block/group numbers, and dates. This enables SSA employees to know in which region and by which (rough) date a block/group combo was issued. This info is used to determine (with, or in the absence of, other data) length of residence in the US for certain types of benefits SSA administers. There is no means for verifying a whole number locally except a wire query to regional or central office. Since the 30's, there have been occasions when certain block and/or group sets have been set aside for particular uses. (As best I recall...) the 700 series was originally assigned to RRB (Railroad Retirement Board) pensioners , who were covered by a pre-existing, non-SSA pension system. The 900 series was used for aliens working in the USA. I think a certain series (part of the 700 block???) has been used to denote Black Lung beneficiaries and/or their dependents (I could be wrong on this). I am an example of how far off this system could be. My hometown (Bristol, Tenn. / Va.) straddles a state line. I grew up on the TN side; the SSA office was on the VA side. TN is in the Atlanta HHS Fed. region, and VA is in the Mid-Atlantic region. As a result, I got a Mid-Atlantic-assigned SSN, even though I resided in the Atlanta region. At the time I left SSA, they were getting concerned about SSNs and security. The reason I remember even this much about a subject within my expected range of knowledge (but not my daily activities) is that I attended security training shortly before I left SSA. I was told (both in initial and follow-up training) that the idea of checksum or other "validation checks" for the numbers had in fact been brought up back at the beginning, but it was decided such features didn't seem too American, and they were not in fact implemented. PROBLEMS: *Yes, the series is running out. *No, there was no consistent and comprehensive tracking of deaths. As a result, there is technically no coherent way of knowing when an SSN is available for re-use. This deficiency mainly applies to the early days. *In the 1950's (??) a wallet manufacturer (Prince Gardner??) put a dummy specimen SS card in a line of billfolds (just for display). An unbelievably large number of people used the dummy cards (and the number upon it) for years. At the time I left SSA, there were still earnings being reported to the "billfold" number, and huges amounts of time and effort had been expended over the years in sorting out all the different peoples' earnings reported to this one bogus number. *People appropriate, take, steal, fabricate, etc., SSNs all the time. I have seen cases where mentation-challenged folks have literally taken a parent's or relative's SS card at their death and begun using it, thinking it somehow inheritable. *Between the mid-70s and the mid-80s the procedures for filing for SSNs got a lot stiffer. The biggest fraud case I ever nailed was a guy who (after defrauding SSA for several years, then losing his ill-gotten checks...) came right back in under a close-but-different variant of one of his pseudonyms and started right out again -- SSN, disability benefits, etc... Strange thing was I believed he was the same guy from the start, but the SSN process gave the benefit of the doubt to those who could explain away lack of ID and evidence. He was a good liar, and I had to let him get a new SSN. Once that hurdle was passed, he went on to disability benefits, and managed to rack up some 2 years' worth of various bennies for himself and the family before the slow fraud investigation process allowed us to shut him down again. The procedures were tightened up sufficiently that by 1985, he would not have had the benefit of the doubt. *(Personal note) I think it was in 1985 that the 600 series was opened and assigned to California (where else?) -- I was wondering if and when they would issue 600-60-0006: "Six hundred _and_ sixty _and_ six" -- the actual phrasing of the "Number of the Beast" in Revelations (for all you urban legend/conspiracy buffs.... ;-) ) Well, anyway --- that's all I remember. -- Randy Randall Whitaker, Informationsbehandling / ADB Umea University, 901 87 Umea Sweden rwhit@cs.umu.se PS. None of this info is secrect, classified, or otherwise unavailable. You have the right to enquire at any SSA office about this stuff, and they are required to inform you. One of the things most surprising about my tenure in the bureaucracy was the degree to which people didn't bother to either check out or question how things worked..... ------------------------------ From: "David H. Close" Subject: Re: Caller ID decision Organization: California Institute of Technology, Pasadena Date: Mon, 6 Jul 1992 21:39:31 GMT Has anyone else commented on the general availability of ANI versus the general unavailability of CLID? If you can afford a T1 link and an 800 number, there is no privacy issue mentioned when you get ANI from your carrier. The caller is usually totally unaware. Its only the analog customer with limited (home, small business) needs who faces the big bruhaha over alleged "privacy". As someone else mentioned, privacy isn't the issue, anonimity (sp?) is. But another, very real, issue is the discrimination against smaller users who can't get the service which is readily available today to large companies. -- Dave Close, dhclose@alumni.caltech.edu, BS'66 Ec Page House rules! ------------------------------ From: Kai Rannenberg Subject: Information Technology Security Evaluation Manual (ITSEM) V0.2 Organization: Technical University of Berlin, Germany Date: Tue, 7 Jul 1992 18:08:23 GMT Hallo, the Data Protection & Data Security Task Force of the German Gesellschaft fuer Informatik (GI) has again published a "Statement of Observations" concerning the IT Security Evaluation initiative driven by the Commission of the European Communities. This time the statement had to be made on the Information Technology Security Evaluation Manual (ITSEM) in its current Version 0.2. The ITSEM shall give help to evaluators and sponsors working with the Information Technology Security Evaluation Criteria (ITSEC) and therefore are related quite closely to them. ITSEC V1.2 was subject of a "Statement of Observations" published by the GI Task Force in February 1992. Discussion of Criticism on ITSEM V0.2 shall take place in Brussels (Belgium) from September 8th to September 10th 1992. Observations, criticism and proposals on ITSEM V0.2 concentrate on the following issues: (1) Lack of Correction of ITSEC problems (2) ITSEC needs much deeper and therefore more improvements than admitted in chapter 1.5. (3) Who oversees the Certification Bodies? (4) Several Classes of potential attackers are not covered. (5) Threats can not be enumerated and must be specified the other way round. (6) The discrimination between strength of mechanisms in only 3 classes (basic, medium or high) is very poor and not adequate. (7) Requirements for Tools and Techniques are missing. The full statement follows. Best wishes Kai ------------------------- cut here ------------------------------------- Statement of Observations concerning the Information Technology Security Evaluation Manual (ITSEM) V0.2 Data Protection and Data Security Task Force of the German Society for Informatics (Praesidiumsarbeitskreis Datenschutz und Datensicherung der Gesellschaft fuer Informatik) June 16, 1992 The German Society for Informatics (GI) with its more than 18 000 members is the largest German association of professionals working in information technology (IT). As its highest board concerned with data protection and data security, we want to bring the following observations and recommendations to the attention of the Commission of the European Communities as the sponsor of ITSEM, the politicians, all professionals working in the field of informatics and especially those engaged in the further standardization of "Evaluation Criteria for IT Security" within ISO/IEC JTC1/SC27 and last but not least society at large. The Information Technology Security Evaluation Criteria (ITSEC) and the accompanying Evaluation Manual (ITSEM) are intended to have a significant influence on security issues, primarily in a technical sense. If they gain it, due to the socio-technological nature of IT systems, they will also have a significant influence on organizational structures. Due to the pervasive nature of IT, the everyday-life of each individual living in the European Community will be affected. This causes significant changes in social structures. If IT systems are insecure, society at large is at risk. If they are structured in an Orwellian way, they are a threat to democracy. Therefore, the points summarized in the following are of upmost concern to us. Observations Except for the first observation, which concerns ITSEM as a whole, the other observations are in a sequence which reflects the ordering of the referenced Paragraphs within ITSEM. 1. Lack of correction of ITSEC problems Except in the area of re-evaluation and re-use of evaluation results, ITSEM V0.2 does not even try to overcome the deficits of ITSEC V1.2. This means that all points raised on ITSEC V1.2 in our Statement of Observations of Feb. 24, 1992, are still valid except those in the respective Chapter 5. We are not only waiting for an answer regarding the contents of our statements, but we are waiting for the urgent needs of an information society being really and thoroughly addressed by the ITSEC/ITSEM actors. Except for its Chapters 8 and 9, ITSEM V0.2 is a missed opportunity in this respect. 2. ITSEC needs much deeper and therefore more improvements than admitted in ITSEM 1.5 There are much more severe deficits in ITSEC V1.2 than those admitted here. Given the public Statements of Observations (e.g. our Statement of Feb. 24, 1992, and the even more detailed Statement of Andreas Pfitzmann of Nov. 29, 1991), 1.5 of ITSEM V0.2 raises severe concerns whether its authors are capable and willing first to understand and thereafter to work on overcoming these deficits. Therefore, the CEC should sponsor the development of alternative proposals and evaluation experiences for future versions of ITSEC and ITSEM. 3. Who oversees the Certification Bodies? It is not only necessary to oversee evaluations (and thereby ITSEFs) as noted in 1.16 of ITSEM V0.2, but Certification Bodies as well. For inside the European Community, an appropriate institution might be the European Parliament. 4. Several classes of potential attackers are not covered As ITSEC, ITSEM does not by far consider all potential attackers. E.g., the designers of the Target of Evaluation (TOE) might implant a universal Trojan Horse, the designers of the tools used in generating (and analysing) the TOE might implant a transitive Trojan Horse, and so forth, as noted already in a Statement of Observations to ITSEC V1.0. In ITSEM, this deficit becomes even more explicit: In 3.34, it is completely forgotten that the designers of the TOE know details which are not in the public domain and which they did not obtain maliciously. In 4.192 b) and c) the following persons have to be added: Designers of the TOE; Designers of tools used to build the TOE; Designers of tools used to build tools used to build the TOE; and so forth. This has to be reflected throughout the rest of ITSEM. 5. Threats cannot be enumerated and must be specified the other way round As is well known both within the fault tolerant computing and within the security community, neither errors nor threats can be enumerated with a reasonable confidence in completeness. Therefore, errors and threats must be specified the other way round, i.e. it has to be stated what properties of which components and subsystems are assumed. If necessary, the assumptions have to be qualified: 1) Under which circumstances are they considered to be true? 2) In distributed systems, it has to be stated: For whom are they considered to be true? (In other words: Who has to rely on them?) In general, in distributed systems, the one who has to rely on an assumption has to be the one who can make it true. Within their computing capabilities, components and subsystems with assumed properties may behave arbitrarily as long as they do not thereby violate these explicitly stated assumptions. All other components and subsystems may behave arbitrarily within their computing capabilities. For a TOE to be considered secure, all its security properties have to be deduced from these assumptions. If these assumptions are reasonably weak, this deduction gives the best attainable confidence in the security of the TOE. Therefore, formulations like "... countering the threats enumerated in the security target." (ITSEM V0.2 3.39) and "... covers all threats enumerated in the security target." (ITSEM V0.2 10.23) are not state of the art and misleading to users of ITSEM. 6. The discrimination between strengths of mechanisms in only three classes (basic, medium or high) is very poor and not adequate. ITSEM 4.193 is a clear indication that the discrimination between strengths of mechanisms in only three classes (basic, medium or high) is very poor and not adequate. By comparing the statements given in b), d), and f) it is evident that resistance to completely different severe attacks is mapped to the same class "high". 7. Requirements for Tools and Techniques are missing In Chapter 7 of ITSEM V0.2, essential requirements on tools and techniques are missing. In part, this is due to the fact that ITSEC does not state, as in [Criteria for the Evaluation of Trustworthiness of Information Technology (IT) Systems, ISBN 3-88784-200-6; German Information Security Agency, 1989, p. 53], that evaluation levels beyond E6 are possible, very desirable, and might be defined in the future. One reason for this and the reason why essential requirements in Chapter 7 of ITSEM are missing is that there are transitive Trojan Horses, cf. the Turing award lecture by [Ken Thompson, Reflections on Trusting Trust; Communications of the ACM 27/8 (1984) 761-763]. These transitive Trojan Horses can spread through the used tools into the TOE. If the Trojan Horses are universal ones [D. Denning: Commutative Filters for Reducing Inference Threats in Multilevel Database Systems; Proc. 1985 IEEE Symp. on Security and Privacy, April 1985, Oakland, Computer Society, 134-146], this threat becomes especially severe. Examples for evaluation levels beyond E6 are Level E7: Verified design history of all tools used to develop the TOE. Level E8: Verified design history of all tools used to develop tools used to develop the TOE. and so forth. The ultimate level would require that all (recursive definition!) used tools have verified design, i.e. you need some form of secure bootstrap in generating these tools. The implictions for Chapter 7 of ITSEM are obvious: Tools and Techniques (T&Ts) must either have completely diverse design history (if possible between each other and most important in any case between the TOE and any T&T) or must be checked by the evaluator thoroughly. Therefore, in A.116 b) (or at least in the corresponding Paragraph on the highest evaluation level to be defined) it has to be stated that the used tools themselves have to be checked and how this shall be done thoroughly. In A.119 (or at least in the corresponding Paragraph on the highest evaluation level to be defined), the source code of all compilers used has to be checked. --------------------------------------- Kai Rannenberg Technische Universitaet Berlin Informatics Department E-Mail: | Snail Mail: | kara@cs.tu-berlin.de | Sekretariat FR 5-10 Phone: (+49 30) 314-73499 | Franklinstr. 28/29 Fax: (+49 30) 314-24891 | D-W-1000 Berlin 10, Germany ------------------------------ From: johnson@spectra.com (boyd johnson) Subject: Re: SSNs and Social Insurance Numbers Organization: Spectragraphics Corporation Date: Tue, 7 Jul 92 20:12:16 GMT In article bear@tigger.cs.Colorado.EDU (Bear Giles) writes: >In article flint@gistdev.gist.com (Flint Pellett) writes: >> >>If anyone really knows about SSN's, I'd love to know what plans >>exist for them in the future. They only have 9 digits, and since >>we have 250,000,000 people (or more-- I haven't kept track) >>currently alive in this country, that indicates that most likely >>20 to 25% of the available numbers are in use by persons currently >>living. I would guess that within the next 100 years that we'll >>run out of 9 digit numbers that haven't already been used: do they >>plan on re-using the numbers of deceased people, (a big potential >>problem, I would think, since estates often live on a long time >>after the person), or are they going to go to 10 digits and break >>computer programs all over the place? A few years ago they went to 9 digit Zip codes and California went from 6 to 7 digit license plates. The 10 or 11 digit SSN would cause similar database problems, but it could be fairly easily remedied. >If they add one digit, they'll certainly add a second (for a checksum >since SSNs are used so widely now). > >But you make two interesting assumptions: first, that the U.S. >Government will care about the fact that other organizations use >the SSN as an identifier (SSN records could probably be freed within >a few years of person's death); and second that the new number will >only be used in the U.S. With a North American Free Trade union >you could make a good point for a NAFTU-SSN... if not a global SSN >(since it is likely people will change countries much more in the >future). Hmmm...interesting: REV 13:16 And he causeth all, both small and great, rich and poor, free and bond, to receive a mark in their right hand, or in their foreheads: REV 13:17 And that no man might buy or sell, save he that had the mark, or the name of the beast, or the number of his name. REV 13:18 Here is wisdom. Let him that hath understanding count the number of the beast: for it is the number of a man; and his number is Six hundred threescore and six. Any guesses as to what the SSN checksum would add up to? -- ======== Boyd Johnson nosc!spectra.com!johnson San Diego, Ca. ======== ------------------------------ End of Computer Privacy Digest V1 #059 ******************************