Air Force Cryptologic Support Center's Newsletter - 28 Feb 92

28 Feb 92

THE CONNECTION Information Letter

ETAP Managers

1.  Attached is the latest edition of our information letter, THE
CONNECTION.  This issue will reach over 950 addressees, and we need
your help to give it the widest dissemination.  Please feel free to
copy and make this issue available to all your COMSEC, COMPUSEC,
and TEMPEST managers.

2.  THE CONNECTION information letter is produced by the Air Force
Cryptologic Support Center Communications-Computer Systems Security
Education, Training, and Awareness Branch.  This information letter
is for the education, training, and awareness of the Air Force. 
MAJCOM and unit security education officers are authorized and
encouraged to copy and redistribute materials in this information 
letter (including copyrighted articles) to educate and train those
organizations involved in communications-computer security and
TEMPEST efforts, including COMSEC accounts.

3.  The articles in this issue are entitled:  THE COMPUTER VIRUS
INTERDICTION SYSTEM (CVIS) FACILITY, STORM CLOUDS OVER AMERICA -
COMPUTER SECURITY:  BEHIND THE GREAT FACADE, THE FAMOUS HACKERS'
SCHOOL, STU III - THE SEQUEL, SMART TEMPEST, and THE STONED VIRUS.

4.  Our regular columns are included.  They are:  AFOSI Computer
Crime Cases, COMSEC Incidents, Tool Box, and Bits and Bytes.  Atch
1 contains two additional pages for the APL dated Oct 91.

5.  Our Communications-Computer Systems Security Education,
Training, and Awareness Branch welcomes your suggestions,
questions, and articles.  Please send your inputs to Ms Olivia
Dominguez, AFCSC/SRME, San Antonio TX 78343-5000, or call DSN
969-3154 or Comml 512-977-3154.


LARRY D. MERRITT                            1 Atch
Director for Securities                     THE CONNECTION, 28 Feb
92


THE COMPUTER VIRUS INTERDICTION SYSTEM (CVIS) FACILITY

by TSgt Rick Brown
AFCSC/SROV

The occurrence of computer viruses has escalated at an enormous
rate.  Until recently, the technology available to the Air Force
for scanning, eradicating, recovering, and preventing computer
viruses was either outdated or inappropriate.  This required units
to use unassessed anti-viral software.

Anti-viral software has been available through vendors,
computer bulletin boards, and trade magazines for some time. 
Software purchased in this manner created problems and continues to
do so because of the following reasons:

- Procured software may not perform its advertised functions.

- Unassessed software may contain viruses.

- The use of such software may violate Air Force regulations.

- The use of such software may create a situation in which the
integrity of critical information is compromised and service is
interrupted.

Until recently, the Air Force had no vehicle for assessing
these products or developing its own.  A vehicle is now available
via the newly developed AFCSC/SR Computer Virus Interdiction System
(CVIS) Facility.  The purpose of the CVIS is to analyze, diagnose,
test, and help cure viruses on Air Force systems.  CVIS is
comprised of two related components:  the Virus Research Laboratory
(VRL) and the Diagnostic Database Platform (DDP).

The CVIS Facility is a computer-based laboratory for MS-DOS and
Macintosh systems configured to analyze, diagnose, test, prevent,
and help cure viruses in the Air Force automation environment.  It
provides the Air Force with the capability to perform the following
virus interdictions:

-Identification and diagnosis (virus identification based on
its attributes).

-Cataloging (inclusion of virus incidents, countermeasures, and
products in the DDP).

-Analysis and test (determination of virus effects and
attributes).

-Prevention (protection of Air Force computer systems from
virus attacks).

-Containment (prevention of virus dispersal).

-Removal (elimination of virus strains and their effects from
Air Force computer systems).

-Predictive research (identification of future virus attack
scenarios and/or attack points and determination of anticipated
countermeasures and procedures).

Virus Research Lab (VRL)

The VRL will address all technical aspects of computer viruses
and accomplish the following:

-Develop a "technical" anti-virus capability for the Air Force
and establish relationships with other organizations with similar
capabilities.

-Provide an isolated test environment to safely test viruses.

-Obtain viruses to develop a testbed against which identified
tools can be evaluated for a reasonable level of assurance.

-Identify virus characteristics.

-Assess commercially available tools that remove viruses and
provide nondestructive recovery.

-Research, design, develop, and test anti-virus products.

-Transfer successfully tested products and test data to the
DDP.

-Provide interface between the DDP and the computing
environment.

-Provide emergency assistance.

-Maintain the virus portion of the DDP.

Diagnostic Database Platform (DDP)

The DDP will be used to develop and maintain information on
viruses and system vulnerabilities.  The DDP component provides
facilities for:

-Maintaining a current Diagnostic Database (DDB).

-Providing emergency assistance to computer sites to identify,
contain, and remove viruses.

-Reporting virus incidents.

-Determining how systems become infected.

-Categorizing viruses.

-Developing countermeasures and preventing infection.

-Developing counteractive products and procedures.

This will allow personnel to provide timely identification and
guidance to the user with a suspected or confirmed viral infection.

The DDB is an automated database containing information on the
following:

-Virus taxonomy.

-Countermeasures used to eliminate virus effects.

-Commercial "off-the-shelf" product information used to
identify, defend, or recover a system from infection.

-Procedures to limit or recover from virus attacks.

-Incidents reported to the CVIS of suspected virus occurrences
and outcomes.

Virus Lab and Diagnostic Data Base Scenario

When the user suspects or confirms an incident involving
disruptions of computer systems and/or networks (caused by a hacker
or virus), the user should contact his/her TASO, BCSSO, and/or
MCSSM, as appropriate within the structure.  The established chain
of command will forward the report to AFCSC/SROV.

Once SROV is contacted, they will determine if the virus had
been  identified before.  If it had, information can be provided
during the initial contact.  When an unknown virus is reported,
SROV will attempt to obtain a copy for analysis.  The VRL (operated
by AFCSC/SREC) will isolate the virus and determine if any existing
tools or countermeasures are effective against it.  If one is
found, the information is relayed to SROV for dissemination.

If no countermeasure exists, the VRL will then identify the
taxonomy of the virus and develop a countermeasure or tool to
eradicate it.  When completed, this information is forwarded to
SROV.  If indications are that the incident is widespread or of a
critical nature, SROV will immediately release advisory information
to all MAJCOMs and FOAs.

Future Projections

The goal of the CVIS is to provide a program that will
completely support Air Force field units in combatting and
developing countermeasures against vulnerabilities and attacks on
Air Force computer systems.  This support includes the following
future CVIS Facility enhancements:

-Multiple VRL "workbenches" (systems for various
machine/operating system combinations).

-Networking capability sufficient to test the ability of some
viruses to propagate to multiple platforms via this medium.

-Capability to provide selected, controlled sites query access
to the browse and symptom interfaces of the DDB.

-Periodic virus information updates to identified Air Force
sites.

-Development of technical security reports.

-Assistance to MAJCOMs in prioritizing their computer systems'
criticality for anti-viral software.

-Development of anti-viral products.

-Development of an Air Force computer bulletin board to
download anti-viral software to field units.

-Similar support to field units with nonstandard (i.e.,
Macintosh or UNIX) systems.

STORM CLOUDS OVER AMERICA
COMPUTER SECURITY:  BEHIND THE GREAT FACADE

by Christine Wood

"If you want your life's work to be useful to mankind, it is not
enough that you understand applied science as such.  Concern for
man himself must always constitute the chief objective of all
technological effort, concern for the big, unsolved problems of how
to organize human work and the distribution of commodities in such
a manner as to assure that the results of our scientific thinking
may be a blessing to mankind, and not a curse."

Albert Einstein

The scales of justice have been tipped.  While consumers
believe that  corporate security policies protect their rights to
privacy and shield them  from theft or loss, in reality justice has
been blind to internal sources or corporate corruption.  This
blindness has opened the door to illegal, unauthorized, and
uncontrollable release of consumers' private information.

Recently, a guest in my home left behind some personal
information containing a check stub (complete with social security
number) and an ATM receipt (complete with account number).  Armed
with these two pieces of information, I could have immediately
accessed their private banking information.  There would be
absolutely no way of anyone detecting or tracing by monitoring of
this account or preventing the use of this information from being
passed on to any other interested parties.  And that is exactly
what's being done everyday all across America.

As technology has made life easier for financial institutions
and information users, it has also made life easier for those
committing fraud and embezzlement and for those with corrupt
motives--creating temptation and opportunity for computer crimes to
thrive.  Lax network security opens up the doors to unauthorized
access, use or modification of information, hackers, and  viruses. 
As a result, millions of dollars, inventory, technology, and
confidential information on individuals have been lost through
computer fraud; and critical data have been destroyed or tampered
with by disgruntled employees.  So why is there so much resistance
to securing information?  Some of the advantages of poor security
practices are:  creating an environment where fraud (in upper
management) can thrive, spending corporate or departmental funds on
projects that are more self-serving, and some just don't see the
need for accountability in those who handle the public's liquid
assets and private information.

Has the conscience of American commerce become seared?

A seared conscience places profitability before accountability,
image before credibility, and "bottom line" before integrity.  It
is a conscience that is calloused or unfeeling.  This mentality is
dangerous in those who make decisions regarding others' entrusted
property because it places an emphasis on profitability, with the
methods unquestioned or perhaps unchallenged.

The Federal communications network is at great risk.

I recently obtained information contained in a risk analysis
and vulnerability study done for AT&T, one of the largest
telecommunications service providers (and government contractors)
in the US.  The study was conducted by a licensed hacker, tasked to
penetrate the system and exploit its areas of vulnerability on the
FTS2OOO administrative network.  The attacker operated their
computer from a remote site, unobserved, gaining complete access to
and control of the network, "masquerading as a valid user on the
mainframe or minicomputer facilities on the LAN."  Access to the
system was gained by obtaining an additional phone line into a
designated work area.  Following this, a commercial software
package was installed on the surreptitious host machine.  The host
machine physically appeared to be turned off by powering down the
monitor and the keyboard locked.  This false host machine was
accessed by a remote computer that had complete control of the
network from a remote location.  The first task in this attack was
to accumulate sensitive data from the network.

This data included user IDs and passwords enabling the user to
logon to  various hosts.  Two of these IDs were data base
administrator-level passwords   giving high levels of access to
critical data bases.  Other passwords    allowed access to
sensitive billing information, subverting the C2 level of security
on the mainframe.  Transmitted data gathered from the network was
sensitive enough to be protected at the source, but then it was
transmitted over the LAN in clear text, placing the data in
jeopardy of being manipulated or destroyed.

Why is there so little concern for data integrity, loss, and theft?

Computer and network security is one of the difficult
investments to get management to spend money on.  The reason there
is so little concern is partially economic.  Project costs increase
with the addition of security personnel, equipment, and studies
needed to adequately secure systems.  Purchasing security is like
purchasing insurance; there seems to be an "it can't happen to us"
mentality.  It is an intangible purchase that only appears valuable
or necessary once an attack has been committed.  Also, there is a
resistance on the part of personnel to learn new procedures that
could complicate their work routines.  If more emphasis is not
placed on the cost of implementing security, the greatest loss
(besides time and money) will be that of the creditability of the
institution.  Future disasters can be averted by  proper
contingency planning, risk analysis reporting, and security
implementation.  Loss of reputation, credibility, and good faith is
of far greater cost to industry than whatever budget expenditures
are necessary to ensure the integrity of their data.

Federal Security:

The Computer Security Act of 1987 - "No teeth behind the law."

The Computer Security Act of 1987 was established to define the
criteria that classified sensitive information and set guidelines
to protect sensitive information to ensure accuracy.

Information security professionals in federal government have
been given the responsibility of implementing computer security
without much in the way  of resources or authority.  A former
member of the Computer Security Advisory Board, formed in 1988 by
the Department of Commerce to oversee compliance with the Security
Act, said that "not much has been accomplished since adequate funds
are not available from Congress for compliance.  What we have is a
law with no teeth in it.  There is little money available for
enforcement in the Federal government itself, let alone the
enforcement of federal contractors."    What is needed, in his
estimation, is a "Champion for the Cause" in Congress.  Someone who
will take a personal interest and stand for the implementation of
the measures provided for in the Act.

Compliance or Smokescreens?

Even where it appears that security measures have been taken,
in many cases these are only smokescreens or facades.  They have
been constructed to give the appearance or illusion of
precautionary measures when in fact the features are not in use.
With credibility and reputation at stake, industry must recognize
the dangers far outweigh the chances that a national security
crisis of major proportion will not occur.

Warnings have been issued and the storm is quickly approaching. 
Loopholes that have not been plugged have been exploited and will
continue to be exploited to an even greater degree.

Industry still has the opportunity to provide assurance to
their customers and stockholders that the utmost protection of
their assets has been provided.  In this process, they will benefit
by ensuring their own long-term success, since customers always
respond to corporations they can trust.

Albert Einstien inferred that technological progress brought
with it many  new responsibilities and concerns for mankind.  Yet,
the saga of information security has thus far only been sung by
those security advocates, professionals, and policy makers who
believe that technology unchecked can lead to our own demise.  It
is time to heed the warnings.

(Reprinted with the permission of Christine Wood & Associates
Business, Marketing & Public Relations Consulting.  This article
appears in its entirety in ISPNews, Vol 2 No 1 Jan/Feb 91 issue.)

Are You Bored?
In a Rut?
Looking for a New Career?

If so, we have the answer to your problems...

THE FAMOUS HACKERS' SCHOOL

That's right, friends--the Famous Hackers' School!  Now you can
learn the ins and outs of hacking in the comfort of your own home,
as you prepare for your new career in this fast-growing hi-tech
field.    Just imagine the look on your friends' faces when they
learn that you are a Certified Hacker!  As a hacker, you will be
smug in the knowledge that no corporate computer system is safe
from your talents.  You'll be able to sleep late and never have to
worry about your bank balance again!

Under the watchful eyes of our anonymous instructors--noted
hackers all--this correspondence course will teach you the finer
points of password plundering, system access level boosting, data
destruction, and electronic banking.

And Famous Hackers' School offers something that no other
schools offer:  backup career guidance.  This special course module
will show you how to turn your eventual arrest into a media event,
a best selling book, and a secure position as a computer security
consultant!

Just send $50,000, and we'll rush your FHS starter kit to you
via the fastest courier available.  This jam-packed starter kit
includes the following:
* A deluxe 486 computer system, complete with 9600-bps modem
and our proprietary "TeleHack" software package.
* A set of passwords to the major corporate computer systems
you'll access during your studies.
* A twenty-gigabyte optical disk for storing looted data.
* A collection of timed viruses for your personal use.
* Official FHS membership card, recognized by bail-bondsmen the
world over.
* A complete set of course manuals, cleverly disguised as
obsolete operating system manuals.
Bonus! Send your money before Friday the 13th, and we'll throw
in our famous "Build-a-Virus" kit, complete with two-page,
illegible photocopied instruction sheet, at no extra charge!

Get started as a hacker today--and have more fun tomorrow!

The Famous Hackers' School
A Division of Bizarro Enterprises

Our Motto:
Nobody likes a hacker...but that's OK, because they'll be sorry!

Send $50,000 (check or money order; no cash or credit cards,
please) to:
Famous Hackers' School
P.O. Box 312
Milford OH 45150
Attn:  Michael A. Banks, Chief Wizard

This article is reprinted with the permission of Michael A. Banks,
who is also the author of THE MODEM REFERENCE (Brady Books/Simon &
Schuster).  Reprinted from Analog Science Fiction/Science Fact
(Astounding).
_________________________________________________________________

The Air Force has established formal procedures under the
Incident Reporting Program (IRP) to identify technical
vulnerabilities and incidents and fix the holes that leave systems
open to attack.  Vulnerability and incident reporting procedures
provide for the collection, consolidation, analysis, reporting, and
notification of technical vulnerabilities and incidents, and the
development and dissemination of corrective measures.  

Vulnerability reporting will continue to be handled in
accordance with Air Force Regulation 205-16, chapter 17, until the
new regulation is published.

AFCSC has also established the Air Force Computer Emergency
Responsive Team to combat the exploitation of computer systems by
hackers or the attack of a virus.  The team provides the analysis
of incident reports and takes actions to obtain the necessary fixes
to eliminate possible recurrences.  AFCSC maintains a data base of
incident information from major commands, field operating agencies,
and direct reporting units.

This is strictly a "tongue-in-cheek" ad.
_________________________________________________________________
STU-III
THE SEQUEL

MSgt Rich Sapp (Retired)
Former ATC Communications Security Manager

STU-III -- Sounds like a movie or television sequel to the
never-ending battle 
the Air Force has been fighting to secure voice communications. 
Secure telephone unit version three (STU-III) is the latest
technological breakthrough in keeping our nation's secrets, and the
critics love it.

"I am very impressed with STU-III," said Lt Col Robert L. Kent,
HQ Air Training Command Director of Personnel, Plans, and
Readiness.  "We had an exercise recently and it was great to be
able to talk to my remote staff without leaving the building.  The
voice quality was very much improved as well.  Another nice thing
about STU-III is how easy it is to access and use.  I can remember
when a secure line was hard to find and very difficult to use.  
The STU-III is easy and right at your fingertips."

STU-III was developed as an easy-to-use, readily-available
means of securing telephone communications.  The STU-III looks very
similar to your average telephone from the outside.  It plugs into
a regular phone jack and works over regular telephone lines too. 
However, the inside of the STU-III is what makes the difference. 
With the use of a KSD-64, which is a small black plastic key, the
user simply places a call to another STU-III and presses the secure
button.  The phones will mate automatically to the highest common
classification level.  There is a display on the phone that lets
you know which office you've contacted and the level of classified
information that can be discussed.

Sounds too good to be true?  It isn't that STU-III, for all its
simplicity, is an unwanted child.  People think that because they
don't handle sensitive or classified information they don't need a
secure phone; but that's not the case.  The telephone is the
greatest threat to security.  A person may think they are carrying
on a harmless conversation, but their conversation, added with
tidbits of information gathered from other sources, can result in
sensitive or classified information falling into the wrong hands. 
The STU-III reduces this threat tremendously.

Colonel Jan P. Huggins, Air Training Communications Division
Commander, agreed with these comments and stated, "The biggest
breeches in security occur over the phone because folks try to talk
around classified information.  People in Air Training Command need
to be just as security minded as everyone else because what we do
is important to national security and must be protected."

Another problem people have with STU-III is storing the key. 
There seems to be a fear factor where STU-III keying material is
concerned.  People are not familiar with how to store it so they
assume it must be a difficult and lengthy process.  It's actually
just the opposite.  The storage requirements for the key are fairly
simple.  The key can be stored in the same room with the STU-III
provided a Government Services Administration (GSA)-approved
container is available.  If a security container is not available,
the key can be stored in a separate office in a locked desk drawer. 
The basic rule of thumb for most office environments is to ensure
that the STU-III, with the KSD-64 installed, is never left
unattended.

The central focal point for STU-III is your local customer
support center, but there are two other agencies to contact once
you know you are getting a STU-III.  Customers should contact their
base COMSEC custodian and their TEMPEST officer.  All three of
these agencies play a key role in the use and distribution of
STU-III.
SMART TEMPEST

by Maj Paul P. Pilipenko
AFCSC/SRPS

Most people think of TEMPEST as a mysterious security field
that requires expensive protective countermeasures.  Though the Air
Force has had a TEMPEST program for more than 20 years, it is a
relatively unknown discipline to many people.

Because of this misconception, TEMPEST was ignored in many
instances and the Air Force was faced with either too much TEMPEST
or none at all.  A solution was needed.

This solution to protect vital classified information while
saving resources was appropriately labeled "Smart TEMPEST." 
Through this initial Smart TEMPEST concept, the Air Force is
ensuring people are aware of TEMPEST and the many alternatives in
protection.  It is educating people so that TEMPEST is applied only
when needed and to the extent required.  A Smart TEMPEST briefing
was formulated and given to all Air Force senior-level personnel
with phenomenal response.  Through these Smart TEMPEST efforts,
which are in line with the intent of the latest national-level
TEMPEST policy, the Air Force has virtually eliminated all new
TEMPEST requirements for shielded enclosures and TEMPEST certified
equipment.  Since the inception of the common- sense Smart TEMPEST
approach, the Air Force has saved over $60 million.

On the downside, Smart TEMPEST has resulted in a dramatic
increase in laboratory TEMPEST testing.  This was primarily due to
the new TEMPEST policy which, in most instances, permits the use of
off-the-shelf communication and computer systems to process
classified information.  The end result is that the majority of
laboratory TEMPEST testing is now targeted toward commercial
equipment.  This vital TEMPEST profile information is required by
Air Force users to determine if sufficient protection is in place
to allow the use of non-TEMPEST equipment.  It was evident that we
did not have the resources to fully satisfy the needs of our Air
Force customers.  Enter the next phase of Smart TEMPEST.

By coincidence, two new and expanded anechoic chambers were
recently completed as part of a military construction program that
relocated the Air Force TEMPEST test facilities from Brooks AFB to
Kelly AFB.  These identical anechoic chambers were designed to
provide an environment conducive to the performance of laboratory
TEMPEST testing on communication and computer systems.  Not only
could individual equipment be tested, but an entire system could be
installed and tested.

The chambers are operated by personnel from the Engineering and
Testing Division of the Air Force Cryptologic Support Center.  As
HQ USAF Executive Agent for Air Force TEMPEST testing, this service
is provided free of charge to any Air Force customer having a need
to have an equipment TEMPEST tested.  Priority is placed on
standard systems used throughout the Air Force.  Currently, one of
the chambers is dedicated to the TEMPEST testing of the DESKTOP III
and its many different configurations.  Results will be published
Air Force-wide once the profile information becomes available. 
Other standard equipment awaiting TEMPEST testing include the
family of SUN workstations, the AT&T 3B2 system, and the family of
McIntoshes.

If you desire a laboratory TEMPEST test on your configuration,
please coordinate through your MAJCOM TEMPEST Officer or call the
TEMPEST office at AFCSC/SRMT, DSN 969-3149 or Comml 512-977-3149,
for additional information.  Together, we can obtain the greatest
benefit in implementing this cost-effective Smart TEMPEST concept.
THE STONED VIRUS

by TSgt Rick Brown
AFCSC/SROV

With the number of known viruses increasing, it has become
necessary that AFCERT routinely provide the Air Force user with
virus information.  This information is provided to educate the
user on what a particular computer virus does, how it activates,
how it impacts the system, and how to remove it.

As a reminder, formal Air Force incident reporting procedures
must be used for any occurrence of a virus.  This procedure
requires that all viruses be reported to AFCSC/SROV, Comml
512-977-3157 or DSN 969-3157 (24-hour hot line) through your MAJCOM
Computer Systems Security Officer (MCSSO).

The following is not intended to provide a detailed technical
description of a virus, but rather a broad overview for general
purposes.

VIRUS NAME:  Stoned Virus
ALIASES:  Marijuana, Hawaii, New Zealand, Australian, Hemp, San
Diego, Smithsonian, 
Stoned-B, Stoned-C, Donald Duck, Rostor, Sex Revolution, Stoned II
DISCOVERED:  Oct 88
STATUS:  Very common and in epidemic proportions
CLASSIFICATION:  Boot Sector Virus
VIRUS LENGTH:  1 sector on disk, 2048 bytes of RAM
METHOD OF INFECTION:  The virus goes memory resident and infects
disks when they are accessed.  This virus infects floppy disk boot
sectors, hard disk boot sectors, and 
hard disk partition tables.
METHOD OF OPERATION:  The Stoned Virus is a boot sector virus that
does not use any bad clusters to hide code.  The virus fits
entirely within the boot sector, and the displaced, original boot
sector is written out to track 0, head 1, sector 3.  The virus boot
sector is written to the original boot sector of the disk.  When
the boot sector is executed, the virus reserves 2K of RAM at the
top of memory for itself and takes over the INT 13H vector.  If
booting is done from a floppy, a check is made on the system timer. 
Thus on one out of every eight system boots, the virus will display
the message.  "Your PC is now Stoned.  LEGALIZE MARIJUANA."  If
booting is performed from a floppy, the virus checks the master
boot record (MBR) of the first hard disk.  If it does not contain
the Stoned Virus, it moves the MBR to cylinder 0, head 0, sector 7
of the first hard disk.  It then replaces the MBR with the virus
boot sector.  Once the hard disk is infected with the virus, the
saved original bootsector is loaded and executed.  Later, when INT
13H is used and if the requested function is a read or write, and
the floppy motor is not running, the virus will try to infect the
floppy disk.  If the disk is already infected, the infection is
skipped.
DAMAGE:  The virus causes damage by interfering with a running
application, overwriting or corrupting a disk's boot sector, and
corrupting the file linkages or 
file allocation table.  There is no intentional damage.
DETECTION METHOD:  ViruScan, CleanUp, F-PROT, IBM Scan, Pro-Scan,
VirexPC, AVTK 3.5+, VirHunt 2.0+
REMOVAL INSTRUCTIONS:  Normal formatting will not remove the virus
from an infected hard disk.  To successfully disinfect diskettes
and hard disks use one of the many anti-viral products available
for this purpose.  In order to disinfect a system infected with the
Stoned Virus, the system must first be powered down and booted with
an uninfected, write-protected system diskette.    This will
eliminate the possibility of reinfecting diskettes once they are
disinfected.
STONED VIRUS VARIANTS:
STONED-A:  This version does not infect the system hard disk.  This
is the original virus and is considered by some to be extinct.  The
position of the text that 
displays "LEGALIZE MARIJUANA" is not displayed.
STONED-B:  Same as above; however, systems with RLL controllers may
experience repeated system hangups.
STONED-C:  The message has been removed.
STONED-D:  This variant can infect high density 3.5" and 5.25"
diskettes.STONED II:  This is similar to the Stoned-B version;
however, it has been modified to avoid being detected by anti-viral
products.  Since its discovery in Jun 90, most products can detect
this variant.  The message displayed has been changed to "Your PC
is now Stoned! Version 2" or "Donald Duck is a lie."
AFOSI COMPUTER CRIME CASES

by TSgt Dwayne Thomas
AFCSC/SRME

Theft of Government Property

Location:  CONUS

Motive:  Personal Gain

Duty Position:  Civilian Supervisor, Traffic Management Office

A civilian supervisor at the Traffic Management Office (TMO)
was suspected of 
stealing over $5,600 worth of government equipment from the TMO
office on base.  A worker checking the manifests against available
stock discovered that the equipment was listed but could not be
found.  An investigation was started and uncovered receipts for the
equipment signed by the subject in the subject's privately-owned
vehicle.  The subject later confessed to taking the equipment.

A search of the subject's residence revealed the stolen
equipment:  two Z-248 computers, two Alps printers, and two
monochrome monitors along with peripheral equipment for both.  The
subject was under the impression that the equipment would not be
missed as the government regularly purchases new equipment in large
quantities.  The equipment was returned to the government, and the
subject was reprimanded and removed from federal civil service.

BOTTOM LINE:  Theft of any equipment owned by the US Government,
whether it is a pen, pencil, paper, typewriter, or computer, is in
violation of Air Force regulations and in some cases punishable
under the Uniform Code of Military Justice (UCMJ).  Report any
equipment losses or suspected losses to your supervisor or Terminal
Area Security Officer (TASO).  Generally, a Report of Survey is
required for loss of or damage to all accountable government
property regardless of dollar value.  In accordance with AFR
177-111, Reports of Survey for Air Force Property, unit commanders
assume responsibility for initiating this report.



Wrongful Appropriation of US Government Equipment and Violation of
Article 121 of UCMJ

Location:  USAFE

Motive:  Personal Financial Gain

Duty Position:  Communications-Computer Systems Operator, Base
Communications Center

A staff sergeant assigned to the Base Communications Center was
in possession of a missing US Government computer hard disk drive
a co-worker had reported stolen during a squadron move.  Subject
confessed to taking the hard disk drive and attempted to install it
on a personal computer at home.  When the drive would not work on
the personal computer, subject tried to sell the hard drive for a
profit of $200 to $300.

Subject was aware that stealing government property was
illegal.  However, subject thought that the chance of getting
caught was slim and that no one would miss the drive because it was
going to be taken off the unit's CA/CRL account.

Member was reduced to the grade of E-4, fined $300 pay per
month for 2 months, and sent to correctional custody for 30 days. 
The hard drive (estimated value of $800) was recovered and returned
to service.

BOTTOM LINE:  Computer hardware or software owned by the US
Government should not be removed from the installation or facility
where it is located.  There are stiff fines and penalties for
violators of these rules.  Can you afford to pay the price? 
COMSEC INCIDENTS

by Mr Richard L. Davis
AFCSC/SRMP

As of the end of Oct 91, we have a total of 521 reported COMSEC
incidents.  At the same time last year, we had 588 reported COMSEC
incidents, a difference of 67 less incidents reported this year. 
No, we can't begin to pat ourselves on the back yet, but we are
improving.  COMSEC personnel are receiving more training today than
in the past, and this training is being passed to their COMSEC
responsible officers (CROs) to ensure all COMSEC material is being
protected IAW all COMSEC policies.

Of the 521 reported COMSEC incidents, 394 are considered
physical incidents.  The rest of the incidents were either
personnel or cryptographic, which we will not discuss.  The types
of physical COMSEC incidents that COMSEC users are reporting to
their COMSEC custodian are:  lost control of the material, physical
loss of the material, and safes left open.  These three categories
have been the leaders every month for the past 10 months. 
Personnel are still leaving material out of their safes and not
protecting it at the end of the duty day.  Material has been left
on work benches, on top of desks, and in destruction facilities. 
These incidents occur because individuals are rushing to get home
or taking off from work and not checking the area completely to
ensure COMSEC material is not left out.  However, these same people
are taking time to pencil whip the Activity Security Checklist
(Standard Form 701) at the exit doors without checking the area. 
If you are one of the COMSEC custodians/users who continue rushing
through security checks and procedures, we can almost guarantee a
COMSEC incident report is in your future.

Physical loss of COMSEC material is still rated second among
COMSEC reported incidents.  Have you asked how anyone could lose
this material?  There are no easy or nice answers.  However, the
best answer is complete negligence on the part of the individuals
who were entrusted with the material.  Once the material is lost,
these individuals always say, "I didn't know, or I wasn't trained
by the COMSEC custodian on how to protect this material."  These
individuals "forget" that they signed statements saying they were
trained and understood the procedures for protecting the material. 
Not once do they question the custodian during their training
because all they want to do is get out of the vault, or they are
afraid to ask questions because they may sound dumb.  There isn't
and never will be a dumb question in the COMSEC world.  Please ask
those questions.  Your custodian should be more than willing to
help prevent COMSEC incidents assigned to his account and your
unit.

No matter how many "red flags" the Air Force provides an
individual to secure their COMSEC, someone will still leave his/her
safe and vault door open to the public.  Why?  Because people are
always in a hurry.  Please don't stand in their 
way when it's time to go home.  In some people, the mind begins to
shut down at the end of the day, and security is the least thought,
so they start pencil whipping the area checklist and the security
container check sheet.  Now, the safes/doors are supposedly secured
for the day because there's an X, time, and initials on the
checklist which tells everyone the job was done right. 
Unfortunately, too often it is not.  If you are guilty of this type
of situation, please stop immediately.  If you can't stop, just
imagine how you  would feel when you see quite a few people
standing around your open safe and desk the next morning and they
are not smiling.  Also, you will become very popular with your boss
and commander.  There is no reason to rush or take short cuts when
it comes to protecting COMSEC material.  If you suspect you are not
controlling and protecting COMSEC material properly, seek out 
your COMSEC custodian for advice.

The COMSEC custodian and other individuals working in the
account, especially the COMSEC users, must work together to help
eliminate these COMSEC incidents.  The Air Force is averaging about
50 to 55 reported incidents a month and about 10 reported practices
dangerous to security.  Most COMSEC account personnel are not
making the mistakes; it's their users.  If COMSEC users made an
effort to become knowledgeable about COMSEC, our incident program
would average about two to three a month.  Some CROs and users
treat this additional duty as a burden and howl "wolf" when
something goes wrong.  They never took the time to read their
COMSEC Users Guide or ask for guidance from the account personnel. 
The majority of the COMSEC account personnel are dedicated
individuals who are willing to provide complete service and
training to their COMSEC users if they seek help.  Don't wait until
you have an incident before you call for help, unless you want to
be the most visible person on base with your commander.

POC is Mr Richard L. Davis, AFCSC/SRMP (Air Force COMSEC
Incidents Office), DSN 969-3178 or Comml 512-977-3178.

TOOL BOX

TEMPEST Information Messages (TIMs) Sent

The following is a listing of TIMs since the last CONNECTION
was published.  It is provided to assist all ETAP managers.  If you
haven't received one of these messages, please call your base or
MAJCOM TEMPEST Manager.  If further information is required, please
call AFCSC/SRMT at DSN 969-3149 or Comml 512-977-3149.

TIM Number:  91-17
Subject:  TEMPEST Alert Message
DTG:  171830Z Oct 91

TIM Number:  91-18
Subject:  Change to TEMPEST Information Message (TIM)
DTG:  300700Z Oct 91
COMING SOON:
ARES 2.0

For those who have been waiting for the release of the new
Automated Risk Evaluation System (ARES), the wait is coming to an
end!

ARES 1.1 was released in Oct 90 to fill a need for a risk
analysis package to support Air Force accreditations.  The concept
was to make the risk analysis QUALITATIVE instead of QUANTITATIVE. 
Many commercial packages are available, but almost all produce a
numerical output as a risk index of some sort.  Run several of
those packages, and you will get several results; few if any will
compare to the others.

ARES, instead, produces a list of potential risks the end
computer security manager (TASO/CSSO) can evaluate, attempt to
correct, and ultimately send to the approving authority as part of
the accreditation package.  Designed to be an iterative tool, ARES
is generally run several times, with the TASO/CSSO correcting
potential risks each time, until they have a package they feel the
approving authority will accredit.  ARES 2.0 will take this
philosophy several steps further.

ARES 2.0 will begin by integrating three functions commonly
related to the TASO/CSSO's duties:  risk analysis, inventory
control, and functional area representation.  These three functions
are linked by a graphical user interface in a Windows(tm)-like
environment.  The user will begin by drawing the TASO/CSSO's
functional area with ARES' graphics package.  Lines, circles, arcs,
and text will allow the user to describe the functional area on the
computer monitor, showing walls, doors, windows, etc.

Next, icons representing different types of computer systems,
from mainframes to memory calculators, are placed on the graphic
for the functional area.  Each time an icon is positioned on the
screen, ARES opens an entry in the inventory database.  Before the
next icon can be placed, the user must give information to uniquely
describe the system.  The system can be completely described,
including all hardware, software, and any COMSEC equipment
attached, at this time or later, depending on the TASO/CSSO.

After the functional area is described, the TASO/CSSO can then
run a risk analysis on any system by "clicking" on the icon and
answering questions and filling out checklists from the risk
analysis menu.  Several systems can then be linked together to
perform a type accreditation.

The increased functionality of ARES has led to increased
hardware requirements.  ARES 2.0 requires an 80286
microprocessor-based computer at a minimum, with at least 6 MB of
free hard disk space; generally, this means any computer as
powerful as or more powerful than a Zenith Z-248.  Video is very
important for ARES 2.0, requiring an EGA monitor or better (VGA,
SVGA, etc.).  The preferred configuration is an 80386 
system with VGA and a mouse.  While the mouse is not absolutely
necessary, it will make using ARES much easier.

With options planned to import/export data to/from ARES'
databases, time scheduling/management, and others, ARES is
migrating from a risk analysis program to a true risk management
tool.  Though computer security will probably never be enjoyable,
ARES 2.0 is the first step toward making the TASO/CSSO duties
easier and less tedious to perform.

ARES 2.0 is scheduled for release to MAJCOMs/FOAs/DRUs in the
spring of 1992.  For more information and/or guidance, please
contact your unit, base, MAJCOM/FOA/DRU communications-computer
system security manager(s).  If further information is required,
please call AFCSC/SROV, San Antonio TX, DSN 969-3156 or Comml 
512-977-3156.  After release, copies may be obtained from your
BCSSO or MCSSM.
Automated TPDL

The automated TPDL is a valuable tool when used in conjunction
with the TEMPEST policy.  The current policy deleted
TEMPEST-approved equipment and shielded enclosures as direct
results of determining what countermeasure levels to apply.  The
new policy places more emphasis on the containment of compromising
emanations within the controlled or accessibility space.  The use
of TEMPEST-approved equipment or shielded enclosures to meet
emanations containment requirements can still be permitted but only
if it can be proven that their use is either a cost-effective
alternative or the only possible solution.  The TPDL provides a
shopping list of products that may satisfy your needs.  Use it and
encourage its use.

The automated TPDL program features have not changed.  You can
still select items meeting a varied set of criteria and in any
order.    Some concern has surfaced as to the date that is
displayed when the TPDL is activated.  The version number and date
displayed on the screen (i.e., version 2.6, 1 May 91) reflect the
program version date and not the actual date of the data.  The 
date on the disk reflects the data version.
The latest version of the TPDL is scheduled to be released in
Jan 92.  Anticipated changes will include:

* Changes that have occurred in the National Security Agency's
Information Systems Security Products and Services Catalogue;
specifically, changes to the Preferred Products List, the Endorsed
TEMPEST Products List, and the Potential Endorsed TEMPEST Products
List.

* New items tested or otherwise TPDL qualified since the last
TPDL.

* Generic guidance, in terms of equipment radiation TEMPEST
zone (ERTZ) for items not listed in the TPDL, has been adjusted to
reflect additional and changed items.  This guidance should not be
used for determining items for procurement.

The TPDL user's manual has not changed and can still be used. 
The TPDL is not releasable to contractors in its entirety.  A
contractor with a need to know can view the list at a government
office or can be provided a partial listing of the items needed. 
If you need procurement guidance, a user's manual, further
information concerning releasability to contractors, or have
questions or improvement suggestions regarding the TPDL, contact
your MAJCOM MCSSM or Mr Mike Schieffer, AFCSC/SRMT, at DSN/STU III
969-3149 or Comml 512-977-3149.  A copy of the TPDL goes to all
MAJCOMs, FOAs, and DRUs.  If you do not have a copy and need one,
contact your MAJCOM TEMPEST Manager.
Assessed Products List (APL)

The 1991 Assessed Products List (APL) was mailed out in Nov 91. 
The Computer Security Policy and Doctrine Branch (SRMC) of the
Directorate of Securities (SR) serves as the customer point of
contact (POC) for COMPUSEC products.  To obtain additional copies
of the APL or final reports, to have a COMPUSEC product assessed,
or to request COMPUSEC system engineering support, please contact
your unit, base, or MAJCOM/FOA/DRU communications-computer system
security manager(s).  If further information is required, please
call AFCSC/SRMC, DSN 969-3180 or Comml 512-977-3180.  For specific
technical questions on any of these APL entries, contact the
Product Assessment and Certification Center (PACC) at DSN 969-3214
or Comml 512-977-3214.

The Vulnerability and Incident Analysis Branch (SROV) in SR
serves as the customer POC for anti-viral products.  To have a
virus product assessed or to request technical support, please
contact your unit, base, or MAJCOM/FOA/DRU communications-computer
system security manager(s).  If further information is required,
please call AFCSC/SROV at DSN 969-3157 or Comml 512-977-3157.

To submit comments, recommendations, address changes, or
requests to be placed on or deleted from automatic distribution for
the APL, contact AFCSC/SRME, DSN 969-3154 or Comml 512-977-3154, or
use the Reader Survey Letter at the end of the APL.

Additional pages for the October 1991 APL are at Attachment 1.

Questions and Answers on the Computer Based Instruction
Courses (CBI)

The following are questions on the CBIs that we are frequently
asked: 

Q:  What do I do when a get an error on testing integrity of
the distribution file when installing the Introduction to Computer
Security CBI?

A:  Ensure the "A:" drive is the default drive when installing
the distribution diskette.  Your prompt should look like "A:>"
before you type INSTALL.  (Note:  A: drive was only used as an
example.  The default drive must be the drive you are using to
install the CBI software.)

Q:  Threats, Vulnerabilities, and Countermeasures lesson won't
advance using the return key while running the Introduction to
Computer Security CBI.  What can I do to correct this?

A:  The course was designed to use the right and left arrow
keys to advance through the various screens.  The option was also
installed to allow users to use the return key to advance forward. 
This option was inadvertently left out of this lesson so you must
use the arrow keys to navigate through it.  The problem has been
corrected with the version 1.2 release of this CBI course.

Q:  When starting the Introduction to Computer Security Course,
DOS gives me an "Out of Environment Space" error.  Can I fix the
problem?

A:  Yes, this error condition is a DOS condition and not a CBI
problem.  To correct it you must add the following line to your
CONFIG.SYS file:

Shell=Command.Com /p /e:size

Size is the amount of memory space you wish to allocate to the
environment space.  DOS 3.1 size is in multiples of 16 bytes.  I
suggest starting out setting it at 32, which equals 256 bytes. 
Increase this size gradually until you do not get 
the error condition.

In DOS 3.2 or higher, size is the actual bytes you wish to
allocate.  I would start it at 512 bytes and increase gradually
until the error condition no longer 
exists.

Each time you change your CONFIG.SYS file you must reboot your
computer before the changes will take place.

Q:  When running the Computer Security CBI I get an "User.Dat
File Not Found" error message.  What does that mean?

A:  Before you can run the CBI you must create the User.Dat
file so the courseware knows who's on the system and can keep track
of his or her scores.  To correct this problem you must do the
following commands:

CD\CBI\PERF <RETURN>  - Change directory to the PERF
subdirectory.

REGSTU <RETURN> - Executes the program that creates the
USER.DAT file.  It allows you to enter the student's name and
assigns the student ID number.

After the USER.DAT file is created, exit the program and type
the following command:

COPY USER.DAT C:\CBI <RETURN> - This makes a copy of the
USER.DAT file in the CBI subdirectory.

Q:  I installed the Computer Security and Introduction to
Computer Security CBIs on a Z150 and a Z200 computer and they won't
run on either system.  What can I do?

A:  Nothing.  The courses were designed to run on either a VGA
or EGA monitor.  Because of the TEMPEST constraints of the Z150 and
Z200 computers, they can only use a CGA monitor and they are not
compatible with the CBI courses.

If you have any other problems or questions with either of the
coursewares we offer, please contact TSgt Timmy Moore, AFCSC/SRME,
at DSN 969-3154 or Comml 512-977-3154.
BITS AND BYTES

C4 SYSTEMS SECURITY MANAGERS CONFERENCE

AFCSC is hosting the Air Force C4 Systems Security Managers
Conference at the Radisson Hotel, 611 NW Loop 410 (near the San
Antonio International Airport), San Antonio TX, on 24-26 Mar 92. 
Lodging will be at the Radisson at the current per diem rate.  The
theme is "Security in Transition--Preparing for the Future."

This forum will present the most current information available
on the present and future of C-CS security programs affecting the
Air Force community.  The conference will be of interest to COMSEC,
COMPUSEC, TEMPEST, and ETAP Managers at the MAJCOM/FOA/DRU level.

The major portion of the conference will be held at the
Radisson Hotel with the classified portion at the SECRET level on
24 Mar in the Larger Auditorium on Kelly AFB.  Attachment 1
contains the draft agenda for the conference.

Reservations for the conference and the hotel must be made by
letter or message and received by this office NLT 15 Feb 92. 
Include in your message or letter your name, rank, SSN, clearance
information, and the dates you will stay at the hotel.  Also
indicate whether you will be attending the Communications-Computer
Systems Security Education and Training Working Group (CSETWG). 
Our message address is:  AFCSC KELLY AFB//SRME//; mailing address
is:  AFCSC/SRME, San Antonio TX 78243-5000.  Send clearance
messages through proper channels to HQ AFIC KELLY AFB TX//DOAS//, 
INFO:  AFCSC KELLY AFB TX//XRR//SRME/SRMC//.

The Radisson Hotel will provide a shuttle from the airport to
the hotel for the attendees.  Bus transportation will be provided
from the hotel to Kelly AFB and return only on 24 Mar. 
Transportation will not be provided for other than conference
business.

POC for the conference is Mrs Sharon Gilmore, AFCSC/SRME. 
Additional information is available from AFCSC/SRME personnel, DSN
969-3154 or Comml 
512-977-3154.
Network Security Testing and Monitoring

(Extracted from DISA Msg DODM 291816Z Oct 91)

Ref:  NTISSD 600, "Communications Security (COMSEC) Monitoring," 10
Apr 90

Per reference, it is required that users of government
telecommunications systems be notified in advance that their use of
these systems constitutes consent to monitoring for COMSEC
purposes.  The same applies to security testing of automated
information systems and networks.

Adequate notice to users can be accomplished by any of the
following means or any combination thereof:

-Displaying a printed message during the log-on process.

-Displaying a printed message periodically or continually
during system operation.

-Decals placed on processing terminals, transmitting and
receiving devices.

-Notices in daily bulletins or similar medium.

-A specific memorandum to users.

-Statement in the standing operating procedures, instructions,
or similar documents.

Recommend, as soon as possible, all users of the Defense Data
Network (DDN) be put on notice that their use of the DDN
constitutes consent to security monitoring and system testing. 
Proper notification in terms of content and specificity is: 
"Government telecommunications systems and automated information
systems are subject to aperiodic security testing and monitoring to
ensure proper communications security (COMSEC) procedures are being
observed.  Use of these systems constitutes consent to security
testing and COMSEC monitoring."

On DDN hosts with limited characters available in the log-in
banners, adequate notice would be provided by displaying the
following:  "Use constitutes consent to security testing and
monitoring."

POC at DISA/DODM is Major Boyd, DSN 222-7580 or Comml
703-692-7580.
Updated List of Old Regulations and New AFSSIs and
AFSSMs
The Air Force has decided to follow National direction and has
taken the approach of combining all four programs (COMSEC, TEMPEST,
COMPUSEC, and ETAP) under one regulation, AFR 56-1, Command,
Control, Communications and Computer (C4) Systems Security Policy. 
AFR 56-1 is the umbrella regulation which establishes policy for
all four programs.

In addition to AFR 56-1, numerous other regulations and
specialized publications, Air Force System Security Instructions
and Air Force System Security Memorandums (AFSSIs and AFSSMs), are
being developed.  AFSSIs will provide instructions and standards
and are directional in nature.  AFSSMs will provide general
guidance and information and are tutorial in nature.  These
specialized publications will complement the regulation and also
expand on policy where needed.

In the process of making this transition, the following is an
updated list of the old regulations and new AFSSIs and AFSSMs:

OLD REGULATIONS                            NEW DOCUMENTS

AFR 56-16, TEMPEST Policy                  AFR 56-1, C4 Systems
Security
AFR 56-18, The Air Force Communica-          Policy
tions Computer Systems Security
Education, Training, and Awareness 
(ETAP) Program
AFR 205-16, Computer Security Policy

AFR 56-1,  Signal Security Policy          AFSSI 4100,
Communications Security
or 56-4, Communications Security           (COMSEC) Program
(COMSEC) Policy

AFR 56-2, COMSEC Glossary                  AFSSM 9000, C4 Systems
Security
(See AFSSM 5000)                           Glossary

AFR 56-3, Classification Guide for         AFSSI 4200,
Classification Guide for  
COMSEC Information                         COMSEC Information
AFSSI 7006, TEMPEST
Classification
Guide

AFR 56-5, Routine Destruction and          AFKAG-1, COMSEC
Operations
Emergency Protection of COMSEC
Material

AFR 56-6, Safeguarding COMSEC              AFKAG-1, COMSEC
Operations
Facilities

AFR 56-7, Management of Manual             AFSSI 4300, Same title
Cryptosystems

AFR 56-8, COMSEC Surveillance              AFSSI 8300, Same title

AFR 56-9, Controlling Authorities          AFSSI 4007, Same title
for COMSEC Keying Material

AFR 56-10, COMSEC User's Guide             AFSSI 4005, COMSEC User
Requirements

AFR 56-11, COMSEC Duties and               AFKAG-1, COMSEC
Operations
Responsibilities

AFR 56-12, Reporting COMSEC Incidents      AFSSI 4006, Same title

AFR 56-13, Safeguarding & Control of       AFKAG-1, COMSEC
Operations
COMSEC Material

AFR 56-16, TEMPEST Policy                  AFSSI 7000, The Air
Force TEMPEST     
Program

AFR 56-17, USAF Voice Callsign Program     AFSSI 8200, Same title

AFR 56-18, The Air Force Communications    AFSSI 9100, The Air
Force C4 Systems
Computer Systems Security Education,       Security Education,
Training, and
Training, and Awareness (ETAP) Program     Awareness Program
(ETAP)

AFR 56-19, Protected Distribution          AFSSI 8500, Same title
Systems

AFR 56-30, Computer Security Policy        AFSSI 5100, The Air
Force COMPUSEC
Program

AFR 56-31, Security Policy and Require-    AFSSI 5101, Computer
Security
ments in the Development and Acquisi-      in the Air Force
Acquisition
tion of Computer Systems                   System

AFR 56-32, Computer Security for           AFSSI 5102, Same title
Operational Systems

AFSSM 5000, Computer Security              AFSSM 9000, C4 Systems
Security
Abbreviations, Acronyms, & Terms           Glossary
AFR 56-2, COMSEC Glossary

AFKAG-1, The Air Force Communications      AFSSI 4008, Off-Line
Operations
Security (COMSEC) Policy and Proce-
dures, Chapter 2

AFKAG-1, The Air Force Communications      AFSSI 4009, AF COMSEC
Inspection
Security (COMSEC) Policy and Proce-        Program
dures, Chapter 4

AFSAL 8108, TRI-TAC                        AFSSI 3011, Same title

AFSAL 3100, STU-III                        AFSSI 3007, STU-III

NACSI 5004/5005, TEMPEST Counter-          AFSSI 7001, The TEMPEST
measures for Facilities Within/            Countermeasures
Assessment
Outside the United States

NACSIM 5203, Guidelines For Facility       AFSSI 7002, Applying
TEMPEST
Design and Red/Black Installation          Countermeasures

AFKAG-2G, AF COMSEC Accounting Manual      AFKAG-2H, Same title

AFKAG-1K, The Air Force Communications    AFKAG-1L, Air Force
Communications
Security (COMSEC) Policy and Proce-        Security (COMSEC)
Operations
dures

Please direct any comments or questions to Ms Rosie Alaniz,
AFCSC/SRMC, DSN 969-3180 or Comml 512-977-3180.

Project FIRESTARTER

AFCSC/SR has been tasked by HQ USAF to be the executive agent
for Project FIRESTARTER, C4 Systems Security Research and
Development (R&D).  The project plan is to centralize C4 systems
security R&D for the MAJCOMs/FOAs/DRUs, with the primary goal of
eliminating costly duplication of effort and developing a
"user-requirements" driven USAF C4 Systems Security R&D Program.

Background.  For the past several years, Air Force MAJCOMs have
gone their own separate ways in regard to C4 systems security R&D
efforts.  The lack of a single point of control for these efforts
has caused both waste and duplication.  HQ USAF realized they had
a problem in this area and directed the following actions:

-Air Staff Involvement.   HQ USAF/SCTT held a meeting on 11 May
88 with representatives of AFSC, ESD, RADC, and AFCSC on ways to
improve the effectiveness of the Air Force C4 systems security R&D
programs.  One of the major issues was to ensure that all MAJCOM
(including FOA/DRUs) requirements were considered in the new
coordinated C4 systems security R&D effort.  As the executive agent
for this effort, AFCSC was instructed to work with appropriate
parties to ensure that all requirements for C4 systems security R&D
efforts were identified and documented.

-AFCSC/SR Tasking from HQ USAF:

Provide MAJCOMs/FOAs/DRUs with the threat information needed to
support their requirements.

Assist the MAJCOMs/FOAs/DRUs in identifying new C4 systems
security capabilities and technologies which must be developed to
secure or evaluate/monitor the security of their C-CS.

Assist the MAJCOMs/FOAs in developing/drafting a Statement of
Operational Need (SON) and a System Operational Requirement
Document (SORD) to document their requirements for the development
of new security technologies or capabilities.

Consolidate validated MAJCOM/FOA/DRU requirements to form an
integrated C4 Systems Security R&D Program.

Advocate and defend funding for the C4 Systems Security R&D
Program through the AFIC Program Objective Memorandum (POM)
process.  This is a Program Element (PE) 33401 effort.

Coordinate with appropriate AFSC Labs and Product Divisions
throughout execution of the approved R&D Program to ensure that
MAJCOM/FOA/DRU and Air Force needs are met.

Accomplishments.  Although the USAF Project FIRESTARTER was not
officially funded until FY92, we were able to initiate primary work
in requirements 
identification and in R&D lab tasking with limited availability of
FY90/91 funds.  To date, the following efforts have been
accomplished:

Multicommand-sponsored Multilevel Security SON.

Eight AFIC SONs covering TEMPEST and data remnants.

Three SONs for SAC covering a Secure Data Base System, Secure
Management of Aggregations Data, and Classified Material Control
Systems.

SON for the Handheld Secure Cellular Radio (AFSPACECOM),
High-Speed Key Generator (AFSC), Network Security System (AFLC),
and Personnel Records Security Systems (AFMPC).

Eleven SORDs covering Multilevel Security (six each), TEMPEST
Testing Enhancements (four each), and Data Requirements.

Each of these MAJCOM SON/SORD assistance efforts is either in
the development phase, the validation phase, or final MAJCOM/AF
coordination.

AFCSC's FIRESTARTER Team is currently assisting in future efforts
such as analysis and development of requirements documentation of
R&D work for improved secure digital satellite voice
communications, programmable high-speed generator, an acoustical
Energy Retrieval/Measuring System, and additional TEMPEST test
equipment.   AFCSC/SRPX (the FIRESTARTER office) sent out a message
to all MAJCOMs in Jan 91 advising them of our assistance service
and asking any MAJCOM that needs assistance in identifying C-CS
security needs to contact AFCSC/SRPX at DSN 969-3116 or Comml
512-977-3116.  We also request that any activity having a
requirement similar to one of those identified in paragraph 1b
above or who wants to cosponsor one of the above SONs/SORDs contact
the FIRESTARTER Team.

Bottom Line--FIRESTARTER is an AF requirements-driven effort to
maximize our C4 systems security R&D results for the R&D monies
expended.  For more information and/or guidance, please contact
your unit, base, or MAJCOM/FOA/DRU communications-computer system
security manager(s).  If further information is required, please
call Mr Don Colbert, AFCSC/SRPX, DSN 969-3116/3136 or Comml
512-977-3116/3136.
Tactical Secure Voice

The Tactical Secure Voice (TSV) Program office hosted a working
group meeting with the POCs from all MAJCOMs to get their inputs
for the upcoming presentation of TSV to the seniors in the MAJCOM
DOs.  Their inputs have been incorporated into the TSV Briefing
which will be presented to each MAJCOM HQ, starting in Jan 92.

The following is a list of MAJCOM POCs submitted to this
office.  Please submit additions, deletions, or changes to
AFCSC/SRPT:

COMMAND       POC               DSN NO

TAC/DRCG      Capt Hoss         574-5927
TAC/DOYC      Capt Cammel       574-4620
TAC/DRCG/SCPS MSgt Goodwin      574-5927
USAFE/SCX     MSgt Von Duering  496-6611
AFSOC/XPQ     Mr Gingrich       579-5552
AFSOC/SCL     TSgt Nelson       579-2464
PACAF/SCXPA   Capt Charon       449-5372
MAC/XOSP      Capt Woods        576-3391
MAC/SCYX      MSgt Hoffman      576-5432
MAC/XRSS      Mr Collins        576-3908
1500 CSGP/    SMSgt Bullock     576-6400
XPSC
SAC/SCPS      Capt Meyers       271-2553
SAC/SCPL      CMSgt Franz       271-5573
AFSPACECOM/   MSgt McGurren     692-5179
LKOS
AFLC/XRNZ     Mr Vondenhuevel   787-4210
AFLC/XRSC     Maj Nelson        787-6151
AFOSI         TSgt Coffey       297-5510
AFRES/SCPP    Mr Gay            468-6401
ATC/TTOI      Mr Dye            487-2172
NORAD/J30G    Maj Holland       692-5475
NORAD/J5RC    Maj Tucker        692-9697
USSOCOM/      CW4 Bryant        968-4630
SOJ6-P
USCENTCOM/    Maj Tuday         968-6412
CCJ6-PM
Joint Staff/  Mr Ritter         968-2461
J6Z
NGB/SCOM      LTC Pansey        858-8680
104 TFG/MAAC  TSgt Burns        636-1367
1845 EEG/XPS  Mr Springer       884-9501
TIC/DS        MSgt Wigner       576-5980
JCSE/XR       Mr Yee/Mr Basta   968-3566
ESD           Ms Woffinden      478-5042

Additional information on maintenance, applications, policy,
requisition, problems, modifications, and operation of TSV
cryptologic equipment will be provided in future CONNECTION issues.

POC is Mr Bruce Ulrich, AFCSC/SRPT, DSN 969-3113 or Comml
977-3113.

Security-Related Lessons Learned Publications

As part of a continuing effort to keep users informed of
available security products, AFCSC will be distributing "lessons
learned" publications to requesting Air Force organizations.  These
publications typically document product assessments and test
results by the various testbeds.  Distribution of these documents
does not indicate Air Force endorsement.  Our purpose is to make
available information that can be useful in the selection of
products for specific needs.

Our initial series of publications document lessons learned
through the application of multilevel security (MLS) technology and
techniques as part of the Joint MLS Technology Insertion Program. 
Their purpose is to relate the experiences gained at the Joint
Staff-designated DOD MLS testbed, which is hosted by US
Transportation Command (USTRANSCOM)/Military Airlift Command (MAC). 
By assessing and testing products for application in the MAC
operational environment, valuable lessons have been learned about
their technical characteristics and security in the operation of
command center systems.  Additionally, experiences from other
organizations are also presented.  Overall, these reports serve as
a reference for those considering integrating these products into
existing or new automated information systems.  A copy can be
obtained from AFCSC/SRPX, San Antonio TX 78243-5000.

Multinet Gateway (MNG) - The MNG is an internetwork device
that provides communications and security services among hosts and
networks operating over a range of security levels.  As a system or
network component, the MNG can be applied as a packet-switched
gateway, information flow filter, and front-end processor, or as
combinations of these.  The MNG resulted from an Air Force research
and development effort involving Loral Command and Control Systems
(formerly Ford Aerospace and Communications Corporation).  The MNG
has undergone testing, assessment, and operational deployment
within various government organizations.  This report introduces
the MNG and summarizes the lessons learned and experiences to date
regarding the MNG at those organizations.

Xerox Encryption Unit (XEU) - The XEU is a communications
security (COMSEC) device that can be used to protect information on
local area networks (LANs) and other communications links.  The
product's successful development under the Commercial COMSEC
Endorsement Program (CCEP) resulted in its endorsement by NSA as an
approved mechanism to protect unclassified, classified, and
sensitive US government information up to the Top Secret level. 
The XEU has undergone testing and assessment at various government
organizations interested in the application of the XEU in their
information systems.  This report introduces the XEU and summarizes
the lessons learned to date regarding testing and assessing the XEU
within the DOD.

Multilevel Security Documentation - This document provides
Automated Information System (AIS) Program Managers (PMs) with a
general discussion for documenting multilevel security (MLS)
activities in support of design, implementation, certification, and
accreditation throughout the acquisition life cycle.  MLS
documentation is essential to demonstrate that security policy and
requirements have been met, security concepts are sound, and
security procedures were followed in developing an AIS. 
Documentation records critical analysis and decisions and presents
evidence to the system Designated Approving Authority (DAA) and
certification authority that security was properly addressed in the
AIS life cycle.  Appropriate scheduling of these activities within
system life cycle phases is essential to ensure that the system
meets and maintains its certification and accreditation
requirements.

Direct any comments or questions to Mr. Joe Cano, AFCSC/SRPX,
DSN 969-3136 or Comml 512-977-3136.
COMSEC Controlling Authorities

COMSEC controlling authorities--what are they and what do they
do?  Each cryptonet or specific short title of COMSEC material has
a controlling authority--that is an organization that oversees,
manages, and controls the cryptosystem.  COMSEC controlling
authorities are responsible for the management, logistics, and
security of the cryptonet.  Specifically, they:

-Identify all cryptonet members and the quantities of keying
material they hold.

-Coordinate logistics support and resupply requirements.

-Authorize cryptonet activation, key implementation dates, and
cryptoperiod extensions.

-Know the operational requirements for the network.

-Establish key change times.

-Make spare group assignments (for codes and authenticators).

-Authorize extracts or local reproduction.

-Evaluate security incidents, etc.

Who can be a controlling authority?  Well, to be an effective
controlling authority, the organization should have some
operational control over the system and be senior to most, but not
necessarily all, network members.  Those members which are elements
of other organizations must abide by any direction pertaining to
the net which is received from the controlling authority.  With the
introduction of electronically-generated key, the organization
directing the key generation acts as the controlling authority
unless those functions are specifically delegated to another
organization.  The Joint Chiefs of Staff, the chiefs of the
military services, the commanders of the Unified and Specified
commands, and the heads of Government departments and agencies may
direct that controlling authorities under their control be changed. 
AFCSC has recently exercised this right.  In the past, COMSEC
accounts have traditionally acted as controlling authorities,
especially on point-to-point systems.  However, a recent policy
change prohibits COMSEC accounts from performing as controlling
authorities because they are rarely senior to the members and
usually have no direct control over the network or its members.

In short, a controlling authority acts as a liaison between
the national COMSEC activity, NSA, all the way down to the
individual network members.  Without controlling authorities,
communications would most likely break down because network members
would not have one central authority to look to for direction and
guidance for consistent operations.  Controlling authorities can be
responsible for the success or failure of our communications
systems and ultimately for the security of these systems.

If you have any questions regarding COMSEC controlling
authorities, refer to AFR 56-9 (Controlling Authorities) or call
your servicing COMSEC account or MAJCOM COMSEC monitoring office. 
If further information is required, please call TSgt Sonja Fox, DSN
969-4821 or Comml 512-977-4821.
Electronic Security Assessments

For the last couple of years, AFCSC Electronic Security
Assessment (ESA) Teams have evaluated a variety of
communications-computer systems (C-CS), organizations, and
facilities.  In some cases, the teams only reviewed the project
specifications for software and hardware of large mainframe
systems, while in other cases they examined the overall security
environment.  The latter included procedural, administrative, and
operational controls for software and hardware on mainframe
computers and personal computers (PCs).  The team's mission is to
review and evaluate the effectiveness of an organization's 
COMPUSEC, TEMPEST, and COMSEC posture and provide the requesting
unit commander a picture of the overall security posture of his
organization.  These assessments are provided as a service to the
requesting commander and not as an 
inspection by an outside agency.

The teams have assessed an assortment of organizations across
the continental United States and provided recommendations that
were extremely well received.  Organizations that have been
assessed by these teams include research and development (R&D)
facilities, test ranges, sites affected by the nuclear reduction
treaties, and sites impacted by the consolidation of automated data
processing facilities.

The teams have assessed 14 sites and identified deficiencies
in almost every area of management and operations of TEMPEST,
COMSEC, and COMPUSEC.  The teams concentrated on policy and
directive compliance, operating procedures, configuration
management, user training and awareness, system connectivity, and
physical security.  The overriding lesson learned from these
assessments is that the fundamental weakness in the security of our
communications-computer systems is people, not the technology.  The
security posture of an organization depends primarily on the
training and discipline of its members.

The specific findings that were common throughout these
organizations are:

- Problems effectively implementing or following applicable
policies, directives, or local operating instructions (i.e., no
risk assessments, incomplete or no accreditation packages, etc.).

- Problems protecting their systems or networks against
unauthorized access (i.e., no access controls, poor password
management, no auditing capabilities, unknown connectivity,
unauthorized bulletin board connections, 
etc.).

- Problems with restricting the use of unauthorized software
on their systems (i.e., copyright/license violations, unapproved
freeware and shareware, games, poor media controls, etc.).

- Problems due to the lack of an effective training and
awareness program for their personnel regarding C-CS security
requirements and practices.
Our capability to provide these types of service is currently
very limited, but with the implementation of the Electronic
Security Survey Teams (ESSTs) and Electronic Security Engineering
Teams (ESETs) in late FY92, this should quickly change (see article
on ESSTs).

Direct any comments or questions to Mr. Fred Ramirez,
AFCSC/SROV, DSN 969-3157 or Comml 512-977-3157.

Electronic Security Survey Teams (ESSTs)

The ESSTs are being built as part of the
Comunications-Computer System Security Vulnerability Reporting
Program (CVRP).  Two other related components are the Electronic
Security Engineering Teams (ESETs) and the Countermeasures
Engineering (CME) Teams.  These teams will provide three different
levels of capability to measure security posture and recommend
countermeasures where deficiencies exist.  The ESST mission is to
test and assess the effectiveness of an organization's COMPUSEC,
TEMPEST, and COMSEC program and provide the requesting commander a
picture of the overall security posture of his organization.  The
ESSTs will concentrate on exploiting the known vulnerabilities that
exist because of poor user and system manager discipline.  ESETs
will concentrate on the more technical problems that exist within
computer and network operating systems, hardware vulnerabilities,
network connectivity issues, and other technical issues.  The CME
Teams will validate technical vulnerabilities, develop
countermeasures for existing vulnerabilities, and provide technical
support to the ESSTs and the ESETs.

The ESSTs will be composed of personnel from Air Force
specialty code  209XX.  These are the folks that are currently
performing the COMSEC monitoring and RED FORCE missions.  AFCSC has
established a 9-week course to train these folks to accomplish the
ESST mission.  There are three courses that are currently
scheduled; the first course will start on 13 Jan 92 and run through
12 Mar 92.  Each course can accommodate up to 16 students.  Upon
completion of the three courses (Aug/Sep 92), the Air Force will
have five teams available to accomplish Electronic Security
Surveys.

We will provide updates on the ESST mission as we get closer
to having these teams ready for deployment.  Direct any comments or
questions to Mr. Fred Ramirez, AFCSC/SROV, DSN 969-3157 or Comml
512-977-3157.
TEMPEST Officer Education Seminar

The TEMPEST Officer Education (TOE) Seminar has been rewritten
to be in line with the latest version of the TEMPEST AFSSIs and
AFSSMs.  The TOE seminar is still available for presentation at
MAJCOM request and location.  In addition to MAJCOM requested
on-site training, AFCSC/SRMT will host TOE seminars in San Antonio. 
The first seminar will be held the week of 24-28 Feb 92, and the
second will be held the week of 9-13 Mar 92.  If you want to
attend, please submit your request through your MAJCOM TEMPEST
manager so it will reach AFCSC/SRMT NLT 5 Feb 92.

For more information concerning the TOE, contact Capt Willie
C. Pope or Mr David B. Parker, AFCSC/SRMT, DSN 969-3149 or Comml
512-977-3149.

GSA Computer Security Courses

GSA Interagency Training Center is offering the following
computer security courses in FY92:

Computer Security (Course No 500):  This is an overview of
computer security issues and security threats.  Federal, State, and
local government employees and government contractors involved with
managing, using, or operating microcomputers, minicomputers, and
mainframe computers within or under the supervision of a government
agency will benefit from detailed explanations of methods of
microcomputer crime prevention, including modem and network
security, national computer security policies, regulations, and
guidelines, and their implementation in government agencies; and
the roles/responsibilities of the National Institute of Standards
and Technology (NIST, formerly the Bureau of Standards), and the
National Computer Security Center.  Course length is 5 days; cost
is $300.  This course will be offered in the following cities:

Atlanta GA - 10-14 Feb 92 (500-02), l5-19 Jun 92 (500-07)
Chicago IL - 14-18 Sep 92 (500-12)
New York NY - 30 Mar-3 Apr 92 (500-04)
San Antonio TX - 18-22 May 92 (500-06)
San Diego CA - 20-24 Jul 92 (500-08)
San Francisco CA - 24-28 Aug 92 (500-11)
Wash DC - 13-17 Jan 92 (500-01), 9-13 Mar 92 (500-03), 4-8 May
92 
(500-05), 27-31 Jul 92 (500-09), 10-14 Aug 92 (500-10)

Computer Security Awareness Training (Course No 510):  This is
an overview of computer security which meets requirements of basic
awareness training under the Computer Security Act of 1987. 
Instruction explains computer terminology.  In addition, the
student learns about some of the vulnerabilities of computer
systems to various natural disasters (i.e., floods and tornadoes)
and human threats; details on how to improve computer security
practices within the working environment; and how to prevent,
detect, and report computer fraud, waste, and abuse.  Federal,
State, or local government employees and Government contractors who
are involved with managing, using, or operating microcomputers,
minicomputers, or mainframe computer systems within or under the
supervision of a government agency will learn about computer
hackers and computer viruses; computer fraud, waste, and abuse; and
the national policies and procedures associated with computer
security including the Computer Security Act of 1987 (Public Law
100-235) and the Office of Management and Budget Bulletin No 90-08. 
Course length is 3 1/2 hours (8:30 am to 12 pm); cost is $95.  This
course will be offered in the following cities:

Atlanta GA - 7 Feb 92 (510-05), 12 Jun 92 (510-11)
Chicago IL - 11 Sep 92 (510-15)
New York NY - 27 Mar 92 (510-08)
Salt Lake City UT - 21 Feb 92 (510-06)
San Antonio TX - 15 May 92 (510-10)
San Diego CA - 17 Jul 92 (510-12)
San Francisco CA - 21 Aug 92 (510-14)
Wash DC - 10 Jan 92 (510-04), 6 Mar 92 (510-07), 24 Apr 92
(510-09),
24 Jul 92 (510-13)

Please remember to include course code and session number for
each class on any form, letter, or purchase order you submit
requesting the above courses.

Direct any comments or questions to Ms Olivia R. Dominguez,
AFCSC/SRME, DSN 969-3154 or Comml 512-977-3154.