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 - Change directory to the PERF subdirectory. REGSTU - 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 - 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.