Air Operations Center (AOC) Standard Operating Procedure (SOP)
Twelfth Air Force (12AF) Air Force Forces (AFFOR)
CONTINGENCY THEATER AUTOMATED PLANNING SYSTEM
A. The Contingency Theater Automated Planning System (CTAPS) was established in 1987 to meet a CAF requirement for a rapidly responsive Command, Control, Communications, Computers and Intelligence (C4I) system to automate and connect elements of the TACS, connect to other organizations or agencies, permit sharing of common data, and generate, disseminate, and execute tasking orders and coordination messages. The program management directive was to modernize and/or replace existing AOC and Air Support Operations Center (ASOC) equipment and to develop a unit level capability. The program has since expanded to accommodate the requirements of all ground elements of the TACS.
B. The program is being bundled as the Theater Battle Management Core Systems (TBMCS) after the CTAPS V5.2 release. At the AOC level, this program broadens the scope to include the Combat Intelligence System (CIS), the airlift planning and execution system (Command and Control Information Processing System - C2IPS), the MCE Automated ATO (AATO), and other unit level initiatives.
A. The CTAPS program philosophy is based on the findings of a 1986 Air Force Studies Board theater battle management study, which recommended using a rapid prototyping/evolutionary acquisition process that exploits existing technology. Applying this philosophy to the development of computer systems at the AOC, ASOC, and units, CTAPS adopted a development and integration methodology based on a common core computer system. This common core system, known as the CTAPS core, has the following characteristics:
(1). The core is based upon current open system standard hardware and software.
(2). The core provides mechanisms for the integration of mission-oriented software applications. The CTAPS core itself provides no mission-oriented functions. Mission systems are created and tailored by integrating a specific mix of applications into the core.
(3). The core continually evolves to exploit emerging standards and technologies and to meet the needs of all integrated applications.
B. The CTAPS core provides the following fundamental components:
(1). Host, network, database, and security configuration software that work in concert with commercial off-the-shelf (COTS) products and an application distribution manager to provide a nearly transparent distributed computing environment.
(2). A configurable support environment for functional user duty positions that include discretionary access profiles, a top-level human-machine interface (HMI), and communication utilities.
(3). US Message Text Format (USMTF) message parsing and preparation that can be used to send and receive messages over any available communications network.
C. The mission applications can be tailored to meet the requirements of the individual command and control element (AOC, ASOC, Wing Operations Center (WOC), CRC, etc.). The bulk of CTAPS mission applications are focused on developing, disseminating, and executing tasking orders (ATO/ACO); they include (when integrated with CIS capabilities) intelligence management, targeting and weaponeering, and air battle planning, dissemination, and execution software. Some of the major mission applications are:
(1). Advanced Planning System (APS). Provides an automated tool to develop air battle plans and taskings for building the ATO. Imports order-of-battle (OB) and TNL data from the intelligence systems (ICM/RAAP/JMEM) and airspace data from the Airspace Deconfliction System (ADS). Outputs to the Computer Assisted Force Management System (CAFMS/CAFMS-X) for execution.
(2). Airspace Deconfliction System (ADS). Provides airspace planners with capability to build an ACO from Combat Airspace Deconfliction System (CADS) or direct Airspace Control Measures (ACM) inputs. Also used in ATO execution to accommodate changing battlefield situations.
(3). Computer Assisted Force Management System (CAFMS). The original seed program around which CTAPS evolved. Provides for planning, dissemination, and execution of the ATO. CAFMS is being updated to an X-Windows/MOTIF version called CAFMS-X in CTAPS V5.2.
(4). Force Level Execution (FLEX). Scheduled to replace CAFMS-X in TBMCS V1.0, FLEX will provide automated tools to import the entire air battle plan from APS and execute the ATO. Currently in development, with a projected fielding of FY 97.
(5). CIS Intelligence Applications. Provides intelligence support to the AOC. The Data Manipulation and Message Analysis (DM/MA) applications allow for data correlation/fusion, situation assessment/display, and order-of-battle development. Together with the Automatic Associator (AA - Constant Source), the Improved-Many-On-Many (IMOM), JMEM, RAAP, and the 5D module, they form the Combat Intelligence System (CIS) bundled software.
(6). Joint Munitions Effectiveness Manual (JMEM). Aids the intelligence planner's weaponeering functions to match air battle plans with proper munitions.
(7). Rapid Application of Air Power (RAAP). The main targeting module in CTAPS; allows planners to select targets/target sets using the ICM database and perform target analysis. Works in conjunction with JMEM to develop the weaponeered TNL, which is used by APS to develop the ATO. RAAP will be bundles as part of CIS in future releases.
(8). 5D. Imagery server within CIS.
(9). Theater Integrated Situation Display (TISD)/JTIDS-Modular Air Operation Center (MAOC) Integration (JMI). Provides for an integrated battlefield display of track data using Tactical Data Information Link (TADIL) A or B (TADIL A/B) links. System will transition to the JMI program which, when coupled with a Class 2 TADIL-J receiver terminal, will provide TADIL-J processing and display capability. The Battlefield Situation Display (BSD) software may incorporate the functionality of TISD/JMI in future versions of CTAPS.
D. The AOC deploys in additive increments based on the level of effort required. Each increment builds upon the lower level increment(s) (i.e., the second increment requires pre-deployment of, or deployment in conjunction with the first increment). CTAPS equipment capabilities in AOC deployable increment unit type codes (UTC) are as follows:
(1). Quick Reaction Package (QRP). Supports a CTAPS host minimum level of effort of 300 to 500 missions.
(2). Limited Reaction Package (LRP). Supports a minimum level of effort of approximately 1000 missions.
(3). Theater Reaction Package (TRP). Handles a 2000+ mission ATO level of.
(4). The current specific numbers within each package can be found in Annex A to this chapter (does not include the SCI LAN CTAPS allocation). While these numbers are tailored to meet specific JFC/JFACC/exercise/contingencies/ operations guidance and objectives, they represent a baseline for initial planning purposes. Additionally, they do not reflect remote terminal requirements which are specific to each exercise and/or operation. Refer to the USAF War and Mobilization Plan (WMP) and Logistics Detail (LOGDET) documents for the latest manpower and equipment data on specific UTCs.
(1). If sufficient time exists prior to deployment of forces, whereby augmentation forces are identified and can be trained before hand, 12 AF/DOY will coordinate for initial core CTAPS training (i.e. EMAIL, System Message Alerts (SMA), LOGIN, remote ops, etc.). The individual sections augmented will train the augmentee in the specific mission software (i.e. APS, ADS, RAAP, etc.).
(2). If forces deploy without previous training:
a. Each AOC division chief or center director is responsible for training their personnel (to include augmentees) in the proper utilization of the CTAPS software corresponding to their function. Unit training plans need to be in place to accommodate this contingency.
b. If required, mobile training teams (MTTs) may be constituted from AOC personnel to go out to geographically separated sites and train key personnel at these locations as to the proper method of installation and operation of CTAPS remote terminal equipment. This is not a preferred option by any means as it can potentially have a major impact to the AOC's ability to maintain its own operational capability. However, this can be alleviated by aggressively pursuing remote CTAPS operator training during peacetime.
B. CTAPS Access. See Annex B.
(1). Read/Write Authorization Levels. See Annex D.
(2). Data backup Procedures. The frequency of system-wide database backups will be directed by the AOC TBMCS System Manager or his designated representative. This decision is based on the AOC's level of effort, as the time between backups translates to potential data lost if not backed up, and a trade-off on system availability to users (while applications are being backed up). For an LRP level of effort, backups at approximately every eight hours would be appropriate. Certain modules such as RAAP and APS have internal module backup capabilities which are the primary means to backup their data. For these modules, the respective division will designate a data manager within their section to establish application specific data backups in coordination with the system-wide backups.
(3). Alternate AOC CTAPS Procedures.
a. All functions of the AOC utilizing CTAPS will establish backup procedures in case the primary CTAPS system fails for prolonged periods of time. An alternate mini-system is provided for (see Annex A) that provides for limited capability to support the ops/plans/intel functions of the AOC. However, priority will be given to ATO generation, followed by ATO execution. SYSAD maintains the system populated with the latest backup from the main system as a precautionary measure. In the case of APS, the Chief of ATO Production (or his representative) will ensure APS is maintained up to date with the latest backup database.
b. In case of a CTAPS system failure, SYSAD will initiate diagnostic actions to determine the extent of the problem. If a fix is anticipated in less than one hour, efforts will be concentrated to fix the main system. If more than one hour downtime is anticipated, parallel efforts will be conducted to fix the main system and the alternate system will brought on line. Once the alternate system is on line, the AOC Director or his designated representative will direct whether to wait further for the main system or switch over to the alternate system.
C. Remote Users. Organizations requesting temporary distribution of CTAPS systems for participation in exercises/contingencies/operations as remotes interconnected to the main AOC system must accept the responsibilities outlined in the Memorandum of Understanding (MOU) contained in Annex E to this chapter. A responsible individual will be designated by the participating unit in advance of system distribution. This individual will be required to fill out, sign, and return the MOU to 12 AF/DOYI prior to the system being shipped to the user. The MOU can be transferred via Email or FAX.
D. TBMCS System Manager will, as a minimum perform the following:
(1) As the AOC TBMCS System Manager, he/she will, in coordination with SYSCON, be responsible for the establishment and maintenance of the AOC’s TBMCS.
(2) Prioritize efforts relative to TBMCS based on inputs received by the supported AOC functional areas. This includes all SYSAD requests received during the normal conduct of operations.
(3) Establish and manage the TBMCS Ops Desk (formerly the CTAPS Help Desk) within the AOC.
(4) Manage the MC Form 37 (Computer Software Change Request) process within the AOC. Together with the functional area chiefs/directors the TBMCS System Manager will consolidate, validate, and prioritized the change requests for higher headquarters submission. All priority one (1) Form 37s will be approved by the AOC Director, and processed and submitted within 24-hrs of the occurrence of the problem generating the form.
ANNEX A - AOC CTAPS Allocation by UTC
ANNEX B - CTAPS Access
ANNEX C - Sample SYSAD Support Request
ANNEX D - Read/Write Authorization Levels
ANNEX E - Remote Ops MOU
ANNEX F - Declassifying CTAPS/TBMCS Hard Disks
ANNEX B TO CHAPTER 10
A. Every CTAPS user has to establish a unique user account within the CTAPS network. Within the AOC, each division chief or center director (or their in-writing designated representative) must certify in writing for each exercise/contingency that all individuals (to include augmentees) in their respective functional area have the necessary clearances and have received the proper positional CTAPS and security training. The format in Appendix 1 can be used to certify large number of individuals requiring access and to establish user accounts at one time. Additionally, the form included in Appendix 2 can also be used to certify individual users.
B. IAW DoD 5200.28-STD, access to the CTAPS network must be protected by the establishment of individual LOGINs and passwords. Each user will be given an initial password which must be changed immediately upon initial login to the system. Failure to do so, violates DoD guidance and may result in de-certification of the CTAPS system and mandate disconnecting with all other interoperating systems (AUTODIN, GCCS, AFATDS, JWICS, etc.). Refer to Appendix 3 for password selection criteria.
A. AOC Functional Area Chiefs or Directors.
(1). It is the responsibility of each AOC functional area Chief or Director to ensure their personnel are properly trained in their duties and responsibilities of their positions within the AOC.
(2). The signature and or initial on the user account request, certifies that the individual(s) for whom the account(s) is (are) being established has (have) or will receive the appropriate CTAPS positional and security training prior to being granted access to CTAPS.
(3). Message Release Authority (MRA) for AUTODIN message traffic will be delineated in a separate letter. See sample letter in Appendix 4 to this annex.
(1). Users must understand the classified nature of the CTAPS architecture, and ensure all information is protected as classified until downgraded by appropriate authorities.
(2). Once a user has gained access to a terminal, he/she must control that terminal. When necessary to be away from the terminal, the user must either use the passworded "Lock Screen" utility or log out of the terminal.
C. TBMCS System Manager will validate and deconflict all CTAPS account requests.
3. UPDATE PROCEDURES.
A. Normal in garrison process. Normally, users account maintenance is performed once a month unless the TBMCS System Manager deems it appropriate to make more frequent updates due to the level/number of changes anticipated.
(1). Functional area POCs will submit unit inputs for LOGIN account maintenance to the TBMCS System Manager NLT the last duty day of the month.
(2). The TBMCS System Manager must validate and deconflict all inputs and submit to SYSAD a consolidated list (EXCEL format - see Appendix 5) with all additions, deletions, or changes NLT than two duty days after receipt of the inputs.
(3). SYSAD will have three duty days after receipt from the TMBCS System Manager to update the user accounts on the master user configuration file and then transfer the file to the appropriate systems.
(4). Priority for updates will be given to the classified Go To War (GTW) system in buildings 70/75. Once the GTW system is updated, the second priority will be given to the 12 AF TBMCS Training System (Bdlg 70, room 216). Other systems, such as the unclassified DOX mini-LAN, will then be updated.
B. Pre-deployment process. As part of any operation, a concerted effort will be made to update the user accounts prior to any deployment, exercise, or operation. As part of this process a clear distinction must be made by the requestor as to whether an account being established is for a permanent party individual or an augmentee as augmentee accounts are not distributed across the 12 AF CTAPS/TBMCS systems (only on the copy of the master file being used for the deployment/employment system).
(1). If enough advance notice exists, functional area POCs will submit any updates to the TBMCS System Manager NLT three weeks prior to STARTEX. SYSAD will take steps to update an exercise master database file which will be used to populate only the employment system.
(2). If little or no advance notice exists, functional area POCs will submit any updates to the TBMCS System Manager as soon as possible, but NLT the deployment of the SYSAD personnel increment. The TBMCS System Manager/SYSAD will use this information to update the employment system during the system setup and configuration phase of the operation.
C. Employment phase process.
(1). Once the system is operational, updates will be submitted daily by the functional area POCs IAW Appendix 1 or 2 to the TBMCS Ops Desk for processing.
(2). The TBMCS Ops Desk will consolidate all account maintenance inputs and validate/ deconflict the requests. Depending on the level of changes, validated requests or a consolidated spreadsheet (see Appendix 5 this Annex) will be provided to SYSAD to update the system.
(3). Normally, user account maintenance is accomplished once a day during the night shift. This is to minimize system down time which will impact system available to the users. System update time will coordinated by SYSAD with the TBMCS System Manager so as to minimize the operational impact of the system on the on-going operation.
APPENDIX 1 - Sample Group CTAPS User Account Request Ltr
APPENDIX 2 - Sample Individual CTAPS User Account Request Form
APPENDIX 3 - Password Selection Criteria
APPENDIX 4 - Sample CTAPS/TBMCS MRA Designation Letter
APPENDIX 5 - Sample LOGIN Account MX Spreadsheet
APPENDIX 1 TO ANNEX B TO CHAPTER 10
SAMPLE GROUP CTAPS USER ACCOUNT (LOGIN) REQUEST LTR
S A M P L E
MEMORANDUM FOR TBMCS Help Desk
FROM: Combat Ops
SUBJECT: CTAPS User Accounts
1. Request the establishment of the following user accounts within the Combat Ops duty group position:
NAME RNK LOGIN DG/DGP
John M. Smith Lt noname CO/CAS
Jane M. Jones Lt yesname CO/DDO
2. I certify that the individual(s) has(have) the proper clearance(s) and will receive the positional CTAPS training required for the designated duty group position prior to having access to the equipment.
AM I. JONES, COL, USAF
Chief, Combat Ops Div
S A M P L E
APPENDIX 2 TO ANNEX B TO CHAPTER 10
SAMPLE INDIVIDUAL CTAPS USER ACCOUNT (LOGIN) REQUEST FORM
AOC CTAPS LOGIN REQUEST
RANK & NAME: (1)_________________________________ LOGIN: ________________________
DUTY GROUP (DG)/DUTY GROUP POSITION (DGP): __(2)_/__(3)__________
(Example: Combat Ops/Status Technician. Check with your AOC functional area chief (Chief, Combat Ops, Combat Plans, Combat Intel, SYSCON, LRC, CSSC)
LOGIN will normally be up to eight (8) characters, built by using up to seven (7) letters from your last name and your first initial (Example: Lt Rodriguez, J. M. would have a LOGIN of "rodriguj"). The LOGIN is all in lower case letters. (NOTE: PASSWORD. Your initial password will generally be given out by your functional area POC and must be changed upon initial login onto the system. This is a mandatory requirement due to the classified nature of AOC and CTAPS ops. Once changed, no one outside yourself (to include SYSAD) will have access to the system on your LOGIN without your password, so don’t forget it. If you forget your password it will require SYSAD intervention to re-initialize your LOGIN which based upon SYSAD workload may not occur as quickly as you may desire.)
APPROVED BY: __(4)______________________ DATE/TIME: __(5)_______________________
RETURN THIS COMPLETED FORM TO THE TBMCS HELP DESK
FOR TBMCS HELP DESK/SYSAD USE ONLY:
TBMCS HELP DESK VALIDATION_____(6)___________________________
Database Updated By: ___(7)___________________________ Date/Time: _(8)____________________________
(1). Rank and name of individual to be assigned the LOGIN. Augmentees will generally be given LOGINs and passwords IAW the note above.
(2)/(3). Full description name or initials (Combat Ops/ Senior Operations Duty Officer or CO/SODO)
(4). Chief or Director of the AOC functional area or his/her designated representative. This individual is certifying that the user has been or will be properly trained in all the CTAPS positional requirements.
(5). Date/time of request
(6). Initial or name of validating authority from the TBMCS Help Desk.
(7). SYSAD individual who updated the CTAPS database with the new user account
(8). Date/time database was updated
(9). Selection of passwords will be IAW 12AF AOC SOP, Chapter 10, Annex B, Appendix 3
APPENDIX 3 TO ANNEX B TO CHAPTER 10
PASSWORD SELECTION AND PROTECTION POLICY
1. PASSWORD SELECTION:
A. Passwords must be at least eight (8) but no more than ten (10) characters in total length. Passwords must contain at least one of the following character types:
- upper case alphabetic [A-Z] character
- lower case alphabetic [a-z] character
- numeric [0-9] or special [ ~`!@#$%^&*()_-+=<>?,/:";’\ ] character
B. Password must not be English words preceded or trailed by a numeric or special character(.3. Passwords must not contain more than one repeated character, example:
eaBae2 Invalid; both "e" and "a" are repeated
Eabde1 Valid; only the "e" is repeated
NOTE: The above 3 restrictions are automatically enforced by the password entry process. However, the entry process WILL allow passwords to be input that are based on poorly selected data, for instance: Your first name is John and you work in 12 AF, therefore you select a password of "John12AF". Such a password (while it meets minimum legal criteria) would be easy for a hacker to break within a matter of minutes, since names and units of assignment are easily obtained information, available to practically everyone.
C. Passwords should not be easily guessed due to being based on data easily associated with the individual, such as birthdays; wife's, pet's, or children's names; office symbols; etc. Intruders (hackers) typically utilize inside information about the individual, their workplace, their personal life, etc., and feed this information into sophisticated password cracking programs to covertly break into password protected accounts.
D. A password that is impossible to remember is just as bad as a password that is easy to crack - to remember a password composed of a meaningless string of characters you will ultimately record this password somewhere where a hacker can discover it. You must be able commit your password to memory, so plan accordingly. To select a password that is easy to remember yet based on random values (and therefore virtually impossible to crack) choose one of the following methods:
(1). Start with a phrase or event that has a meaning to you. Then reduce the phrase or event to an acronym that can be easily remembered. Examples:
"My dog weighs 50 pounds" "Mdw50#"
"new years eve 91 at Dallas" "nye91aD"
(2). Select a common word that has special meaning to you, for instance "Aardvark" (you used to fly F-111s).
(3). Offset the letters on the keyboard by shifting 2 keys to the right for each letter in "Aardvark", you then have: "ddygndy"
(4). Capitalize the first letter in the derived password to adhere to restriction #1, you then have: "Ddygndy"
(5). Your derived password is now based on random values AND is extremely difficult to crack by a potential intruder, even if aided by insider knowledge and sophisticated hacking tools.
NOTE: You could have shifted one/two/three keys right/left/up/down on the keyboard and achieved similar results. The key aspect of building derived passwords is to inject randomization into the selection process.
2. PASSWORD PROTECTION:
A. Treat ALL passwords as if they protect classified information. NEVER write down your password, it must be committed solely to memory. Do not share your password with other personnel, whether they are authorized access to the TBMCS system or not. If they require access, they must have their own account established.
B. An initial password assigned to your NEW account by SYSAD MUST be changed to a unique password known only to you upon your initial use of the account (LOGIN). Failure to do so could subject your account to being disabled.
C. If you maintain an account on a static system, the password must be changed at a minimum every 90 days. You may change your password whenever you like, but not more than once in a 24 hour period.
D. Do not utilize processes or services that require you to input your account and password across a network, such as ftp or telnet. These processes are potentially insecure, and may allow your password to be un-encrypted while transported across the network. A hacker could gain covert access to a portion of your local or wide area network, and passively collect network traffic packets to gain unauthorized access to accounts if un-encrypted passwords are present in data packets on the network.
E. If passwords are forgotten, they may not be recalled from the system because they are stored in one-way encrypted form. If this occurs, SYSAD must recreate a new initial password (re-initialize) for the user account.
F. Passwords should be changed whenever the user suspects the password has been compromised. All actions within the CTAPS processing environment are auditable, and are associated back to the user account that initiated the action. Any compromise of a user ‘s password, could result not only in a breach of security and compromise of the system's integrity, but also in the user being attributed with actions not taken by that individual.
APPENDIX 4 TO ANNEX B TO CHAPTER 10
SAMPLE CTAPS/TBMCS MRA DESIGNATION LTR
S A M P L E
MEMORANDUM FOR CTAPS/TBMCS Help Desk
FROM: Combat Ops
SUBJECT: CTAPS MRA Designation
1. The following Duty Group/Duty Group Position(s) (DG/DGPOS) are authorized to have AUTODIN message traffic release authority (MRA) via the CTAPS/TBMCS applications:
2. I certify that the individuals assigned to these positions have been trained as to the responsibilities they assume as a MRA.
AM I. JONES, COL, USAF
Chief, Combat Ops Div
S A M P L E
ANNEX C TO CHAPTER 10
SAMPLE TBMCS SYSAD SUPPORT REQUEST
TBMCS SYSAD SUPPORT REQUEST
EXERCISE/OPERATION NAME: _________________________DATE/TIME:______________________
RNK/NAME:(1)___________________ LOGIN:(2)______________ KY-68/DSN/OCSS NO.:(3)________
DG/DGP:(4)_____________________ TERMINAL/WORKSTATION NAME:(5)_____________________
PROBLEM VALIDATED BY: (8)__________________ PRIORITY:(9)_____________________________
******************************** FOR TBMCS HELP DESK/SYSAD USE ONLY *********************************
TBMCS HELP DESK VALIDATED BY: (10)__________________PRIORITY: (11) __________________
DATE/TIME RECEIVED BY SYSAD:_______________ RECEIVED BY:__________________________
ASSIGNED TO: (12)__________________ TIME ASSIGNED/COMPLETED:(13)__________/_________
SYSAD CORRECTIVE ACTION: (14)______________________________________________________
FIX/WORKAROUND TO REQUESTOR: (15)________________________________________________
FORM 37 ACTION TAKEN (IF REQUIRED): (16)_____________________________________________
(1). Rank and name of individual submitting request
(2). Assigned LOGIN for the above individual
(3). AOC number at which the requesting individual can be reached for any further questions; circle type of phone and put number in blank
(4). Assigned Duty Group/Duty Group Position (e.g. Combat Ops/Defensive Duty Officer or CO/DDO)
(5). Terminal name can be found at the top of the HMI menu bar
(6). Application or module for which support is needed. Be as specific as possible (i.e. CAFMS Ops/MID)
(7). Describe in as much detail as possible what the nature of the request is (i.e. cannot commit to the database)
(8). Name and rank of individual validating the request. Each functional area must review and validate any request coming from their functional area
(9). Established by the validating authority. Can be:
1 - Immediately 3 - Within 6 Hrs
2 - Within 2 Hrs 4 - When time allows (within 12 Hrs)
Correct prioritization will ensure request are handled in the correct order. Abuse of the prioritization will result in inefficient utilization of limited SYSAD resources
(10)/(11). TBMCS Help Desk Validation & Priotirity
(12). SYSAD assigned to fulfill the validated request
(13). Time request was assigned to SYSAD and completed by SYSAD
(14). Corrective action taken by SYSAD to fill the request
(15). Fix or corrective action provided to the user requesting the support
(16). Form 37 action taken if the problem involves a software limitation or problem (system limitations or new capabilities will be user responsibility; system problems will be handled by SYSAD; problems will be resolved by the TBMCS System Manager). Attach Form 37.
ANNEX D TO CHAPTER 10
READ/WRITE AUTHORIZATION LEVELS
1. GENERAL. In addition to access to the overall CTAPS network, each individual’s access will be further constrained based on his AOC position and the related duties and responsibilities of that position. Within CTAPS this position corresponds to a specific duty group position (DGPOS) which in turn maps to specific permissions within CTAPS. The DGPOS will determine which CTAPS modules the individual may have access to, and within each module what level of permission he/she may have (i.e. read-only, read/add/update, or read/add/update/delete). These permissions are pre-determined by each AOC functional area based on past experience as well as mission requirements.
A. Each AOC functional areas must:
(1). Review their read/write authorization matrix at a minimum once a month and submit any changes to the TBMCS System Manager for update of the master database. The same process addressed for user account access in Annex B to this chapter will be used.
(2). Designate two (primary and secondary) message receipt focal points within their functional area. At least one of these focal points must be logged on at all times within CTAPS during any exercise/operation to ensure they are properly notified of receipt/forwarding of any messages.
(3). Coordinate with the TBMCS System Manager for their functional area AUTODIN message routing office symbols to CTAPS DGPOSs requirements (i.e. all messages addressed to SOUTHAF/A-4 route to DIR-LRC).
B. The TBMCS System Manager is responsible for coordinating with the SYSAD section to ensure the appropriate read/write templates (see Appendix 1 and 2) and message routing symbols mapping tables are maintained up to date based on the AOC functional area inputs.
C. Although the permissions are pre-built into the CTAPS system, they can be amended as required by the mission. The process addressed for user account maintenance in Annex B to this chapter will be used for updating permissions.
3. PERMISSION MATRICES.
A. Various modules require different authorization levels to accomplish certain tasks. APS, for instance, currently has two levels: all (level 4) or nothing (level 0). Others, like CAFMS, have the permission levels broken down by individual screens. The following represent the general permission associated with each level:
(1). Level 0 - No permissions (option will not appear on the HMI)
(2). Level 1 - Database select capabilities (read only)
(3). Level 2 - Database update, select, insert capabilities (read/write)
(4). Level 3 - Database update, select, insert, and delete capabilities (read/write/delete)
(5). Level 4 - Full database capabilities. Same as Level 3 above, however, some applications such as APS are uniquely coded to accept only a Level 4. In addition, certain CAFMS applications, because of the sensitivity of the actions accomplished on the database require a Level 4 for any action to be accomplished. These CAFMS applications are ATO Collate (COL), ATO Schedule (SCH), ATO Mission Data Edit (AME), Operations Mission Data Edit (OME), ATO Archive (ARC), Delete ATO Database (ADB), ATO Transmit (AXT), ATO Clone (CLON), and ATO Transfer.
B. Because of the dynamic nature of the individual matrices, these will be published separately on a quarterly basis.
C. Any questions relative to the permission levels for each DGPOS should be addressed first with the functional area CTAPS focal points, then to the TBMCS System Manager.
APPENDIX 1 - V5.1.X ATASK System Listing
APPENDIX 2 - V5.1.X ATASK Module Listing
ANNEX E TO CHAPTER 10
REMOTE OPERATIONS MOU
MEMORANDUM OF UNDERSTANDING
Please completely fill out the following information:
Organization/Unit: ______________________________ Installation: ________________________________
Commander: ____________________________________ Commander’s DSN Phone: ____________________
Exercise/Contingency: ____________________________ Dates Support Required: ______________________
Unit Shipping/Mailing Address: ___________________________________________
The undersigned, as the designated representative of the above commanding officer agrees to accept the following responsibilities pursuant to the receipt and operations of a CTAPS computer system(s).
1. Protect the system during all phases of operation and transport from misuse, abuse, and theft.
2. Insure adequate power, ventilation, and cooling are provided for nominal system operations. The minimum specifications are detailed in the CTAPS Remote Users Guide (RUG), which will be included with the shipment. This information can be provided in advance of system shipment if required.
3. Insure access control procedures to the CTAPS system are enforced. Protect system passwords at the SECRET classification level. Insure system operations are conducted in an area offering physical security protection required for classified system operations. Insure all products, magnetic media (to include CTAPS removable system hard drive), and dot matrix printer ribbons are protected, stored, and transported at the classified level.
4. Declassify the hard drives prior to return to 12 AF. Instructions to accomplish declassification will be included with the shipment. Return/reship the unclassified system within 5 calendar days after ENDEX or termination of operations. The return shipping address will be included in each box/case shipped.
5. Insure the system is properly powered up and shutdown during operations, only as necessary to support mission operations. Proper procedures are detailed in the RUG.
6. Insure the system and supporting communications equipment are setup in the operations area and that required remote operator(s) and communications support personnel are in place during the circuit access times spelled out in the exercise Communications Plan Annex K or Tasking Order. Insure all required COMSEC aids/materials, as required by the Exercise or Contingency COMSEC callout message, are available when and where needed.
7. 12 AF POCs for resolving CTAPS support requirements and TBM issues are as follows:
12 AF/DOYI 612 ACOMS/SCOCM
Attn.: TBMCS System Manager Attn: Automated TBM Systems Administration
5340 E. Gafford Way, Bldg 70/Suite 223 5340 E. Gafford Way, Bldg 72/Suite 115
Davis-Monthan AFB, AZ 85707 Davis-Monthan AFB, AZ 85707
DSN: 228-4810/5280; FAX 3986 DSN: 228-2020/2019; FAX 3761
COMM: (520) 228-4810/5280 COMM: (520) 228-2020/2019
Designated Individual’s Name and Rank (Typed or Printed) Signature
________________ _____/(_____)______-________ _______ ___________________________________
Unit/Office Symbol DSN/COMM Phone Number FAX Ext Email Address
ANNEX F TO CHAPTER 10
DECLASSIFYING CTAPS/TBMCS HARD DISKS
The following are instructions for declassifying a hard disk. (Note: comments enclosed with quotes are case sensitive: you must enter commands exactly as shown in either UPPER or lower case.)
1. Boot-up the system using the normal boot-up/power-on procedures using a good bootable disk with an accessible "ctapsopr" account.
2. LOGIN as "ctapsopr" and press return (the Enter key on the keyboard).
3. Enter the ctapsopr account password and return. If the password is unknown, contact the system administrator at the Air Operations Center (AOC) that your system was last attached to. They should be able to provide the ctapsopr password if they modified it for security reasons. If the password cannot be provided, locate a disk (either classified or unclassified) that has a known password for ctapsopr if you have multiple disks at your location. If no disk can be located that is both bootable and the ctapsopr user account is accessible, contact 12AF systems administration at the numbers listed below.
4. After successfully LOGIN to the system, if a command line appears without a windows interface and menu, type "/usr/bin/X11/xinit" and return at the command line. A window manager should start and a green menu titled "ctapsopr menu" should appear (if the window manager does not start, type "mwm&" and return at the command line within the blank white window to start the motif window manager). For systems previously completely configured to an AOC host system (a LOGIN banner screen would appear after boot-up), the window manager should launch automatically and the ctapsopr menu should be displayed.
5. From the ctapsopr menu, click on the "UNIX Window" selection with the right mouse button. (Note: If a window does not appear or "UNIX Window" is not a choice from the menu, contact 12 AF systems administration at the numbers listed below.)
6. Once the UNIX Window appears, LOGIN as the "ctapsopr" user and press return. Enter the same password as in step 3 above and press return. If this was successful you should be at a shell prompt that looks like: "root@hostname(~)>" (you may have to press return again if your prompt doesn’t appear - some systems automatically display a message of the day [motd] immediately prior to opening a shell session).
Note: Follow steps 7-14 if your CTAPS system is a Sun Sparc 2. If your CTAPS system is a Sun Sparc 10 or 20 go to step 15.
7. The next 6 steps (8-13) will verify that the munix boot file resides in the root (/) directory on the disk, or load it from floppy if necessary.
8. At the prompt enter "cd /" and return. Then enter "ls munix*" and return. Hopefully a list of at least 1 file appears.
9. If the file "munix" exists go to step 14.
10. If the file "munix.Z" exists, then at the command line enter "uncompress munix.Z" and return. Go to step 14.
11. If no files are listed after the ls command executed in step 8, insert the floppy provided by 12 AF that contains the munix.Z file into the 3.5" floppy port located on the right side of the Sun Sparc Station CPU.
12. Enter the command "tar -xvf /dev/rfd0" and return. This will extract the munix.Z compressed boot file from the floppy.
13. Enter the command "uncompress munix.Z". This will uncompress the file (similar to DOS pkunzip).
14. Enter the command "reboot munix". This will reboot your system using the munix memory-resident kernel file (standalone operating system). Takes approximately 5 minutes. Go to step 22.
Note: Steps 15-21 are for Sun Sparc 10 or 20 systems. You must have a CD-ROM drive and the CD that contains the Solaris 1.1 (SunOS 4.1.3) operating system to declassify disks attached to Sparc 10 or 20 systems. If you do NOT have a CD-ROM you can place the disk(s) into Sparc 2 systems that are currently booted up with the Sparc 2 munix standalone OS and declassify the disk(s).
15. At the prompt type "halt" and return. Let the system shutdown totally, the system’s monitor screen will go black and when halted turn all white and display either a ‘>‘ or an ‘ok’ prompt.
16. If a CD-ROM drive is already attached to your system: go to step 20. If a CD-ROM drive is NOT currently attached to your system: after the system has halted, spin down the hard drives and power off the data shuttle and any other SCSI peripherals cabled to the SCSI bus attached to the Sun Sparc CPU.
NOTE: Do not power off the CPU.
17. Attach a CD-ROM drive to the system’s SCSI bus. Be sure that the CD-ROM is pinned to SCSI ID 6. Be sure the CD-ROM is correctly cabled to the SCSI bus using a small-SCSI <-> small-SCSI adapter cable. You may remove any other SCSI peripherals (tape drives, etc) attached to the SCSI bus. After the CD-ROM has been attached power on the data shuttle and the CD-ROM drive. Let this disks spin up fully.
18. To verify that the CD-ROM has been properly connected accomplish the following: If you are at the ‘>‘ prompt, type "n" and return to bring up the ‘ok’ prompt. At the ‘ok’ prompt type "probe-scsi" and return. The system’s SCSI controller will list the SCSI devices it detects. All disk to be declassified within the data shuttle and the CD-ROM drive must be accessible to the controller. The CD-ROM will be listed at ‘TARGET 6’, and should be described as a ‘REMOVABLE READ-ONLY DEVICE’.
19. If the CD-ROM or the disk drive(s) are not seen by the SCSI controller, then accomplish the following: spin the disks down. Power off the CPU, the data shuttle, and the CD-ROM drive. Power on the CPU first. Wait until it tries and fails to boot up and then reverts to the ‘>‘ or ‘ok’ prompts. Then power on the data shuttle and the CD-ROM drive, insuring that the disks spin up fully. Try the steps in 18. above to see if the controller now recognizes all the attached SCSI devices. If the controller still fails to recognize the devices, check the system cabling - the cables have not been jumpered correctly.
20. Insert a Solaris 1.1 (Sun OS 4.1.3) CD into the CD-ROM drive. You need to place the CD into a CD caddy and insert it into the CD-ROM drive port.
21. At the ‘ok’ prompt type "boot CD-ROM" (if you are at the ‘>‘ prompt type "b CD-ROM"). This will boot the system into ‘single user’ mode with a memory resident operating system from where you can execute the declassification routine. After the system is booted up, you may remove the CD-ROM from the system and move it to another Sparc 10 or 20 if you need to declassify several disks but have limited CD-ROM resources.
Both the Sparc 2 boot from the munix file and the Sparc 10/20 boot from the CD-ROM will execute similar startups. Wait until the system has completed its reboot then proceed to step 22.
22. At the end of the reboot you will be asked:
1 - Install SunOS miniroot
2 - Exit to single user shell
Select option "2" and return
a "#" prompt will appear for the command line
Note: Once the system has been booted from the munix kernel file, the UNIX miniroot operating system is memory resident. Any hard drive in the data shuttle may be spun down and removed without effecting the CPU operations. The system will remain booted up until the system is halted or power is turned off. If you do not desire to declassify the hard drive that held the munix file from which the system was booted, you may spin down the disk and remove it. Any other hard drive may be placed into the data shuttle, spun up, and declassified using the remaining instructions.
23. Type "format" and return at the "#" prompt. You may have more than one disk in the data shuttle, but only one disk will be declassified at a time.
24. The system should ask you to select a disk. If only one disk is present, enter "0" for that disk. If multiple disks are present, select the disk you desire to declassify first (normally the disk in the left bay of the shuttle will be designated sd3 and the disk in the right bay will be sd1). Recommend you always declassify the disk that has the munix file loaded LAST, just in case the power gets turned off, or some other unexpected event interrupts the declassification process and you need to reboot your system and start again. If you have multiple disks in the shuttle and one is classified - you will need to declassify both disks. Be sure not to have good unclassified disks and SECRET disks (to be declassified) spun-up in the same shuttle at the same time, unless you intended to declassify them both.
25. After selecting the disk, some disk info will be displayed, the "format>" prompt will appear, and a number of formatting options will be listed. Enter "analyze" and return at the "format>" prompt.
26. Another list of options will appear, enter "purge" and return at the "analyze>" prompt.
Note: If the error "No defect list found" appears follow the below steps:
a. Enter "quit" to return to the format menu, the "format>" prompt will reappear.
b. Enter "defect" and return, defect options will be listed, and the "defect>" prompt will appear.
c. Enter "original" and return at the "defect>" prompt. The "defect>" prompt will return immediately.
d. Enter "commit" and return, and answer "y" to the query to confirm the commit action.
e. Enter "quit" and return, to return to the format menu.
f. Re-accomplish steps 25 and 26.
27. After you enter the purge command, the system will prompt you to confirm your decision. Enter "y" and let the system do its thing. The system will accomplish 4 passes writing 1s and 0s to all disk writable areas, and accomplish a 5th verification pass if the first 4 were successful. This effectively wipes all data on the disk, declassifying the hard drive. This takes approximately 2 hours for a 1 Gigabyte disk, when completed the "analyze>" prompt will reappear. Enter "quit" and return, to exit "analyze>" and return to the "format>" prompt.
28. Enter "label" and return, then "y" to confirm labeling the disk.
29. You may now spin down and remove the declassified disk. Please ensure any classified paper labels or stickers are completely removed from the hard drive.
30. If you wish to declassify another hard drive, insert it into an empty slot of the data shuttle, preferably the left slot, and spin the disk up. Wait until the disk is fully spun up and enter "disk" and return at the "format>" prompt, to select the newly inserted disk to be declassified, and return to step 25. You may declassify as many disks as desired as long as the CPU is NOT powered off or halted.
31. For 12 AF supported remote sites that have multiple MDB disks: Recommend that you use the CTAPS clone procedures to rebuild the newly declassified disk(s) as soon as possible after declassification. Of course, you need to have a good (bootable) unclassified disk containing the correct version of CTAPS to clone from.
32. If you need any other assistance or have any questions concerning these procedures please contact the 12 AF systems administration office at DSN: 361-2019/5136.
Air Operations Center (AOC) Standard Operating Procedure (SOP)
Twelfth Air Force (12AF) Air Force Forces (AFFOR)