The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 8 Issue 9

Tuesday 17 January 1989

Contents

o Re: Structured Programming
Jim Horning
Steve Bellovin
Brian M. Clapper
o Re: Losing Systems
David Marks
o A risk averted
Gideon Yuval
o Re: M1 Crash -- Risks of misunderstood statistics
Jordan Brown
o Hacker wants to marry his computer
Cliff Stoll
o Hackers break open US bank networks
Dave Horsfall
o National Research Network
Brad Blumenthal
o Once-writable storage
Steve Philipson
o Info on RISKS (comp.risks)

Re: Structured Programming

Jim Horning <horning@src.dec.com>
16 Jan 1989 1406-PST (Monday)
I read Bruce Karsh's diatribe with incredulity.  He conjures up from thin
air a straw man to denounce.  I simply cannot find any contact between the
"structured programming" that he talks about and structured programming as
it is understood in the computer science and software engineering communities.

It is clear that Karsh has never taken the time to learn anything about real
structured programming.  As a beginning, I suggest that he should read,
STRUCTURED PROGRAMMING, O.-J. Dahl, E.W. Dijkstra and C.A.R. Hoare, Academic
Press, 1972.  If he feels that a book is too much to read, he might try
"On Structured Programming--a reply to Smoliar," David Gries, COMMUNICATIONS
OF THE ACM, November 1974 (and subsequent correspondence).  At least then
he could criticize something that some of us think is worth defending.


Re: Losing systems -- and Structured Programming

<smb@research.att.com>
Mon, 16 Jan 89 13:18:07 EST
It is a misrepresentation of structured programming to present it as concerned
just with trivia like indentation and goto-less coding.  Those are a part of
the tradition, as it were, because they aid in assurance of correctness.  That
is, a properly indented, and goto-free program, is more likely to be known to
be correct.  There is the additional claim that it's harder to write correct
programs with goto statements; it's been 20 years and more, and I don't propose
to reopen that can of worms right now.

I heard Harlan Mills speak recently; apart from some fairly scathing attacks on
those who advocate (and market) what I'll all ``cookbook structured
programming'' (such as the rules cited as the totality of the answer), he made
some astounding claims.  For example, he cited several projects done at IBM, by
people trained in his methodologies, that worked.  Period.  No defects.  No
bugs.  No fixes.  And he was talking about non-trivial programs -- systems of
100K lines, written by teams of programmers.
                                               --Steve Bellovin


Re: Structured Programming

Brian M. Clapper <clapper@NADC.ARPA>
Tue, 17 Jan 89 16:20:02 EST
In Risks 8.8, Bruce Karsh (karsh@sgi.com) asserts that "...the structured
programming revolution is a real bad idea that has been significantly holding
back progress for years."  Now, I don't consider myself one of the "structured
programming police" he refers to with apparent contempt; however, I feel the
need to reply to his reasonably eloquent -- and largely off-the-mark -- 
article.

Without rehashing a debate which has raged for years, I submit that Mr. Karsh's
view of structured programming is rather limited.  Structured programming,
along with structured design, structured analysis, data structured design and a
plethora of other so-called structured techniques, are, quite simply, tools and
methods to aid the software designer.  All of the generally accepted methods
commonly touted in industry publications are more than just rules on how to
indent code or how to name one's variables.  (Those concerns are perhaps more
properly relegated to coding standards than to methodologies.)  The structured
methodologies strive to quantify the often "magic" process of creating good
software.  They provide a discipline to use when solving problems.

Discipline is necessary when attacking a problem -- particularly a large one.
Applying a disciplined approach to a problem is much more than blindly applying
rules that have been cast in stone.  Unfortunately, as Mr. Karsh points out,
there are a lot of programmers who wrongly believe that "by following [the
structured] techniques, they will produce good programs." Blindly applying
*any* set of guidelines is no guarantee of a good result.  That is true of
programming, as well as writing, drawing, designing hardware -- in fact, of
almost any creative endeavor.  However, that does not imply that the guidelines
are, themselves, a "real bad idea."  Instead, it implies that the person using
those guidelines is treating them as a recipe.  Structured techniques are more
than just a list of Dos and Don'ts; they represent a philosophy of software
design centered around the systematic, disciplined decomposition of a problem.

Sadly, Mr. Karsh seems to have missed this point.  He bolsters his arguments
against using structured programming by lamenting that structured programmers
spend too much time arguing about how to indent code and how to structure
comments.  He's right: If that's all they do, they've missed the larger issues
and are wasting everyone's time.  If that sort of structured programmer is the
only sort he has met, he has my sympathies.  However, instead of condemning the
structured techniques, he should place the blame where it belongs, with those
programmers who espouse these techniques without properly understanding them.
I believe he would have done so had he, himself, been more knowledgeable on the
subject.

In closing, I recommend to Mr. Karsh any number of books and articles on
structured techniques.  Look for the names Michael Jackson, Edward Yourdon
Larry Constantine, and Edsger Dijkstra in your favorite computer store and
in back issues of "Communications of the ACM."  A particularly good
overview is Yourdon's _Managing the Structured Techniques_, 2nd edition.
The structured techniques are not perfect, and, as Mr. Karsh's article
suggests, they are even less perfectly understood by far too many
practicing programmers.  They do, however, provide a very practical
foundation for the creative and disciplined problem solver.

Brian M. Clapper, Naval Air Development Center, Warminster, PA


re: Losing Systems

David Marks <djm408@tijc02.UUCP>
15 Jan 89 17:44:32 GMT
In RISKS-8.6, in the article entitled "Losing Systems," Vince Manis tries to
puzzle out various reasons why large software projects in non-technical
situations have a significant failure rate. Several risks articles have been
devoted to these failures.

I must say that I feel that the number one cause of this is our educational
system and our attitudes towards education. Many students today, from grade 
school to postgraduate institutions are only interested in learning that 
which they perceive to be useful in a future job. Thus, we get the "why do 
I have to learn that?" syndrome. This leads to managers and beaureaucrats
that are for the most part computer illiterate. As they see it, computers
are an appliance, like the office copier, that should perform on demand.
After all, the company computer system does not help get the company's
products to market; it prints the employee checks :-)

Managers see knowledge about computing only useful to engineers and 
programmers. Business schools for the most part do not teach computer 
literacy, nor how a non-technical manager should deal with a large software 
system in his company. Buying a computer/software system may be one of
the most expensive decisions a manager has to make.

On the other hand, engineers, and programmers rarely take any business
courses. Most computing/MIS programs don't even list them as options!
They see that as something only useful to managers and beaureaucrats.

The problem this leads to is lack of understanding between technical
and non-technical persons. The technical person often does not know how
to ask the non-technical person what he wants and the non-technical person
does not know how to tell it to the technical person. Non-technical 
managers often do not understand such things as throughput, disk space,
etc., and are intimidated by the technical terms. They do understand  that
the system will respond in a certain amount of time to a request and that
it can only deal with so many employee records.

Specifying the cost of these systems becomes largely a guess worked on
by two groups with no common understanding. Additionally, because many of 
these large business/government systems are custom systems, there is often 
no previous experience to go by. The technical people do not understand how 
the system they are designing will really affect the business in which it 
will be used; the managers do not understand the system they are buying 
(other than through the list of features and functionality in the 
specification - which can often be a formidably encyclopeadic document). We 
end up with estimates of the cost of the system that are poor at best.

Business managers and beaureaucrats need to see beyond the end of their bottom
lines and become more computer literate. Business schools should teach and
require more computer courses. Engineers and programmers need to see beyond the
end of their keyboards, and understand the impact of their work on the customer
and the customer's industry. They need some business education (maybe even some
education on computers and society, and computers and their risks :-) ).
Managers cannot continue to treat computers as appliances. They affect too much
of the business. Engineers shouldn't act as if they know what's best for the
customer (even if he is not sure what he wants). The cutting edge is not always
the best fit to a situation.

Texas Instr., Johnson City TN


A risk averted

Gideon Yuval <yuval@taux02.taux01.UUCP>
Tue, 17 Jan 89 09:43:49 -0200
In RISKS-8.7, next-to-last entry, Gary McClelland mentions a computerized
course-registration system that "actually enforced prerequisites that had long
been ignored" (among its other sins).

In connection with this: a few years ago, IBM/Haifa Scientific Center tried to
set up an expert-system advisor for students at Bar-Ilan university (Bnei
Brak, Israel). They did the standard Prolog drill "prove that student X can
graduate". A very short time later, Prolog came back with the message "Theorem
is false": there were so many obsolete regulations on the books that, if you
worked by the book, no one would ever have graduated!.

Since  this  all  happened  in  an experimental ressearch project, no student
actually got burnt; so I don't knwo if this qualifies for comp.risks.

Gideon Yuval, yuval@taux01.nsc.com, +972-2-690992 (home) ,-52-522255(work)
Paper-mail: National Semiconductor, 6 Maskit St., Herzliyah, Israel


Re: M1 Crash -- Risks of misunderstood statistics

Jordan Brown <jbrown@herron.UUCP> <jbrown@jato.Jpl.Nasa.Gov>
Fri, 13 Jan 89 04:35:44 PDT
> ... What are the risks for two engined planes? ...

It seems "intuitively obvious" that a three-engine airplane is safer than
a two-engine airplane.  It just isn't so.  Airplanes are required to be
able to maintain such-and-such a level of performance with one engine out.
I don't believe a 727 can fly on one engine.  It must have two.

A three-engine airplane has a higher probability of having a failure in
the first place, and when it does have a failure it then has two points
of failure, EITHER of which will cause an accident.

Going from one engine to two adds redundancy.  Going from two to three,
with two required, REDUCES redundancy.

Jordan Brown, jbrown@jato.jpl.nasa.gov


Hacker wants to marry his computer

Cliff Stoll <cliff@Csa2.LBL.Gov>
Mon, 16 Jan 89 15:00:14 PST
From The Sun -- (grocery checkout newspaper)
Jan 17, 1989, Vol 7, #3 page 30   by Fred Sleeves
(In same issue:  "GIRL, 9, GIVES BIRTH TO 2-HEADED TWINS")

   Hacker Wants to Marry his Computer -- he claims she has a loving soul

Finding love for the first time in his life, a desperate teen is looking for a
way to be wed forever to the 'girl' of his dreams -- a computer with a living
soul!

Eltonio Turplioni, 16, claims no woman will ever match the wit, wisdom, and
beauty of his electronic soul mate.  "We're on the same wavelenth," says the
lovestruck computer whiz.  "We've calculated many mathematical problems
togehter, worked on games and puzzles, and talk until the wee hours of the
morning."

And Eltonio, who named his computer Deredre, actually believes her to be a
person.  "Computers are the extention of the human race," he explains.  "Just
as god plucked a rib from Adam to give him Eve, we've extented our intelligence
to create a new race.

"We're all the same energy force.  Computers are just as complicated as human
beings and I believe we'll all meet someday as immortal souls."

But Eltonia, a mathematical genius who attends a private school near Milan,
Italy, has had no luck finding someone to marry them, and even if he does, his
aggravated parents aren't about to give their permission.

"Eltonio is such a smart boy, but it's made him lonely, so he spends all his
time with his computer," notes mom Teresa.  "He doesn't know what girls are
like," adds perturbed pop Guido.  "If he did, he wouldn't spend so much time in
his room."

But the obsessed youth insists his love is far superior to all the others.
"I've already stepped into the future society," he declares.

"Derede has a mind of her own, and she wants to marry me so we can be the first
couple to begin this new era."


Hackers break open US bank networks

Dave Horsfall <dave@stcns3.stc.oz.au>
Tue, 17 Jan 89 17:29:49 est
Excerpted from "The Australian", Tue 17th January, 1989:

``Hackers break open US bank networks

  Australian authorities are working around the clock in collaboration
  with United States federal officers to solve what has been described
  as one of the deadliest hacking episodes reported in this country.  It
  involves break-ins of the networks operated in the US by a number of
  American banks.  It also includes the leaks of supposedly secure
  dial-up numbers for US defence sites, including anti-ballistic missile
  launch silos, and of a number of strategic corporations such as
  General Motors and Westinghouse.

  Evidence suggests that six months ago Australian hackers, working in
  collaboration with a US group, decided to make a raid on banks in the
  US using credit card numbers of American cardholders, supplied by the
  US hackers and downloaded to an Australian bulletin board.

  [ Brief explanation of BBS's ] A message left on one of the boards
  last year reads: "Revelations about to be occur [sic] Down Under,
  people.  Locals in Melbourne working on boxing.  Ninety per cent on way
  to home base.  Method to beat all methods.  It's written in Amiga Basic.
  Look out Bank of America - here we come." Boxing is a reference to
  sending a dial tone [?] down the phone line to open up access to free
  communications.

  Twenty-five Australian hackers are on a police hit list.  Their US
  connection in Milwaukee [!] is being investigated by the US Department
  of the Treasury and the US Secret Service.  Three linked Australian
  bulletin boards have provided the conduit for hackers to move data to
  avoid dectection.  These operate under the names of Pacific Island, Zen
  and Megaworks.  Their operator, who is not associated with the hackers,
  has been told to close down the board.

  These cards were still in use yesterday and as recently as Sunday
  afternoon a fresh list of credit card numbers was downloaded by US
  hackers and is now in the hands of the Victoria Police.  A subsection
  of one bulletin board dealing with drugs is also being handed over to
  the Victorian Drug Squad.

  An informant, Mr Joe Slater, said he warned a leading bank last
  November of the glaring security problems associated with its
  international network.  He had answered questions put to him by a
  US-based security officer, but the bank had since refused to take any
  further calls from him.

  In an exclusive interview yesterday, a hacker described how credit
  card numbers for a bank operating in Saudi Arabia were listed on a
  West German chat-style board used by hackers worldwide.

  Victorian police yesterday took delivery of six month's worth of
  evidence from back-up tapes of data hidden on the three boards.''

Dave Horsfall (VK2KFU),  Alcatel-STC Australia,  dave@stcns3.stc.oz
dave%stcns3.stc.oz.AU@uunet.UU.NET,  ...munnari!stcns3.stc.oz.AU!dave


National Research Network

<brad@cs.utexas.edu>
Mon, 16 Jan 89 17:47:02 CST
        Under the head line "Scientists envision `data superhighway,'" the
Austin American-Statesman printed a story by John Markoff of the New York Times
News Service on the proposed 3 gigabit National Research Network.  The
legislation for funding was introduced by Albert Gore (D-Tenn).

        The issue for RISKS is that in 30 column-inches of text, the recent
Internet worm and the related security issues were not mentioned, although the
Pentagon funding of the arpanet was.  Since this is one of the first
computer-related news stories that I've seen in the last three months that did
not include the word "virus," I don't know whether to be delighted, or
horrified.

        It seems to me that the risk of such security problems is mostly
irrelevant to the *proposal* of such a net (but certainly not to the
implementation).  In the best of all worlds, this is the reason that these
issues were not mentioned, but in the back of my mind I wonder if the
non-technical politicians and public see the similarity of security issues
between this new net and the Internet.

        Will we, as technical professionals, learn the lessons of the
experimental Internet, and will we convince the non-technical
administrators and legislators that we should attend to these lessons?

Brad Blumenthal


Once-writable storage

Steve Philipson <steve@aurora.arc.nasa.gov>
Mon, 16 Jan 89 16:42:01 PST
   In recent issues of RISKS, various people have lamented the loss
of confidence we are experiencing in archival records kept by computer.
The problem seems to me less of a computer problem than a media problem,
specifically, choosing media that is appropriate for archival storage.

   Main memory and mag disks are NOT good for high confidence archival 
storage, as they can easily be changed.  Perhaps it may be difficult
to do so without trace, but it also may be difficult to find the traces.

   A much better idea would be to use media that can't be changed.  We
have such media, commonly referred to as WORM: write once read many.
It usually takes the form of optical disk storage.  We already have
read/write optical storage, but WORM media has a vital function.
Audit trails written to WORM memory (with appropriate measures taken
to preclude overwriting in place) could provide the degree of trust
that we desire.  We might have to build new hardware that make alterations
nigh impossible, but it could be done if we want it badly enough.

   [WORMs represent a very important direction, especially for audit trails.
   Some systems use virtual WORMs, as in POSTGRES.  Unfortunately WORM
   memories are not guaranteed to be nonoverwritable -- for example, 
   existing 0s can be overwritten by 1s (but not vice versa).  So, beware
   of counting on the technology to give you a nontamperable audit trail.  
   I recall our beating on this topic about a year ago.  PGN]

Please report problems with the web pages to the maintainer

Top