USAF Cryptologic Support Center Newsletter 03/10/93
FROM: AFCSC/SRM 10 Mar 93
250 Hall Blvd, Suite 347
San Antonio TX 78243-7063
SUBJ: THE CONNECTION Information Letter
TO: All ETAP Managers
1. Attached is the latest edition of our information letter, THE CONNECTION.
This issue will reach over 900 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 C4 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 C4 systems security and TEMPEST efforts, including COMSEC accounts.
3. The articles in this issue are entitled: "USER FRIENDLY" IS A RELATIVE
TERM, DATA REMANENCE, and RUNNING NOVELL'S NETWARE IN A MORE SECURE
4. Our regular columns are included. They are: AFOSI Computer Crime Cases,
COMSEC Incidents, Tool Box, and Bits and Bytes. Atch 1 contains another page
for the APL dated Oct 92.
5. Our C4 Systems Security Education, Training, and Awareness Branch welcomes
your suggestions, questions, and articles. Please send your inputs to Ms
Olivia Dominguez, AFCSC/SRME, 250 Hall Blvd, Suite 347, San Antonio TX
78243-7063, or call DSN 969-3154 or Comml 210-977-3154.
FELICIANO A. RODRIGUEZ 1 Atch
Chief, Security Policy and THE CONNECTION, 10 Mar 93
"USER FRIENDLY" IS A RELATIVE TERM
by SMSgt Charlie Bowden
Air Force News Center
Used to be the most a person might need to get into their mail
was a letter-opener. The stilleto-shaped tools ran the gamut from
the very plain to the ornate, with handles ranging from polished
metal to onyx or ivory.
In a worst-case scenario, a person could whip out a pocket
knife or just rip off the end to get the gold inside.
Times have changed. Today, seems like most folks need a
password to get their mail. It's a sign of the computer age.
You come to work and you turn on your computer. It asks for
your password. If you're lucky, and get it right, any new mail or
messages will flash onto the screen and tell you to do any
assortment of jobs, or maybe just that you have mail
Or perhaps there's some wry note from that fountain of
knowledge and power known simply as the sysops, a seemingly
vengeful person who sometimes leaves trite sayings and musings
intended to create a false sense of friendliness on the part of the
computer staring blindly at you.
For those of us who are deskbound, enslaved by the swivel chair
and the turbo-enhanced keyboard, passwords are like a ball and
chain clamped tightly around our ankles.
Oh, everyone understands the need for passwords. Audie Murphy,
the much-decorated hero from World War II, probably used them
regularly. Certainly, they are widely used in movies about combat
and sentry posts and perimeters and such. Beetle Bailey has great
fun using and abusing them in the funnies. But when your fingers
do the walking to your electronic mailbox, passwords are just the
tip of the proverbial iceberg under which lies a nest of
new-fangled terms that tend to leave one dazzled at the absurdity
of trying to speak, write, or even comprehend computerese.
Just the other day, while sitting in for that infamous sysops,
I noticed someone frantically trying to page the sysops on the
bulletin board. All the caller received was a terse, prepared note
each time citing the working hours of the sysops. The caller
then reminded the unthinking board that it was presently within the
timeframe of the sysops workday so, fool that I am, I broke in and
offered my assistance. Of course, when I hit the break key, a
message appeared to the caller saying something along the line of,
"Good day, this is the sysops, how may I help you?" As I watched
that little note I thought, What power. Me, the sysops, the wizard
that speaks across miles of empty space offering wisdom,
wisecracks, and, as the mood fits, sound advice.
Actually, no. This caller needed help cracking the sometimes
simple but confusing messages that greet users of computer systems
and had been told that the password was expiring, choose a new one.
The obvious question: How? I certainly didn't know, but I
remembered something my granddaddy used to say, "If you don't know,
admit it up front and avoid being stupid later."
Momma didn't raise no fools, so I grudgingly told the caller
the real sysops was on leave. But since we were in chat mode, or
letting fingers do the talking, we carried on a little conversation
that had both of us signing off with fond adieux.
Certainly, if they could, our two computers would be smiling
broadly at this conversation.
Then Private Bailey and the sysops conspired to make my day.
Turning from the bulletin board and feeling pretty good with
myself, I signed back onto my own system. I was greeted with a
note: "Your password has expired."
by Capt James B. Hiller
Have you ever wondered how to get rid of information on
computer media? Depending on the type of media and the
classification of the information, this can be a very difficult
Air Force Systems Security Instruction (AFSSI) 5020, Remanence
Security, deals with this problem. It provides the fundamental
concepts, policy, and rationale for remanence security as part of
the Air Force computer security (COMPUSEC) program. AFSSI 5020
also lays out specific methods of handling all kinds of
media--optical, semiconductor, and unique technologies, as well as
traditional magnetic storage. For completeness, it deals with
other peripheral devices, such as monitor screens, printers, and
printer ribbons. This article will focus on magnetic remanence
issues, leaving the others for another opportunity.
Unmistakably, the biggest problem we see in the Air Force is lack
of consideration for data removal when systems and networks are
being planned or purchased. It doesn't matter whether they are
big, small, embedded, deployable, general purpose, or
mission-unique. Data removal is not unlike death and taxes. Some
events that will require data removal are:
- Taking a system or component out of service. - Performing
maintenance on a media device that has failed or is not operating
- Changing the mission being supported by the hardware.
- Changing the organization that is responsible for managing or
operating the hardware, such as from government to contractor.
- Abandoning the equipment in a non-secure environment -
remember the US Embassy in Iran, the USS Pueblo, and Mount
Pinatubo? These situations really do happen to real people!
The only time it's too late to start thinking about remanence
is when you discover you need to remove information before the end
of the duty day. Otherwise, you can make a lot of headway in
solving your problems, even if the question was missed during the
budget cycle. AFSSI 5020 is structured to assist you in a very
Chapter 1 defines the scope of the document, organizational
responsibilities, and classification management concepts on which
remanence policy is based. The main idea here is that actual
declassification is an acceptance of risk based upon the
application and verification of thorough erasure procedures. The
erasure procedures must embrace the technical challenges presented
by the particular medium.
Chapter 2 provides the basic remanence security policy. It
specifies the difference between purging and clearing and the
purposes of each. It then describes these activities and their
relationship to declassification as an acceptance of risk. It
concludes with general handling requirements for all storage
devices regardless of type (optical, magnetic, etc.) or intended
classification. It is very important to be clear on these
concepts, as they form the basis for understanding the abilities
and limitations of the procedures beginning in Chapter 4. Another
key point here is that many of the policy requirements in this
chapter apply to devices storing unclassified information.
Chapter 3 discusses the elements of threat and risk as seen
from the remanence point of view. This is the "who cares" of the
whole remanence question. It provides a framework for
understanding the relationship between the value of information,
the cost of "destroying" it, the cost or ease of retrieving it, and
potential loss from compromise. Regardless of the size, type, or
use of a given system, you can apply the essence of this chapter
during the planning and maintenance processes to make sure
remanence issues and capabilities are covered.
The remaining chapters provide specific requirements and
procedures for various storage technologies. In some cases, you
can draft these words directly into your local operating
instructions. In other cases, there is enough latitude in the
requirements that you should specify local procedures which are
verifiably compliant with the requirements.
Once you've gotten a good feel for the flavor of AFSSI 5020,
you're bound to develop a variety of implementation questions.
Read AFSSI 5020 a few more times, as it is extremely versatile and
should answer most of your questions. If it falls short, contact
your Base C4 Systems Security Office or other COMPUSEC focal point
RUNNING NOVELL'S NETWARE IN A MORE SECURE MANNER
by 2Lt Scott Olson
Running Netware with the default factory settings is a lot
like buying a car with a high-tech security system and leaving the
keys in the door. Netware provides a great number of security
tools to increase the assurance in the security of the network, but
they must be set properly to be effective. With the workplace
moving toward an increasingly networked environment, it is
essential that careful consideration is given to the security of
these networks. This article concerns itself with the security
features of Netware, the industry leader in PC based networks. The
people who will benefit the most by reading this article are system
administrators currently running Netware v3.11. Those
administrators running v2.x can gain some insight to the security
features of Netware, but they must realize that v3.11 is
significantly more secure and in many instances recommendations
cannot be implemented with v2.x.
In order to proceed with creating a more trusted computing
environment, it is helpful first to simply examine the security
features that Netware offers its users. When using Netware the
first security feature that most users come into contact with is
the login sequence. The backbone of this sequence is the password
which should be used on all versions of Netware. All user accounts
should be set so that passwords are mandatory; otherwise, all other
attempts to secure the network become moot. Other password options
which enhance the security of the network are requiring users to
change their passwords periodically, requiring passwords of a given
length, and enabling intrusion detection. Intrusion detection is
the process where an account is locked for a given amount of time
after a number of failed login attempts. This account will be
locked for a specified amount of time or until the system
administrator unlocks it. The function of this feature is to
prevent someone from repeatedly trying to log in and guess some
user's password. In addition to locking the account, Netware gives
statistics about the address and time of the failed attempts which
can aid in determining the true nature of the detected intrusion.
A second security feature of the Netware login sequence is the
use of encrypted passwords. For versions of Netware starting with
v2.15c, encrypted passwords are used during the login sequence.
This is important because it prevents malicious users from
capturing passwords crossing the network in clear text. Novell
uses an encryption scheme which creates a different encryption key
for every login; therefore, playback of the encrypted password is
fruitless. It is important to note that this encryption scheme is
only used on PCs and that for logins from Macintoshes the password
is still passed in clear text.
A further security feature of Netware is the use of login
scripts. There is one system login script which is executed each
time a user logs into the workstation. There is an additional user
login script which is specific to each user. It is important for
every user to have a login script because in some of the earlier
versions of Netware there was no login script, allowing another
user to create one for them. This vulnerability exists because
user login scripts are kept in the mail directory. This
constitutes a distinct danger since actions such as granting
directory privileges can be automated through the login script. If
a login script already exists, it cannot be overwritten except by
someone with supervisor privileges.
In addition to protection of the login sequence, Netware
provides security for files and directories through designated
attributes and rights. Attributes are assigned to either files or
directories and tell Netware what actions can be taken with these
files. The complete list of attributes are: Archive Needed, Copy
Inhibit, Delete Inhibit, Execute Only, Hidden, Index, Purge, Read
Audit, Rename Inhibit, Shareable, System, Transactional, and Write
Audit. Not all of these attributes are available for every version
of Netware and some only apply to files. The Netware manuals
should be consulted for a description of the function and
availability of these attributes.
Rights to files and directories can be assigned to both users
which tell Netware which users are allowed to take certain actions
on a file or in a directory. The list of rights for versions of
Netware v2.2 and above are: Create, Erase, Read, Write, Modify,
File Scan, Supervisory, and Access control. The Netware manuals
should be consulted for the specific functions of these rights.
Another Netware security feature is the ability to assign
security equivalents to users and groups. This characteristic
could be better described as a vulnerability if it is mismanaged.
Netware has the ability to give all of the privileges of one user
to another by assigning them as a security equivalent through
SYSCON. This includes the ability to become supervisor security
equivalent. It is important for the system administrator to keep
an eye on security equivalents, especially for people who are
supervisor equivalent. When the program SECURITY is run, it gives
a complete list of all users that have supervisor equivalence.
A final, and one of the most overlooked, security concern for
Netware is file server security. It is essential to control access
to the file server. There are several methods available for the
network security to be compromised if a person has physical access
to the file server. Netware security starts with a secure file
While this article gives an overview of the generic security
Netware, AFCSC/SREC has produced a paper which includes a more
detailed step- by-step checklist of actions to take to run Netware
in a more secure manner. Any interest in this paper should be
directed to 2Lt Scott Olson, AFCSC/SREC, 250 Hall Blvd, Suite 140,
San Antonio TX 78243-7063, DSN 969-3134 or Comml 210-977-3134,
AFOSI COMPUTER CRIME CASES
by TSgt Dwayne L. Thomas
Destruction of Government Property, Unauthorized Access to
Article 134 of UCMJ
Motive: Personal revenge and vandalism
Duty Position: Systems Administrator, Military
An investigation was initiated after a CONUS-based research
center had reported that various files contained in the center's
mainframe computer had been altered. The subject (a Sgt assigned
as the Systems Administrator) had created a program that only he
was able to access. This resulted in the subject being able to
access, extract, and subsequently delete information without being
detected. Being the Systems Administrator, the subject had enough
knowledge of the passwords, audit trails, and software to
manipulate information at will. After the investigation began,
subject admitted fixing the computer so that no one else could
access the subject's personal program. The subject was upset with
upper management for not giving the amount of recognition due for
creating another program for the center's use. Subject stated that
months had been spent working on this program. Subject also felt
pressured because past job performance and two altercations at the
NCO Club might cause denial of reenlistment. Subject also was a
co-owner in a failing carpet and upholstery cleaning business and
stated that building a program that only one person could run would
make the subject important to the mission and increase chance for
Subject was fined 1 month's pay, denied reenlistment, and given
a bad conduct discharge.
BOTTOM LINE: It is vitally important that no one person have all
the knowledge about how to operate a system because if one day that
person is sick, quits, or dies, the organization will be in a world
of trouble. Some ways to prevent this are by assigning a primary
and alternate administrator, having continuity books available, and
having training sessions. Remember, computers are dumb machines
and are only as smart as the person who's programming them.
Wrongful Use and Conversion of Government Computer, Theft of
Government Property, Copyright Violation, Violation of Title 18 of
U.S. Code 641
Motive: Personal financial gain
Duty Position: Functional User, Military
An investigation was initiated after it was discovered that a
SSgt assigned to the Base Data Processing Facility had been
misusing government resources for personal profit. The subject was
working part time for a local contractor and was making profit by
making illegal copies of government purchased software. The
subject would take pieces of equipment from the duty section and
provide it to the contractor. The subject would copy the
government software and provide one copy to the contractor and keep
one copy so that it could be replicated and sold for more money.
After the investigation began, the subject admitted making copies
of the government software and contacting other companies to see if
they wanted to purchase copies of the stolen software. Subject
also admitted bringing disks in from home and running them on the
government systems for evaluation. Subject felt that even though
violations had occurred, accountability was questionable because
security briefings on the legalities involved with copying
government software had not been provided. The extra money had
helped the subject with a bad financial situation.
The subject resigned from his part-time job, was fined 2
months' pay, given a letter of reprimand, and placed on a control
BOTTOM LINE: Even though the Air Force purchases large amounts of
software from various companies, it is still subject to copyright
laws the same as any individual. We must continue to educate all
our personnel that this is a very, very serious offense and
complacency is not an acceptable excuse. Also, the risk of
introducing viruses from unauthorized software onto a computer
system can completely halt an operation. Never allow unauthorized
software into your duty section. Remember, taking chances like
this with the security of your system is like having a friend with
a drinking problem and for his/her birthday you give him/her a
shopping spree at a liquor store--it's a no-win situation!
by Mr Richard L. Davis
The total number of physical and cryptographic COMSEC incidents
reported within the Air Force for the following past 2 years were:
CY91 - 480
CY92 - 364
This Trend Summary will compare CY91 with CY92 COMSEC incidents
and the previous 6 months with the past 6 months. Data on
practices dangerous to security (PDS) will also be included in this
The total number of COMSEC incidents reported for the Jan-Jun
92 time frame was 191 as compared to the Jul-Dec 92 total, which
was 173. This is a decrease of 18 incidents.
The total and type of COMSEC incidents that occurred in CY91
and CY92 are:
Type Of Incident 1991 1992
Physical 432 330
Cryptographic 48 34
Total: 480 364
PDSs 74 116
Physical, cryptographic, and PDS COMSEC incidents are
categorized into the following types and totals (comparing the past
6 months with the previous 6 months):
Physical Categories: Jan-Jul 92 Jul-Dec 92 Totals
Loss Control Of COMSEC 53 63 116
Permanent Loss 49 32 81
Unsecured Safes/Workcenters 20 15 35
Destruction Irregularities 19 17 36
Lost Two-Person Integrity 7 14 21
Unauthorized Access/Use 13 4 17
Damaged Packages 4 6 10
Unauthorized Shipping Mode 5 4 9
Unauthorized Reproduction 2 2 4
Facility Construction 1 0 1
Totals: 173 157 330
Used Superseded Material 1 1 2
Extended Crypto Period 9 8 17
Unauthorized Use Of Material 6 3 9
Unauthorized Maint Performed 2 4 6
Totals: 18 16 34
Inadvertent Destruction 18 37 55
Inadvertent Opening 5 5 10
Physical Loss 3 9 12
Destruction Irregularities 13 6 19
Unauthorized Viewing 1 2 3
Material Pulled from Canister 1 0 1
Unauthorized Shipping Mode 2 0 2
Damaged Packages 1 0 1
Loss of Control of COMSEC 4 6 10
Forced Entry Into Safe 0 1 1
Unauthorized Reproduction 2 0 2
Totals: 50 66 116
Now that you have seen the total breakdown of all the COMSEC
incidents of the past 2 years and the two 6-month periods, let's
compare the previous 6 months with the past 6 months and show some
of our major problems (by categories) that have been and still are
the leading factors within the COMSEC incident world.
Loss of control of COMSEC has been the front-runner of COMSEC
incidents in the past 3 years. If you noticed, during the Jan-Jun
time frame, there were 53 incidents and in Jul-Dec there were 63.
This was an increase of 10 reported incidents. We are supposed to
decrease incidents--not increase them. The same types of
occurrences are still happening as before, just different personnel
are losing the handle. Material is still being left unattended in
hallways, government vehicles, and any place you can think of. As
you can see, there were 116 incidents of this type in 1992. We had
116 people go "brain dead" for some reason. This can be the only
logical reason for leaving their COMSEC material
Permanent loss of COMSEC material is still the second
runner-up. There was a decrease of 17 incidents when comparing the
two 6-month periods. During the first 6 months, there were 49
COMSEC incidents; and during the latter 6 months, there were 32,
with a grand total of 81 for the year. People are very, very
careful not to lose their money or paycheck, so why can't they
apply the same rules and hard-nosed controls when it comes to
protecting their COMSEC? The primary reason for lost COMSEC
material is not paying attention to details.
Unsecured safe/workcenter incidents decreased by five in the
latter 6 months as compared to the first 6 months. There were 20
reported incidents in the first 6 months, while 15 incidents were
reported for the latter months. People are still not checking
their safes at the end of the day. They are assuming it's locked
or secured. One day their assumptions will prove them wrong. The
COMSEC Managers must instill in all their users to take that extra
minute to check safes and stop the rushing. Remember, speed can
cause a COMSEC incident.
Destruction irregularities decreased by two for this reporting
period. There were 19 incidents for the last reporting period as
compared to 17 incidents this period. Single signatures on
destruction reports at the users' level, material claiming to be
destroyed but later found intact, and falsification of signatures
on destruction reports are some of the reasons for the 36 incidents
for the year.
Loss of two-person integrity was on the down swing, but somehow
it's back again and on the increase. The first 6 months there were
only seven incidents of this type reported. However, for the last
6-month period, we doubled, with a total of 14 incidents. Even
though the total count for 1992 was 21 as compared to 29 for 1991,
each 6-month period should show some type of decline, not double
its quantity from the last reporting period. It shows we
completely fell off track and must get back to where we started the
first 6 months. COMSEC users must be retrained on two-person
Unauthorized access/use showed a definite decline for this
period as compared to the last reporting period. For this period
there were only four incidents compared to 13 for the first
reporting period. This low count of incidents can be contributed
to unauthorized personnel being stopped at the door, individuals
being checked before any material is handed to them, and using the
proper material for the right purpose.
Damaged packages were due mostly to the inner wrapper splitting
open from the heavy weight of the material or to overpacking.
There was a total of six incidents for this period as compared to
our incidents for the latter period. The grand total for the year
was 10 incidents.
Unauthorized shipping mode for this period accounted for four
incidents, and the latter 6 months had five incidents. Even though
there were only 10 incidents for the year, shipping COMSEC material
by the correct mode of transportation is a must.
Unauthorized reproduction remained the same for both periods
with two incidents each. Users are beginning to understand that
they must obtain the controlling authorities' approval prior to any
Use of superseded material also remained the same for both
reporting periods with one incident each. Users must check their
COMSEC material before it's put into effect.
Extended crypto period had a total of 17 violations for the
year. There were nine incidents for the first 6 months, while for
the latter months there were eight incidents. Both terminal ends
are held responsible for incidents of this type. It seems that the
one end is waiting for the other to make the call, but somehow no
one calls until after the grace period.
Unauthorized use of COMSEC material declined by three this
reporting period. The majority of these incidents were caused by
individuals accidentally using the wrong COMSEC material on
equipment not authorized for its use. This type of incident could
be totally eliminated if individuals took the time to check the
COMSEC material before inserting it into the equipment.
Unauthorized maintenance performed on COMSEC equipment is a
definite, "no-no," so why do Mr Goodwrenchs who work on cars,
coffee pots, and toasters think they are crypto maintenance
personnel? There was a total of six incidents for the year.
During the last 6 months, we had four personnel who thought they
were maintenance personnel. Please inform them to leave COMSEC
equipment alone. PDSs are on the rise. Even though no case
numbers are assigned to these incidents, they show the Air Force's
weakness in handling their COMSEC material. Please notice the
category Inadvertent Destruction. People are destroying material
with their eyes shut. Perhaps they figure since it's the end of
the month, they must destroy something. COMSEC material should be
checked more than once before it is put into destruction status.
Make sure the right material is being destroyed.
All COMSEC incidents could be prevented if everyone followed
established procedures and rules for protecting COMSEC material.
Also, retraining some of our COMSEC users is a must because the
majority of COMSEC incidents are caused by the users. Every effort
must be made to continue educating every user within the Air Force.
Every COMSEC Manager knows who his/her weak links are. As
managers, you must go directly to those weak links and strengthen
them with knowledge about COMSEC. If we all work together and
continuously educate all COMSEC users, COMSEC incidents will be
POCs are Mr Richard Davis and Mr Ted Wesolowski, AFCSC/SRMP
(Air Force COMSEC Incident Office), DSN 969-4822 or Comml
TEMPEST Information Messages (TIMs) Sent
The following is a list of TIMs which were sent to each MAJCOM
TEMPEST Manager since the last CONNECTION was published. It is
provided to assist all ETAP managers. If you haven't received one
of these messages, please contact your base or MAJCOM TEMPEST
Manager for assistance.
TIM Number: 92-12
Subject: TEMPEST Officers Education (TOE) Schedule
DTG: 181300Z Sep 92
TIM Number: 92-13
Subject: TEMPEST Alert Message
DTG: 011300Z Oct 92
TIM Number: 92-14
Subject: AIG 8567 Recapitulation
DTG: 101330Z Dec 92
TIM Number: 93-01
Subject: New TEMPEST Policy Requirements
DTG: 281130Z Jan 93
AFCSC/SR Bulletin Board (C4IX)
The Air Force Cryptologic Support Center Securities Directorate
(AFCSC/SR) has established a bulletin board system (BBS) for the
exchange of command, control, communications, and computer (C4)
systems security information. The aptly-named C4 Information
Exchange (C4IX) is designed to provide an electronic medium of
communications between AFCSC/SR and the field.
Files will be available on the C4IX for download. These files
will be, but are not limited to, C4 systems security education
products, anti-viral products, and continuing updates to current
and future products. The C4 information letter, THE CONNECTION,
and its back issues will soon be among the first products C4IX
users will have access to. The Introduction to Computer Security
computer-based instruction (CBI) course is already on the board.
As they become available, advisories and bulletins from the Air
Force Computer Emergency Response Team (AFCERT) will be put in
their own area on the C4IX. On-line messages and bulletins will
inform users of new additions to the BBS. The C4IX is currently
a single-line BBS but is in the process of being upgraded. New
users must fill out a questionnaire defining who they are, where
they work, and their positions within their organizations. The
following are the steps needed to become a C4IX member:
- The caller must provide all the necessary information in the
new user questionnaire. An incomplete questionnaire will generally
prevent the new user from gaining full access.
- The BBS administrators will contact personnel in the new
user's organization to determine whether the new user requires
- After the potential user has been verified, the new user will
be entered onto the board or put in a holding queue, depending on
availability of system
- If granted, full access generally takes 2 working days.
- Once a user is a C4IX member, full regular access will be
given, and the user will be able to use the file and message areas
for up to 1 hour a day.
Communications software should be set to 2400bps, no parity, 8
bit words, and 1 stop bit, also known as 2400N81; once the system
becomes multi-line, modem speeds will increase to 9600bps. For
file transfer protocols, see the appropriate on-line help section;
currently, only ASCII, Kermit, and XModem protocols are supported.
As the BBS becomes updated and more sophisticated, so will the
The C4IX can be reached at DSN 969-4792 or Comml 210-977-4792,
24 hours a day, and the system operators (sysops) are generally
available for paging between 0700 and 1630 hours Central time,
Monday through Friday.
Restructure of C4 Systems Security Publication
As we progress in our security publication efforts, we are
pleased to note that most of the instructions and memorandums which
support security program maintenance and daily activities have been
completed. We have started to plan
second-generation updates and improvements for several of these.
One significant change we expect to see in the near future is
a restructure of the C4 Systems Security publication series to
conform with the Air Force Instruction/Pamphlet organization now
being implemented. New documents will be changed as they are
published, rather than by specific dates. Generally, Air Force
Systems Security Instructions (AFSSI) will become Air Force
Instructions (AFI) and Air Force Systems Security Memorandums
(AFSSM) will become Air Force Pamphlets (AFP).
We don't expect substantial content change based solely on the
restructuring, although policy and technical improvements that
would have been made anyway will be reflected. There will be some
instances in which closely related documents will be merged to
reduce the total number of publications and eliminate textual
As you receive new publications and continue implementation of
existing ones, we are always looking for your comments and
suggestions for improvement based on your experience in using the
publications. Send your suggestions through command channels to
AFCSC/SRMC for computer security publications, AFCSC/SRMP for
communications security publications, AFCSC/SRMT for TEMPEST
publications, and AFCSC/SRME for the ETAP publication. Please
direct any comments or questions to Mr Patrick Hedges, AFCSC/SRMC,
DSN 969-3180 or Comml 210-977-3180.
1993 Computer Security (COMPUSEC) Workshop
We are pleased to announce that the 1993 COMPUSEC Workshop for
MAJCOM, FOA, and DRU representatives will be held in San Antonio TX
from 5 to 7 May 93. The focus of this workshop is to provide a
working-level exchange on COMPUSEC issues, problems, successes, and
future needs between AFCSC/SR personnel and the various MAJCOMs and
staff agencies. Specific information and travel instructions are
contained in AFCSC/SRM message 041550Z Feb 93, Subject: C4S
Security Education and Training Working Group (CETWG) Meeting and
1993 Computer Security (COMPUSEC) Workshop.
To construct a dialog that is beneficial for the COMPUSEC
practitioner, we have asked the MAJCOM and staff agency focal
points to send topic ideas to AFCSC/SRMC by 22 Mar 93. The range
of topics can be virtually anything of importance in the daily
management and execution of COMPUSEC activities: system
acquisition, COMPUSEC management in the operations and maintenance
phase of a system, successes and failures in implementing the new
publications, needs for software tools, problems in security test
and evaluation, system design issues--anything that is a help or
hindrance in realizing an effective COMPUSEC program.
We'd like to be able to invite people from every Air Force unit
and office. Unfortunately, to keep the forum at a workable size,
we're not able to do that. What we'd really like to see is for
computer security and system acquisition or management people at
every level to forward COMPUSEC concerns, issues, and suggestions
for improvement through command channels to AFCSC/SRMC between now
and 22 Mar 93. We'll review these inputs internally and bring the
right COMPUSEC experts to the workshop to discuss them with the
The 1993 COMPUSEC Workshop is just one of several opportunities
this year to work together to improve Air Force system security
programs. Please direct any comments or questions to Capt Jim
Hiller, AFCSC/SRMC, DSN 969-3180 or Comml 210-977-3180.
Air Force Policy Directive (AFPD) 33-2
This policy directive addresses Command, Control,
Communications, and Computer (C4) Systems Security. The
publication of this document, scheduled for 15 Mar 93, supersedes
AFR 205-16, AFR 56-1, AFR 56-16, and AFR 56-18. It integrates the
disciplines of COMPUSEC, COMSEC, TEMPEST, and ETAP. The policy is
high level and succinct and provides the framework for the
specialized publications addressing each discipline. The directive
also provides the metrics for measuring compliance with the policy.
Please address any comments or questions to Mr Craig Andrews,
AFCSC/SRMC, DSN 969-3180 or Comml 210-977-3180.
The New AFSSI 9100 and Return of RCS Reporting of ETAP
Training AFCSC/SRME completed the final draft of AFSSI 9100 and
the document has been forwarded to the TIC for final editing. We
are attempting to have the instruction published and sent to PDO
before the end of Mar 93.
Due to the numerous policy changes in the C4 Systems Security
community during the last year, the draft AFSSI 9100 has gone
through numerous changes. Initially, the Communications-Computer
Systems Security ETAP Ancillary Training Utilization Report
(RCS:HAF-SCT(A)8902) requirement, which used to be in AFR 56-18,
was deleted from AFSSI 9100. The RCS report has been included in
the new AFSSI 9100. Using Air Staff guidance, we developed metrics
for all of the security disciplines to include ETAP. The
information will be used to obtain a better feel of the Air Force's
The new RCS report will be called C4 Systems Security ETAP
Training Utilization Report (RCS:HAF-SC(A)8902). The reporting
procedures will be similar to the procedures outlined in AFR 56-18.
POC is Capt Johnson, AFCSC/SRME, DSN 969-3154 or Comml
New TEMPEST Policy Changes
AFCSC/SR sent two letters, both dated 2 Dec 92, to all MAJCOM
TEMPEST Managers. The first letter superseded AFCSC/SR letter, 23
Jul 91, Subject: TEMPEST Policy. The second letter superseded
AFCSC/SR letter, 4 Nov 91, Subject: TEMPEST Policy. The letters
informed the Air Force TEMPEST community about the renumbering of
AFSSI 7000 and AFSSI 7001 with the rescinding of AFR 56-16. The
new AFSSI 7001 (formerly 7000) and new AFSSI 7002 (formerly 7001)
were sent with each accompanying letter. The letters instructed
each MAJCOM TEMPEST Manager to distribute both the letter and the
new document to all subordinate units.
Please address any comments or questions to Mr Jose Linero,
AFCSC/SRMT, DSN 969-3149 or Comml 210-977-3149.
COMSEC Inspection Reports
Ever wondered what happens to that COMSEC Inspection Report you
got? No, unfortunately, it didn't just go away. It found its way
to the good folks at AFCSC/SRMP. MSgt George Bird, TSgt Sonja Fox,
and SSgt Maria Short of the COMSEC Support Section review all Air
Force Command COMSEC Inspection Reports. Using the discrepancies
identified in each report, they prepare an annual COMSEC Inspection
Trend Analysis Report.
This report, along with those from the COMSEC Insecurity
Office, are used to give a snapshot picture of the COMSEC posture
of the United States Air Force. The report is forwarded to the Air
Staff, where it is used to brief the Chief of Staff on the current
compliance level of security standards.
So, you want to know how you're doing? Well, last year's
results tell us you're having difficulty complying with accounting,
inventory, emergency plans requirements, training, and operating
instructions (OI). If we eliminate the problems with training and
with OIs, the remainder should go away. It stands to reason that
if you have detailed and up-to-date OIs and are performing good
training from these OIs, there will be no discrepancies.
Sounds easy enough in theory. In reality, you have to work at
it. You have to keep your OIs up to date, and you have to educate
and train all COMSEC users on proper procedures. Once fully
trained, keep everyone up to par with refresher training and call
your most knowledgeable Base COMSEC Manager for a staff assistance
visit. They will gladly come and tell you how you are doing.
After all, better they find it than a MAJCOM inspection team
because if the inspection team finds it, that's when we go to work
on the report to the Chief! POC at AFCSC/SRMP is MSgt George Bird,
DSN 969-4822 or Comml 210-977-4822.
Air Force Electronic Key Management Working Group
The Air Force Electronic Key Management Working Group is
planning its next session at AFCSC, San Antonio TX, on 22-26 Mar
93. Many topics covering the upcoming changes in the Air Force
COMSEC account management program will be discussed at this
semiannual forum. A prime subject of interest is the proposed
centralizing of the USAF COMSEC Inspection Program. Rising travel
costs and manpower reductions have forced the Air Staff and COMSEC
program managers to look at several alternatives to the current
program. Four options are being studied by all meeting
- AFCSC become the central agency responsible for performing
all CONUS account inspections on a 2-year cycle. Overseas accounts
will be serviced by OL personnel stationed in the Pacific and
- The USAF/SC Field Operating Agency (FOA) at Scott AFB assume
this role with similar OL locations in the overseas areas.
- Both agencies share the CONUS account inspection program
based on geographical proximity and the Air Staff designated lead
office set up overseas OLs for the OCONUS accounts.
- Keep the program at the MAJCOM level.
Based on the decision reached at the working group, the final
program should commence operations in FY94 when appropriate funding
and personnel resources are allocated to the selected agency(ies).
We will keep the C4 systems security community posted on further
developments in this critical phase of the USAF COMSEC account
Please address any comments or questions to MSgt George Bird,
AFCSC/SRMP, DSN 969-4822 or Comml 210-977-4822.
The prescribing directive for COMSEC policy (AFSSI 4100) has
recently been published and is now available for distribution.
Although it is entitled "COMSEC Program," it really contains policy
criteria applicable to the entire Air Force COMSEC program.
AFSSI 4100 supersedes AFR 56-1, Signal Security Policy, dated
3 Nov 86, and will implement the new Air Force Policy Directive
(AFPD) 33-2, Command Control, Communications, and Computer (C4)
Systems Security Program, currently in the final editing process at
AFSSI 4100 prescribes procedural policy for securing and
protecting telecommunications systems and COMSEC equipment and
material. It affects development, procurement, installation, and
operation of all equipment used to process classified and sensitive
information within the Air Force.
There are plenty of copies available; so start now to order
your copy through normal PDO channels.
Please direct your comments or questions to Mr Ralph Tejeda,
AFCSC/SRMP, DSN 969-4822 or Comml 210-977-4822.
MAJCOM TEMPEST Managers Conference
There is a MAJCOM TEMPEST Managers Conference planned for 25-27
May 93 at Kelly AFB TX. Purpose of the conference is to discuss
the latest changes in National TEMPEST policy and the Air Force
response to the changes.
Please direct any comments or questions to Mr Dwight Bohl,
AFCSC/SRMT, DSN 969-3149 or Comml 210-977-3149.
C4 Systems Security Education and Training Working
The next CETWG for MAJCOM, DRU, and FOA ETAP managers will be
held on 3-4 May 93 at the Lexington Suites Hotel in San Antonio TX.
The CETWG will be held in conjunction with the COMPUSEC Working
Group which is being held on 5-7 May 93. AFCSC/SRM message 041550Z
Feb 93, Subject: C4S Security Education and Training Working Group
(CETWG) Meeting and 1993 Computer Security (COMPUSEC) Workshop,
contains registration details.
Just in case you didn't receive the message, here are the
important bits. Please send the attendee's name, rank/grade, duty
title, full official mailing and message address, DSN and
commercial telephone numbers, smoking/nonsmoking room preference,
and requested check-in and check-out dates to our POC. We must
receive this information, in writing, no later than 19 Mar 93.
There is no need to send clearance information; but if you need to
speak to a specific individual, please note that also.
We encourage all ETAP managers to voice their concerns to their
MAJCOM ETAP manager. We encourage each MAJCOM, DRU, and FOA ETAP
manager to attend this working group. We have a lot of useful
information to pass along and need your input on computer security
courses being developed. There will be representatives
from OPSEC, COMSEC, and TEMPEST there as well.
If you have any questions or comments, please contact TSgt Lois
Adrian-Hollier, AFCSC/SRME, at DSN 969-3154 or Comml 210-977-3154.
To the best of our knowledge, the text on this page may be freely reproduced and distributed.
If you have any questions about this, please check out our Copyright Policy.
totse.com certificate signatures