From: risks@CSL.SRI.COM (RISKS Forum)
Newsgroups: comp.risks
Subject: RISKS DIGEST 14.23
Date: 7 Jan 93 18:16:04 GMT
Reply-To: risks@csl.sri.com
Distribution: world
Organization: The Internet

RISKS-LIST: RISKS-FORUM Digest  Thursday 7 January 1993  Volume 14 : Issue 23

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

  Contents:
Leap Year Causes Problems for ATM Machines (Conrad Bullock)
Ross Perot Campaign Steals Credit Data? (Richard N. Kitchen)
Computer failures in B767 (Wm Randolph Franklin)
Laserprinter Forgery (Matt Healy)
Large Foreign Exchange Rates (R. Y. Kain)
Stolen to order systems (Lord Wodehouse)
Prosecution in the Cindu case (Meine van der Meulen)
Re: Microprocessor Design Faults (A. Padgett Peterson)
Release of Maps to NGOs? (Daniel J Yurman)
AFCEA ACCE Conference Announcement (John Wack)

 The RISKS Forum is moderated.  Contributions should be relevant, sound, in 
 good taste, objective, coherent, concise, and nonrepetitious.  Diversity is
 welcome.  CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive 
 "Subject:" line.  Others may be ignored!  Contributions will not be ACKed.  
 The load is too great.  **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS,
 especially .UUCP folks.  REQUESTS please to RISKS-Request@CSL.SRI.COM.     

 Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
 CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 14, j always TWO digits).  Vol i
 summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out.
 The COLON in "CD RISKS:" is essential.  "CRVAX.SRI.COM" = "128.18.10.1".
 <CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.

 For information regarding delivery of RISKS by FAX, phone 310-455-9300
 (or send FAX to RISKS at 310-455-2364, or EMail to risks-fax@cv.vortex.com).

 ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
 Relevant contributions may appear in the RISKS section of regular issues
 of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

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

Date: Thu, 7 Jan 93 17:20:30 NZT
From: Conrad Bullock <Conrad.Bullock@actrix.gen.nz>
Subject: Leap Year Causes Problems for ATM Machines

Extracts from two newspaper articles on an ATM glitch which corrupted
thousands of customer cards on Dec 31st in New Zealand.
These articles are both from general circulation newspapers. The
second gives a little more information.

"Year too long for money machines", By Roger Fea, New Zealand Herald,
Jan 2, 1993.

   The passing leap year caught several thousand ASB Bank customers
short on Thursday - when the bank's money machines refused to process
their transactions.
   The ASB's managing director, Mr Ralph Norris, said that a "faulty
date checking routine" had corrupted the magnetic strip on the
customers' money machine cards.
   The fault had to do with the fact that 1992 was a leap year and
that Thursday was the 366th and last day of the year.
   The money machines were programmed to acknowledge the extra day but
instead of the year 1992 being encoded, the figure 02 was used.
   The problem became apparent about 10 am on Thursday and covered a
period from midnight to noon that day, when it was fixed.
   Only those customers who made two separate transactions during the
period were initially affected. The first transaction went through but
the problem occurred when their cards were inserted a second time.
   Mr Norris said all customers who used their cards during the 12
hours - possibly about 10,000 - were now carrying corrupted cards.
   If they used them subsequently up until Monday or Tuesday their
transactions would be similarly rejected. By that time a new programme
would be in place which would bypass the problem.
   [ Information about cards still working with other bank's machines
and EFT-POS, as well as various apologies and contact information. ]
   

"Leap year spikes cashcards", NZPA, Waikato Times, Jan 2, 1993.

   About 1500 TSB Bank customers in Taranaki had their Cashflow cards
"corrupted" yesterday by a computer software fault that could ripple
around the world with disastrous consequences.
   TSB customers, who used their cards between midnight Wednesday and
about 12:30pm Thursday to make withdrawals, found they could not use
the cards again and needed replacement cards.
   "It's quite a serious problem we are talking about ... which has
the potential to ripple around the world," TSB information services
manager John Hollins said.
   The 18 TSB automated teller machines (ATMs) throughout the region
operated on a version of an NCR-based machine code which made no
allowance for leap years. So after a first withdrawal on Thursday the
machines no longer recognised the cards and came up with an "unable to
process" message, Mr Hollins said.
   [ Information about the ASB being affected, but not the Trust Banks,
which the ASB and TSB were once part of. ]
   Bank customers overseas who used ATMs which operated on the same
NCR code could also expect problems after their first withdrawals on
the last day of 1992, which had been a leap year, Mr Hollins said.
   However, customers who used Cashflow machines for other
transactions - such as account balance queries, transfers of money, or
deposits - were not affected.
   [ EFT-POS still worked OK, various apologies ].

-----
Background from Conrad:

Both ASB and TSB are regional banks (although the ASB are starting to
move into other regions). The nationwide trading banks (which also use
NCR ATMs, amongst others) do not seem to have been similarly affected.

This is another instance where New Zealand, as the first country in
the world to see the new day, also gets to experience date-related
bugs first - such as the recent 3pm Nov 1 1992 bug which broke many
banking systems running on Tandem CLX hardware - as the bug hit NZ
(then Australia, then Japan.....) a workaround was developed, and 
problems were averted in Europe and the US.....

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

Date: Tue, 05 Jan 93 13:11:00
From: <KitchenRN@ssd0.laafb.af.mil>
Subject: Ross Perot Campaign Steals Credit Data?

News reports indicated that the Ross Perot campaign is being investigated by
the FBI, Secret Service, and Federal Trade Commission for allegedly using
stolen computer codes to obtain credit reports on some campaign workers.
Investigators refused to discuss the case, but former Perot campaign
employees, Equifax (the credit reporting company) and Orix Consumer Leasing of
Secaucus, NJ admitted having spoken to investigators.

Equifax said at least seventeen credit files of former Perot campaign workers
may have been accessed illegally.  Some Equifax reports were obtained using
the security code of Orix, which claims to never have requested the credit
reports on Perot volunteers.  Officials at Orix and Equifax have said they
believe Orix's security codes were stolen.  [Source: LA Times 2 or 3 Jan 93]

Richard N Kitchen  kitchenrn@ssd0.laafb.af.mil 

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

Date: Tue, 5 Jan 1993 18:05:37 GMT
From: wrf@ecse.rpi.edu (Wm Randolph Franklin)
Subject: Computer failures in B767

The B767 aircraft suffers repeated failures of the computer that controls the
individual passenger lights, sound, etc.  Unlike earlier aircraft, all the
switches on the armrests, including the individual light switches, sound
channel and volume, and attendant call button, are controlled by a computer.
On a recent flight that I was on, from Milan to Washington, the computer
wedged shortly into the flight.  Although one attendant figured that the
situation would have to wait until the plane landed, another managed to reset
the computer.  According to the attendants, these computer problems happen all
the time.

Now of course this is not a life-critical system, but it is certainly
ominous that such a simple task cannot be implemented correctly.  I'm
also curious about replacing 300 local light switches by a centralized
computer with 300 inputs and 300 outputs.  Ditto for the channel
controls.

Wm. Randolph Franklin,  wrf@ecse.rpi.edu, (518) 276-6077;  Fax: -6261
ECSE Dept., 6026 JEC, Rensselaer Polytechnic Inst, Troy NY, 12180 USA

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

Date: Tue, 5 Jan 1993 22:40:24 GMT
From: matt@wardsgi.med.yale.edu (Matt Healy)
Subject: Laserprinter Forgery

Years ago (pre-wordprocessing) I used an IBM Selectric typewriter with a
correction key.  For a lousy typist like me, this was *wonderful*.  However,
the manual warned against using a correctable (carbon film) ribbon for typing
legal documents because undetectable alterations would be too easy.

Well, recently on a Delta flight from Hartford to Atlanta one of the options
on the inflight sound system was an interview with Frank Abagnale, a reformed
forger who now advises companies on fraud prevention.

Abagnale said that output from most laserprinters and photocopiers can be
removed in a similar manner with correction tape because the toner powder,
like carbon film ribbon, only sits on the surface of the paper but does not
impregnate the fibers.  I tried it and he's right.

He said some of his clients have had checks altered in this manner.  He
suggested two solutions:

  1: use an impact printer with inked fabric ribbons

  2: there is a fixative, similar to the stuff artists
     use to protect charcoal drawings, that can be sprayed
     over the printout, making removal of toner more difficult.

Matt Healy  matt@wardsgi.med.yale.edu

PS: In the Selectric, IBM had the best keyboard I have ever used.  Why didn't
they use it for the PC?  Closest approximation I have used recently is an old
Leading Edge Model D.   

       [If you wish to answer Matt's question, send mail to HIM, not to RISKS.
       By the way, the Selectric touch was fine, but the ball kept getting
       out of alignment.  I have some wonderful concrete (abstract) poetry 
       generated in 1969 using just such a ball.  I had a real ball!  PGN]

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

Date: Wed, 6 Jan 93 11:02:32 -0600
From: kain@ee.umn.edu (faculty R. Y. Kain)
Subject: Large Foreign Exchange Rates

During the fall I recall that there was a RISKS contribution in which the
writer speculated about the number of digit positions required to specify a
real currency exchange rate, concluding that something like four or five digits
would surely be adequate. This is incorrect - my daughter was previously in
Zaire in the Peace Corps and is now in Congo in the Peace Corps. They (she and
her husband had to leave Zaire when the Peace Corps cancelled the program in
the country due to unrest which was partly due to the economy, which is in a
shambles. When they went in the Peace Corps (Thanksgiving 1990 for Zaire), the
exchange rate was something like 400 Zaires per dollar (officially) and about
800 Zaires per dollar in the real market. When they left the country the rate
was about 80,000 Zaires per dollar (Sept. 1991), and the official rate had
been dropped for some time. This weekend the rate is about 2,500,000 Zaires
per dollar!! (And the largest piece of money is a [recently printed] note for
5,000,000 Zaires, but the government has said that in order to control things
they were going to remove that one from circulation!)

So in the face of unreasonable people (dictators, etc.), perhaps we need to use
a floating point representation for the exchange rates - but I do think that
one decimal digit for the exponent should be adequate. (And no one should need
seven digit accuracy in the mantissa.)

Richard Y. Kain, EE Department, University of Minnesota   kain@ee.umn.edu

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

Date: 06 Jan 93 13:22:00 GMT
From: Lord Wodehouse <w0400@ggr.co.uk>
Subject: Stolen to order systems

A letter in the UK magazine DEC User Jan 1993 page 6 shows a new danger"

  I think all readers should consider the implications of what happened to
  our company on 26th September 1992.

  At about 7:00am, our alarm was triggered, police and managers alerted,
  but by 7:07am we were already too late. In a precise but crude act, a
  single window was shattered by two lumps of concrete and our main PDP
  11/84 processor was detached from all peripherals and lifted through
  the broken window.

  Naturally, we have restoration media of the recovery list, programmes and
  latest data. We were back in operation on Wednesday  night thanks to our
  maintenance contract, software support and up-to-date back-up media.

  We are still reviewing potential motives and ramifications, but there
  have been other thefts in the area and complete systems are apparently
  reaching the former Eastern Bloc. In the meantime, if anyone offers you
  a cheap PDP, please let me know.
                                        A McManus
                                        Financial controller, Ritrama (UK)

[BTW, I guess the letter shows 1) a criminal problem, and 2) why you make
backups.)

Lord John - The Programming Peer  w0400@ggr.co.uk
                    tlx  - 8951942 GLXPRI G      fax  - +44 81 423 4070

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

Date: Wed, 6 Jan 93 09:41 MET
From: MEULEN@tno.nl
Subject: Prosecution in the Cindu case

The statement 

    The dutch news said that the responsible person has been found and
    he will be charged with neglig[ent] conduct causing death.

in RISKS-14.20 on the Cindu accident aroused some excitement. In my first
contribution in RISKS-14.21 I forgot to add details.

Although there were some rumours that employees of Cindu would be prosecuted,
the public prosecutor decided not do so. He thinks the employees were punished
enough already by what had happened and that the case is too complex to be
able to focus responsibility for the accident to one person. The rumours
focused on the man who forgot to check the recipe before executing it. He was
an apprentice operator, 3 months in service, and was alone when the accident
happened.

Dutch government charges the Cindu company as a whole for breaking several
environmental, health, safety, and economical laws. The public prosecutor
demands a fine of one million guilders (approx. US$600,000) and a suspended
sentence (trial period of two years) to close the plant if another accident
happens again. The latter is quite new in the Netherlands.

The judge pronounced judgement on 5 January: a fine of 200,000 guilders
(approx. US$100,000) mainly for breaking health and safety laws. (Of course
Cindu is liable for damage etc., but this is civil law). 

Meine van der Meulen, meulen@tno.nl, The Netherlands Organization for
Applied Scientific Research TNO, Department of Industrial Safety,
Apeldoorn, The Netherlands, Phone: +31-55-493493.

   [Also noted by Anton van Reeken, A.vanReeken@be.rulimburg.nl.]

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

Date: Tue, 5 Jan 93 11:22:00 -0500
From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
Subject: Re: Microprocessor Design Faults (Wichmann, RISKS-14.22)

Mr. Wichmann makes the point that while often market pressures result in
manufacturers concealing bugs in chips he states that:

  "In contrast, quite a few software vendors have an open bug reporting scheme
  --- and almost all provide a version number to the user."

Unfortunately recent events have indicated that Microsoft does not always
adhere to this maxim, choosing instead to "slipstream" certain corrections.
Further from reports I have received, Microsoft employees have been
distributing misinformation on incidents.

The situation is as follows: when MS-DOS 5.00 was released, the CHKDSK program
apparently contained a flaw that causes corruption of disks containing over
approximately 65,280 clusters if the /F switch is used. Depending on cluster
size, this indicates that disks or partitions containing approximately 128MB,
256MB, 512MB, 1024MB, or 2048MB are at risk.

The problem had been corrected in a version of MS-DOS 5.00 dated 11-91 however
other than the date, the only way to check is with a byte-for-byte check since
both versions are exactly the same length (16,200 bytes).  For reference, the
earlier version contains the string 8B 4F 0F 8B F9 at offset DS:263E while the
"fixed" one contains 8B 7F 0F 32 ED at the same offset.

The sad part is that people have reported MicroSoft personnel as first
recommending the undocumented VER /R switch and using only "Revision A".
Unfortunately *every* version of MS-DOS 5.00 reports "Revision A". Just today
I received a note from someone who contacted Microsoft and was told to
"execute COMMAND.COM and check the version number" again both the old (04-91)
and the new (11-91) versions report exactly the same thing.

Further, this mirrors the response received when I called to report that
certain corrupt values in the partition table could cause a floppy boot to
hang ("You must have a bad floppy...").

To make matters worse, Microsoft appears unwilling to post an approved "patch"
to the problem preferring to handle it on an individual basis (sounds kind of
like WordPerfect here - call with a problem and they send you a set of "magic"
disks).

Thus it would seem that Mr. Wichmann has been spared contact with Microsoft in
his assessment. I only wish it was true...

Padgett <padgett@tccslr.dnet.mmc.com>
        
ps.  Apparently  the  11-91  version of  MS-DOS  5.00  Revision  A 
     contains  a  number  of changes to  other  programs  however 
     IO.SYS, MSDOS.SYS, and COMMAND.COM appear to be the same.
        
pps. IBM  PC-DOS  5.00 is said to return something  meaningful  to 
     VER/R  -  the version dated 2-92 apparently has  the  CHKDSK 
     "fix".

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

Date: Mon, 4 Jan 93 16:37:10 MST
From: djy@inel.gov (Daniel J Yurman)
Subject: Release of Maps to NGOs?

PROCEDURES FOR RELEASE OF GIS DATA TO THE PUBLIC

There are many instances where non-governmental organizations request data and
maps, e.g. coverages, from geographic information systems (GIS) owned by
Federal and State agencies, but operated for these agencies by contractors.
Release of data from these systems usually requires the contractor to submit
the requested data / maps to the agency which in turn releases its to the
requesting organization.  GIS pose a special case because map coverages often
involve multiple layers of data from third parties and have widely varying
levels of quality.

This posting presents a hypothetical case regarding release of GIS data, poses
some questions, offers a straw man, and requests feedback.  The contractor and
the agency face substantial risks if the data are misused, misinterpreted, or
the results of these actions create problems for the users.

REQUESTS AND LIABILITY

Examples of non-governmental entities include other contractors doing work for
the same or other State agencies, businesses which want to use the data for
their own purposes, and "good government" groups and other interest groups,
who have reason to believe the data / maps will add value to their work.

The issue is raised about the use of released data for purposes for which they
are not intended and the ability of the original contractor and the agency to
protect themselves against problems with the quality of the released data.
For instance, should the original contractor prepare a "caveat emptor"
statement.

Further, the original GIS contractor gets much of its data from its primary
customer, the Agency, and from other State agencies.  The contractor does not
"own" the data, does not own the hardware and software of the GIS -- it was
paid for with tax dollars -- and, yet may be held liable by its customer for
inappropriate release or failure to properly qualify the release of these same
data.

CASE EXAMPLE

Let's take a hypothetical State Alcoholic Beverage Control Agency (ABC) which
has collected information on package sales by retail outlet, by product, and
other useful marketing information.  The State Agency sells all alcoholic
beverages in the State except beer and wine, which are sold in grocery stores.
It also regulates the sale of alcoholic beverages in restaurants and bars.

The State has built a GIS to make maps of sales data to support "targeting" of
different products by demographics, but also to help keep tabs on public
consumption habits in order to monitor "demand" for package sales v.
restaurant sales.  The ABC Agency argues it must have this data in map form so
that it does not overstock stores near high volume bars and in resort areas.
This has raised privacy issues and the legislature is asking whether the
Agency has gone overboard in meeting its regulatory mandates.

WHY THE DATA ARE REQUESTED

Some of the questions coming from the legislature are motivated by lobbying
pressures from the liquor industry.  The industry has a generally adversarial
relationship with the ABC Agency.  It will likely use the GIS data to make a
case in the current legislative session for changing the extent of the ABC
Agency's powers.  On the other side, a civil rights organization has requested
the GIS maps in order to show there are a disproportionate number of liquor
licenses in minority neighborhoods, and to show that the ABC Agency
discriminates against minority applicants for these licenses.

Numerous requests have been received by the Agency for copies of its maps.
Suppose you are the contractor who runs the GIS for the ABC Agency.  What
would you do in terms of qualifying the release of the GIS data, electronic
files, and hardcopy maps?  What kind of release procedures would you want to
use to cover your operation?

STRAW MAN

I'll start by offering a "straw man" caveat emptor statement.

        The primary objective of this data is to support specific
        legislative, regulatory, and administrative objectives of
        the ABC Agency and decision making which affects its
        operations.  This agency takes no responsibility for
        interpretation or use of this data for purposes other
        than for which it was originally intended.  ABC Agency
        databases and GIS coverages include many types of
        information with varying degrees of quality and
        reliability depending on the original sources.

        Further, it is the policy of the ABC Agency to accept and
        use the best data possible and to provide its users with
        information on the quality of that data.  ABC data are
        subject to periodic updates, and it is the responsibility
        of external users to obtain these updates.

Whether the data is ready for release or not the ABC Agency may be forced by
Freedom of Information Act requirements in the hypothetical state to release
the data and gis coverages.  The absence of a legislative mandate to make the
data public in other instances may not be a sufficient reason to withhold it.

This case revolves around marketing and regulatory data for alcoholic
beverages, but a parallel case could be developed for releasing GIS data on
hazardous waste sites which impinges on public safety, privacy, and real
estate values.

SUMMARY

The original question is -- what should the contractor and the government
agency do when faced with multiple requests for GIS data by non-governmental
entities?  What kind of "release policy and procedures" should be developed,
and does anyone have any examples?

Dan Yurman, Idaho National Engineering Laboratory, PO Box 1625,
Idaho Falls, ID 83415  djy@inel.gov 1-208-526-8591  Fax: 1-208-526-6902

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

Date: Thu, 7 Jan 93 11:00:51 EST
From: John Wack <wack@ariel.ncsl.nist.gov>
Subject: AFCEA ACCE Conference Announcement

Announcing the 4th AFCEA Computing Conference & Exposition Conference,
Sponsored by the Armed Forces Communications and Electronics
Association (AFCEA) in cooperation with the Association for 
Federal Information Resources Management (AFFIRM).

Objective:
	A forum for military, civil government and industry computer
	hardware, software and systems professionals and users to exchange
        information and strengthen professional knowledge regarding 
        capabilities, technology and application of information systems.

Focus:
	This is not a DoD-only conference.  The scope and focus of
	the conferences has continued to broaden to include presentations
	and demonstrations directed towards civil government and industry.  
        Individuals from government, industry, and academia are invited to 
        attend and will find the conference interesting	and pertinent.

Dates:
	Conference - February 2-4, 1993
	Exposition - February 3-4, 1993

Location:
	Hyatt Regency Crystal City
	2799 Jefferson Davis Highway
	Arlington, Virginia

Hotel Reservations:
	AFCEA has blocked rooms at the Hyatt Regency Crystal City at
	special conference rates of $126.00/Single and $140.00/Double.
	Call (703) 418-1234 or (800) 233-1234 and be sure to mention
	that you are an ACCE '93 attendee to receive the discount rates.

Security Tracks:

Panel:  Critical Programs Lead the Way

Recent policy and mission assignments in DoD strongly support the goal to
achieve adequate levels of security at an affordable price.  To meet this
goal, security requirements must be addressed early, from the top down, and
throughout a systems life cycle to be effective.  The panel will cover a cross
section of activities representing the latest DoD approach to systems
security.  Presentations will address the vital role of security architecture,
discuss current programs for meeting critical multilevel security
requirements, and describe a specific security product being developed for the
Navyis COPERNICUS program.

Moderator:  Mr. Robert Ayers, Program Manager, Defense Information
Systems Security Program, Defense Information Systems Agency (DISA)

Panelists: 

Mr. James S. Demerest, III Chief, DISSP Architecture Division National
Security Agency (NSA), The Road to the DoD Goal Security Architecture

lit. Col. John Sheldon, Program Manager Multi-level Security Technology
Insertion Program Defense Information Systems Agency (DISA), The Multilevel
Security Technology Insertion Program

Mr. Michael S. Harrison, SPAWAR INFOSEC Support Office, Embeddable INFOSEC
Product

Panel: Standards - the Key to Interoperability

To achieve security in an open systems environment requires the development of
comprehensive standards touching nearly every dimension of information
technology.  While progress is being made in selected areas, the broadly based
security standards structure needed to support the performance and user
demands of emerging networks is yet to be developed.  The immensity of the
task requires Government and industry to work closely together on a national
and international basis.  The National Institute of Standards and Technology
(NIST) plays a fundamental role in this effort.  NIST, DoD, and industry
presenters on the panel will discuss status, issues, and the direction for a
number of important security standards activities.

Moderator:  Dr. Stuart Katzke, Chief, Computer Security Division
National Institute of Standards and Technology (NIST)

Panelists: 

Major Truce George, PhD., USAF, Sr. Techical Assistant Strategic Network
Division National Security Agency (NSA), 
Status of Computer to Computer Security Protocols

Prof. Thomas C. Bartee, Institute for Defense Analysis (IDA), 
Converging Labeling Standards

Mr. Paul T. Cummings Sr. Software Engineering Manager, Manager ULTRIX MLS+
Digital Equipment- Corporation, 
Initiatives of the Trusted Systems Interoperability Group

Mr. F. Lynn McNulty, Associate Director for Computer Security National
Institute of Standards and Technology- (NIST), 
Infrastructure for the Digital Signature Standard

Panel: Near-Term Implementations

Current demands for network security cannot wait for mid- or long-term
solutions.  The need is now!  This panel will address actions to provide
solutions to real time network security demands.  Panel members will present
accomplishments and near-term plans in analyzing systems, Beta Testing, and
ongoing systems security applications.  The discussions will describe a System
Security Profile, an ongoing Beta Test of the Preliminary Message Security
Protocol, products applications at the Air Mobility Command on the Global
Defense Support System (GDSS), and the plans for the Reserve Component
Automation System (RCAS), the first Army system with MLS.

Moderator:  Mr. Charlie C. Baggett, Jr., Chief, Information Systems
Security Programs Group National Security Agency (NSA)

Panelists:

Mr. Robert Wandell, Work Center Chief for System Security Profiles
National Security Agency (NSA), System Security Profiles

lit. Col. Philip Toler, USAF DMS Implementation Team Defense
Information Systems Agency (DISA), 
Pre-Message Security Protocol (PMSP) E-Mail Beta Test

Major Paul Law, USAF Implementation Team Air Mobility Command,
Global Decision Support System Applications

Ms. Victoria Thompson, Reserve Component Automation System (RCAS) PMO
Air Mobility Command, RCAS Information Systems Security

Panel: Evaluation, Certification and Accreditation

The explosive growth of information technology is outstripping our capacity to
perform the security evaluations needed at the product level.  Similarly,
there are insufficient resources to perform the certification and
accreditation processes required at the system level.  The panel will discuss
plans and programs to enhance evaluation, certification, and accreditation
capability.

Moderator:  Mr. Daniel J. Ryan, Director Information Systems Security
Office of the Deputy Assistant Secretary of Defense (CI&SCM)

Panelists:

Commander Debbie Campbell, USN Standards, Criteria and Guidelines Division
National Security Agency (NSA), Converging Certification and Accreditation
Approaches in the Federal Government

Mr. Stanley J. Chincheck, Head of Communication Security Section Naval
Research Laboratory, Project Outreach - First Results

Mr. Larry D. Merritt, Director for Securities Air Force Cryptologic
Support Center, The Air Force INFOSEC Certification Program

Tutorial: Understanding System Security Solutions

The Information Systems Security field is complex and filled with jargon.
This three-hour session is directed at providing a clear, plain English
understanding of the fundamentals of information protection and the solutions
now available.  In addition, there will be a special presentation on how to
conduct INFOSEC business in the DoD.

Presenters:

Mr. James P. Litchko, Director of Business Development Trusted
Information Systems, Security Tool Kit `93

Mr. Joel E. Sachs, Vice President of Business Development Arca Systems, Inc.,
Multilevel Security - What It Is and What It Can Do

Mr. Daniel J. Ryan, Director, Information Systems Security Office of the
Deputy Assistant Secretary.  of Defense (CI&SCI), How to Conduct INFOSEC
Business in the DoD

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

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