Text File

11-Aug-87 19:59:25-PDT,14393;000000000000 Return-Path: <NEUMANN@f4.csl.sri.com> Received: from csl.csl.sri.com (CSL.SRI.COM) by F4.CSL.SRI.COM with TCP; Tue 11 Aug 87 19:55:25-PDT Received: from F4.CSL.SRI.COM by csl.csl.sri.com (3.2/4.16) id AA14174 for RISKS-LIST@f4.csl.sri.com; Tue, 11 Aug 87 19:57:01 PDT Message-Id: <8708120257.AA14174@csl.csl.sri.com> Date: Tue 11 Aug 87 19:54:17-PDT From: RISKS FORUM (Peter G. Neumann -- Coordinator) <RISKS@csl.sri.com> Subject: RISKS DIGEST 5.27 Sender: NEUMANN@csl.sri.com To: RISKS-LIST@csl.sri.com

RISKS-LIST: RISKS-FORUM Digest Tuesday, 11 August 1987 Volume 5 : Issue 27

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents: Re: Secrecy About Risks of Secrecy (Jerome H. Saltzer) "Mustn't tire the computer!" (A. N. Walker) Automated environmental control RISKS (Joe Morris) Social Security Inside Scoop (Lance Keigwin via Martin Minow) Fire protection in the computer room (Dave Curry)

The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. FTP back issues Vol i Issue j from F4.CSL.SRI.COM:<RISKS>RISKS-i.j. Volume summaries for each i in max j: (i,j) = (1,46),(2,57),(3,92),(4,97).

----------------------------------------------------------------------

Date: Tue, 11 Aug 87 11:55:08 EDT To: RISKS FORUM (Peter G. Neumann -- Coordinator) <RISKS@csl.sri.com> Subject: Re: Secrecy About Risks of Secrecy (RISKS-5.26) From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>

From: "Maj. Doug Hardie" <Hardie@DOCKMASTER.ARPA> I am not convinced that you can publish overviews that do not provide any thoughtful person with enough insight to fairly easily complete the details of the attack. I believe that it is the initial identification of a flaw that is difficult, not the exploitation of it.

That comment rings completely true. I would argue the following implication: publication of any information about a problem should be accompanied with full detail, so that the good guys have all the information they need to get on top of it. (Security lesson number one: technology transfer to the good guys is an order of magnitude harder than to the bad guys.)

Hardie continues to comment on a comment by our moderator. . . [... If a system is fundamentally flawed, it should not be used in critical applications where those flaws could result in serious compromise... PGN]

I suspect that removing all sensitive information from critical applications would cripple the government. Also, there is no way to replace all those systems with secure systems in the near future. Even if we only buy secure systems for new applications, it will be several decades before the fundamentally flawed systems are gone.

I think that both of these positions are a little too polar, and thus are dancing around the real-world problem. There are situations when it may be a reasonable risk to leave sensitive information in a flawed system, for example when you are fairly sure that your opponent doesn't yet realize the information is there and probably won't trip over it immediately, or when you are fairly sure that the other side hasn't yet learned of the security flaw. But since knowledge of such things spreads, that kind of decision is very time-sensitive--the risk increases every day. So the decision must be accompanied by a plan to shore things up, either by fixing the flaw, getting the information moved to a safer place, or--a common solution--putting other barriers around the flawed system. Anyone who continues to run a flawed system for years, much less decades, while trying to maintain secrecy about its problems isn't taking a risk any more, he is inviting a disaster. Jerry

[The placing of supposed barriers again is subject to the skepticism that Jerry has about the system itself... The problem is recursively unsolvable in any definitive sense, although the perceived risks are often only a shadow of the actual risks. PGN]

------------------------------

Date: 11 Aug 87 18:21:26 BST (Tue) To: risks@csl.sri.com Subject: "Mustn't tire the computer!" From: "A. N. Walker" <anw%maths.nottingham.ac.uk@Cs.Ucl.AC.UK>

`The Observer' [national Sunday paper] reports on `the nightmare of a woman robbed of 8,750 pounds'. Her Abbey National Building Society [do you have building societies? a sort-of bank with just deposit accounts and mortgage accounts] cash card had been used to steal 250 pounds (the daily limit) per day for 35 consecutive days from her account. The RISKS interest comes from the comment by Abbey National's head of security (i.e., not just a spokesman): "It is true that we tell counter staff at branches to make enquiries if cheques are cashed on three consecutive days. But to instruct the computer to do this on ATMs would be far too time-consuming," he said.

Elsewhere, Abbey National claims to process 5.7M transactions per year; say 15K transactions per day average, perhaps 50K per day peak. I'll leave others to estimate the size of the computer needed to compare three or four 50K-record files within a day, looking for repeated transactions on individual accounts, and the amount of time needed to write the software.

The moral is: don't expect computers to perform all the routine, boring tasks that they do so much better than people.

Andy Walker, Maths Dept, Nottm Univ, UK

------------------------------

To: risks@csl.sri.com Subject: Automated environmental control RISKS Date: Tue, 11 Aug 87 13:01:37 EDT From: Joe Morris (jcmorris@mitre.arpa) <jcmorris@mitre.arpa> Organization: The MITRE Corp., Washington, D.C.

In RISKS-5.25, Henry Spencer asks about problems with the computerized environmental/energy controls that are becoming popular in large office buildings. Several years ago (and with a former employer) I had the dubious pleasure of seeing what happens when one of these systems is installed without considering that the building tenants might not fit the 'standard' mold. The building, located on a university campus, housed four floors of professors' offices, a lecture hall, and the computer center. The new environmental control system, which was run remotely from the Physical Plant offices, was retrofitted to the building several years after it was constructed, and was designed for use where the building was occupied during the day and vacant at night. Sure enough...the first night the $%^&* thing turned the air conditioning compressors off at about 19:00, causing all sorts of panic in the computer room. No damage resulted from this (except a few gray hairs), but it highlights the sort of incompatibilities that can result when too many assumptions are made about an environment. Joe

------------------------------

Date: Tue, 11 Aug 87 19:00:24 edt From: decvax!LOCAL!minow@decwrl.dec.com (Martin Minow) To: decwrl!risks@csl.sri.com [Found on Usenet (net.consumers)] Subject: Social Security Administration -- Inside Scoop

Date: 10 Aug 87 23:27:53 GMT Path: decvax!decwrl!labrea!aurora!ames!amdcad!cae780!ubvax!lance From: lance@ubvax.UUCP (Lance Keigwin) Organization: Ungermann-Bass Enterprises

Just after college I accepted a job with the Social Security Admin (SSA) in a NYC district office. I spent several years with SSA as a claims representative, operations supervisor, and regional program specialist. Fortunately I had the good sense to leave several years ago, when it became very clear that federal service was not an alternative to anything.

In these jobs I dealt with all levels of the SS program. Undoubtedly the two biggest headaches for SSA (and the public claimants) were resolving discrepancies in dates of birth and earnings records. Screwups in establishing age is another story, and far less controversial. SSA's record there is really pretty good, if the claims rep is not a dope.

But scrambled earnings records are almost impossible to fix. This usually happens when somehow an employer gets a hold of a wrong number, usually from an employee (although the employer could pick it up from almost anywhere...and they do!). Of course there is cross-checking against what SSA believes is the right name and number but all it takes is some (#$%@$%) clerk to cross refer two numbers to the same person and zap! Suddenly you're record relects someone else's wages too. Or worse: your covered earnings are credited to some third party. This happens all the time because people forget their numbers, re-apply for a second one, guess wrong, etc. Safeguards exist but if you consider the scale here (all those workers, all those employers, and the general interest of the average gov't employee in doing the job right even if it means more work and worsened processing statistics) there are bound to be major problems.

When does the error come to light to you, John Q. Public? If at all, almost always at retirement, some decades in the future; at a time when many employer records are gone, if not the employer itself, and your recollection is at best fuzzy. Chances are probably 9 in 10 that you'll never get credit for all the taxes you paid, if your record is messed up obviously enough for a rep to notice it and to look into it.

My advice:

1) Never, NEVER give anyone a fake SSN. It will haunt you later in life. If SSA has to search for earnings under a different number (spotted on an application for employment, a credit card report, school record, etc.) you will suffer significant delays in getting your correct benefit at best. More likely, you will never live to see the tax credit.

2) Always, ALWAYS request a statement of your earnings every three years. There are screwy statute of limitations regulations (3 years, 3 months and 15 days), about when an error can be corrected. Also the statement of earnings you get will only breakout the last several years individually, and will total all prior years in one lump sum, so it it good to do it periodically.

3) If you suspect an error, ask for a complete posting of each year (a "certified earnings record"). If you're given a little card to complete and told it will be mailed to you, don't buy it! You can only get a complete record by seeing a Service or Claims representative, who must complete an SSA-450 for transmission to HQ in Baltimore. Insist on a photocopy of it when it arrives. Be troublesome, if necessary.

4) If you do see an error, put your dispute in writing and if you must mail it in, do so certified mail. Establishing the date you first suspected an error is important. SSA has ways of "scouting" an employer's records. Ask to have it done.

5) Check your W-2 for the correct SSN. Paystubs too, but especially the W-2. Report any error to your employer and IRS.

6) If you don't want to give your correct SSN to someone and feel you must fake it, give them a number that starts with "9". There is no such thing as a real 900-series number so you are not risking screwing up yours or someone else's account. SSA will never accept it.

7) If you get an official decision that goes against you, protest if you really believe you're being cheated. There are several appellate steps, and usually the official who decides is reasonably intelligent and responsible. Read the back of the notice about "reconsiderations", "hearings", etc. The reversal rate it very high.

As a matter of interest, two years after I started work for SSA I requested a record of my earnings. Sure enough, there was an error in two quarters. Want to guess who the employer was that messed up? Yep, SSA. It took them 3 years to fix it. Good thing I had an "in". :-)

I also discovered that my retired father should have been getting benefits for three of his student children (an SSA snafu). I had us apply, and asked for full retroactivity (over 8 years). The claims examiner awarded only 12 months of retroactivity. I appealed. We won. Total family benefits came to over $7000. I used my $1500 to buy a washer and dryer.

Lance P. Keigwin (lance@ubvax.UUCP) (408)496-0111 (operator) 562-7738 (direct) US Mail: Ungermann-Bass Inc, 2560 Mission College Blvd, Santa Clara, CA 95052 UUCP : {ucbvax,decwrl,ihnp4,allegra}!amd!ubvax!lance pyramid!ubvax!lance

------------------------------

Date: Tue, 11 Aug 87 18:08:47 EST From: davy@intrepid.ecn.purdue.edu (Dave Curry) To: risks@csl.sri.com Subject: Fire protection in the computer room

The discussion of the NASA computer room which got flooded brings this to mind.

Here at Purdue, the University fire department (actually, I think it's the Safety & Security folks) doesn't like Halon systems. Admittedly, there are risks to humans when using Halon systems, since Halon's function is to remove the oxygen from the air. (I have heard stories that some Halon manufacturer placed people in a room full of Halon to prove it was "safe"--not sure I'd want to try that one, although they apparently all survived with no ill effects.)

Anyway, we as computer folks like Halon. Sprinklers tend to have rather adverse effects on the hardware. But, we can't install a Halon system in our computer rooms. We have to install a sprinkler system. So.... we have Halon extinguishers and sprinklers. We haven't had any leaks. Yet. Covers are a neat idea; too bad we don't have any (a risk we probably shouldn't be taking).

The risk here is due to a lack of understanding on the part of people who don't work with the hardware... they don't realize that their aversion to Halon (which is easily countered by having the firefighters wear airmasks) puts several million dollars worth of equipment, not to mention the probably incalculable value of the data stored, at risk.

--Dave Curry, Purdue University

------------------------------

End of RISKS-FORUM Digest ************************ -------