Read AFI33-138 text version

BY ORDER OF THE SECRETARY OF THE AIR FORCE

AIR FORCE INSTRUCTION 33-138 28 NOVEMBER 2005 Communications and Information ENTERPRISE NETWORK OPERATIONS NOTIFICATION AND TRACKING

COMPLIANCE WITH THIS PUBLICATION IS MANDATORY ACCESSIBILITY: Publications and forms are available on the e-Publishing website at www.e-publishing.af.mil for downloading or ordering.

RELEASABILITY: There are no releasability restrictions on this publication. OPR: SAF/XCIFN Supersedes AFI33-138, 7 December 2004. Certified by: SAF/XCIF (Col Porter Clapp) Pages: 92

This Air Force instruction (AFI) implements Air Force Policy Directive (AFPD) 33-1, Command, Control, Communications, and Computer (C4) Systems; the Information Assurance Vulnerability Management Program; and incident and vulnerability reporting guidance provided in Chairman of the Joint Chiefs of Staff Manual (CJCSM) 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND). This instruction prescribes and explains the various notification and tracking processes required to direct action and report status throughout the Air Force Network Operations (AFNETOPS) hierarchy. The specific processes addressed include Time Compliance Network Order (TCNO); Command, Control, Communications and Computers Notice to Airmen (C4 NOTAM); and incident, vulnerability, security incident, and service interruption reporting. This instruction applies to all Air Force military and civilian personnel and to Air Force contractors who develop, acquire, deliver, use, operate, or manage Air Force information systems. Supplementation of this instruction is permitted but is not required. If supplements are issued, major commands (MAJCOM), field operating agencies (FOA), and direct reporting units (DRU) will furnish a copy to Secretary of the Air Force (SAF/XCIF), 1030 Air Force Pentagon, Washington DC 20330-1030; field units will furnish a copy to the next echelon of command. This publication applies to the Air National Guard. Send recommended changes or comments to Headquarters Air Force Communications Agency (HQ AFCA/EASD), 203 W. Losey Street, Room 1100, Scott AFB IL 62225-5233, through appropriate channels, using Air Force (AF) IMT 847, Recommendation for Change of Publication, with an information copy to SAF/XCIF. The reporting requirements in this instruction are exempt from licensing in accordance with AFI 33-324, The Information Collections and Reports Management Program; Controlling Internal, Public, and Interagency Air Force Information Collections. Ensure that all records created as a result of processes prescribed in this publication are maintained in accordance with Air Force Manual (AFMAN) 37-123, Management of Records (will become AFMAN 33-363), and disposed in accordance with Air Force Records Information Management System (AFRIMS) Records Disposition Schedule (RDS) located at https://afrims.amc.af.mil/rds/ index.cfm. See Attachment 1 for a glossary of references and supporting information.

2

AFI33-138 28 NOVEMBER 2005

SUMMARY OF CHANGES This change incorporates interim change (IC) 2005-01 (Attachment 13) and alters FOA/DRU reporting directly to the Air Force Network Operations and Security Center (AFNOSC) due to FOA/DRU NOSC realignment. Mission Support Centers (MSC) will be treated as Network Control Centers (NCC) for reporting purposes. Multiple tables have been updated to reflect this conversion. Additional minor administrative corrections were made and office symbols updated. A bar ( | ) indicates a revision from the previous edition. Chapter 1-- GENERAL INFORMATION 1.1. 1.2. Figure 1.1. 1.3. Table 1.1. 1.4. 1.5. Table 1.2. Introduction. ............................................................................................................... Notification and Tracking Hierarchy. ........................................................................ Notification and Tracking Hierarchy. ....................................................................... Submitting Notifications and Reports to the Air Force Network Operations and Security Center (AFNOSC) ................................................................................ AFNOSC Report Priority and Contact Information. ................................................ Operational Reporting. ............................................................................................... Reporting Incidents not Covered by this Instruction. ................................................ Reporting Incidents not Covered by this Instruction. ............................................... 8 8 8 9 9 10 10 10 11 12 12 12 12 12 13 13 14 15 15 15 15 16 16 16

Chapter 2-- ROLES AND RESPONSIBILITIES 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 2.9. 2.10. 2.11. 2.12. 2.13. 2.14. Introduction. ............................................................................................................... Director, Information, Services and Integration (SAF/XCI) ..................................... Major Command Senior Communicator .................................................................... Air Force Communications Agency (AFCA) ............................................................ Air Force Network Operations and Security Center (AFNOSC) .............................. Air Force Network Operations and Security Center (AFNOSC). ............................. Network Operations and Security Center (NOSC) .................................................... Network Control Center (NCC)/Mission Support Centers (MSC) ............................ Program Executive Officer (PEO) ............................................................................. Functional System Designated Approving Authority (DAA) ................................... Program Management Office (PMO) and System Program Office (SPO) ................ Major Command (MAJCOM) Liaison to Air Force-Managed Systems ................... Information System Security Manager (ISSM) and Information System Security Officer (ISSO) ........................................................................................................... Workgroup Manager (WM) and Functional System Administrator (FSA) ...............

AFI33-138 28 NOVEMBER 2005 2.15. End Users ...................................................................................................................

3 16 17 17 17 17 17 17 18 18 18 18 19 19 19 20 20 20 20 20 20 20 21 21 21 22 22 22 23 23 23

Chapter 3-- TCNO MANAGEMENT Section 3A--Introduction 3.1. 3.2. Purpose. ...................................................................................................................... Applicability. .............................................................................................................

Section 3B--TCNO Generation Process 3.3. 3.4. 3.5. Table 3.1. 3.6. Table 3.2. 3.7. 3.8. 3.9. 3.10. 3.11. When to Generate a Time Compliance Network Order (TCNO). ............................. Releasing Authority. .................................................................................................. Establishing Time Compliance Network Order (TCNO) Priority. ............................ TCNO Priority Categories. ....................................................................................... Assigning TCNO Suspense Dates. ............................................................................ Determining TCNO Suspense Dates. ....................................................................... Assigning a Tracking Number. .................................................................................. Providing Implementation Details. ............................................................................ Specifying Justification. ............................................................................................. Other Time Compliance Network Order (TCNO) Content. ...................................... Example Time Compliance Network Order (TCNO). ...............................................

Section 3C--TCNO Dissemination and Acknowledgment 3.12. Dissemination Timelines. .......................................................................................... 3.13. 3.14. 3.15. Single Distribution List. ............................................................................................. Time Compliance Network Order (TCNO) Dissemination. ...................................... Acknowledging Time Compliance Network Orders (TCNO). ..................................

Section 3D--TCNO Implementation 3.16. 3.17. 3.18. 3.19. Implementing Time Compliance Network Orders (TCNO). ..................................... Two-Person Compliance. ........................................................................................... FSA and WM Actions. ............................................................................................... PMO and SPO Actions. .............................................................................................

Section 3E--TCNO Extensions 3.20. 3.21. General Guidance. ..................................................................................................... Extension Request Format. ........................................................................................

4 3.22. Table 3.3. Table 3.4. 3.23. 3.24.

AFI33-138 28 NOVEMBER 2005 Processing Extensions. ............................................................................................... TCNO Extension Categories and Timeframes. ........................................................ Time Compliance Network Order (TCNO) Extension Approval Process. .............. Program Management Office (PMO) and System Program Office (SPO) Extension Requests. .................................................................................................................... Evaluating Extension Requests. ................................................................................. 24 24 25 25 26 27 27 27 29 30 30 31 31 31 32 33 33 33 33 34 34 35 35 35 35 35 36 36 36

Section 3F--TCNO Compliance Reporting 3.25. 3.26. 3.27. 3.28. 3.29. 3.30. General Guidance. ..................................................................................................... Recording TCNO Compliance. .................................................................................. Compiling TCNO Compliance Statistics. .................................................................. Initial and Follow-On TCNO Compliance Statistics Reporting. ............................... Preventing Duplicate TCNO Compliance Information. ............................................ Resolving TCNO Compliance Reporting Discrepancies. ..........................................

Section 3G--Assessing TCNO Compliance 3.31. Table 3.5. TCNO Compliance Levels. ........................................................................................ TCNO Compliance Levels. .......................................................................................

Chapter 4-- C4 NOTAM MANAGEMENT 4.1. 4.2. 4.3. Table 4.1. 4.4. Introduction. ............................................................................................................... Types of C4 NOTAMs. ............................................................................................. C4 NOTAM Formatting Guidance. ........................................................................... C4 NOTAM Priority Categories. .............................................................................. C4 NOTAM Dissemination. ......................................................................................

Chapter 5-- INCIDENT AND VULNERABILITY REPORTING Section 5A--Introduction and General Procedures 5.1. 5.2. 5.3. Purpose. ...................................................................................................................... General Reporting Requirements. .............................................................................. Incident and Vulnerability Report Classification Guidance. .....................................

Section 5B--Incident Reporting 5.4. Table 5.1. Incidents Defined. ...................................................................................................... Incident Categories. ..................................................................................................

AFI33-138 28 NOVEMBER 2005 5.5. 5.6. 5.7. 5.8. Table 5.2. 5.9. Table 5.3. Incident Detection. ..................................................................................................... General Incident Response Actions. .......................................................................... ASIM-Identified Incidents. ........................................................................................ Incident Reporting. .................................................................................................... Incident Reporting Action Matrix. ............................................................................ Malicious Logic Incidents. ........................................................................................ Malicious Logic Reporting Action Matrix. ..............................................................

5 37 37 37 37 38 38 39 39 39 40 41 41 41 41 41 42 42 43 44 44 44 44 44 44 44 44 45 45 45 45

Section 5C--Vulnerability Reporting 5.10. Table 5.4. Vulnerability Reporting. ............................................................................................ Vulnerability Reporting Action Matrix. ...................................................................

Chapter 6-- SECURITY INCIDENT REPORTING 6.1. 6.2. 6.3. 6.4. 6.5. 6.6. Table 6.1. Security Incidents. ..................................................................................................... Related Guidance. ...................................................................................................... Classification Guidance. ............................................................................................ Security Incident Reporting. ...................................................................................... Classified Message Incidents (CMI). ......................................................................... Corrective Actions. .................................................................................................... Security Incident Reporting (SIR) Action Matrix. ...................................................

Chapter 7-- SERVICE INTERRUPTION REPORTING Section 7A--Introduction and General Procedures 7.1. 7.2. 7.3. Introduction. ............................................................................................................... Operational Reporting of Mission Impact. ................................................................ Service Interruption Reporting Classification Guidance. ..........................................

Section 7B--Authorized Service Interruptions (ASI) 7.4. 7.5. 7.6. 7.7. 7.8. Table 7.1. Authorized Service Interruption (ASI) Definition. .................................................... ASI Approval Authority. ........................................................................................... General ASI Coordination Guidance. ........................................................................ Submission of ASI Requests for Approval by the AFNETOPS/CC. ........................ Submission of ASI Requests for Approval by the MAJCOM DAA. ........................ ASI Submission Timelines. ......................................................................................

6 7.9. 7.10. 7.11.

AFI33-138 28 NOVEMBER 2005 Notification of Approved ASIs. ................................................................................. Tracking ASIs During Execution. ............................................................................. Extension of an Ongoing ASI. ................................................................................... 45 46 46 46 46 46 46 47 47 48 49 50 50 50 50 51 59 61 63 69 70 71 72 75 77 79

Section 7C--Unscheduled Service Interruptions 7.12. 7.14. Table 7.2. 7.15. Table 7.3. Table 7.4. Unscheduled Service Interruption (USI) Definition. ................................................. USI Reporting Categories. ......................................................................................... USI Reporting Categories. ........................................................................................ USI Reporting. ........................................................................................................... Unscheduled Service Interruption (USI) Action Matrix. .......................................... Unscheduled Service Interruption (USI) Reporting Timelines. ............................... 7.13. USIs Linked to Incidents. ..........................................................................................

Chapter 8-- INFORMATION COLLECTIONS, RECORDS, AND FORMS OR INFORMATION MANAGEMENT TOOLS (IMT) 8.1. 8.2. 8.3. Information Collections. ............................................................................................ Records. ..................................................................................................................... Forms or IMTs (Adopted and Prescribed). ................................................................

Attachment 1-- GLOSSARY OF REFERENCES AND SUPPORTING INFORMATION Attachment 2-- EXAMPLE TCNO Attachment 3-- PMO/SPO COMPLIANCE STATUS MESSAGES Attachment 4-- TCNO EXTENSION PACKAGES Attachment 5-- EXAMPLE INFORMATIVE C4 NOTAM Attachment 6-- EXAMPLE SCHEDULED/UNSCHEDULED EVENT C4 NOTAM Attachment 7-- EXAMPLE SUMMARY C4 NOTAM Attachment 8-- INCIDENT REPORTS (IR) Attachment 9-- MALICIOUS LOGIC REPORTS Attachment 10-- VULNERABILITY REPORTS (VR) Attachment 11-- SECURITY INCIDENT REPORTS (SIR)

AFI33-138 28 NOVEMBER 2005 Attachment 12-- AUTHORIZED SERVICE INTERRUPTION REQUESTS Attachment 13-- INTERIM CHANGE (IC) 2005-1 TO AFI 33-138, ENTERPRISE NETWORK OPERATIONS NOTIFICATION AND TRACKING

7 81 83

8 Chapter 1 GENERAL INFORMATION

AFI33-138 28 NOVEMBER 2005

1.1. Introduction. This instruction prescribes and explains the various processes necessary to direct action and report status throughout the AFNETOPS hierarchy. Specifically, it details the steps required to generate, disseminate, acknowledge, implement, track, and report network compliance and status information using the TCNO. It also introduces and provides guidance for the use of C4 NOTAMs. The C4 NOTAMs are closely related to TCNOs with the primary difference being that they are informative in nature and are the primary means for disseminating network information that does not direct specific action to be taken, or compliance to be tracked. Incident, vulnerability, and security incident (to include classified message incidents [CMI]) reporting processes, and the processes for managing and reporting service interruptions, both authorized and unscheduled, are defined. 1.2. Notification and Tracking Hierarchy. All network and computer security professionals within the tiered AFNETOPS hierarchy perform a subset of the procedures to produce and manage TCNOs or C4 NOTAMs. Those same individuals perform a variety of tasks in the various reporting processes described within this instruction. Figure 1.1. provides a simple illustration of the interrelationships and associated lines of communication among the various organizations and personnel involved. NOTE: Refer to AFI 33-115, Volume 1, Network Operations (NETOPS), for a complete explanation of the AFNETOPS hierarchy.

AFI33-138 28 NOVEMBER 2005 Figure 1.1. Notification and Tracking Hierarchy.

9

NOTES: 1. This category applies to those Program Management Offices (PMO)/System Program Offices (SPO) that fall under a HQ USAF functional and do not administratively align under Air Force Materiel Command (AFMC). 2. This category applies to those HQ USAF FOA and DRU Network Control Centers (NCC) or Mission Support Centers (MSC) that operate and maintain a network. All other FOA/DRU tenant units residing on an Air Force base shall comply with the security policy of the host base NCC and the supporting NOSC. 1.3. Submitting Notifications and Reports to the Air Force Network Operations and Security Center (AFNOSC) . NOSCs will notify and submit all reports to the AFNOSC Command and Control Division using the methods listed in Table 1.1. Use Defense Switched Network (DSN) to make initial verbal reports, followed by full documentation using priority 2, Enterprise Tracking and Notification Graphical User Interface (eTANG). If eTANG is not available then use priority 3, and so on, until all methods have been exhausted. Use classified transmission means when required.

10 Table 1.1. AFNOSC Report Priority and Contact Information. Priority 1 Method Remarks

AFI33-138 28 NOVEMBER 2005

Voice (All Secure Telephone Unit-III/ DSN: 781-1043 Secure Terminal Equipment Capable) Commercial: 318-456-1043 Toll Free: 877-833-6725 eTANG Secure E-Mail (Secret Internet Protocol Router Network [SIPRNET]) Defense Messaging System (DMS) [email protected]

2 3

4

c:US, o:U.S. Government, ou:DOD, ou:AF, ou:Organizations, l:Barksdale AFB LA, ou:AFNOSC(uc) c:US, o:U.S. Government, ou:DOD, ou:AF, ou:Organizations, l:Barksdale AFB LA, ou:AFNOSC(sc)

5 6 7

Secure FAX Unclassified FAX Unclassified E-Mail (Non-Secure Internet Protocol Router Network [NIPRNET])

DSN: 781-7633 Commercial: 318-456-7633 DSN: 781-2618 Commercial: 318-456-2618 [email protected]

1.4. Operational Reporting. In addition to the reporting requirements listed throughout this instruction, confirmed network/system intrusions and changes to Information Operations Condition (INFOCON) require the submission of Operational Event/Incident Report (OPREP-3) to the servicing command post per AFI 10-206, Operational Reporting. Individuals preparing OPREP-3s should coordinate with the servicing NCC or NOSC before the information is sent to the command post. The NCC submits report information applicable to the base metropolitan area network (MAN). The NOSC submits report information applicable to the MAJCOM network. The AFNOSC will submit report information applicable to the entire Air Force Enterprise Network (AFEN). Per AFI 10-206, Commander Air Force Forces-Computer Network Operations (COMAFFOR-CNO) is a required recipient of all computer incident-related OPREP-3s. The required content for all Communications/Computer Event OPREP-3s is detailed in AFI 10-206. 1.5. Reporting Incidents not Covered by this Instruction. There are a variety of information system/ network incidents that fall under the jurisdiction of other programs for investigation and reporting purposes. Examples include theft or loss of information system resources; fraud, waste, and abuse; and copyright violations. Table 1.2. provides reference to the governing publications for these types of incidents.

AFI33-138 28 NOVEMBER 2005 Table 1.2. Reporting Incidents not Covered by this Instruction. R U L E 1 2 3 A If the incident relates to theft/loss of information system resources fraud, waste, and abuse copyright violation B then follow the guidance in AFI 33-112, Computer Systems Management; AFMAN 23-220, Reports of Survey for Air Force Property AFI 90-301, Inspector General Complaints AFI 51-303, Intellectual Property--Patents, Patent Related Matters, Trademarks and Copyrights

11

12 Chapter 2

AFI33-138 28 NOVEMBER 2005

ROLES AND RESPONSIBILITIES 2.1. Introduction. Overarching roles and responsibilities for Air Staff offices, AFNETOPS organizations, and network/system personnel are defined here. Additional process-specific responsibilities are elaborated throughout the remainder of this document. Refer to Department of Defense (DOD) directives and instructions, Chairman of the Joint Chiefs of Staff (CJCS) instructions and manuals, and Defense Information Systems Agency (DISA) circulars for an explanation of DOD, Joint, and DISA offices' respective roles and responsibilities. 2.2. Director, Information, Services and Integration (SAF/XCI) will: 2.2.1. Establish Air Force policy and guidance for the AFNETOPS notification and tracking processes. 2.2.2. Ensure Air Force notification and tracking policy and processes are consistent with DOD and Joint guidance. 2.2.3. Provide the Air Force position when attending Air Force, DOD, or Joint forums relating to the processes covered by this instruction. 2.2.4. Keep senior Air Force and DOD leaders informed on any issues relating to the processes covered by this instruction. 2.2.5. Be the Air Staff focal point for the consolidation and presentation of situational awareness vulnerability, incident, and network/system availability data to senior Air Force leaders (e.g., Deputy Chief of Staff, Air and Space Operations [HQ USAF/XO]; Deputy Chief of Staff, Installations and Logistics [HQ USAF/IL]; Secretary of the Air Force, Office of Warfighting Integration and Chief Information Officer [SAF/XC]). 2.2.6. Work with the involved organizations that own systems traversing the AFEN to accomplish timely compliance with TCNOs. 2.2.7. Ensure training and mission-ready standardization and evaluation criteria are established for all network professionals charged with supporting the requirements of this instruction. 2.3. Major Command Senior Communicator will: 2.3.1. Plan, program, and budget for the capability to respond to TCNOs that impact end user workstations and/or core network servers and infrastructure. 2.3.2. When delegated as the MAJCOM Designated Approving Authority (DAA), approve or disapprove applicable TCNO extension requests based on an assessment of the overall risk to the AFEN and to supported operations (see Section 3E). 2.4. Air Force Communications Agency (AFCA) will: 2.4.1. Develop AFNETOPS notification and tracking processes consistent with SAF/XCI policy and guidance.

AFI33-138 28 NOVEMBER 2005

13

2.4.2. Interpret AFEN incident statistics and generate the annual Assessment of The State of Information Protection in the Air Force report according to AFI 33-205, Information Protection Metrics and Measurements Program. 2.5. Air Force Network Operations and Security Center (AFNOSC) Director and Commander, Air Force Forces, Computer Network Operations (COMAFFOR-CNO) . NOTE: The AFNOSC Director is also assigned as the COMAFFOR-CNO. Refer to AFI 33-115, Volume 1, for a detailed explanation of the command relationships between the Commander of Air Force Network Operations (AFNETOPS/CC) and the AFNOSC Director/COMAFFOR-CNO. The COMAFFOR-CNO will: 2.5.1. Ensure Air Force compliance with the Information Assurance Vulnerability Management (IAVM) Program and vulnerability incident reporting direction specified in CJCSM 6510.01. 2.5.2. Direct the issuance of TCNOs and C4 NOTAMs, as required. 2.6. Air Force Network Operations and Security Center (AFNOSC). The AFNOSC is a distributed organization that combines the capabilities of the AFNOSC Command and Control Division, Barksdale AFB LA, AFNOSC Net Security Division (formerly the Air Force Computer Emergency Response Team), Lackland AFB TX, and the AFNOSC Net Operations Division (formerly the Air Force Network Operations Center), Gunter Annex, Maxwell AFB AL, to preserve the availability, integrity, and confidentiality of the Air Force's networks, information systems, and the information contained within those elements, respectively. The AFNOSC will: 2.6.1. Serve as the Air Force Office of Primary Responsibility (OPR) to register, acknowledge, and track implementation of IAVM program messages (i.e., Information Assurance Vulnerability Alerts [IAVA], Information Assurance Vulnerability Bulletins [IAVB], and Technical Advisories (TA) as defined in CJCSM 6510.01.) 2.6.2. Serve as the Air Force OPR to acknowledge and track Joint Task Force-Global Network Operations (JTF-GNO) Computer Network Operations Tasking Orders (JTF-GNO CTO), as required. 2.6.3. Serve as the Air Force OPR to generate, disseminate, and track implementation of Air Force-level TCNOs in accordance with Chapter 3. 2.6.4. Serve as the Air Force OPR to generate and disseminate Air Force-level C4 NOTAMs in accordance with Chapter 4. 2.6.5. Assess the impact of IAVAs, IAVBs, TAs, JTF-GNO CTOs, and TCNOs on Air Force operations. 2.6.6. Compile and maintain TCNO and associated IAVA compliance status, and other network security metrics to maintain an AFEN situational picture according to applicable DOD, CJCS, and Air Force guidance. Report status to higher headquarters and JTF-GNO as required. 2.6.7. Serve as the Air Force OPR for incident response and countermeasure generation for incidents that traverse multiple MAJCOMs or meet/exceed current Air Force incident thresholds. 2.6.7.1. Work with the NOSCs in assessing the scope of unauthorized network activities and incidents. 2.6.7.2. Recommend a countermeasure or a set of countermeasures to neutralize intruder activity and to foster recovery operations.

14

AFI33-138 28 NOVEMBER 2005 2.6.7.3. Work with NOSCs in eradicating malicious logic from networks, information systems, and stand-alone computing devices. 2.6.7.4. Track all ongoing, validated incidents. 2.6.7.5. Report all validated incidents to JTF-GNO and other agencies (e.g., SAF/XCI, Air Force Office of Special Investigations) as required. 2.6.7.6. Disseminate incident reports, trend analysis and vulnerability assessments to NOSCs, SAF/XCI, and HQ AFCA/EVPI, as required. 2.6.8. Serve as the Air Force OPR to provide, manage, and disseminate computer malware (i.e., viruses, trojans, malicious logic, etc.) incident alert reports via subscription based service to JTF-GNO, NOSCs, Department of Defense Computer Emergency Response Team (DOD CERT), and other approved entities. 2.6.9. Serve as the Air Force OPR to provide, manage, and maintain the most current anti-virus definitions and automated anti-virus product update service for the Air Force. 2.6.10. Track, compile, analyze, and report Air Force-wide statistics on unauthorized network activities, malicious logic, and virus incidents. Report the analysis results to AFCA/EVPI as required according to AFI 33-205.

2.7. Network Operations and Security Center (NOSC) will: 2.7.1. Serve as the OPR for their assigned area of responsibility (AOR) to acknowledge, disseminate, implement, track, and report TCNOs and C4 NOTAMs. This includes Air Force-generated and MAJCOM-generated TCNOs (for MAJCOM-unique systems). 2.7.2. Disseminate and track TCNOs for MAJCOM-level SPOs and PMOs. NOTE: The AFMC NOSC will disseminate TCNOs to those Air Force-level PMOs and SPOs that are administratively supported by AFMC. 2.7.3. Track, compile, assess, and report AOR-wide compliance, extension, and situational awareness metrics on TCNOs in accordance with Chapter 3. 2.7.4. Serve as the OPR responsible for managing responses and preventing unauthorized network activity and incidents within their respective AORs. 2.7.5. Oversee and orchestrate vulnerability, security incident, and incident response actions whenever they affect the MAJCOM enclave network or whenever a NCC or network professional requires assistance. 2.7.6. Work with the AFNOSC, NCCs, and MSCs to assist customers in eradicating malicious logic from networks, information systems, and stand-alone computing devices. 2.7.7. Work with the AFNOSC, NCCs, and MSCs to assist customers in assessing the scope of unauthorized network activities and incidents. 2.7.8. Track, compile, assess, and report to the AFNOSC all unauthorized network activities and incidents that affect multiple NCCs or meet/exceed current Air Force incident thresholds in accordance with Chapter 5. 2.7.9. Maintain situational awareness by tracking, compiling, assessing, and reporting AOR-wide statistics on incidents and reporting TCNO compliance statistics to the NOSC's chain of command.

AFI33-138 28 NOVEMBER 2005 2.8. Network Control Center (NCC)/Mission Support Centers (MSC) will:

15

2.8.1. Serve as the wing/base OPR to acknowledge, disseminate, and implement TCNOs and C4 NOTAMs and to track and report compliance with TCNOs. 2.8.2. Track, compile, assess, and report wing/base TCNO compliance, extension, and situational awareness metrics (to include geographically separated units [GSU]) in accordance with Chapter 3. 2.8.3. Serve as the wing/base OPR responsible for managing responses and controlling unauthorized network activity and incidents that occur within their AOR and meet current Air Force incident thresholds. NCCs must: 2.8.3.1. Oversee and orchestrate vulnerability, security incident, and intrusion response actions whenever an incident affects the base backbone network, a Community of Interest network, a system, or whenever a network professional requests assistance. 2.8.3.2. Work with the NOSC and network professionals to assist Air Force customers in eradicating malicious logic from networks, information systems, and stand-alone computing devices. 2.8.3.3. Work with the NOSC and network professionals to assist Air Force customers in assessing the scope of unauthorized network activities and incidents. 2.8.3.4. Track, compile, assess, and report to their parent NOSC all unauthorized activities and incidents that occur on any network or system under the NCC's purview. 2.8.3.5. Maintain wing situational awareness by tracking, compiling, and reporting wing statistics on unauthorized network activity and incidents. 2.8.4. MSCs are treated as NCCs throughout the rest of this instruction. 2.9. Program Executive Officer (PEO) will: 2.9.1. Ensure PMOs/SPOs process and comply with TCNOs. 2.9.2. Ensure PMOs/SPOs report through the appropriate NOSC or directly to the AFNOSC as detailed within this instruction. 2.10. Functional System Designated Approving Authority (DAA) will: 2.10.1. Work with PMOs/SPOs to ensure TCNO extension requests are processed in accordance with Section 3E. 2.10.2. Thoroughly understand the risk to the AFEN and supported operational missions before endorsing or approving TCNO extension requests. 2.11. Program Management Office (PMO) and System Program Office (SPO) will: 2.11.1. Serve as the OPR to process, evaluate, test, and coordinate TCNOs and risk mitigation countermeasures for those functional systems for which they are responsible. 2.11.2. Within allocated funds and resources, ensure program has the capability to respond to all TCNOs. 2.11.3. Determine a TCNO's applicability, risks, vulnerabilities, and impact to their programs and inform affected agencies of the results in accordance with paragraph 3.19.

16

AFI33-138 28 NOVEMBER 2005 2.11.4. Ensure a countermeasure is developed for every applicable TCNO.

2.12. Major Command (MAJCOM) Liaison to Air Force-Managed Systems will: 2.12.1. Serve as the MAJCOM OPR to coordinate configuration management functions between Air Force PMOs/SPOs, MAJCOM PMOs/SPOs, and Functional System Administrators (FSA). 2.12.2. Receive and disseminate projected and actual risk mitigation countermeasure and fix action release status. 2.13. Information System Security Manager (ISSM) and Information System Security Officer (ISSO) will: 2.13.1. Immediately notify the appropriate AFNETOPS organization and the DAA upon discovering an unauthorized network activity or incident as directed within this instruction. 2.13.2. Work with the NOSCs, NCCs, and network and security professionals to assist Air Force customers in eradicating malicious logic from a network, information systems, and stand-alone computing devices. 2.13.3. Work with the NOSCs, NCCs, and network and security professionals to assist Air Force customers in assessing the scope of unauthorized network activities or incidents. 2.13.4. Ensure unit workgroup managers (WM) and FSAs are taking aggressive action to implement TCNOs within the mandatory timeframe. 2.14. Workgroup Manager (WM) and Functional System Administrator (FSA) will: 2.14.1. Implement TCNO countermeasures as approved by each system's configuration control authority and as directed by the servicing NCC in accordance with the TCNO instructions. 2.14.2. Coordinate TCNO implementation with the servicing NCC, users, and external agencies. 2.14.3. Report TCNO compliance metrics to the servicing NCC according to the requirements of this instruction. 2.14.4. Work with the NCC and network and security professionals to assist Air Force customers in eradicating malicious logic from a network, information systems, and stand-alone computing device. 2.14.5. Work with the NCCs and network and security professionals to assist Air Force customers in assessing the scope of unauthorized network activities or incidents. 2.15. End Users will: 2.15.1. Comply with Air Force, MAJCOM, and local system and network security policies. 2.15.2. Report unauthorized network activities or incidents, which includes all forms of malicious logic, to their WM/FSA to ensure notification continues up the chain of command.

AFI33-138 28 NOVEMBER 2005 Chapter 3 TCNO MANAGEMENT Section 3A--Introduction 3.1. Purpose. 3.1.1. Compliance with Air Force TCNOs is mandatory.

17

3.1.2. Time Compliance Network Orders (TCNO) are downward-directed operations, security, or configuration management-related orders issued by the AFNOSC or NOSCs. The TCNO provides a standardized mechanism to issue one "order" to the entire AFNETOPS hierarchy, directing how to operate and make changes to the AFEN. The AFNOSC or NOSCs generate TCNOs internally or in response to an IAVA to direct the implementation of an operational or security vulnerability risk mitigation procedure or fix action (i.e., countermeasure). 3.1.3. The TCNO process is used to inform responsible Air Force agencies of network and system vulnerabilities and to direct and track the implementation of countermeasures. This chapter defines the TCNO process and provides guidance, procedures, and formats to process TCNOs. 3.1.4. The TCNO replaces the Directive C4 NOTAM, AFCERT Advisories and Advisory Compliance Messages. Existing Directive C4 NOTAMs, AFCERT Advisories, and Advisory Compliance Messages will remain valid until superceded by a TCNO. Informative, Scheduled Event, Unscheduled Event, and Summary C4 NOTAMs will continue to be used as identified in Chapter 4. 3.2. Applicability. The processes defined within this chapter apply to the mitigation of identified vulnerabilities on any Air Force-owned/managed device connected to the AFEN or other DOD network. Devices, also referred to as "assets," include workstations, servers, infrastructure components (e.g., router, switch) and networked peripherals (e.g., network printers). Embedded computers within weapon systems are excluded from this definition unless they are directly accessible through the AFEN and thus vulnerable to exploitation. Section 3B--TCNO Generation Process 3.3. When to Generate a Time Compliance Network Order (TCNO). The AFNOSC or NOSCs will produce TCNOs under the following conditions: 3.3.1. The AFNOSC will generate a TCNO to implement an IAVA, or where applicable, a JTF-GNO CTO. TCNO timelines are set to ensure downward-directed timelines are met. 3.3.2. The AFNOSC can generate a TCNO to address IAVBs, TAs, Air Force-identified vulnerabilities or to direct other network operations/defense actions. TCNO timelines are set based on an internal analysis of the scope of effort necessary for units to achieve compliance and the potential impact on planned and ongoing operations. 3.3.3. NOSCs can generate a TCNO to address MAJCOM-specific vulnerabilities or to direct other network operations/defense actions. NOSCs should coordinate MAJCOM-unique TCNOs with the AFNOSC to ensure the network defense and network operations aspects of TCNO-directed actions are evaluated for their overall impact on the AFEN.

18 3.4. Releasing Authority.

AFI33-138 28 NOVEMBER 2005

3.4.1. The AFNOSC is the only organization authorized to release an Air Force-wide TCNO. 3.4.2. NOSCs can release a TCNO for units within their AOR. 3.5. Establishing Time Compliance Network Order (TCNO) Priority. The releasing agency assigns a TCNO priority based on an assessment of the scope and potential impact of the vulnerability to the AFEN and supported operations and where applicable, to comply with JTF-GNO implementation and reporting requirements. NOSCs releasing a MAJCOM-specific TCNO should coordinate with the AFNOSC when assigning priority. The five defined priorities are summarized in Table 3.1. Table 3.1. TCNO Priority Categories. Priority Description Critical Widespread and imminent/ongoing threat to the AFEN and supported operations. Serious Widespread threat to the AFEN and supported operations is expected. High Threat to the AFEN and supported operations is likely. Medium Threat to the AFEN is possible but is mitigated by such factors as difficulty of exploitation, limited deployment of vulnerable operating system, etc. Low Threat to the AFEN is unlikely due the assessed difficulty of exploiting the vulnerability.

3.6. Assigning TCNO Suspense Dates. For each TCNO generated, the releasing organization will assign several key suspense dates to help prioritize work by tasked organizations and to ensure information exchange reporting requirements are met. 3.6.1. Receipt Acknowledgment Date. The date by which tasked organizations will acknowledge receipt of the TCNO to their next higher echelon. 3.6.2. Initial Compliance Statistics Date. The date by which tasked organizations will provide their first compliance statistics update to their next-higher echelon. 3.6.3. Compliance Date. The date by which tasked organizations must achieve full compliance with the implementation actions mandated by the TCNO. 3.6.4. Table 3.2. provides guidance for establishing each of the required dates.

AFI33-138 28 NOVEMBER 2005 Table 3.2. Determining TCNO Suspense Dates. R U L E A B then the If the TCNO priority is: Critical Serious High Medium Low NOTES: receipt acknowledgment date will be £ 24 hrs after TCNO release (Note 1) initial compliance statistics date will be the first Monday after TCNO release C D

19

compliance date will be (Note 2) £ 15 days £ 30 days £ 45 days £ 60 days

1 2 3 4 5

1. Organizations not manned 24 hours, 7 days-a-week, will acknowledge receipt the next duty day. 2. The compliance reporting timeframes listed are the maximum allowed. More restrictive compliance dates may be established by the originating organization based on the assessed threat or as necessary to meet higher echelon requirements (i.e., a NOSC can shorten NCC compliance dates, an NCC can shorten WM/FSA compliance dates). 3.7. Assigning a Tracking Number. TCNO tracking numbers are built based on the day they are released (recorded as Julian date and year) and the order of release during that given day. The standard numbering format is: the identifier "TCNO," issuing agency, four-digit year, three-digit Julian date, a three-digit increment number, and a single character revision identifier. For example, the tracking number assigned to the first TCNO released by the AFNOSC on 19 January 2004 would be "TCNO AFNOSC 2004-019-001". If the original TCNO is revised, the tracking number becomes "TCNO AFNOSC 2004-019-001A", a revision of the "A" version will bear the revision identifier "B" and so on. 3.8. Providing Implementation Details. 3.8.1. Identify the affected operating systems, applications, and versions. This information helps responsible individuals quickly assess the TCNO's applicability to their systems. 3.8.2. Provide step-by-step countermeasure implementation instructions. Sort the countermeasures by platform (e.g., RISC, Intel, Macintosh) and by operating system (e.g., WIN NT/2000/XP, UNIX, LINUX) whenever possible. Prepare written instructions for network professionals at the journeyman-level to afford some assistance for system administrators and help expedite countermeasure implementations. Due to the possible variety of system configurations, it's impossible to write detailed implementation instructions for every scenario, therefore NOSCs, NCCs, and PMOs/SPOs may augment the instructions as outlined below:

20

AFI33-138 28 NOVEMBER 2005 3.8.2.1. NOSCs and NCCs may augment the AFNOSC's detailed, step-by-step implementation instructions as required so that apprentice-level network and system administration personnel can implement the countermeasures. 3.8.2.2. PMOs/SPOs may augment the AFNOSC's step-by-step implementation instructions as required. Write instructions so that apprentice-level network and system administration personnel can implement the countermeasures. When specific implementation procedures other than those provided by AFNOSC, PMO or SPO are required, provide the sources to obtain those procedures. 3.8.3. Include an estimate of the downtime required to implement the countermeasures. 3.8.4. Identify residual risks associated with non-compliance; i.e., not implementing countermeasures. Consider the worst-case scenario and chances for exploitation.

3.9. Specifying Justification. The releasing agency will encapsulate or reference applicable IAVAs, IAVBs, TAs, JTF-GNO CTOs, and related TCNOs/C4 NOTAMs in all TCNOs. These references help the AFNETOPS and acquisition communities correlate TCNOs with DOD-level messages. 3.10. Other Time Compliance Network Order (TCNO) Content. The releasing agency may list other relevant information about the vulnerability and countermeasure in the TCNO. This may include information from sources like an associated IAVA, vendor security notice, etc. 3.11. Example Time Compliance Network Order (TCNO). Refer to Attachment 2 for a TCNO example. Section 3C--TCNO Dissemination and Acknowledgment 3.12. Dissemination Timelines. Timely dissemination of vulnerability and countermeasure information to the personnel responsible for implementation is critical to ensure the integrity and availability of the AFEN. All involved organizations will ensure critical and serious priority TCNOs are disseminated to their subordinate organizations within 24 hours of receipt. High, medium, and low priority TCNOs will be disseminated at the originator's discretion. 3.13. Single Distribution List. The AFNOSC will maintain a single distribution list of Air Force units that must receive AFNOSC-generated TCNOs to include: 3.13.1. Action Addressees: NOSCs, and all Air Force-level PMOs and SPOs not administratively assigned to AFMC. 3.13.2. Information Addressees: SAF/XCIF, HQ USAF/XOIW, Numbered Air Force SC/A6s, HQ AFCA/EVPI, HQ AFCA/ECF/ECN, and others as required. 3.14. Time Compliance Network Order (TCNO) Dissemination. The AFNOSC and NOSCs will disseminate TCNOs using eTANG and/or SIPRNET electronic mail (E-mail). All organizations send or forward a TCNO as follows: 3.14.1. The AFNOSC disseminates TCNOs to NOSCs, FOA/DRU NCCs/MSCs and all Air Force program offices not administratively assigned to AFMC.

AFI33-138 28 NOVEMBER 2005

21

3.14.2. The NOSC disseminates TCNOs to all NCCs within its AOR and to its MAJCOM-level PMOs and SPOs. 3.14.3. The NCC disseminates TCNOs to all FSAs and WMs within the NCC's AOR. This includes host, tenant, and GSU organizations serviced by the NCC. 3.14.4. All Air Force tenant units on Air Force installations to include FOAs and DRUs must coordinate with their servicing NCCs to receive TCNOs. 3.14.5. PMOs/SPOs forward TCNOs to the applicable Joint PMO for evaluation under the following conditions: 3.14.5.1. Programs for which the Air Force is not the lead service. 3.14.5.2. For a TCNO that was not generated as a result of an IAVA. 3.15. Acknowledging Time Compliance Network Orders (TCNO). Subordinate units and recipients will acknowledge receipt of the TCNO to their next higher echelon. 3.15.1. NCCs will receive and compile TCNO acknowledgement reports from FSAs and WMs and will acknowledge receipt of the TCNO to their NOSC. 3.15.2. NOSCs receive and compile TCNO acknowledgement reports from their NCCs and MAJCOM-level PMOs and SPOs and will acknowledge receipt of the TCNO to the AFNOSC. 3.15.3. DELETED 3.15.4. The AFNOSC will receive TCNO acknowledgement reports from NOSCs, and Air Force-level PMOs and SPOs. 3.15.5. The AFNOSC sends IAVA acknowledgments to JTF-GNO within the timeframes specified by the IAVA. 3.15.6. Acknowledgment by subordinate to higher-echelon organizations will be accomplished using one of the following methods: 3.15.6.1. Organizations will use eTANG to acknowledge receipt according to the timeframes established by the recipient's next higher echelon. 3.15.6.2. Organizations that do not have access to eTANG will send acknowledgement reports via SIPRNET E-mail. The subject line of the message will be in the format "ACKNOWLEDGEMENT RECEIPT FOR TCNO Tracking Number" where TCNO Tracking Number is the assigned number for the TCNO being acknowledged. For example, "ACKNOWLEDGEMENT RECEIPT FOR TCNO AFNOSC 2004-052-001". Section 3D--TCNO Implementation 3.16. Implementing Time Compliance Network Orders (TCNO). The goal of the TCNO process is the mitigation of risk to the AFEN through the implementation of network vulnerability countermeasures. Countermeasures will generally entail configuration changes to systems, installation of software patches, or the search for and removal of specific files or tools used for malicious purposes. The AFNOSC directs NOSCs, NCCs, PMOs, and SPOs to implement TCNOs using the information and guidance contained within the TCNO. Organizations should submit a request for an extension as described in Section 3E if

22

AFI33-138 28 NOVEMBER 2005

there are valid reasons the TCNO-directed timeline cannot be met for the application of countermeasures to workstations. 3.17. Two-Person Compliance. NOSC and NCC personnel will follow a Two-Person Compliance process for all TCNO-directed countermeasures applied to core servers or infrastructure components. The process is as follows: 3.17.1. One NOSC/NCC crew member, the TCNO implementer, will apply the TCNO-directed countermeasure using the procedures outlined in the TCNO. Once countermeasure implementation is complete, the TCNO implementer will verify the application of the countermeasure by checking file versions/dates, registry settings, or other applicable indications of successful countermeasure implementation. 3.17.2. Once the TCNO-directed countermeasure is verified by the TCNO implementer, a second NOSC/NCC crew member, the TCNO validator, will validate the successful application of the countermeasure by verifying the procedures outlined in the TCNO were followed and by checking file version/dates, registry settings, or other applicable indications of successful countermeasure implementation. 3.17.3. The TCNO implementer and validator will document the implementation of the TCNO-directed countermeasure as outlined in paragraph 3.26.4. 3.18. FSA and WM Actions. The ultimate goal is to be able to achieve TCNO implementation through automated means but there are many occasions when implementation must be manually accomplished on workstations or functional servers at the FSA- and WM-level. In these instances, FSAs and WMs will implement TCNOs according to the step-by-step instructions in the TCNO, or as directed by the system's configuration controlling authority (e.g., PMO or SPO). 3.18.1. FSAs and WMs must coordinate all TCNO activities with the servicing NCC. 3.18.2. Specific local configurations or processes may preclude FSAs and WMs from following the TCNO step-by-step instructions exactly. In these situations, variations to the step-by-step instructions are authorized, provided compliance with the TCNO is achieved and verified. 3.18.3. FSAs and WMs discovering errors in the step-by-step instructions that could potentially damage systems or make the countermeasure ineffective should immediately send that information to their next higher AFNETOPS echelon. Similarly, report changes to the instructions that could expedite or clarify countermeasure implementation. Forward this information through the reporting hierarchy to the AFNOSC for their consideration. If warranted, the AFNOSC may release a revised version of the original TCNO to reflect the new guidance. 3.19. PMO and SPO Actions. 3.19.1. PMOs and SPOs are responsible for controlling the configuration of their functional systems and must establish procedures to evaluate the applicability of TCNOs to their systems. FSAs are responsible for the actual implementation of TCNO countermeasures on functional systems, but should only proceed with the permission of the PMO, SPO, NOSC, NCC or as established in the program Configuration Management Plan. PMOs and SPOs will establish procedures for each of the following situations:

AFI33-138 28 NOVEMBER 2005

23

3.19.1.1. The TCNO does not apply to the program. Provide a reason (e.g., the affected operating system is not used by the system). 3.19.1.2. The TCNO applies to the program and the FSAs are authorized to implement the countermeasure according to the procedures contained in the TCNO. 3.19.1.3. The TCNO applies to the program but the FSAs are not authorized to implement the countermeasure according to the procedures contained in the TCNO. In this case, specify the actual implementation procedures or a source for those procedures. 3.19.1.4. The TCNO applies to the program but actual implementation procedures are not yet available. In this case, provide a reason the implementation procedures are not available (e.g., procedures are being tested, software release is being built) and an action plan with timelines for completing required actions. 3.19.1.5. The applicability of the TCNO to the program is not known at this time. In this case, provide an action plan for evaluating applicability of the TCNO. 3.19.2. For each of the scenarios elaborated in paragraph 3.19.1. the following reporting guidance applies: 3.19.2.1. All PMOs/SPOs will utilize the ENOSC web-based status page to maintain TCNO-specific applicability/status information as outlined in paragraph 3.19.1. 3.19.2.2. Air Force-level PMOs/SPOs will notify the AFNOSC as soon as TCNO applicability is determined and/or implementation procedures are available. The AFNOSC will in-turn notify the NOSCs to begin TCNO implementation (see Attachment 3, Example 1 for a sample message). 3.19.2.3. MAJCOM-controlled PMOs and SPOs will notify their parent NOSC as soon as TCNO applicability is determined and/or implementation procedures are available (see Attachment 3, Example 2 for a sample message). 3.19.3. PMOs and SPOs will ensure all previous TCNOs are incorporated into new system development. Section 3E--TCNO Extensions 3.20. General Guidance. On rare occasions, extensions to TCNOs may be required to achieve compliance. An approved extension authorizes the delay of compliance with a TCNO countermeasure for a specified period past the required TCNO compliance date. 3.20.1. Extensions will only be granted for TCNOs where additional time is required to bring affected workstations into compliance. Extensions will not be granted for achieving TCNO compliance on affected core servers, infrastructure components or functional servers. 3.20.2. An extension does not grant the requesting agency the authority to accept the vulnerabilities or risks identified in the TCNO indefinitely; rather, it is approval to accept the risk for a specified period based on an operational risk management decision. 3.21. Extension Request Format. Refer to Attachment 4 for required extension content.

24

AFI33-138 28 NOVEMBER 2005

3.22. Processing Extensions. The extension process has been broken into three sequential categories that are summarized in Table 3.3. Table 3.4. outlines the required endorsement and approval authorities by category of extension and requesting organization. Table 3.3. TCNO Extension Categories and Timeframes. Category First (Note 1) Second (Note 2) Third (Note 2) NOTES: 1. First extension requests should be submitted as soon as the inability to comply is known but not later than 7 days before the TCNO-specified compliance date. 2. Second and third extension requests should be submitted as soon as the inability to comply is known but not later than 14 days before the expiration date of the previously-approved extension. Time Period Covered Original compliance date plus 30 days First extension compliance date plus 60 days (31 ­ 90 days from original compliance date) Second extension compliance date up to two years (91 days ­ 2 years from original compliance date)

AFI33-138 28 NOVEMBER 2005 Table 3.4. Time Compliance Network Order (TCNO) Extension Approval Process. R U L E 1 2 3 4 5 6 7 8 9 10 11 12 third extension second extension A If the extension requested is a first extension B and it is being requested by the NCC NOSC C then it must be endorsed by the wing/base DAA (Note 1) first Colonel in NOSC chain of command D and the approval authority will be the MAJCOM DAA

25

FOA/DRU NCC/MSC FOA/DRU DAA (Note 2) PMO/SPO NCC NOSC program manager functional system DAA wing/base DAA (Note 1) AFNOSC Director and MAJCOM DAA (Note 2) MAJCOM DAA

FOA/DRU NCC/MSC FOA/DRU DAA (Note 2) PMO/SPO NCC NOSC functional system DAA wing/base DAA (Note 1) AFNETOPS/CC and MAJCOM DAA (Note 2) MAJCOM DAA

FOA/DRU NCC/MSC FOA/DRU DAA (Note 2) PMO/SPO functional system DAA

NOTES: 1. In those cases where the MAJCOM DAA has assumed the responsibility of the wing/base enclave DAA, the request for extension must still be endorsed by the host wing commander. Refer to AFI 33-202, Volume 1, Network and Computer Security, for the definition and assignment of DAAs. 2. Send extension requests electronically to the following E-mail account: Secure: [email protected] 3.23. Program Management Office (PMO) and System Program Office (SPO) Extension Requests. PMOs and SPOs will comply with the timetable and endorsement levels established in Table 3.3. and Table 3.4. when requesting extensions for the development and dissemination of countermeasures for client-side (workstation-based) functional applications (e.g., DMS client). PMOs and SPOs must ensure the functional system DAA understands that approving a first extension or endorsing a second or third extension leads to an acceptance of residual risk that applies to network enclaves outside the functional system DAA's span of control.

26

AFI33-138 28 NOVEMBER 2005

3.24. Evaluating Extension Requests. Based on the category of extension (i.e., first, second, third) the approval authority (see Table 3.4.) will conduct an overall analysis of the residual risk to the AFEN and supported operations posed by the non-compliant workstations being allowed to continue to operate. By approving an extension, the approval authority is accepting any stated mitigating actions and the associated risks. 3.24.1. First extension approval authorities will: 3.24.1.1. Log and track all extension requests (i.e., recommendations, approvals, extensions, disapprovals, and terminations) throughout the extension process. 3.24.1.2. Inform the requesting organization in writing whether the requested extension has been approved or disapproved. 3.24.1.2.1. If the evaluation of the extension request leads to a disapproval, the extension approval authority will contact the requestor to determine if additional risk mitigation procedures are available. 3.24.1.2.1.1. If additional risk mitigation procedures are available, the requesting organization may supplement their original extension request package and request reevaluation of their request. 3.24.1.2.1.2. If additional risk mitigation approval procedures are not available, the extension approval authority will direct any required corrective actions based on the assessed risk to the AFEN (e.g., disconnect/isolate non-compliant workstations from the network) 3.24.1.2.2. First extension approval authority extension approvals/disapprovals will address the following in their response: 3.24.1.2.2.1. Whether the level of risk imposed on the AFEN is acceptable/unacceptable. 3.24.1.2.2.2. State the potential operational impacts to the AFEN. 3.24.1.3. Provide the AFNOSC a copy of all approved first extensions. 3.24.1.4. Periodically review existing extensions to ensure requesting organizations are making satisfactory progress towards achieving full compliance and/or processing a second extension request as necessary. 3.24.2. For all second and third extensions the AFNOSC will: 3.24.2.1. Log and track all extension requests (i.e., recommendations, approvals, extensions, disapprovals, and terminations) throughout the extension process. 3.24.2.2. Inform the requesting organization in writing whether the requested extension has been approved or disapproved. 3.24.2.2.1. If the evaluation of the extension request leads to a disapproval, the AFNOSC will contact the requestor to determine if additional risk mitigation procedures are available. 3.24.2.2.1.1. If additional risk mitigation procedures are available, the requesting organization may supplement their original extension request package and request reevaluation of their request.

AFI33-138 28 NOVEMBER 2005

27

3.24.2.2.1.2. If additional risk mitigation approval procedures are not available, the AFNOSC will direct any required corrective actions based on the assessed risk to the AFEN (e.g., disconnect/isolate non-compliant workstations from the network). 3.24.2.2.2. AFNOSC extension approvals/disapprovals will address the following in an endorsement cover letter: 3.24.2.2.2.1. Whether the level of risk imposed on the AFEN is acceptable/unacceptable. 3.24.2.2.2.2. State the potential operational impacts to the AFEN. 3.24.2.3. Periodically review existing extensions to ensure requesting organizations are making satisfactory progress towards achieving full compliance and/or processing an additional extension request as necessary. 3.24.3. The AFNOSC will make current TCNO extension information available to NCCs, NOSCs, PMOs, SPOs, and SAF/XCI. Section 3F--TCNO Compliance Reporting 3.25. General Guidance. The ability of commanders to maintain situational awareness of the health and availability of Air Force information systems and networks is essential to their ability to make informed decisions for accomplishing assigned missions. Ensuring commanders remain aware of risks to the AFEN and Air Force information systems dictates the status of TCNO compliance be accurately tracked, compiled, and assessed. 3.26. Recording TCNO Compliance. Tracking and recording TCNO compliance begins at the level the TCNO is implemented (i.e., FSA or WM for manually implemented TCNOs on workstations or functional servers, NCC or NOSC for automated TCNO implementation or for implementation of TCNOs on core servers and infrastructure components). Compliance with each TCNO will be tracked to the "asset" level to ensure all required network/system components are addressed. For the purposes of this instruction, an asset is defined as any device connected to the AFEN. Devices include but are not limited to workstations, servers, infrastructure components (e.g., router, switch) and networked peripherals (e.g., network printers). Compliance with a TCNO is accomplished when all actions directed in the TCNO are accomplished on all affected assets. The implementation of mitigation actions not specified in a TCNO do not constitute compliance, but may be considered during the extension process and must be annotated in an extension request. 3.26.1. WMs will record and maintain the following information for each manually-implemented TCNO: 3.26.1.1. The name, rank, unit, office symbol, phone number, and E-mail address for the person who implemented the TCNO. 3.26.1.2. The date receipt of the TCNO was acknowledged to the host NCC. 3.26.1.3. A list of the compliant assets. 3.26.1.4. Exception details, as applicable, to include the identifying information (e.g., computer name) for assets on which TCNO compliance was not achieved and the specific reasons TCNO compliance was not achieved or was delayed.

28

AFI33-138 28 NOVEMBER 2005 3.26.1.5. The date compliance was achieved and reported to the host NCC. 3.26.2. FSAs will record and maintain the following information for each TCNO implemented on their functional system. NOTE: These requirements are in addition to and separate from any documentation requirements levied by the controlling PMO or SPO: 3.26.2.1. The name, rank, unit, office symbol, phone number, and E-mail address for the person who implemented the TCNO. 3.26.2.2. The date receipt of the TCNO was acknowledged to the host NCC. 3.26.2.3. Exception details, as applicable, to include any reason TCNO compliance was not achieved or was delayed (e.g., the program PMO and SPO is developing a software release). Record the estimated date compliance will be achieved. 3.26.2.4. The date compliance was achieved, verified, and reported to the host NCC. 3.26.3. NOSC/NCC crew members will record and maintain the following information for each TCNO implemented by automated means (e.g., a script designed to run and install a software patch at startup or network login, automated patch distribution): 3.26.3.1. The name, rank, unit, office symbol, phone number, and E-mail address for the person who implemented the TCNO. 3.26.3.2. The date receipt of the TCNO was acknowledged. 3.26.3.3. A description of the automated process utilized. 3.26.3.4. A list of all the assets successfully patched via the automated process. 3.26.3.5. Exception details, as applicable, to include the identifying details (e.g., computer name) of assets on which TCNO compliance was not achieved and the specific reasons TCNO compliance was not achieved or was delayed. 3.26.3.6. The date compliance was achieved, verified, and reported to the next higher level. 3.26.4. NOSC/NCC crew members will record and maintain the following information for each TCNO implemented on a core server or infrastructure component (see paragraph 3.17. for further detail on two-person compliance). NOTE: The information listed below will be recorded by asset (i.e., individual core server or infrastructure component) so that a complete record of changes made to that asset is retained: 3.26.4.1. Identifying information for the asset (e.g., server name, network address). 3.26.4.2. The date receipt of the TCNO was acknowledged. 3.26.4.3. The name, rank, unit, office symbol, phone number, and E-mail address for the NOSC/ NCC crew member who implemented the TCNO. 3.26.4.4. The name, rank, unit, office symbol, phone number, and E-mail address for the NOSC/ NCC crew member who validated the implementation of the TCNO. 3.26.4.5. Exception details, as applicable, listing specific reasons TCNO compliance was not achieved or was delayed. 3.26.4.6. The date compliance was achieved, verified, and reported to the next higher level.

AFI33-138 28 NOVEMBER 2005

29

3.26.5. FSAs, WMs, NCCs, NOSCs, and the AFNOSC will retain the specific information listed above as well as all other relevant TCNO compliance related communications in accordance with Air Force Web-RIMS RDS, https://webrims.amc.af.mil/rds/index.cfm. 3.27. Compiling TCNO Compliance Statistics. In addition to the information listed in paragraph 3.26., FSAs, WMs, NCCs, NOSCs, and the AFNOSC will compile the following information at their respective levels. This information is used for up-channel reporting of TCNO compliance. NOTE: FSAs and WMs are only responsible for compiling this information for those TCNOs applied manually. 3.27.1. Unclassified Workstations. 3.27.1.1. The total number of workstations affected by the TCNO. 3.27.1.2. The total number of workstations in compliance with the TCNO. 3.27.1.3. The total number of non-compliant workstations with an approved extension. 3.27.1.4. The total number of non-compliant workstations without an approved extension. 3.27.2. Classified Workstations. 3.27.2.1. The total number of workstations affected by the TCNO. 3.27.2.2. The total number of workstations in compliance with the TCNO. 3.27.2.3. The total number of non-compliant workstations with an approved extension. 3.27.2.4. The total number of non-compliant workstations without an approved extension. 3.27.3. Unclassified Core Servers, Infrastructure Components, and Functional Servers. 3.27.3.1. The total number of assets affected by the TCNO. 3.27.3.2. The total number of assets in compliance with the TCNO. 3.27.3.3. The total number of non-compliant assets. 3.27.3.4. If TCNO compliance has not been achieved due to the unavailability of a patch/countermeasure for a PMO/SPO-controlled functional system, document the specific functional system and the number of functional system assets affected. 3.27.4. Classified Core Servers, Infrastructure Components, and Functional Servers. 3.27.4.1. The total number of assets affected by the TCNO. 3.27.4.2. The total number of assets in compliance with the TCNO. 3.27.4.3. The total number of non-compliant assets. 3.27.4.4. If TCNO compliance has not been achieved due to the unavailability of a patch/countermeasure for a PMO/SPO-controlled functional system, document the specific functional system and the number of functional system assets affected. 3.27.5. If the TCNO compliance date has passed, include an explanation for why the organization has been unable to achieve TCNO compliance, describe the mitigation actions that have been taken to protect the noncompliant assets, and provide an estimated compliance date.

30

AFI33-138 28 NOVEMBER 2005

3.28. Initial and Follow-On TCNO Compliance Statistics Reporting. The timely up-channel flow of TCNO compliance statistics through the AFNETOPS hierarchy provides a picture of overall risk to the AFEN and Air Force information systems. All organizations have the responsibility to ensure their compliance status reports are timely, accurate, and reflect the actual compliance status of the network enclaves and information systems for which they have responsibility. Initial and follow-up reporting of compliance statistics will be conducted as follows: 3.28.1. FSAs and WMs will record and compile their TCNO compliance information for those TCNOs applied manually and report it to their servicing NCC or NOSC in the manner and within the initial reporting timeframe specified by their servicing NCC or NOSC. 3.28.2. NCCs will work with all FSAs and WMs within the NCC's AOR to attain initial compliance status as quickly as possible. NCCs will submit initial compliance statistics to their NOSC within the initial reporting timeframe directed by their NOSC. 3.28.3. NOSCs will ensure initial compliance statistics from subordinate NCCs are received, compiled, and forwarded to the AFNOSC within the initial reporting timeframe established by the TCNO. 3.28.4. DELETED 3.28.5. The AFNOSC will record and compile TCNO compliance statistics from all NOSCs. The AFNOSC will provide updates of Air Force compliance with TCNO-linked IAVAs to the JTF-GNO based on this compiled information. 3.28.6. FSAs, WMs, NCCs, and NOSCs will send follow-on reports to their next higher echelon as compliance status changes. To facilitate up-channel reporting to HQ USAF and JTF-GNO, all roll up status must be submitted weekly to the AFNOSC no later than 1800Z every Monday until full TCNO compliance is achieved. 3.28.7. Reporting of compliance statistics by subordinate to higher-echelon organizations will be accomplished using one of the following methods: 3.28.7.1. Organizations will use eTANG to report compliance statistics according to the timeframes established by the recipient's next higher echelon. 3.28.7.2. Organizations that do not have access to eTANG will send a compliance statistics message via SIPRNET E-mail. The subject line of the message will be in the format "COMPLIANCE STATISTICS FOR TCNO Tracking Number" where TCNO Tracking Number is the assigned number for the TCNO being reported. For example, "COMPLIANCE STATISTICS FOR TCNO AFNOSC 2004-052-001." 3.29. Preventing Duplicate TCNO Compliance Information. To ensure an accurate picture of the Air Force's TCNO compliance can be built, it is critical that TCNO compliance be reported through only one hierarchical reporting channel. 3.29.1. The host NCC is responsible for compiling and reporting TCNO compliance information for all host base units connected to any NCC-controlled network. 3.29.2. All Air Force tenant units, to include tenant GSUs, residing on an Air Force base and connected to any NCC-controlled network shall comply with the security policy of the host NCC. Accordingly, all NCC-serviced tenant units and GSUs must report compliance through their host NCC, regardless of parent MAJCOM/FOA/DRU.

AFI33-138 28 NOVEMBER 2005

31

3.29.3. An NCC-serviced tenant unit or GSU may be tasked to provide copies of TCNO compliance information to their parent MAJCOM/FOA/DRU but that parent unit should not include that information in their consolidated report. The tenant unit and GSU must inform their parent unit that their compliance status has already been reported to their host NCC. 3.29.4. Per CJCSM 6510.01, non-Air Force tenant units connected to an Air Force-network must report IAVA compliance information to their parent combatant command, service, or agency and they must provide an information copy to their host NCC. Compliance information for these non-Air Force tenant units should be included in up-channel compliance reports but should be accompanied by a comment indicating that it is for information only; i.e., that it should not be reported by the AFNOSC to the JTF-GNO for those TCNOs linked to an IAVA. 3.29.5. This paragraph provides a practical example of the guidance provided in the preceding paragraphs. The host NCC on an ACC base services an AETC tenant unit. The AETC tenant unit will report TCNO compliance status to the host NCC. The host base NCC will include the AETC tenant unit's TCNO compliance status when reporting to the ACC NOSC. The ACC NOSC subsequently includes the AETC tenant unit's TCNO compliance status information when reporting ACC's TCNO compliance status to the AFNOSC. AETC may also task their tenant unit to report TCNO compliance statistics to the AETC NOSC; however, when the AETC NOSC reports TCNO compliance status to the AFNOSC they must not include their tenant unit's compliance information as the AFNOSC has already received the status of those assets in the data reported by ACC. 3.30. Resolving TCNO Compliance Reporting Discrepancies. Resolve all discrepancies with reported compliance information at the lowest level possible. In other words, NCCs should resolve TCNO compliance status discrepancies reported by FSAs/WMs before reporting status to their NOSC, and the NOSCs should resolve obvious discrepancies before reporting their status to the AFNOSC. For example, a PMO has indicated TCNO compliance cannot be achieved on their functional system until the next scheduled software release, which exceeds the TCNO compliance date, yet the local FSA reports TCNO compliance. This is an obvious discrepancy and should be resolved before sending the report to the NOSC. Section 3G--Assessing TCNO Compliance 3.31. TCNO Compliance Levels. Assessing TCNO and associated IAVA compliance information provides commanders at all levels with situational awareness of the risks imposed on the AFEN and Air Force information systems. Achieving 100% compliance with all TCNOs is and will remain the ultimate goal to ensure the security and integrity of the AFEN and the information contained therein. The following compliance assessment construct grants commanders the flexibility to balance available resources against operational risk while still meeting Air Force compliance standards. The following paragraphs and Table 3.5. describe the five defined compliance levels. 3.31.1. Compliance Level 1 (CL 1), GREEN. 100% of core servers and infrastructure components are patched with documented two-person compliance (see paragraph 3.17.), 100% of functional servers are patched, and at least 95% of all workstations are patched. The following actions must be taken and documented in a mitigation plan for those workstations not yet patched: 3.31.1.1. Establish positive identification of all workstations not patched. 3.31.1.2. Conduct an operational risk management assessment of potential impact to local and Air Force missions if vulnerable workstations are exploited.

32

AFI33-138 28 NOVEMBER 2005 3.31.1.3. Ensure the ability exists to isolate all vulnerable workstations should they be exploited. 3.31.1.4. Ensure all attempts possible have been made to patch all workstations through both automated and manual means. 3.31.2. Compliance Level 2 (CL 2), YELLOW. 100% of core servers and infrastructure components are patched with documented two-person compliance (see paragraph 3.17.), 100% of functional servers are patched, and less than 95% of all workstations are patched and an extension has been submitted and approved by the appropriate authority as listed in Table 3.4. 3.31.3. Compliance Level 3 (CL 3), ORANGE. 100% of core servers and infrastructure components are patched with documented two-person compliance (see paragraph 3.17.), 100% of functional servers are patched, and less than 95% of all workstations are patched and an extension has not been approved. 3.31.4. Compliance Level 4 (CL 4), RED. Less than 100% of core servers, infrastructure components, and functional servers are patched. 3.31.5. Compliance Level 5 (CL 5), BLUE. This compliance level is identical to Compliance Level 1 with the exception that it is used when one or more functional servers cannot be patched by the local installation due to the fact that the controlling PMO/SPO has not released a patch/fix action.

Table 3.5. TCNO Compliance Levels. Level CL 1­GREEN Conditions 100% Core (with documented two-person compliance); 100% Functional; >= 95% Workstations with Mitigation Plan

CL 2­YELLOW 100% Core (with documented two-person compliance); 100% Functional; < 95% Workstations with Extension CL 3­ORANGE 100% Core (with documented two-person compliance); 100% Functional; < 95% of Workstations without Extension CL 4­RED CL 5­BLUE < 100% Core/Functional 100% Core; Awaiting Functional; >= 95% of Workstations with Mitigation Plan

AFI33-138 28 NOVEMBER 2005 Chapter 4 C4 NOTAM MANAGEMENT

33

4.1. Introduction. Command, Control, Communications, and Computers Notice to Airmen (C4 NOTAM) are closely related to TCNOs with the primary difference being that they are informative in nature and are not used to direct actions. They are used by all organizations within the AFNETOPS hierarchy. They are the primary means for disseminating network information that does not direct specific action to be taken, or compliance to be tracked. In some cases, acknowledging receipt of a C4 NOTAM may be required. 4.2. Types of C4 NOTAMs. The types of C4 NOTAMs are Informative, Scheduled Event, Unscheduled Event, and Summary. 4.2.1. Informative C4 NOTAMs (IC4N). IC4Ns can be received from and sent by all levels of the AFNETOPS hierarchy. They serve as the primary vehicle for disseminating network information to Airmen that does not require specific actions to be taken or compliance to be tracked. In some cases, acknowledging receipt of an IC4N may be required. IC4Ns do not require compliance reporting, instead the responsibility remains with the recipient to take actions that best fit their situation. See Attachment 5 for a sample. 4.2.2. Unscheduled Event C4 NOTAMs (UEC4N). UEC4Ns are the standard format for network event reporting. All levels of the AFNETOPS hierarchy can transmit a UEC4N to notify others of any significant network event. The most common types of information included in this report will be, but not limited to, network and equipment outages, incidents, and newly detected vulnerabilities. The sender will be responsible for releasing, initial, update, and final UEC4Ns, as needed. See Attachment 6 for a sample UEC4N and Chapter 5, Chapter 6, and Chapter 7 for guidance on the use of UEC4Ns within the incident, vulnerability, security incident, and service interruption reporting processes. 4.2.3. Scheduled Event C4 NOTAMs (SEC4N). SEC4Ns are used by all levels of the AFNETOPS hierarchy to report scheduled network events including, but not limited to, preventive maintenance, upgrades, or authorized service interruptions. The sender will be responsible for releasing, initial, update, and final SEC4N as needed. See Attachment 6 for a sample and Chapter 7 for guidance on the use of SEC4Ns within the service interruption reporting process. 4.2.4. Summary C4 NOTAMs (SC4N). SC4Ns are similar in nature to an Informative C4 NOTAM but have a broader scope and are prepared and transmitted on a recurring basis, typically once each day. Their primary use is for up-channel notification of summary status from the various NCCs to their NOSC and from the various NOSCs to the AFNOSC. See Attachment 7 for a sample. 4.3. C4 NOTAM Formatting Guidance. To facilitate standardized report formats, C4 NOTAMs will be built using the same general template as TCNOs. The following paragraphs provide guidance specific to the generation of C4 NOTAMs. 4.3.1. Assigning a Tracking Number. C4 NOTAM tracking numbers are built based on the day they are released (recorded as Julian date and year) and the order of release during that given day. The standard numbering format is: the identifier "C4-N," issuing agency, four-digit year, three-digit Julian

34

AFI33-138 28 NOVEMBER 2005 date, and a three-digit increment number. For example, the tracking number assigned to the first C4 NOTAM released on 19 Jan 2004 would be "C4-N AFNOSC 2004-019-001." 4.3.2. Establishing C4 NOTAM Priority. The releasing agency assigns a C4 NOTAM priority based on an assessment of the scope and potential impact of the topic being addressed to the AFEN and supported operations. NOSCs releasing a MAJCOM-specific C4 NOTAM do not need to coordinate with the AFNOSC when assigning priority. The five defined priorities to be used when generating C4 NOTAMs are summarized in Table 4.1.

Table 4.1. C4 NOTAM Priority Categories. Priority Description Critical The topic being addressed informs recipients of a widespread and imminent/ongoing threat to the AFEN and/or provides details on a network/system outage negatively impacting ongoing combat operations. Serious The topic being addressed informs recipients of an expected threat to the AFEN and/or provides details on a network/system outage negatively impacting ongoing combat support operations. High The topic being addressed informs recipients of a likely threat to the AFEN and/or provides details on a network/system outage negatively impacting ongoing administrative/business operations across a major enclave of the AFEN (i.e., MAJCOM-wide outage).

Medium The topic being addressed informs recipients of a threat not expected to impact the AFEN and/ or provides details on a network/system outage negatively impacting ongoing administrative/ business operations at a single Air Force installation. Low The topic being addressed is purely informative in nature.

4.4. C4 NOTAM Dissemination. Originating organizations will disseminate C4 NOTAMs using eTANG where available. If the originating organization does not have access to eTANG, then SIPRNET E-mail or NIPRNET DMS message are the preferred alternate means of distribution.

AFI33-138 28 NOVEMBER 2005 Chapter 5 INCIDENT AND VULNERABILITY REPORTING Section 5A--Introduction and General Procedures

35

5.1. Purpose. The overall purpose of the various incident and vulnerability reporting processes is to improve the overall security posture of the AFEN, Air Force information systems, and stand-alone computing devices through quick positive control and reporting of network and information system incidents. The following sections detail the minimum required policies, procedures, and report formats to handle, process, and report: 5.1.1. Incidents. This includes network/system incidents such as intrusions, scans, probes, and malicious logic events. Reporting accurate incident information as close to near-real-time as possible is crucial to effective countermeasure response. Refer to Section 5B for specific guidance. 5.1.2. Vulnerabilities. Anyone detecting a new vulnerability must report it through the chain of command. Timely, accurate vulnerability reports are crucial to the success of mitigating the threats posed by identified vulnerabilities. A TCNO may be generated as a direct result of vulnerability reports. Refer to Section 5C for specific guidance. 5.2. General Reporting Requirements. 5.2.1. End users and Air Force network professionals (e.g., NOSC and NCC personnel, FSAs, WMs, ISSOs, ISSMs) must report all identified incidents and vulnerabilities. 5.2.2. The AFNOSC, as the Air Force service component to JTF-GNO, is responsible for reporting all incident and vulnerability information in accordance with CJCSM 6510.01, and any supplemental direction published by JTF-GNO. 5.2.3. NOTE: Report Sensitive Compartmented Information incidents, assessments, and other unauthorized network activity according to applicable Defense Intelligence Agency or National Security Agency procedures. 5.3. Incident and Vulnerability Report Classification Guidance. 5.3.1. Classified Report Guidance. Mark, handle, store, and transmit all classified reports according to AFI 31-401, Information Security Program Management. Consult security classification guides (e.g., AFI 10-2005, Defensive Counterinformation Security Classification Guide), as necessary to assist in assigning an appropriate classification. Consider classifying a report when an incident or vulnerability's impact possesses the potential to cause: 5.3.1.1. Damage, serious damage, or grave damage to national security. 5.3.1.2. Failure of the entire AFEN, or significant portion thereof. 5.3.1.3. Failure of one or more MAJCOM networks. 5.3.1.4. Failure of an entire base network. 5.3.1.5. Failure of a Command and Control (C2) functional system.

36

AFI33-138 28 NOVEMBER 2005 5.3.1.6. Significant adverse operational impact to a critical mission due to the aggregated effect of an incident (e.g., exploited vulnerability, classified message incident, denial of service attack). 5.3.2. Unclassified Report Guidance. Mark all unclassified reports as "For Official Use Only" (FOUO) and protect the report from public distribution under Freedom of Information Act Exemption Number 2 from Air Force Supplement to DOD Regulation 5400.7 (DODR 5400.7/AFSUP1), DOD Freedom of Information Act Program. Mark reports as FOUO when: 5.3.2.1. An incident DOES NOT result in a compromise or significant adverse impact to national security; Air Force, MAJCOM, or wing operational missions or networks. 5.3.2.2. A report identifies an incident on a specific unclassified network, information systems, or stand-alone computing device.

Section 5B--Incident Reporting 5.4. Incidents Defined. Incidents, within the context of this instruction, include attempted entry, unauthorized entry, and attacks on an information system to include: unauthorized probing, browsing; disruption or denial of service; altered or destroyed input, processing, storage, or output of information; or changes to system hardware, firmware, or software characteristics with or without the users knowledge, instruction or intent (e.g., malicious logic). An incident may also involve a violation of law. If a violation of law is evident or suspected, the incident must also be reported to law enforcement organizations for appropriate action. Table 5.1. defines seven distinct incident categories utilized by the Air Force to characterize detected incidents (derived from CJCSM 6510.01). Table 5.1. Incident Categories. Category Description I II III Root-Level Intrusion: An unauthorized person gained root-level access/privileges on an Air Force computer/information system/network device. User-Level Intrusion: An unauthorized person gained user-level privileges on an Air Force computer/information system/network device. Attempted Access: An unauthorized person specifically targeted a service/vulnerability on an Air Force computer/information system/network device in an attempt to gain unauthorized or increased access/privileges, but was denied access. Denial of Service (DoS): Use of an Air Force computer/information system/network was denied due to an overwhelming volume of unauthorized network traffic. Poor Security Practice: An Air Force computer/information system/network was incorrectly configured or a user did not follow established policy. Scan/Probe: Open ports on an Air Force computer/information system/network device were scanned with no DoS or mission impact. Malicious Logic: Hostile code successfully infected an Air Force computer/information system/network device. Unless otherwise directed, only those computers that were infected will be reported as a Category VII incident.

IV V VI VII

AFI33-138 28 NOVEMBER 2005

37

5.5. Incident Detection. There are several ways an incident may be detected. The primary detection tool is the fleet of Automated Security Incident Measurement (ASIM) sensors deployed across the AFEN. Additional techniques employed to detect incidents include but are not limited to: review of critical audit logs by network professionals (e.g., Firewall logs); virus detection and prevention software; and reporting of anomalous network/information system events by end users and network professionals. Reporting accurate incident information as close to near real time as possible is crucial to effective response. 5.6. General Incident Response Actions. In addition to the specific reporting actions specified throughout this section, the AFNOSC, NOSCs, and NCCs are authorized to: 5.6.1. Terminate network services and isolate an offending network or system until an incident is resolved. NOTE: Coordinate these actions with the AFNOSC prior to taking action. Also coordinate with the responsible DAA and affected commanders. 5.6.2. Restore network services and connectivity to systems that were previously terminated due to incident response actions. 5.7. ASIM-Identified Incidents. ASIM sensors are utilized to monitor the various enclaves that make up the AFEN. The events identified by an ASIM sensor are analyzed by crew members at the NOSCs and the AFNOSC, and Incident Reports (IR) are created for any confirmed incidents as follows. 5.7.1. Assign a category for each IR from those defined in Table 5.1. 5.7.2. The AFNOSC will assign an incident report identification (IRID) number upon confirmation of a Category I, II, IV, or VII incident that consists of the letters "IR", the four-digit calendar year, and a three-digit serial number. For example: IR-2004-018, where 2004 is the calendar year and 018 is the 18th incident for that year. 5.7.3. NOSCs send IRs to the NCC ASIM point of contact (POC) (typically the Intrusion Detection Specialist), who in turn forwards the report to the affected network or information system owner for action (i.e., end user, WM, FSA, etc.). 5.7.4. The user validates the IR, corrects the situation as required, and prepares a response according to the criteria below: 5.7.4.1. Category I, II, and IV Incidents. Provide the required information to complete an IR according to paragraph 5.8. and Attachment 8, and provide a response as directed (no later than 24 hours). 5.7.4.2. Category VII Incidents. Provide the required information to complete a Malicious Logic Report according to paragraph 5.9. and Attachment 9, and send a written response as directed (no later than 72 hours). 5.8. Incident Reporting. The NCCs, NOSCs, and AFNOSC record suspicious and unauthorized network and information systems access and activity. Suspicious activity may include detection of network scanning, multiple connection attempts to a network device from an unknown entity, etc. Intrusion activity may include unauthorized individuals gaining full (root) or limited (user) access to a network device or information system, and unusual or excessive network activity. Upon detecting a suspected or verified incident, immediately notify the Primary Recipient according to the guidance in Table 5.2. and Attachment 8. Reporting of malicious logic incidents (Category VII) is covered in paragraph 5.9.

38 Table 5.2. Incident Reporting Action Matrix. then take the indicated Actions 1 2, 8 2, 8 2, 8 2, 8 3, 8 4-8 and the Primary Recipient will be WM NCC NCC NCC NCC NOSC AFNOSC

AFI33-138 28 NOVEMBER 2005

If the originator / recipient of the IR is End User WM FSA ISSO ISSM NCC NOSC Actions 1

and Informational Recipients will be N/A ISSO and FSA ISSO/ISSM ISSM and Wing IA Office Wing IA Office and DAA Wing/FOA/DRU IA Office and DAA MAJCOM IA Office and MAJCOM DAA

Upon detection of an incident, end users will immediately notify their assigned WM and provide information to assist the WM making required notifications and in filling out an IR. If the WM is unavailable, end users will immediately notify the next computer security professional in the chain of command (i.e., FSA, NCC, NOSC, ISSO, ISSM, etc.). Upon detection or notification of an incident, the WM, FSA, ISSO, or ISSM will notify their servicing NCC. After notifying the NCC, the WM, FSA, ISSO, or ISSM will prepare and transmit an IR to the servicing NCC. If there is no servicing NCC, send the IR directly to the parent NOSC. Upon detection or notification of an incident, notify the parent NOSC. After notifying the NOSC, prepare and send an IR to their parent NOSC. Upon detection or notification of an incident, contact the AFNOSC for assessment of the incident and assignment of an IRID (upon validation). After making initial contact with the AFNOSC, follow-up by submitting an initial IR and generate a UEC4N to track the event. Submit an update IR every 7 days until all actions required to resolve the incident are complete. Submit a final IR within 24 hours of the all action related to the incident being completed. Send an informational copy of all IRs to the Informational Recipients indicated.

2

3 4 5 6 7 8

5.9. Malicious Logic Incidents. All end users accessing the AFEN are required to report unusual network, information system, and stand-alone computing device events suspected to stem from some form of malicious logic as follows: 5.9.1. Prepare malicious logic reports (MLR) according to the guidance in Table 5.3. and Attachment 9 for each malicious logic incident (Category VII) that occurs. NOTE: If multiple infections occur due to the same variant of a worm, virus, etc., report the infection as one malicious logic incident. 5.9.2. Unless otherwise directed by the AFNOSC, do not up-channel report any malicious logic event that was detected and eradicated by approved anti-virus software.

AFI33-138 28 NOVEMBER 2005 Table 5.3. Malicious Logic Reporting Action Matrix. then take the indicated Actions 1 2, 3, 9 2, 3, 9 2, 3, 9 2, 3, 9 4, 9 5-9 and the Primary Recipient will be WM NCC NCC NCC NCC NOSC AFNOSC

39

If the originator / recipient of the MLR is End User WM FSA ISSO ISSM NCC NOSC Actions 1

and Informational Recipients will be N/A ISSO and FSA ISSO/ISSM ISSM and Wing IA Office Wing IA Office and DAA Wing/FOA/DRU IA Office and DAA MAJCOM IA Office and MAJCOM DAA

End users will immediately report any suspected or actual malicious logic incident to their WM. This includes reporting all virus alerts generated by anti-virus software, whether the user believes them to be valid or not. If the WM is unavailable, end users must report the event to the next network or computer security professional in the chain of command (i.e., ISSO, ISSM, FSA, etc.) Remove the malicious logic and gather information from the end user to prepare an MLR. WM, FSA, ISSO and ISSM will submit an MLR to the servicing NCC. If there is no servicing NCC send the MLR directly to the parent NOSC. For malicious logic events that result in an infection (i.e., the malicious logic was not quarantined or eradicated by anti-virus software), the NCC will immediately submit an MLR to their parent NOSC and will provide periodic updates to the NOSC until the malicious logic has been eradicated. NOSC will create and update MLR incident records through the Computer Security Assistance Program 21st Century Database System (CDS). For those organizations that do not have access to CDS, submit final MLRs directly to the AFNOSC via E-mail. Submit an initial UEC4N to the AFNOSC upon initial notification of a confirmed malicious logic infection within their AOR. Submit an update UEC4N every 24 hours until the malicious logic is eradicated. Submit a final UEC4N within 24 hours of a malicious logic infection being eradicated. Send an informational copy of all MLRs to the Informational Recipients indicated.

2 3 4

5

6 7 8 9

Section 5C--Vulnerability Reporting 5.10. Vulnerability Reporting. Anyone detecting a newly discovered vulnerability or unexplained network/system anomaly for which no risk mitigation procedure has been established must report it as detailed in Table 5.4. and Attachment 10. 5.10.1. If the newly discovered vulnerability or unexplained network/system anomaly was exploited or an actual incident occurred, go directly to Section 5B.

40

AFI33-138 28 NOVEMBER 2005 5.10.2. The AFNOSC will assign a Vulnerability Report Identifier (VRID) that consists of the letters "VR", the originator's parent organization (i.e., MAJCOM, FOA, DRU), the four-digit calendar year, and a three-digit serial number. For example: VR-USAFE-2004-003, where the USAFE NOSC is the originating organization, 2004 is the calendar year, and 003 is the 3rd vulnerability identified for that year.

Table 5.4. Vulnerability Reporting Action Matrix. then take the indicated Actions 1 2, 9 2, 9 2, 9 2, 9 3, 7- 9 4, 5, 7- 9 6-9 and the Primary Recipient will be WM NCC NCC NCC NCC NOSC AFNOSC

If the originator / recipient of the VR is End User WM FSA ISSO ISSM NCC NOSC PMO or SPO Actions 1

and Informational Recipients will be N/A ISSO and FSA ISSO/ISSM ISSM and Wing IA Office Wing IA Office and DAA Wing/FOA/DRU IA Office and DAA MAJCOM IA Office and MAJCOM DAA

N O S C o r Functional System DAA AFNOSC

Upon detection of a vulnerability, end users will immediately provide information to their WM to assist the WM in filling out an initial Vulnerability Report (VR). If the WM is unavailable, end users will immediately notify the next computer security professional in the chain of command (i.e., ISSO, ISSM, FSA, NCC, NOSC). WM, FSA, ISSO, and ISSM prepare and send reports to the servicing NCC. If there is no servicing NCC send the report directly to the parent NOSC. NCCs prepare and send reports to their parent NOSC. NOSCs, and USAF PMOs/SPOs will contact the AFNOSC to obtain a VR tracking number. Prepare and send an initial VR to the AFNOSC within 24 hours of detection. Generate a UEC4N to track the event. PMOs or SPOs detecting a vulnerability in their functional system will prepare and submit a VR to their servicing NOSC (MAJCOM PMO/SPO) or to the AFNOSC (USAF PMO/SPO). Prepare and send update VR to the Primary Recipient as directed (at least every 30 days). Prepare and send a final VR to the Primary Recipient within 5 days of resolution. Send an informational copy of all VRs to the Informational Recipients indicated.

2 3 4 5 6 7 8 9

AFI33-138 28 NOVEMBER 2005 Chapter 6 SECURITY INCIDENT REPORTING

41

6.1. Security Incidents. The introduction of information that is classified above the level that a network, information system, or stand-alone computing device is authorized to process results in a security incident. Prompt security incident reporting facilitates rapid containment of the situation and helps to determine how the classified information was introduced to the system, its overall impact on AFEN operations, the effect on Air Force operational missions, and what can be done to prevent future occurrences. The most common type of security incident within the information system environment involves the inadvertent dissemination of classified information through an unclassified E-mail, either within the body of the E-mail or as an attachment. In these situations, known as CMIs, additional steps must be taken to prevent the rapid proliferation of the message throughout the Air Force (see paragraph 6.5.). 6.2. Related Guidance. In addition to the reporting requirements established within this instruction, the following additional reporting guidance must be followed: 6.2.1. AFI 31-401, Information Security Program Management. AFI 31-401 provides detailed guidance on conducting security incident inquiries/investigations and requires that all security incidents involving Information Systems be coordinated with Unit Security Managers and the installation Information Security Program Manager (ISPM). 6.2.2. AFI 33-212, Reporting COMSEC Deviations. AFI 33-212 provides specific guidance for dealing with security incidents where communication security (COMSEC) material is involved. 6.3. Classification Guidance. Protect the transmission, reception, and storage of security incident information and reports at the same level of classification as the information compromised. This guidance applies to all verbal as well as written communications. All details of the security incident are classified until the systems involved are sanitized and the information is no longer accessible to unauthorized personnel. Refer to AFI 31-401 for additional guidance. 6.4. Security Incident Reporting. In addition to the security incident reporting and resolution requirements in AFI 31-401, every person involved in an security incident must provide all relevant information to their WM, FSA, ISSO, ISSM, etc., or to their respective NCC, NOSC, as quickly and in as much detail as is known, according to the guidance in this chapter, Table 6.1., and in Attachment 11. 6.4.1. Minimum Initial Security Incident Report (SIR) Requirements. The WM, FSA, ISSO, or ISSM verbally submits the following information immediately to the NCC via secure means: 6.4.1.1. The location of the file/message (e.g., a shared network drive, a workstation hard drive, an end users E-mail store). 6.4.1.2. The originator of the classified file/message and their organization. 6.4.1.3. All known personnel who have access to, or are known to have accessed, the file. In the case of a CMI, all recipients of the classified information (e.g., file, message) including those to whom the message was originally sent and those to whom the message was forwarded. 6.4.2. SIR Identifier (SIRID). NOSCs will assign a single SIRID for each non-related security incident. The tracking number is based on the source (i.e., the MAJCOM, FOA, or DRU where the secu-

42

AFI33-138 28 NOVEMBER 2005 rity incident occurred or from where the message originated in the case of CMIs) and consists of: the letters "SI"; the MAJCOM, FOA, or DRU; the four digit calendar year; and a serial number. For example: SI-ACC-2004-002, where the ACC NOSC is the parent NOSC, 2004 is the calendar year, and 002 is the serial number indicating the security incident is the second recorded for that year. The NOSC immediately provides the SIRID to its subordinate NCC via secure means. 6.4.3. SIR Analysis. Each NOSC will track and compile information contained in each SIR for analysis purposes to determine the best methods to prevent future occurrences.

6.5. Classified Message Incidents (CMI). In addition to the general security incident actions elaborated in paragraph 6.4., the servicing NCC must determine whether the contaminated message has been disseminated beyond its AOR (i.e., base enclave). 6.5.1. Local Containment. If the NCC is able to verify local containment of the message (i.e., no end user has sent it to another base), they will initiate reporting as detailed in paragraph 6.4. and Table 6.1., and corrective actions in accordance with paragraph 6.6. 6.5.2. Multiple Bases Affected. If it is determined that multiple bases are affected, the NCC must also determine if the classified message originated on their base or if they were a recipient from an outside sender. Once determined, the NCC: 6.5.2.1. Receiving Base: Notifies the servicing NCC at the originating location via secure means and initiates local corrective actions. 6.5.2.2. Originating Base: Notifies their parent NOSC via secure means to initiate the reporting process. The notified NOSC will then notify all other affected NOSCs, who will in turn notify their affected bases about the incident. All affected NCCs will implement local corrective actions. 6.6. Corrective Actions. To contain and resolve the security incident, NCCs will coordinate all actions with affected unit security managers, WMs, and the Information Security Program Manager (ISPM), and will implement sanitization procedures and direct the appropriate WMs to sanitize affected users' workstations in accordance with AFSSI 5020, Remanence Security.

AFI33-138 28 NOVEMBER 2005 Table 6.1. Security Incident Reporting (SIR) Action Matrix. then take the indicated Actions 1 2, 3, 10 2, 3, 10 2, 3, 10 2, 3, 10 2, 4, 7-10 5-10 and the Primary Recipient will be WM NCC NCC NCC NCC NOSC AFNOSC

43

If the originator / recipient of the SIR is End User WM FSA ISSO ISSM NCC NOSC 1

and Informational Recipients will be Unit Security Manager ISSO and FSA ISSO/ISSM ISSM and Wing IA Office Wing IA Office and DAA Wing/FOA/DRU IA Office and ISPM MAJCOM IA Office and MAJCOM DAA

Actions: (NOTE: SEND ALL REPORTS BY SECURE MEANS) Personnel discovering an electronic file, document, presentation, etc., containing information classified above the level the system is cleared for, must cease all operations on the affected system immediately and report the security incident to their WM via secure means. If the WM is unavailable, report the security incident to the next network/security professional (e.g., FSA, ISSO, ISSM, Unit Security Manager) in the chain-of-command or to the servicing NCC via secure means. Coordinate with the NCC to isolate, clear, and sanitize the affected systems and to report damage assessment information. Provide required information from paragraph 6.4.1. to the servicing NCC by secure phone. If there is no servicing NCC, provide the initial report directly to the NOSC by secure phone. Notify the NOSC immediately via secure phone and submit an initial SIR. Specify whether the security incident/CMI is contained to a single base or if it is a CMI that affects multiple sites (see paragraph 6.5.). Assign an SIRID per paragraph 6.4.2. for each reported security incident. Immediately notify the AFNOSC via secure phone and convey the initial SIR information (see paragraph 6.4.1.). Generate a UEC4N to track the resolution of the security incident. Prepare and send an appropriately classified initial SIR to the Primary Recipient. Prepare and send an update SIR to the Primary Recipient every 4 hours until the security incident is closed. Prepare and send a final SIR to the Primary Recipient within 2 hours of completing sanitization.

2 3 4

5 6 7 8 9

10 Send an informational copy of any SIR to the Informational Recipients indicated.

44 Chapter 7

AFI33-138 28 NOVEMBER 2005

SERVICE INTERRUPTION REPORTING Section 7A--Introduction and General Procedures 7.1. Introduction. The Air Force's reliance on network communications is expanding as more mission essential processes and systems become automated, integrated, and interconnected via networks. To ensure maximum availability and capability of the AFEN it is essential that the AFNETOPS hierarchy maintain situational awareness of the status of both authorized service interruptions and unscheduled service interruptions. 7.2. Operational Reporting of Mission Impact. In addition to the reporting requirements defined within this chapter, AFNETOPS organizations will prepare and submit OPREP-3s through their servicing command post for those authorized or unscheduled service interruptions that are known to have or are expected to degrade mission capability of an operational unit. Submit the OPREP-3 as a "Mission-Impairment" event in accordance with AFI 10-206. Include the AFNOSC as an addressee in addition to the minimum addressees required by AFI 10-206. 7.3. Service Interruption Reporting Classification Guidance. All reporting documents generated as a result of the processes described within this chapter (i.e., OPREP-3s, SEC4Ns, UEC4Ns) will be classified according to their content, applicable program trusted facility manuals, or applicable classification guides. Section 7B--Authorized Service Interruptions (ASI) 7.4. Authorized Service Interruption (ASI) Definition. ASIs are scheduled periods of network, equipment, or system downtime required to conduct preventive maintenance actions, software or equipment upgrades or replacement, system reboots, etc. There are three defined types of ASIs. 7.4.1. Preventive Maintenance Inspection (PMI). PMI ASIs are required for any preventive maintenance actions accomplished on a recurring basis. Examples include routine maintenance of server equipment or server reboots required due to the application of TCNO-directed countermeasures. 7.4.2. Routine. Routine ASIs are required for any network system changes that will require an interruption of service to complete. Examples include service interruptions required to perform system/ software upgrades, or to repair or replace faulty equipment. 7.4.3. Emergency. Emergency ASIs are for those ad hoc events which require an immediate service interruption to correct hazardous or degraded conditions where loss of mission capability could occur through lack of immediate action. Examples of emergency outages include power problems, equipment malfunctions, imminent system failures, or any hazardous condition that requires immediate attention and cannot otherwise be scheduled as a routine service interruption. 7.5. ASI Approval Authority. 7.5.1. The AFNETOPS/CC is the approval authority for routine and emergency ASI requests associated with those AFEN links, nodes, functional systems, or services on the AFEN (1) directly support-

AFI33-138 28 NOVEMBER 2005

45

ing an active combat operation; (2) whose compromise or loss could affect national security; (3) whose compromise or loss would degrade or disable critical C2 communications; or (4) whose compromise or loss would negatively impact a preponderance of the Air Force. The AFNOSC is the focal point for the coordination of ASIs that must be approved by the AFNETOPS/CC. NOTE: The AFNOSC will further elaborate the specific links, nodes, functional systems, or services that require AFNETOPS/CC approval through the AFNETOPS Special Instructions to Communicators (SPIN-C) and associated daily Communications Tasking Orders (CTO). 7.5.2. The MAJCOM DAA is the approval authority for all PMI ASI requests and those routine and emergency ASI requests that do not meet the criteria specified in paragraph 7.5.1. The NOSCs are the focal point for the coordination of all ASIs that must be approved by the MAJCOM DAA. 7.6. General ASI Coordination Guidance. 7.6.1. Service interruptions should be scheduled at a time that will have the minimum impact on supported end users. 7.6.2. Requesting organizations must complete applicable local level coordination (e.g., major tenant unit commanders and wing commander for NCCs; MAJCOM directors and MAJCOM DAA for NOSCs) on all ASIs prior to submitting the ASI request for approval. 7.6.3. Attachment 12 outlines the information that must be provided by the requesting organization on all ASI requests. 7.7. Submission of ASI Requests for Approval by the AFNETOPS/CC. NOSCs, FOA/DRU NCC/ MSCs, USAF PMO/SPOs will submit all routine and emergency ASI requests affecting any links, nodes, functional systems, or services as defined in paragraph 7.5.1. to the AFNOSC Net Operations Division for processing according to the timelines specified in Table 7.1. 7.8. Submission of ASI Requests for Approval by the MAJCOM DAA. NCCs and MAJCOM PMO/ SPOs will submit all PMI ASI requests, and those routine or emergency ASI requests impacting all links, nodes, functional systems, or services (that do not meet the criteria specified in paragraph 7.5.1.) to their NOSC for processing according to the timelines specified in Table 7.1. Table 7.1. ASI Submission Timelines. R U L E 1 2 3 4 5 MAJCOM DAA A If the required approval level is (paragraph 7.5.) AFNETOPS/CC B C

and the ASI type is Routine Emergency PMI Routine Emergency

then the ASI request must be submitted S 21 days prior to requested ASI date as soon as the need for the ASI is known S 3 days prior to requested ASI date as soon as the need for the ASI is known

7.9. Notification of Approved ASIs.

46

AFI33-138 28 NOVEMBER 2005 7.9.1. The primary means for notifying AFNETOPS organizations of approved ASIs is the daily CTO. All AFNETOPS/CC-approved ASIs will be listed in the daily AFNOSC CTO. All MAJCOM DAA approved ASIs will be listed in a MAJCOM-specific CTO. 7.9.2. AFNETOPS organizations responsible for executing approved ASIs will notify all affected users 7 days prior, 1 day prior, and again at 1 hour prior to a scheduled service interruption.

7.10. Tracking ASIs During Execution. AFNETOPS organizations executing ASIs will submit an initial SEC4N to the ASI approving authority and any other affected AFNETOPS organizations upon initiation of the ASI. For ASIs scheduled to exceed four hours in duration, an update SEC4N will be submitted every four hours, or as directed by the ASI approving authority. A final SEC4N will be submitted upon successful completion of the ASI. 7.11. Extension of an Ongoing ASI. In the event required ASI actions (i.e., equipment replacement, software upgrade, etc.) cannot be completed during the time period approved for the ASI, the organization executing the ASI must request an extension from the ASI approving authority. If the extension is not approved and normal operations cannot be restored within the ASI-approved time period, the outage should be reported as an unscheduled service interruption as described in Section 7C. Section 7C--Unscheduled Service Interruptions 7.12. Unscheduled Service Interruption (USI) Definition. USIs are those unscheduled network, equipment, or application outages or degradations that are caused by such things as environmental problems (e.g., fire, flood, loss of power, loss of air conditioning), equipment malfunctions, system crashes, etc. 7.13. USIs Linked to Incidents. If it is discovered during the course of troubleshooting that a USI was the result of an incident as defined in paragraph 5.4. and Table 5.1., go directly to the Incident Reporting section (Section 5B) and follow the procedures elaborated within that section. 7.14. USI Reporting Categories. Four broad categories of reportable assets/services are defined: Critical Core Service, Core Service, End User Equipment, and Functional System. Table 7.2. summarizes the four defined reporting categories. NOTE: The AFNOSC will further elaborate the specific assets and services that fall within each of the defined categories through the AFNETOPS SPIN-C and daily CTO.

AFI33-138 28 NOVEMBER 2005 Table 7.2. USI Reporting Categories. Category Description

47

Critical Core A core service whose loss or degradation would severely impair the operational Service capability of an entire network enclave. Some examples include, but are not limited to, service delivery points and directory services servers. Core Service Core services encompass user services such as E-mail, shared file/data storage, network printing and web services; network management services such as domain name system, network address management, directory services, network boundary protection; and the switched and routed networks that make up the AFEN. NOTE: Refer to AFI 33-115, Volume 1, for the complete definition of Core Services. End user equipment includes workstations, printers, peripherals, end building local area network components, etc. A specific system used, owned, operated, and maintained by a functional community.

End User Equipment Functional System

7.15. USI Reporting. Upon detection or notification of a USI, notify the Primary Recipient and take the actions as outlined in Table 7.3. Table 7.4. specifies the timelines associated with USI reporting.

48

AFI33-138 28 NOVEMBER 2005

Table 7.3. Unscheduled Service Interruption (USI) Action Matrix. If the originator / recipient of information on a USI is a WM or FSA NCC NOSC PMO or SPO Actions 1 2 Troubleshoot and resolve the identified problem when possible. Upon detection or notification of an USI that cannot be resolved at the WM-/FSA-level, notify the servicing NCC through the Help Desk. Provide all available information to assist the NCC with troubleshooting the source of the service interruption. Make an initial voice report to the Primary Recipient in accordance with Table 7.4. Prepare and submit an initial UEC4N to the Primary Recipient in accordance with Table 7.4. The initial UEC4N will contain as much detail as possible. Prepare and submit update UEC4Ns to the Primary Recipient in accordance with Table 7.4. Each update UEC4N should clearly indicate any changes that have occurred since the previously report. Prepare and submit a final UEC4N to the Primary Recipient in accordance with Table 7.4. The final UEC4N should summarize the root cause and any mission impact that resulted from the unscheduled service interruption. Report USIs to the servicing NOSC (MAJCOM PMO/SPO) or to the AFNOSC (USAF PMO/SPO) as specified by applicable AFIs, or the governing service level agreement, memorandum of understanding, or memorandum of agreement. Send an informational copy of all UEC4Ns to the Informational Recipients indicated. then take the indicated Actions 1, 2, 8 3-6, 8 3-6, 8 7, 8 and the Primary Recipient will be NCC NOSC AFNOSC NOSC or AFNOSC and Informational Recipients will be locally determined

3 4 5 6

7

8

AFI33-138 28 NOVEMBER 2005 Table 7.4. Unscheduled Service Interruption (USI) Reporting Timelines. A R U L E 1 2 3 If the reporting category is (Note 1) Critical Core Service B and the reporting individual or unit is a WM/FSA NCC NOSC C D and (Note 2) an initial voice report will be made immediately immediately immediately an initial UEC4N is submitted N/A = 30 mins = 30 mins hourly every 2 hrs update UEC4Ns submitted E F G

49

then report to NCC NOSC AFNOSC

the final UEC4N is submitted once restored to normal operations

4 5 6 7

Core Service

WM/FSA NCC NOSC

NCC NOSC AFNOSC

immediately = 30 mins = 1 hour when WM/FSA resolution not possible

N/A = 1 hour = 2 hours every 4 hrs every 8 hrs once restored to normal operations

E n d - U s e r WM or FSA NCC Equipment

N/A, a trouble ticket will be opened at the NCC

8

Functional system user functional as specified by functional system controlling authority System system help desk or support center PMO SPO or NOSC AFNOSC o r as specified by applicable AFIs, service level agreements, memorandums of understanding, or memorandums of agreement.

9

50 Chapter 8

AFI33-138 28 NOVEMBER 2005

INFORMATION COLLECTIONS, RECORDS, AND FORMS OR INFORMATION MANAGEMENT TOOLS (IMT) 8.1. Information Collections. No information collections are created by this publication. 8.2. Records. All vulnerability and incident-related documentation created in accordance with this publication will be maintained according to Air Force Web-RIMS RDS, Table 33-25, Rules 9 and 10. TCNO compliance records created in accordance with this publication (paragraph 3.26.) will be maintained according to Air Force Web-RIMS RDS, Table 33-25, Rule 11. All compiled TCNO compliance information (paragraph 3.27.) will be maintained according to Air Force Web-RIMS RDS, Table 33-25, Rule 15. Air Force Web-RIMS RDS is located at https://webrims.amc.af.mil/rds/index.cfm. 8.3. Forms or IMTs (Adopted and Prescribed). 8.3.1. Adopted Forms or IMTs. AF Form 847, Recommendation for Change of Publication. 8.3.2. Prescribed Forms or IMTs. No forms are prescribed by this publication.

DONALD J. WETEKAM, Lt Gen, USAF DCS/Installations and Logistics

AFI33-138 28 NOVEMBER 2005 Attachment 1 GLOSSARY OF REFERENCES AND SUPPORTING INFORMATION References 44 U.S.C. 3501 et seq, The Paperwork Reduction Act DODI 8500.2, Information Assurance (IA) Implementation, February 6, 2003 DODR5400.7 AFSUP1, DOD Freedom of Information Act Program

51

CJCSM 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND) AFPD 33-1, Command, Control, Communications, And Computer (C4) Systems AFPD 33-2, Information Protection (will become Information Assurance) AFPD 63-1, Capability-Based Acquisition System AFI 10-206, Operational Reporting AFI 10-2005, Defensive Counterinformation Security Classification Guide AFI 31-401, Information Security Program Management AFI 33-112, Computer Systems Management AFI 33-115, Volume 1, Network Operations (NETOPS) AFI 33-202, Network and Computer Security AFI 33-205, Information Protection Metrics and Measurement Program AFI 33-212, Reporting COMSEC Deviations AFI 33-324, The Information Collections and Reports Management Program; Controlling Internal, Public, and Interagency Air Force Information Collections AFI 33-360, Volume 2, Content Management Program-Information Management Tool (CMP-IMT) AFI 51-303, Intellectual Property--Patents, Patent Related Matters, Trademarks and Copyrights AFI 90-301, Inspector General Complaints AFMAN 23-220, Reports of Survey for Air Force Property AFMAN 37-123, Management of Records AFSSI 5020, Remanence Security Abbreviations and Acronyms AF--Air Force AFCA--Air Force Communications Agency AFEN--Air Force Enterprise Network AFNETOPS--Air Force Network Operations

52 AFNETOPS/CC--Commander of Air Force Network Operations AFI--Air Force Instruction AFMAN--Air Force Manual AFMC--Air Force Materiel Command AFNOSC--Air Force Network Operations and Security Center AOR--Area of Responsibility AFPCA--Air Force Pentagon Communications Agency AFPD--Air Force Policy Directive ASI--Authorized Service Interruption ASIM--Automated Security Incident Measurement 10 CS--10th Communications Squadron 11 CS--11th Communications Squadron C2--Command and Control

AFI33-138 28 NOVEMBER 2005

C4 NOTAM--Command, Control, Communications and Computers Notice to Airmen CAMPS--Consolidated Air Mobility Planning System CC/S/A--Combatant Command, Service, and Agency CDS--Computer Security Assistance Program 21st Century Database System CJCS--Chairman of the Joint Chiefs of Staff CL--Compliance Level COMAFFOR-CNO--Commander Air Force Forces-Computer Network Operations CMI--Classified Message Incident CND--Computer Network Defense COMSEC--Communication Security CTO--Communications Tasking Order DAA--Designated Approving Authority DISA--Defense Information Systems Agency DMS--Defense Messaging System DOD--Department of Defense DOD CERT--Department of Defense Computer Emergency Response Team DoS--Denial of Service DRU--Direct Reporting Unit DSN--Defense Switched Network

AFI33-138 28 NOVEMBER 2005 E-mail--Electronic Mail ENOSC--Enterprise Network Operations Support Cell eTANG--Enterprise Tracking and Notification Graphical User Interface FOA--Field Operating Agency FOUO--For Official Use Only FSA--Functional System Administrator GSU--Geographically Separated Unit HQ USAF--Headquarters United States Air Force IA--Information Assurance IAM--IA Manager IAO--IA Oficer IAVA--Information Assurance Vulnerability Alert IAVB--Information Assurance Vulnerability Bulletin IAVM--Information Assurance Vulnerability Management IC4N--Informative C4 NOTAM INFOCON--Information Operations Condition IP--Internet Protocol IR--Incident Report IRID--Incident Report Identifier ISPM--Information Security Program Manager ISS--Internet Security Systems ISSM--Information System Security Manager ISSO--Information System Security Officer JTF-GNO--Joint Task Force-Global Network Operations JTF-GNO CTO--JTF-GNO Global Network Operations Tasking Order LAN--Local Area Network MAJCOM--Major Command MAN--Metropolitan Area Network MLR--Malicious Logic Report MSC--Mission Support Center NCC--Network Control Center NETOPS--Network Operations

53

54 NIPRNET--Non-Secure Internet Protocol Router Network NOSC--Network Operations and Security Center OPR--Office of Primary Responsibility OPREP-3--Operational Event/Incident Report PEO--Program Executive Officers PMO--Program Management Office PMI--Preventive Maintenance Inspection POC--Point of Contact RDS--Records Disposition Schedule SC4N--Summary C4 NOTAM SEC4N--Scheduled Event C4 NOTAM SIR--Security Incident Report SIRID--Security Incident Report Identifier SIPRNET--Secret Internet Protocol Router Network SPIN-C--Special Instructions to Communicators SPO--System Program Office TA--Technical Advisory TCNO--Time Compliance Network Order UEC4N--Unscheduled Event C4 NOTAM USI--Unscheduled Service Interruption VR--Vulnerability Report VRID--Vulnerability Report Identifier WM--Workgroup Manager Terms

AFI33-138 28 NOVEMBER 2005

Air Force Enterprise Network (AFEN)--The AFEN is an information environment comprised of interoperable computing and communication components. The AFEN is part of the Global Information Grid. Therefore, the AFEN is the interconnected, end-to-end set of information capabilities, associated processes, and personnel for collecting, processing, storing, disseminating, and managing information on demand to warfighters, policy makers, and support personnel. The AFEN includes all owned and leased communications and computing systems and services, network operating systems, data, security services, and other associated services necessary to achieve information superiority. (AFI 33-115, Volume 1) Air Force Network Operations Security Center (AFNOSC)--A c o m m a n d a n d c o n t r o l e n t i t y composed of the AFNOSC Command and Control Division at Barksdale AFB LA, the AFNOSC Net Security Division (formerly the Air Force Computer Emergency Response Team) at Lackland AFB TX, and the AFNOSC Net Operations Division (formerly the Air Force Network Operations Center) at Gunter

AFI33-138 28 NOVEMBER 2005

55

Annex, Maxwell AFB AL. The AFNOSC was created by the Chief of Staff of the Air Force to ensure and preserve the availability, integrity, and confidentiality of Air Force networks (voice, video, and data), its information systems, stand-alone computing devices, and the information contained within those elements respectively. The AFNOSC is under the leadership of the AFNOSC Director, (8 Air Force Vice Commander) and the AFNETOPS/CC, (8 Air Force Commander). Asset--Any device connected to the AFEN. Devices include but are not limited to workstations, servers, infrastructure components (e.g., router, switch) and networked peripherals (e.g., network printers). Command, Control, Communications, and Computers Notice to Airmen (C4 NOTAM)-- C4 NOTAMs are closely related to TCNOs with the primary difference being that they are informative in nature and are not used to direct actions. They are used by all organizations within the AFNETOPS hierarchy. They are the primary means for disseminating network information that does not require specific actions to be taken, or compliance to be tracked. However, in some cases, acknowledging receipt of a C4 NOTAM may be required. There are four types of C4 NOTAMs: Informative, Scheduled Event, Unscheduled Event, and Summary. Countermeasures--Action, device, procedure, technique, or other measure that reduces the vulnerability of an information system. (AFI 33-202) Designated Approving Authority (DAA)--Official with the authority to formally assume responsibility for operating an information system or network within a specified environment. (AFI 33-202) Enclave--Collection of computing environments connected by one or more internal networks under the control of a single authority and security policy, including personnel and physical security. Enclaves always assume the highest mission assurance category and security classification of the automated information system applications or outsourced information technology-based processes they support, and derive their security needs from those systems. They provide standard IA capabilities, such as boundary defense, incident detection and response, and key management, and also deliver common applications, such as office automation and electronic mail. Enclaves may be specific to an organization or a mission, and the computing environments may be organized by physical proximity or by function independent of location. Examples of enclaves include LANs and the applications they host, backbone networks, and data processing centers. (AFI 33-202) End User--An end user is defined as an individual assigned to an organization that uses or operates any portion of the AFEN, any information system connected to the AFEN, and any stand-alone computing devices. Event--Any network activity, whether it is suspicious or not. It includes everything that happens across the network (e.g., web access, E-mail, file transfer protocol). Functional System--A specific system used, owned, operated, and maintained by a functional community. (AFI 33-202) Functional System Administrator (FSA)--Functional system administrators ensure functional system servers, workstations, peripherals, communications devices, and software are on-line and supported. They must thoroughly understand their customer's mission and be completely knowledgeable of hardware and software capabilities and limitations supporting that functional system. Their area of responsibility is from the user's terminal to the server, but does not include the network backbone infrastructure. Functional system administrators are not normally assigned to the NCC, but are a logical extension of NCC functionality.

56

AFI33-138 28 NOVEMBER 2005

Incident--An attempted entry, unauthorized entry, and an information attack on an information system. It includes unauthorized probing, browsing; disruption, or denial of service; altered or destroyed input, processing, storage, or output of information; or changes to system hardware, firmware, or software characteristics with or without the users knowledge, instruction or intent (e.g., malicious logic). An incident may also involve a violation of law. If a violation of law is evident or suspected, the incident must also be reported to both security and law enforcement organizations for appropriate action. Two common incident types are Intrusions and Malicious Logic. The terms Incident and Security Incident are used interchangeably within DOD guidance documents but for the purposes of this instruction, the events defined here will be known simply as Incidents. Information Assurance Vulnerability Alert (IAVA)--The IAVA is generated by the DOD CERT when a vulnerability is the most severe and a corrective action is of the highest priority. IAVAs are generated when a new vulnerability to a privileged system exists and poses an immediate threat to the DOD. Because of the priority of the IAVA, acknowledgement and compliance with the corrective action is tracked and reported by each combatant command, service, and agency (CC/S/A). The IAVA is one of three types of notification defined by CJCSM 6510.01 within the Information Assurance Vulnerability Management (IAVM) Program. The other two notifications include Information Assurance Vulnerability Bulletins, and Technical Advisories. Information Assurance Vulnerability Bulletin (IAVB)--The IAVB addresses new vulnerabilities that do not pose an immediate threat to the DOD. However, chain of command involvement is required because non-compliance with a corrective action could escalate the threat. CC/S/A acknowledgement of the IAVB is required. The IAVB is one of three types of notification defined by CJCSM 6510.01 within the IAVM Program. The other two notifications include Information Assurance Vulnerability Alerts and Technical Advisories. Information Systems Security Manager (ISSM)-- Principal advisor on computer security matters to DAA. (NOTE: DODI 8500.2, Information Assurance (IA) Implementation, February 6, 2003, IA Manager [IAM]). The individual responsible for the information assurance program of a DOD information system or organization. While the term IAM is favored within the DOD, it may be used interchangeably with the IA title Information Systems Security Manager (ISSM). (AFI 33-202) Information Systems Security Officer (ISSO)--Official who manages the Computer Security program for an information system assigned to him or her by the ISSM; including monitoring information system activities, and ensuring that the information system is operated, maintained, and disposed of according to security policies and practices. (NOTE: DODI 8500.2 IA Officer [IAO]). An individual responsible to the IAM for ensuring that the appropriate operational IA posture is maintained for a DOD information system or organization. While the term IAO is favored within the DOD, it may be used interchangeably with other IA titles (e.g., Information Systems Security Officer, Information Systems Security Custodian, Network Security Officer, or Terminal Area Security Officer). (AFI 33-202) Intrusion--A type of incident characterized by unauthorized access to an information system. Malicious Logic--Malicious logic is one type of incident. It expands on what was previously termed a "Virus" which was primarily defined as a software-driven attack. Malicious logic is broader in scope. It is defined as the intentional insertion of firmware and software to disrupt the availability, integrity, or confidentiality of a network, information systems, stand-alone computing device, and the information they process respectively.

AFI33-138 28 NOVEMBER 2005

57

Metropolitan Area Network (MAN)--A MAN delivers information (voice, video, data, imagery, telemetry, and sensory) from a base external service delivery point to the hub servicing all essential sites within a base and deployed site. It encompasses analog/digital physical and wireless media (e.g., cable, microwave, infrared), network management and information protection systems, and infrastructure components (e.g., multiplexers, routers, switches, repeaters, hubs). The MAN extends from the interface of the user's terminal to the interfaces of the base-level host, base-level server, base-level service delivery point, and transmission systems that provide connectivity to off-base assets. The MAN includes all the base network backbone infrastructure components. Mission Support Center (MSC)--MSCs look, feel and act similar to a MAJCOM NOSC but are assigned to a FOA or DRU. They are responsible to a functional for monitoring network and application performance to ensure mission accomplishment over and above what is done by the local NCC. (AFI 33-115, Volume 1) Program Executive Officer (PEO)--A military or civilian official who has primary responsibility for directing several Major Defense Acquisition Programs and assigned major system and non-major system acquisition programs. A PEO only reports to and receives guidance and direction from the Air Force Acquisition Executive. (AFPD 63-1) Program Manager (PM)--A military or civilian official responsible for managing an acquisition program. Also known as a single manager or a system program director. Program Management Office (PMO)--Within the context of this instruction, a PMO develops, acquires, and fields technical solutions for Air Force-networks and systems. PMOs exist at the Air Force and MAJCOM levels. Security Incident--The introduction of information that is classified above the level that a network, information system, or stand-alone computing device is authorized to process. System Program Office (SPO)--Like PMOs, a SPO develops, acquires, tests, fields and supports Air Force systems throughout their lifecycle. Unlike PMOs, SPOs generally come under administrative authority of Air Force Materiel Command or Air Force Space Command. Technical Advisories (TA)--Technical Advisories are generated when new vulnerabilities exist but are generally categorized as low risk. Advisories are issued because these vulnerabilities could potentially escalate in the future if not mitigated. The TA is one of three types of notification defined by CJCSM 6510.01 within the IAVM Program. The other two notifications include Information Assurance Vulnerability Alerts and Information Assurance Vulnerability Bulletins. Technique--A means of exploiting a computer or network vulnerability. Time Compliance Network Orders (TCNO)--TCNOs are downward-directed operations, security, or configuration management-related orders issued by the AFNOSC or NOSCs. The TCNO provides a standardized mechanism to issue one "order" amongst AFNOSC/NOSC/NCCs, telling them how to run and make changes to the AFEN. TCNOs may be generated internally or in response to an IAVA to direct the implementation of an operational or security vulnerability risk mitigation procedure or fix action (i.e., software patch). Unauthorized Result--An unauthorized consequence to an event. Vulnerability--Weakness in an information system, or cryptographic system, or components (e.g., system security procedures, hardware design, internal controls) that could be exploited. (AFI 33-202)

58

AFI33-138 28 NOVEMBER 2005

Workgroup Manager (WM)--Workgroup managers support a functional community (e.g., work centers, flights, squadrons, or organizations) and serve as the first line of help to resolve customers' administrative and technical problems. WMs are usually not assigned to the NCC, though are logically an extension of the help desk. WMs take direction from the NCC and FSA. NCC direction takes precedence over FSA direction. WMs install, configure, and operate client/server devices.

AFI33-138 28 NOVEMBER 2005 Attachment 2 EXAMPLE TCNO

59

A2.1. The following sample illustrates the format for a manually generated TCNO. The information in italics provides explanatory information and would not appear in an actual TCNO: CLASSIFICATION: UNCLASSIFIED (overall classification of the TCNO content) RELEASE TIME: 03/09/2004 7:20:14:AM CST (based on eTANG timestamp) TCNO TRACKING NUMBER: TCNO AFNOSC 2004-069-001 (refer to paragraph 3.7.) ORIGINATING AGENCY: AFNOSC (self-explanatory) PRIORITY: Critical (refer to paragraph 3.5. and Table 3.1.) SUBJECT: ASN.1 Vulnerability Could Allow Code Execution, MS 04-007 (descriptive subject, typically the name of the advisory being implemented) MISSION IMPACT: System Compromise (brief statement of potential mission impact if TCNO is not implemented) EXECUTIVE SUMMARY: 1. Summary (provide a brief summary of the vulnerability/issue being addressed) 1.1. A vulnerability in the Microsoft ASN.1 Library could allow... 2. Implementation Details (provide implementation details as described in paragraph 3.8.) 2.1. Affected platforms, operating systems, applications, and versions: Microsoft Windows NT Server 4.0 Service Pack 6a Microsoft Windows NT Server 4.0 Terminal Server Edition Service Pack 6 2.2. Countermeasure implementation instructions 2.2.1. Users should download patches from ENOSC's website and follow the posted installation instructions. 2.3. Estimated downtime required to implement the countermeasures: 2.3.1. Manually per system: 5 to 20 minutes 2.3.2. Automated update system (e.g., SMS): 30 minutes per thousand clients. 2.4. Risks associated with non-compliance: Remote Code Execution ACTION: Apply fix action specified in paragraph 2.2. to classified and unclassified systems to comply with this TCNO. REMARKS: 1. Statistical Reporting 1.1. Report statistics in accordance with AFI 33-138, Chapter 3. 1.2. Discontinue status updates once compliance is reached and reported to the AFNOSC.

60 REPORTING REQUIREMENTS:

AFI33-138 28 NOVEMBER 2005

1. All organizations with eTANG capability will report compliance via eTANG. Compliance will be recorded in the appropriate boxes within the STATISTICS TAB. 2. For organizations lacking eTANG, reporting to the AFNOSC must be accomplished via SIPRNET E-mail message with the subject line of "COMPLIANCE STATISTICS FOR TCNO AFNOSC 2004-069-001" RECEIPT ACKNOWLEDGMENT REQUIRED DATE: 17 Feb 04 (refer to paragraph 3.6. for guidance on establishing receipt response, compliance and statistics suspense dates) COMPLIANCE REQUIRED DATE: 23 Feb 04 STATISTICS REQUIRED DATE: 23 Feb 04 POC INFORMATION: AFNOSC Crew Commander, mailto:[email protected], DSN 781-1043 REFERENCES: MS 04-007 (relevant bulletin/alert/advisory used to produce TCNO as described in paragraph 3.9.)

AFI33-138 28 NOVEMBER 2005 Attachment 3 PMO/SPO COMPLIANCE STATUS MESSAGES

61

A3.1. Example 1--Air Force Functional System Time Compliance Network Order (TCNO) Compliance Status Message. From: Sent: To: Info: Subject: HQ SSG (DMS-Air Force PMO) Monday, May 15, 2003 1:29 PM AFNOSC NOSCs, NCCs, DMS-Air Force FSAs DMS-Air Force TCNO Status - TCNO AFNOSC XXXX-XXX-XXX

Reference: TCNO AFNOSC XXXX-XXX-XXX, "Vulnerability in Microsoft Windows NT, Version 4.0" on 14 May 2003. Required implementation date is 21 May 2003. 1. This message is to inform you of the compliance status for DMS-Air Force. 2. TCNO AFNOSC XXXX-XXX-XXX MAY OR MAY NOT apply to the DMS-Air Force program. Microsoft Windows NT, Version 4.0 is used in current versions of the application software. However, the DMS-Air Force application specifically prohibits use of the vulnerable protocols identified in the TCNO. The DOD DMS PMO is evaluating this vulnerability to verify DMS is protected. 3. FSAs are NOT authorized to implement the TCNO procedures. Implementing TCNO procedures as listed could cause loss of message traffic. 4. The DMS-Air Force action plan for complying with TCNO AFNOSC XXXX-XXX-XXX is as follows: a) 15 ­ 30 May ­ DOD DMS PMO completed evaluation to verify DMS is protected against the vulnerability. b) 1 Jun ­ DOD DMS PMO informs Service DMS PMOs of DMS compliance status. c) 2 Jun ­ DMS-Air Force PMO will inform Air Force organization of DMS compliance status and additional action plan items, as required. 5. FSAs should follow local procedures and notify the servicing NCC that DMS-Air Force is considered NOT compliant with TCNO AFNOSC XXXX-XXX-XXX. Send DMS-Air Force action plan information to the NCC, send follow-up status when the PMO releases additional information. 6. The DMS-Air Force PMO approved these actions. Contact the DMS-Air Force PMO at DSN XXX-XXXX, if you have any questions. //SIGNED// Signature Block of Submitter

62

AFI33-138 28 NOVEMBER 2005

A3.2. Example 2--MAJCOM Functional System Time Compliance Network Order (TCNO) Compliance Status Message. From: Sent: To: Info: Subject: HQ AMC/SCP (CAMPS PMO) Monday, May 15, 2003 1:29 PM AMC NOSC AFNOSC, NOSCs, NCCs, CAMPS FSAs CAMPS TCNO Compliance Status - TCNO AFNOSC XXXX-XXX-XXX

Reference: TCNO AFNOSC XXXX-XXX-XXX, "Vulnerability in Microsoft Windows NT, Version 5" on 14 May 2003. Required implementation date is 21 May 2003. 1. This message is to inform you of the current compliance status for the AMC Consolidated Air Mobility Planning System (CAMPS). 2. TCNO AFNOSC XXXX-XXX-XXX does apply to the CAMPS program. Microsoft Windows NT, Version 5 is used in all current versions of the application software. 3. CAMPS' FSAs are NOT authorized to implement procedures as outlined in the TCNO. Implementing the TCNO procedures as listed could cause the loss of user information and mission data. 4. Specific CAMPS implementation instructions for TCNO AFNOSC XXXX-XXX-XXX are available for download from the following URL: https://scott.af.mil/camps/tcno status/TCNO AFNOSC XXXX-XXX-XXX.html. Questions or comments about the instructions should be referred to the CAMPS helpdesk at DSN 576-4949, option 4. 5. CAMPS' FSAs must immediately download the instructions and implement the countermeasure. Upon implementation, follow local procedures and notify your servicing NCC that compliance with TCNO AFNOSC XXXX-XXX-XXX is achieved. 6. CAMPS' PMO approved these actions. Contact the CAMPS PMO at DSN XXX-XXXX, if you have any questions. //SIGNED// Signature Block of Submitter

AFI33-138 28 NOVEMBER 2005 Attachment 4 TCNO EXTENSION PACKAGES

63

A4.1. Required Extension Request Information. The extension request will include the following information (see A4.3. for a sample first extension package and A4.4. for a sample second extension package): A4.1.1. AFNOSC-Assigned TCNO Tracking Number. Include the TCNO number for which the extension is being requested. Additionally, if the TCNO is related to an IAVA, IAVB or TA, include the IAVA, IAVB, or TA number as well. A4.1.2. Vulnerability Description. Include a short description of vulnerability as identified in the associated TCNO. A4.1.3. Original Compliance Date. List the original compliance date as stated in the TCNO. A4.1.4. Extension Type. List the type of extension being requested; i.e., First (0-30 days), Second (31-90 days), or Third (91 days through 2 years). A4.1.5. Previous Extensions: For second and third extension requests, list the type and expiration date of all previously granted extensions. A4.1.6. Requested Extension Date. This should be the date the requesting organization expects to be compliant. A4.1.7. Affected Units/Installations. List the unit and/or location covered by the extension (e.g. NOSC plus all subordinate installations). A4.1.8. Justification. Explain why the original compliance date, or a previously granted extension date cannot be met. It is imperative this justification be as detailed and complete as possible. For example, do not simply state, "The systems are legacy systems and are scheduled for replacement in 18 months." Rather, provide complete details, "The systems are Solaris 2.5 legacy systems and the patch procedures outlined in the TCNO cannot be applied. When the patch is applied the software package called MapSense will not function. MapSense is used by the 121st Squadron to create 3D graphic maps. We have contacted MapSense and they state that we would need to upgrade to a current version of Solaris. However, our current hardware is Sun MP630 and cannot be upgraded to a more current version of Solaris. The Sun MP630 are being replaced and the new systems will be completely installed by 15 Sep 2005." A4.1.9. Risk Mitigation Actions. Describe in detail what actions have been taken or processes put in place to mitigate the risk associated with the vulnerability. If some amount of the risk can be mitigated through other actions, this will help extension evaluation and approval officials assess the residual risk imposed on the AFEN and Air Force information systems if the extension is approved. For example, "These systems communicate with only three outside sources using only one protocol. TCP Wrappers have been placed on the devices to limit access to the specific protocol. Further, we have placed a router in front of the devices and denied all access except the internet protocol (IP) addresses from the three input sources." NOTE: Do not get so specific as to cause the extension request to be classified. For example, in the preceding example, there is no need to list the specific protocol or the IP addresses that were being authorized through the router.

64

AFI33-138 28 NOVEMBER 2005 A4.1.10. Mission Impact. State any mission that would be degraded or lost if the affected workstations are directed to be disconnected from the network. Be as specific as possible. For example, "Removing this system from the network will prevent the 121st Squadron's ability to provide virtual 3D maps for supporting on-going operations." A4.1.11. Number and Percentage of Non-compliant Workstations. Provide both raw number and percentage of total affected workstations that are non-compliant. A4.1.12. Method Used to Identify Non-compliant Workstations. Identify the automated or manual means that was used to identify affected non-compliant workstations. A4.1.13. Supporting Material. Note any vendor or PMO information as well as any extenuating factors that will assist the extension approval authority in reaching a decision. A4.1.14. POC Information. Include name, phone and E-mail contact information for requesting agency POC. For second or third extensions, this POC should be from the MAJCOM/FOA/DRU level, not base/wing level.

A4.2. Extension Endorsement. In accordance with Table 3.4., all extension requests must be endorsed before being forwarded to the extension approval authority. The endorsement will indicate that the endorsing official: A4.2.1. Has evaluated the supporting documentation and concludes that the deployment of the recommended fix is not possible within the time frame required by the TCNO or previous extension. A4.2.2. Has reviewed the mitigation action and believes these actions are sufficient to minimize the risk posed to the AFEN until the affected workstations can be brought into compliance. A4.2.3. Has analyzed the risk that the unfixed but mitigated vulnerability levies and has compared the risk to the mission impact if the workstations are ordered disconnected and finds that the impact to the supported missions is greatest if the workstations are disconnected. A4.2.4. Understands the risk is not just to his/her network, but to the whole AFEN.

AFI33-138 28 NOVEMBER 2005 A4.3. Sample First Extension Request.

65

17 February 2004 MEMORANDUM FOR 123 WG/CC FROM: 123 CS/CC SUBJECT: First Extension Request for TCNO AFNOSC 2004-041-001 1. TCNO Number. TCNO AFNOSC 2004-041-001 2. Vulnerability Description. A vulnerability has been identified in the XYZ Library. Successful exploitation of this vulnerability could allow an attacker to execute code with system privileges and then take any action on the system, including installing programs, viewing/changing data, or creating new privileged user accounts. 3. Original Compliance Date. 23 Feb 2004 4. Extension Type. First extension (additional 30 days) 5. Requested Extension Date. 25 Mar 2004 6. Affected Units. This extension is being requested for all 123 WG units and tenant units supported by the 123 CS. 7. Justification. Initial automated distribution of the required patch was accomplished on 14 February 2004 and only 60% of the affected workstations were successfully patched. An additional 15% of the affected workstations were successfully patched during a subsequent automated distribution of the patch. It has been determined that the automated patch failed on the remaining non-compliant workstations because they require a service pack to be installed before the required patch will install successfully. The required service pack must be manually installed at the workgroup manager level and this process will take several weeks to accomplish on all remaining affected workstations across the installation. 8. Risk Mitigation Actions. Actions have been taken to mitigate the operational impact to local, MAJCOM, and the Air Force mission if a vulnerable workstation is exploited by positively identifying all workstations not patched and developing a quick reaction plan to isolate any exploited workstations. All of the vulnerable systems are behind the base perimeter defenses and current Anti-Virus signatures should prevent the exploit before it can reach the vulnerable workstations. 9. Mission Impact. The impact of disconnecting any single non-compliant workstation is minimal; however, the impact of disconnecting the 3,267 non-complaint workstations across the installation would be considerable as the personnel who normally use those workstations would be unable to conduct their daily duties. 10. Number and Percentage of Non-compliant Workstations. 3,267 (75% of 4,356). 11. Method Used to Identify Non-compliant Workstations. Due to the standard implementation of Windows 2000 across the installation, all workstations on the installation are affected by this vulnerability. We are in the process of conducting Internet Security Systems (ISS) scans to positively identify non-compliant workstations and will run a new scan every three days until compliance is achieved. 12. Supporting Material. N/A 13. POC Information. Capt John Smith, 123 CS/SCB, DSN 123-4567.

66

AFI33-138 28 NOVEMBER 2005

// SIGNED // MARY A. JONES, Lt Col, USAF Commander 123rd Communications Squadron 1st Ind, 123 WG/CC MEMORANDUM FOR MAJCOM DAA I have reviewed this extension request and have concluded that full compliance with the TCNO will not be achievable within the compliance date of 23 February 2004 specified in TCNO AFNOSC 2004-041-001. I have reviewed the mitigation actions taken and am confident the risk posed to the AFEN and supported operations is less than the negative impact of disconnecting the 1,089 non-compliant workstations across my installation. I recommend approval of the extension until 25 March 2004 as requested. 19 February 2004

// SIGNED // MARK L. MARTIN, Brig Gen, USAF Commander 123rd Wing 2d Ind, MAJCOM DAA MEMORANDUM FOR 123 WG/CC I have reviewed subject request for extension to TCNO AFNOSC 2004-041-001. The expected operational impacts to the AFEN have been determined to be negligible and I accept the risk associated with this extension. The requested extension is granted until 25 March 2004. 21 February 2004

// SIGNED // DAVID W. PETERS, Colonel, USAF Designated Approving Authority cc: AFNOSC

AFI33-138 28 NOVEMBER 2005 A4.4. Sample Second Extension Request.

67

8 March 2004 MEMORANDUM FOR MAJCOM DAA FROM: NOSC SUBJECT: Second Extension Request for TCNO AFNOSC 2004-041-001 1. TCNO Number. AFNOSC TCNO 2004-041-001 2. Vulnerability Description. A vulnerability has been identified in the XYZ Library. Successful exploitation of this vulnerability could allow an attacker to execute code with system privileges and then take any action on the system, including installing programs, viewing/changing data, or creating new privileged user accounts. 3. Original Compliance Date. 23 February 2004 4. Extension Type. Second extension (additional 30 days) 5. Previous Extensions. First extension until 25 March 2004 was granted on 23 February 2004 6. Requested Extension Date. 23 April 2004 7. Affected Units/Installations. This extension is being requested to cover the NOSC and all subordinate MAJCOM installations and units. 8. Justification. Initial automated distribution of the required patch was accomplished across the MAJCOM on 14 February 2004 and 60% of the affected workstations were successfully patched. An additional 15% were successfully patched during a subsequent automated distribution of the patch. It has been determined that the automated patch failed on the remaining non-compliant workstations because they require a service pack to be installed before the required patch will install successfully. The required service pack must be manually installed at the workgroup manager level and this process has been underway for several weeks. As of 8 March 2004, 83% of the workstations across the MAJCOM have been successfully patched but it will take 8 more weeks to achieve full compliance. 9. Risk Mitigation Actions. Actions have been taken to mitigate the operational impact to local, MAJCOM, and the Air Force mission if a vulnerable workstation is exploited by positively identifying all workstations not patched and developing a quick reaction plan to isolate any exploited workstations. All of the vulnerable systems are behind the base perimeter defenses and current Anti-Virus signatures should prevent the exploit before it can reach the vulnerable workstations. 10. Mission Impact. The impact of disconnecting any single non-compliant workstation is minimal; however, the impact of disconnecting the 8,615 non-complaint workstations across the command would be considerable as the personnel who normally use those workstations would be unable to conduct their daily duties. 11. Number and Percentage of Non-compliant Workstations. 8,615 (17% of 50,678). 12. Method Used to Identify Non-compliant Workstations. Due to the standard implementation of Windows 2000 across the command, all workstations are affected by this vulnerability. We are running ISS scans every three days to positively verify compliance and to identify non-compliant workstations. 13. Supporting Material. N/A

68

AFI33-138 28 NOVEMBER 2005

14. POC Information. Maj Joe E. Washington, NOSC Chief, DSN 123-4567. // SIGNED // MARY A. JONES, Lt Col, USAF Commander 123rd Communications Squadron 1st Ind, MAJCOM DAA MEMORANDUM FOR AFNOSC Director I have reviewed this extension request and have concluded that full compliance with the TCNO will not be achievable within the first extension compliance date of 25 March 2004. I have reviewed the mitigation actions taken and am confident the risk posed to the AFEN and supported operations is less than the negative impact of disconnecting the 8,615 non-compliant workstations across the command. I recommend approval of the extension until 23 April 2004 as requested. 10 March 2004

// SIGNED // DAVID W. PETERS, Colonel, USAF Designated Approving Authority 2d Ind, AFNOSC Director MEMORANDUM FOR NOSC I have reviewed subject request for a second extension to TCNO AFNOSC 2004-041-001. The expected operational impacts to the AFEN have been determined to be negligible and I accept the risk associated with this extension. The requested extension is granted until 23 April 2004. 12 March 2004

// SIGNED // WILLIAM P. SMITH, Brig Gen, USAF AFNOSC Director

AFI33-138 28 NOVEMBER 2005 Attachment 5 EXAMPLE INFORMATIVE C4 NOTAM

69

A5.1. The following sample illustrates the format for a manually generated Informative C4 NOTAM. The information in italics provides explanatory information and would not appear in an actual C4 NOTAM: CLASSIFICATION: UNCLASSIFIED (overall classification of the C4 NOTAM content) RELEASE TIME: 03/09/2004 7:20:14:AM CST (added based on eTANG timestamp) TRACKING NUMBER: C4-N AFNOSC 2004-052-001 (see paragraph 4.3.1.) ORIGINATING AGENCY: AFNOSC (either "AFNOSC" or originating NOSC) TYPE: Informative (will always be "Informative" for Informative C4 NOTAMs) PRIORITY: Low (refer to paragraph 4.3.2. and Table 4.1.) SUBJECT: Port 3531 AFIN Block (descriptive subject) MISSION IMPACT: Loss of Port 3531 communications prevents remote administration of non-critical legacy systems x and y. Nearby administrators still able to physically access system and accomplish mission. (brief statement of potential mission impact if TCNO is not implemented) EXECUTIVE SUMMARY: (provide a brief summary of the issue being addressed) In response to NSIRC-047-04 addressing Peer to Peer (P2P) activity from military hosts, AFNOSC will implement a block for port 3531... ACTION: (provide any relevant coordination guidance) Exemption requests should be directed to the AFNOSC... REMARKS: (provide any additional remarks relevant to the topic being addressed) REPORTING REQUIREMENTS: None RECEIPT RESPONSE REQUIRED DATE: None COMPLIANCE REQUIRED DATE: None STATISTICS REQUIRED DATE: None POC INFORMATION: AFNOSC Crew Commander, [email protected], DSN 781-1043 REFERENCES: NSIRC-047-04 (relevant bulletin/advisory used to produce C4 NOTAM)

70 Attachment 6

AFI33-138 28 NOVEMBER 2005

EXAMPLE SCHEDULED/UNSCHEDULED EVENT C4 NOTAM A6.1. The following sample illustrates the format for a manually generated Scheduled or Unscheduled Event C4 NOTAM. The information is italics provides explanatory information and would not appear in an actual C4 NOTAM. CLASSIFICATION: UNCLASSIFIED (overall classification of the C4 NOTAM content) RELEASE TIME: 3/11/2004 09:32:04 AM (based on eTANG timestamp) TRACKING NUMBER: C4-N AFNOC 2004-071-002 (see paragraph 4.3.1.) ORIGINATING AGENCY: AFNOSC (self-explanatory) TYPE: Unscheduled Event ("Scheduled Event" or "Unscheduled Event") CATEGORY: Initial ("Initial" "Update" or "Final") PRIORITY: Medium (refer to paragraph 4.3.2. and Table 4.1.) SUBJECT: Wright Patterson NIPRNET Outage MISSION IMPACT: (brief statement of the actual or projected operational impact of the event) EXECUTIVE SUMMARY: (provide any additional details available to include such things as start and stop times for unscheduled outages, affected operating systems or applications for malicious logic outbreaks, etc.) POC INFORMATION:(contact information for the originator of the C4 NOTAM, typically a crew commander)

AFI33-138 28 NOVEMBER 2005 Attachment 7 EXAMPLE SUMMARY C4 NOTAM

71

A7.1. The following sample illustrates the format for a manually generated Summary C4 NOTAM. The information in italics provides explanatory information and would not appear in an actual C4 NOTAM. CLASSIFICATION: UNCLASSIFIED (overall classification of the C4 NOTAM content) RELEASE TIME: 01/30/2004 05:20:14 PM EST (based on eTANG timestamp) TRACKING NUMBER: C4-N ACC 2004-030-001 (see paragraph 4.3.1.) ORIGINATING AGENCY: ACC (self-explanatory) TYPE: Summary (will always be "Summary" for Summary C4 NOTAMs) PRIORITY: Low (refer to paragraph 4.3.2. and Table 4.1.) SUBJECT: ACC Summary C4 NOTAM (indicate the originating agency) SUMMARY: 1. PERIOD COVERED: 1.1. START: (start time for the period covered) 1.2. STOP: (stop time for the period covered) 2. INFOCON LEVEL: (list the current originating organization's INFOCON-level) 3. CURRENT ANTI-VIRUS DEFINITION: (list the current definition version deployed across the originating organization's AOR) 4. PROJECTED AND CURRENT OUTAGES: (list of projected and current outages) 5. SIGNIFICANT EVENTS RECAP: (summary of all the significant events for the period covered) 6. REMARKS: (any additional comments on status of reporting organization) POC INFORMATION: (contact information for the originator of the C4 NOTAM, typically a crew commander)

72 Attachment 8 INCIDENT REPORTS (IR)

AFI33-138 28 NOVEMBER 2005

A8.1. Incident Reports (IR). The information outlined in this attachment is required for all IRs. Prepare and submit a separate IR for each incident being reported. A8.2. Administrative Information. A8.2.1. C4 NOTAM Tracking Number. The UEC4N associated with the report. A8.2.2. Incident Report Identification (IRID). The AFNOSC-assigned IRID tracking number. Leave this item blank if the AFNOSC has not assigned an IRID. A8.2.3. Report Type. Indicate whether the report is an initial, update, or final report. A8.2.4. Report Dates. A8.2.4.1. Initial Report. Enter the date the report was created and submitted (yyyy-mm-dd). A8.2.4.2. Update or Final Report. Include both the original initial report date as well as the date the update/final report was created and submitted (yyyy-mm-dd). A8.2.5. Report Originator Information. Provide the following information for the individual who prepared the report. A8.2.5.1. Name, rank, and duty title. A8.2.5.2. Unit, Wing, Base, and MAJCOM. A8.2.5.3. E-mail address. A8.2.5.4. Phone number (DSN and commercial). A8.2.6. Security Classification and Authority. Enter the classification of the report and state the rationale for classifying the report. As an example, CONFIDENTIAL. The intruder gained root level access on a command and control mission system at four geographically separated units. If classified, state the classification guide that makes the report classified. A8.3. Description of Incident. State which category of intrusion is being reported and provide a brief description of the event. A8.3.1. Date/Time Incident Occurred. Date and ZULU time that incident actually occurred. A8.3.2. Category. The assessed category of the incident (e.g., Category I, Root Level Intrusion). See Table 5.1. for definitions of the seven defined incident categories. A8.3.3. Incident Description. Provide a brief description of the incident. A8.3.3.1. Vulnerability Information. Identify the vulnerability exploited, if known. Identify the TCNO, if any applies to the vulnerability, and indicate whether the affected assets were thought to be TCNO compliant. A8.3.3.2. Unauthorized Results. Describe any adverse actions accomplished by the intruder during the course of the incident (e.g., intruder gained access to one domain controller and uploaded hacker tools).

AFI33-138 28 NOVEMBER 2005

73

A8.3.4. Detection Method. Indicate how the incident was detected (i.e., ASIM, review of Firewall logs, etc.). A8.4. Mission Impact and Damage Assessment. A8.4.1. Enter one of the following mission impact types. Lack of System Availability, Loss of Integrity, Information Compromise, Loss of Accountability, or Other. Provide a full explanation if "Other" is entered. Specify the direct impact to any mission. A8.4.2. Enter the TOTAL for each of the damage assessment indicators below as they apply to the specific incident. A8.4.2.1. Number of networks/information systems affected. A8.4.2.2. Number of users directly affected. A8.4.2.3. Number of personnel working on the incident. A8.4.2.4. Number of man-hours spent to recover networks and information systems. A8.4.2.5. Hours of network downtime spent in recovery operations. A8.4.2.6. Any materiel cost attributable to recovering from the incident. A8.5. Technical Details. The following information should be provided as applicable to the incident being reported. Use a separate sheet for each non-related target and session. A8.5.1. Attack Target Information. A8.5.1.1. Network domain name (e.g., AFCERT.csap.af.mil). A8.5.1.2. Internet Protocol (IP) address (e.g., 132.28.145.43). A8.5.1.3. System Location (e.g., In DMZ; behind firewall). A8.5.1.4. Operating system and version (e.g., SUN Solaris 2.6). A8.5.1.5. System security classification (e.g., Unclassified, SECRET). A8.5.1.6. Network/system function (i.e., Administration, C2, communications, logistics, domain name server). A8.5.1.7. How the intrusion was detected (e.g., ASIM alert, review of Firewall logs). A8.5.1.8. Information systems audit information. A8.5.2. Attack Source Information. A8.5.2.1. Date/Time of the session. A8.5.2.2. IP address (include host name, if available). A8.5.2.3. Description of incident to include the attack method. A8.6. Resolution Actions Taken. Provide a brief description of actions taken to resolve the incident (e.g., patches installed, passwords changed).

74

AFI33-138 28 NOVEMBER 2005

A8.7. Notifications. State who was notified of the incident. Include the name, date, and time for each notification.

AFI33-138 28 NOVEMBER 2005 Attachment 9 MALICIOUS LOGIC REPORTS

75

A9.1. Malicious Logic Reports (MLR). The information outlined in this attachment is required for all MLRs. MLRs should be entered into CDS. For those organizations without access to CDS, a MLR template can be downloaded from https://afcertmil.lackland.af.mil/virus/mlr.doc. Once filled in, E-mail the MLR directly to the AFNOSC ([email protected]). A9.2. Administrative Information. A9.2.1. C4 NOTAM Tracking Number. The UEC4N associated with the report. A9.2.2. Report Date. Date the MLR was completed and submitted. A9.2.3. Report Originator Information. Provide the following information for the individual who prepared the report. A9.2.3.1. Name, rank and duty title. A9.2.3.2. Unit, Wing, Base, and MAJCOM. A9.2.3.3. E-mail address. A9.2.3.4. Phone number (DSN and commercial). A9.2.4. Classification of Report. The classification level of the report depends on the type of information system, application, or network infected. Only unclassified reports can be entered into CDS. Any MLR with a classification higher than unclassified must be transmitted to the AFNOSC using a classified transmission system (i.e., E-mail, fax). A9.3. Malicious Logic Information. A9.3.1. Infection Date. The date the malicious logic event occurred (yyyy-mm-dd). A9.3.2. Malicious Logic Name. Give the name of the malicious logic file as reported by the anti-virus software. If no anti-virus software alert was seen or did not occur, provide the file name or the name of the attachment (if found in an E-mail). A9.4. Mission Impact and Damage Assessment. A9.4.1. Hours Lost. List number of work hours expended. This is cumulative and includes the time of the reporting individual, and all other personnel at all other offices directly involved in identifying, repairing, and recovering from a malicious logic event. The work hours expended will be calculated to the nearest tenth (.1) hour increment. A9.4.2. Remarks. Detail any specific adverse mission impacts that resulted from the malicious logic event. A9.5. Infected System Information. These fields are used to list the cumulative number of infected systems by category indicated. A9.5.1. Mission Critical Servers.

76 A9.5.2. Mission Critical Clients. A9.5.3. Mission Support Servers. A9.5.4. Mission Support Clients. A9.5.5. Administrative Servers. A9.5.6. Administrative Clients.

AFI33-138 28 NOVEMBER 2005

A9.6. Affected Software Information. Identify any application affected by the malicious logic in one of the following categories. A9.6.1. Operating System and Version. A9.6.2. Application and Version. A9.6.3. Standard (Functional) System and Version. A9.7. Source of Infection. Indicate the source of infection using the following categories. A9.7.1. Air Force software. A9.7.2. Commercial-off-the-shelf software. A9.7.3. Personal disks. A9.7.4. E-mail (includes attachments). A9.7.5. Downloaded files. A9.7.6. World Wide Web Java applet. A9.7.7. Other or Unknown. A9.8. Anti-virus Product Information. This section addresses the type of anti-virus software installed, virus definitions, applications used, and application patches installed. A9.8.1. Installed Anti-virus. Provide the installed anti-virus product by name and version number. A9.8.2. Current Signature. Provide the anti-virus signature version that was installed at the time of infection. A9.9. Notifications. State who was notified and include the name, date, and time for each notification.

AFI33-138 28 NOVEMBER 2005 Attachment 10 VULNERABILITY REPORTS (VR)

77

A10.1. Vulnerability Reports (VR). Use the format below to submit initial, update, and final VR for newly discovered vulnerabilities for which no risk mitigation procedure has been established. If the newly discovered vulnerability was exploited or an incident actually occurred, go directly to Incident Reporting section (Section 5B). Prepare and submit a separate VR for each vulnerability being reported. A10.2. Administrative Information. A10.2.1. C4 NOTAM Tracking Number. The UEC4N associated with the report. A10.2.2. Vulnerability Report Identification (VRID). The AFNOSC-assigned VRID tracking number. Leave this item blank if the AFNOSC has not assigned an VRID. A10.2.3. Report Type. Indicate whether the report is an initial, update, or final report. A10.2.4. Report Dates. A10.2.4.1. Initial Report. Enter the date the report was created and submitted (yyyy-mm-dd). A10.2.4.2. Update or Final Report. Include both the original initial report date as well as the date the update/final report was created and submitted (yyyy-mm-dd). A10.2.5. Report Originator Information. Provide the following information for the individual who prepared the report. A10.2.5.1. Name, rank and duty title. A10.2.5.2. Unit, Wing, Base, and MAJCOM. A10.2.5.3. E-mail address. A10.2.5.4. Phone number (DSN and commercial). A10.2.6. Security Classification and Rationale. Enter the classification of the report and state the rationale for classifying the report. For example, "SECRET. Vulnerability detected allows root-level access to a command and control information system that is connected to the SIPRNET." A10.3. Vulnerability Description. Describe the nature and effect of the vulnerability in sufficient detail so the computing environment can be reconstructed and the flaw repeated. NOTE: The intent is that the vulnerability must be demonstrable and repeatable so that it can be validated by either the AFNOSC Net Security Division or a national agency with validation authority. A10.4. Mission Impact and Damage Assessment. Initial reports should contain estimates or projections of mission impact and expected damage should the vulnerability be exploited. Supplemental and final reports corroborate the impacts and damages that can be attributed to the exploited vulnerability. This information helps set priorities for countermeasure development and dissemination. A10.4.1. Approximate the expected damage if this vulnerability were to be exploited. Provide estimates of the total number of:

78

AFI33-138 28 NOVEMBER 2005 A10.4.1.1. Networks, information systems, and users that are considered to be at risk or vulnerable to an attack. A10.4.1.2. Hours of work/productivity expected to be lost (downtime x number of users) to fix the problem. A10.4.1.3. Personnel required to implement vulnerability mitigation procedures. A10.4.2. Enter one of the following mission impact types: Loss of System Availability, Loss of Integrity, Information Compromise, Loss of Accountability, or Other.

A10.5. Technical Details. Enter information as it applies to this newly discovered vulnerability. A10.5.1. Security Mode of Operation. Enter one of the following: Dedicated, System High, Multi-level. A10.5.2. Connectivity. State whether the vulnerability affects the wide area network, MAN, LAN, or a combination of networks. Provide each network's OPR (MAJCOM and Unit). A10.5.3. Configuration. State whether the affected device is used to support a network, information system, or stand-alone device, and if it is a single or multi-user device. A10.5.4. Hardware/Software. Enter the make and model of the hardware. Provide the software operating system and version number, and the application name and version number. A10.6. Notifications. State who was notified and include the name, date, and time for each notification.

AFI33-138 28 NOVEMBER 2005 Attachment 11 SECURITY INCIDENT REPORTS (SIR)

79

A11.1. Security Incident Reports (SIR). The information outlined in this attachment is required for all SIRs. Prepare and submit a separate SIR for each security incident being reported. A11.2. Administrative Information. A11.2.1. C4 NOTAM Tracking Number. The UEC4N associated with the report. A11.2.2. Security Incident Report Identification (SIRID). The NOSC-assigned SIRID tracking number. Leave this item blank if the NOSC has not assigned an SIRID. A11.2.3. Report Type. Indicate whether the report is an initial, update, or final report. A11.2.4. Report Dates. A11.2.4.1. Initial Report. Enter the date the report was created and submitted (yyyy-mm-dd ). A11.2.4.2. Update or Final Report. Include both the original initial report date as well as the date the update/final report was created and submitted (yyyy-mm-dd). A11.2.5. Report Originator Information. Provide the following information for the individual who prepared the report. A11.2.5.1. Name, rank and duty title. A11.2.5.2. Unit, Wing, Base, and MAJCOM. A11.2.5.3. E-mail address. A11.2.5.4. Phone number (DSN and commercial). A11.2.6. Security Classification and Rationale. Enter the classification of the report as outlined in paragraph 6.3. and AFI 31-401. A11.3. Description of Incident. Provide a synopsis of how the classified information was introduced onto the unclassified network/system. Provide a brief description of actions taken to identify and resolve the incident. A11.3.1. Security Incident Scope. Provide a description of the number of personnel who have access to, or are known to have accessed, the file and/or the number of information systems affected. In the case of a CMI, indicate the number of recipients of the classified information (e.g., file, message) including those to whom the message was originally sent and those to whom the message was forwarded. See paragraphs 6.4.1. and 6.5. for guidance. A11.3.2. POC for Sanitized Office. Provide the POC for each location the message was discovered and sanitized. A11.3.2.1. Rank and name. A11.3.2.2. DSN and commercial phone numbers. A11.3.2.3. Office, unit, wing, base, and MAJCOM/FOA/DRU.

80

AFI33-138 28 NOVEMBER 2005

A11.4. Mission Impact and Damage Assessment. Provide estimates for initial and update reports, these reports project the mission impact and the expected damage caused by the security incident. Provide actual numbers in the final report, the final report confirms actual damage factors. NOTE: The following mission impact and damage assessment is specific to the impact on network and information system access and supported missions. AFI 31-401 provides guidance on conducting a damage assessment to determine the effect of a compromise of classified information on the national security. A11.4.1. Type of Impact. Enter one of the following: Mission Critical, Mission Support, or Administrative. A11.4.2. Enter the TOTAL for each item as they apply to the specific security incident being reported. A11.4.2.1. Networks, information systems, and users directly affected. A11.4.2.2. Productivity Lost. Estimate how much productivity would be lost to fix problems for initial and supplemental reports. Provide actual numbers for final report. Use the formula "total users multiplied by total hours down". Provide the number of man-hours spent to sanitize networks and information systems. A11.4.2.3. Hours of network downtime spent in sanitization operations. A11.4.2.4. Costs incurred for initial and supplemental reports. A11.5. Technical Details. A11.5.1. Configuration. Identify the equipment involved in the security incident (i.e., one or more of the following): A11.5.1.1. Defense Message System-Air Force (DMS-Air Force). A11.5.1.2. Exchange. A11.5.1.3. File/Web/Application Server. A11.5.1.4. Commercial-Off-The-Shelf E-mail equipment (e.g., MS Exchange). A11.5.1.5. Other messaging/file transfer devices. (Give full description.) A11.6. Notifications. State who was notified and include the name, date, and time for each notification.

AFI33-138 28 NOVEMBER 2005 Attachment 12 AUTHORIZED SERVICE INTERRUPTION REQUESTS A12.1. ASI Requests. The information outlined in this attachment is required for all ASI requests. A12.2. Administrative Information. A12.2.1. Request Date. Date the ASI request was submitted.

81

A12.2.2. Requesting Organization Information. Provide the following information for the organization requesting the service interruption and the designated POC. A12.2.2.1. Name, rank and duty title. A12.2.2.2. Unit, Wing, Base, and MAJCOM. A12.2.2.3. E-mail address. A12.2.2.4. Phone number (DSN and commercial). A12.3. ASI Description. A12.3.1. ASI Type. PMI, Routine, or Emergency. See paragraph 7.4. for descriptions of each. A12.3.2. Affected Link/Node/Functional System/Service. Specify the service or system that is impacted by the requested service interruption (e.g., file/print, E-mail, base backbone). Also specify any specifically effected components that make up the impacted service or system. A12.3.3. Actions to be Completed. Describe the actions to be completed during ASI (e.g., upgrade, replacement, reboot). A12.3.4. Expected Effect. Describe the effects the actions to be completed will have on the service/ system and include expected negative impacts if the service interruption is not approved. A12.3.5. Expected Impact to the AFEN and Supported Operations. Describe the expected impact to the AFEN and supported operations while the actions to be completed are implemented. Include the number of users that will be impacted. Clearly specify the direct impact to any missions. A12.4. Implementation Schedule. A12.4.1. Requested ASI Start Date and Start Time (in ZULU time). A12.4.2. Scheduled Duration of ASI. A12.5. Implementation Details. A12.5.1. ASI Implementer. Specify who will actually perform the actions to be completed during the period of the ASI (e.g., contractor support, NCC/NOSC crew members). A12.5.2. Monitoring Plan. Describe the plan for monitoring the system/service while the actions to be completed are ongoing. A12.5.3. Rollback/Recovery Plan. Outline the rollback/recovery plan that will be enacted should the actions to be completed fail.

82

AFI33-138 28 NOVEMBER 2005

A12.6. Approvals. List applicable local level approvals and the name, rank, and duty title of the individual providing local approval (e.g., wing commander, MAJCOM DAA) and the date/time approval was granted.

AFI33-138 28 NOVEMBER 2005 Attachment 13

83

INTERIM CHANGE (IC) 2005-1 TO AFI 33-138, ENTERPRISE NETWORK OPERATIONS NOTIFICATION AND TRACKING 28 NOVEMBER 2005 OPR: SAF/XCIFN (Maj Sam Arwood) Certified by: SAF/XCIF (Col Porter Clapp) This Air Force instruction (AFI) implements Air Force Policy Directive (AFPD) 33-1, Command, Control, Communications, and Computer (C4) Systems; the Information Assurance Vulnerability Management Program; and incident and vulnerability reporting guidance provided in Chairman of the Joint Chiefs of Staff Manual (CJCSM) 6510.01, Defense-in-Depth: Information Assurance (IA) and Computer Network Defense (CND). This instruction prescribes and explains the various notification and tracking processes required to direct action and report status throughout the Air Force Network Operations (AFNETOPS) hierarchy. The specific processes addressed include Time Compliance Network Order (TCNO); Command, Control, Communications and Computers Notice to Airmen (C4 NOTAM); and incident, vulnerability, security incident, and service interruption reporting. This instruction applies to all Air Force military and civilian personnel and to Air Force contractors who develop, acquire, deliver, use, operate, or manage Air Force information systems. Supplementation of this instruction is permitted but is not required. If supplements are issued, major commands (MAJCOM), field operating agencies (FOA), and direct reporting units (DRU) will furnish a copy to Secretary of the Air Force (SAF/XCIF), 1030 Air Force Pentagon, Washington DC 20330-1030; field units will furnish a copy to the next echelon of command. This publication applies to the Air National Guard. Send recommended changes or comments to Headquarters Air Force Communications Agency (HQ AFCA/EASD), 203 W. Losey Street, Room 1100, Scott AFB IL 62225-5233, through appropriate channels, using Air Force (AF) IMT 847, Recommendation for Change of Publication, with an information copy to SAF/XCIF. The reporting requirements in this instruction are exempt from licensing in accordance with AFI 33-324, The Information Collections and Reports Management Program; Controlling Internal, Public, and Interagency Air Force Information Collections. Ensure that all records created as a result of processes prescribed in this publication are maintained in accordance with Air Force Manual (AFMAN) 37-123, Management of Records (will become AFMAN 33-363), and disposed in accordance with Air Force Records Information Management System (AFRIMS) Records Disposition Schedule (RDS) located at https://afrims.amc.af.mil/rds/ index.cfm. See Attachment 1 for a glossary of references and supporting information. SUMMARY OF REVISIONS This change incorporates interim change (IC) 2005-01 (Attachment 13) and alters FOA/DRU reporting directly to the Air Force Network Operations and Security Center (AFNOSC) due to FOA/DRU NOSC realignment. Mission Support Centers (MSC) will be treated as Network Control Centers (NCC) for reporting purposes. Multiple tables have been updated to reflect this conversion. Additional minor administrative corrections were made and office symbols updated.

84 Figure 1.1. Notification and Tracking Hierarchy.

AFI33-138 28 NOVEMBER 2005

NOTES: 1. This category applies to those Program Management Offices (PMO)/System Program Offices (SPO) that fall under a HQ USAF functional and do not administratively align under Air Force Materiel Command (AFMC). 2. This category applies to those HQ USAF FOA and DRU Network Control Centers (NCC) or Mission Support Centers (MSC) that operate and maintain a network. All other FOA/DRU tenant units residing on an Air Force base shall comply with the security policy of the host base NCC and the supporting NOSC. 2.2. Director, Information, Services and Integration (SAF/XCI) will: 2.2.5. Be the Air Staff focal point for the consolidation and presentation of situational awareness vulnerability, incident, and network/system availability data to senior Air Force leaders (e.g., Deputy Chief of Staff, Air and Space Operations [HQ USAF/XO]; Deputy Chief of Staff, Installations and Logistics [HQ USAF/IL]; Secretary of the Air Force, Office of Warfighting Integration and Chief Information Officer [SAF/XC]). 2.4.1. Develop AFNETOPS notification and tracking processes consistent with SAF/XCI policy and guidance.

AFI33-138 28 NOVEMBER 2005

85

2.6.7.5. Report all validated incidents to JTF-GNO and other agencies (e.g., SAF/XCI, Air Force Office of Special Investigations) as required. 2.6.7.6. Disseminate incident reports, trend analysis and vulnerability assessments to NOSCs, SAF/XCI, and HQ AFCA/EVPI, as required. 2.6.10. Track, compile, analyze, and report Air Force-wide statistics on unauthorized network activities, malicious logic, and virus incidents. Report the analysis results to AFCA/EVPI as required according to AFI 33-205. 2.7.6. Work with the AFNOSC, NCCs, and MSCs to assist customers in eradicating malicious logic from networks, information systems, and stand-alone computing devices. 2.7.7. Work with the AFNOSC, NCCs, and MSCs to assist customers in assessing the scope of unauthorized network activities and incidents. 2.8. Network Control Center (NCC)/Mission Support Centers (MSC) will: 2.8.4. MSCs are treated as NCCs throughout the rest of this instruction. 3.13.1. Action Addressees: NOSCs, and all Air Force-level PMOs and SPOs not administratively assigned to AFMC. 3.13.2. Information Addressees: SAF/XCIF, HQ USAF/XOIW, Numbered Air Force SC/A6s, HQ AFCA/EVPI, HQ AFCA/ECF/ECN, and others as required. 3.15.3. DELETED 3.15.4. The AFNOSC will receive TCNO acknowledgement reports from NOSCs, and Air Force-level PMOs and SPOs.

86

AFI33-138 28 NOVEMBER 2005

Table 3.4. Time Compliance Network Order (TCNO) Extension Approval Process. R U L E 1 2 3 4 5 6 7 8 9 10 11 12 third extension second extension A If the extension requested is a first extension B and it is being requested by the NCC NOSC C then it must be endorsed by the wing/base DAA (Note 1) first Colonel in NOSC chain of command D and the approval authority will be the MAJCOM DAA

FOA/DRU NCC/MSC FOA/DRU DAA (Note 2) PMO/SPO NCC NOSC program manager functional system DAA wing/base DAA (Note 1) AFNOSC Director and MAJCOM DAA (Note 2) MAJCOM DAA

FOA/DRU NCC/MSC FOA/DRU DAA (Note 2) PMO/SPO NCC NOSC functional system DAA wing/base DAA (Note 1) AFNETOPS/CC and MAJCOM DAA (Note 2) MAJCOM DAA

FOA/DRU NCC/MSC FOA/DRU DAA (Note 2) PMO/SPO functional system DAA

NOTES: 1. In those cases where the MAJCOM DAA has assumed the responsibility of the wing/base enclave DAA, the request for extension must still be endorsed by the host wing commander. Refer to AFI 33-202, Volume 1, Network and Computer Security, for the definition and assignment of DAAs. 2. Send extension requests electronically to the following E-mail account: Secure: [email protected] 3.24.3. The AFNOSC will make current TCNO extension information available to NCCs, NOSCs, PMOs, SPOs, and SAF/XCI. 3.28.4. DELETED 3.28.5. The AFNOSC will record and compile TCNO compliance statistics from all NOSCs. The AFNOSC will provide updates of Air Force compliance with TCNO-linked IAVAs to the JTF-GNO based on this compiled information.

AFI33-138 28 NOVEMBER 2005 Table 5.2. Incident Reporting Action Matrix. and the Primary Recipient will be WM NCC NCC NCC NCC NOSC AFNOSC

87

If the originator / recipient of the IR is End User WM FSA ISSO ISSM NCC NOSC Actions 1

then take the indicated Actions 1 2, 8 2, 8 2, 8 2, 8 3, 8 4-8

and Informational Recipients will be N/A ISSO and FSA ISSO/ISSM ISSM and Wing IA Office Wing IA Office and DAA Wing/FOA/DRU IA Office and DAA MAJCOM IA Office and MAJCOM DAA

Upon detection of an incident, end users will immediately notify their assigned WM and provide information to assist the WM making required notifications and in filling out an IR. If the WM is unavailable, end users will immediately notify the next computer security professional in the chain of command (i.e., FSA, NCC, NOSC, ISSO, ISSM, etc.). Upon detection or notification of an incident, the WM, FSA, ISSO, or ISSM will notify their servicing NCC. After notifying the NCC, the WM, FSA, ISSO, or ISSM will prepare and transmit an IR to the servicing NCC. If there is no servicing NCC, send the IR directly to the parent NOSC. Upon detection or notification of an incident, notify the parent NOSC. After notifying the NOSC, prepare and send an IR to their parent NOSC. Upon detection or notification of an incident, contact the AFNOSC for assessment of the incident and assignment of an IRID (upon validation). After making initial contact with the AFNOSC, follow-up by submitting an initial IR and generate a UEC4N to track the event. Submit an update IR every 7 days until all actions required to resolve the incident are complete. Submit a final IR within 24 hours of the all action related to the incident being completed. Send an informational copy of all IRs to the Informational Recipients indicated.

2

3 4 5 6 7 8

88 Table 5.3. Malicious Logic Reporting Action Matrix. and the Primary Recipient will be WM NCC NCC NCC NCC NOSC AFNOSC

AFI33-138 28 NOVEMBER 2005

If the originator / recipient of the MLR is End User WM FSA ISSO ISSM NCC NOSC Actions 1

then take the indicated Actions 1 2, 3, 9 2, 3, 9 2, 3, 9 2, 3, 9 4, 9 5-9

and Informational Recipients will be N/A ISSO and FSA ISSO/ISSM ISSM and Wing IA Office Wing IA Office and DAA Wing/FOA/DRU IA Office and DAA MAJCOM IA Office and MAJCOM DAA

End users will immediately report any suspected or actual malicious logic incident to their WM. This includes reporting all virus alerts generated by anti-virus software, whether the user believes them to be valid or not. If the WM is unavailable, end users must report the event to the next network or computer security professional in the chain of command (i.e., ISSO, ISSM, FSA, etc.) Remove the malicious logic and gather information from the end user to prepare an MLR. WM, FSA, ISSO and ISSM will submit an MLR to the servicing NCC. If there is no servicing NCC send the MLR directly to the parent NOSC. For malicious logic events that result in an infection (i.e., the malicious logic was not quarantined or eradicated by anti-virus software), the NCC will immediately submit an MLR to their parent NOSC and will provide periodic updates to the NOSC until the malicious logic has been eradicated. NOSC will create and update MLR incident records through the Computer Security Assistance Program 21st Century Database System (CDS). For those organizations that do not have access to CDS, submit final MLRs directly to the AFNOSC via E-mail. Submit an initial UEC4N to the AFNOSC upon initial notification of a confirmed malicious logic infection within their AOR. Submit an update UEC4N every 24 hours until the malicious logic is eradicated. Submit a final UEC4N within 24 hours of a malicious logic infection being eradicated. Send an informational copy of all MLRs to the Informational Recipients indicated.

2 3 4

5

6 7 8 9

AFI33-138 28 NOVEMBER 2005 Table 5.4. Vulnerability Reporting Action Matrix. and the Primary Recipient will be WM NCC NCC NCC NCC NOSC AFNOSC

89

If the originator / recipient of the VR is End User WM FSA ISSO ISSM NCC NOSC PMO or SPO Actions 1

then take the indicated Actions 1 2, 9 2, 9 2, 9 2, 9 3, 7- 9 4, 5, 7- 9 6-9

and Informational Recipients will be N/A ISSO and FSA ISSO/ISSM ISSM and Wing IA Office Wing IA Office and DAA Wing/FOA/DRU IA Office and DAA MAJCOM IA Office and MAJCOM DAA

N O S C o r Functional System DAA AFNOSC

Upon detection of a vulnerability, end users will immediately provide information to their WM to assist the WM in filling out an initial Vulnerability Report (VR). If the WM is unavailable, end users will immediately notify the next computer security professional in the chain of command (i.e., ISSO, ISSM, FSA, NCC, NOSC). WM, FSA, ISSO, and ISSM prepare and send reports to the servicing NCC. If there is no servicing NCC send the report directly to the parent NOSC. NCCs prepare and send reports to their parent NOSC. NOSCs, and USAF PMOs/SPOs will contact the AFNOSC to obtain a VR tracking number. Prepare and send an initial VR to the AFNOSC within 24 hours of detection. Generate a UEC4N to track the event. PMOs or SPOs detecting a vulnerability in their functional system will prepare and submit a VR to their servicing NOSC (MAJCOM PMO/SPO) or to the AFNOSC (USAF PMO/SPO). Prepare and send update VR to the Primary Recipient as directed (at least every 30 days). Prepare and send a final VR to the Primary Recipient within 5 days of resolution. Send an informational copy of all VRs to the Informational Recipients indicated.

2 3 4 5 6 7 8 9

90 Table 6.1. Security Incident Reporting (SIR) Action Matrix. and the Primary Recipient will be WM NCC NCC NCC NCC NOSC AFNOSC

AFI33-138 28 NOVEMBER 2005

If the originator / recipient of the SIR is End User WM FSA ISSO ISSM NCC NOSC 1

then take the indicated Actions 1 2, 3, 10 2, 3, 10 2, 3, 10 2, 3, 10 2, 4, 7-10 5-10

and Informational Recipients will be Unit Security Manager ISSO and FSA ISSO/ISSM ISSM and Wing IA Office Wing IA Office and DAA Wing/FOA/DRU IA Office and ISPM MAJCOM IA Office and MAJCOM DAA

Actions: (NOTE: SEND ALL REPORTS BY SECURE MEANS) Personnel discovering an electronic file, document, presentation, etc., containing information classified above the level the system is cleared for, must cease all operations on the affected system immediately and report the security incident to their WM via secure means. If the WM is unavailable, report the security incident to the next network/security professional (e.g., FSA, ISSO, ISSM, Unit Security Manager) in the chain-of-command or to the servicing NCC via secure means. Coordinate with the NCC to isolate, clear, and sanitize the affected systems and to report damage assessment information. Provide required information from paragraph 6.4.1. to the servicing NCC by secure phone. If there is no servicing NCC, provide the initial report directly to the NOSC by secure phone. Notify the NOSC immediately via secure phone and submit an initial SIR. Specify whether the security incident/CMI is contained to a single base or if it is a CMI that affects multiple sites (see paragraph 6.5.). Assign an SIRID per paragraph 6.4.2. for each reported security incident. Immediately notify the AFNOSC via secure phone and convey the initial SIR information (see paragraph 6.4.1.). Generate a UEC4N to track the resolution of the security incident. Prepare and send an appropriately classified initial SIR to the Primary Recipient. Prepare and send an update SIR to the Primary Recipient every 4 hours until the security incident is closed. Prepare and send a final SIR to the Primary Recipient within 2 hours of completing sanitization.

2 3 4

5 6 7 8 9

10 Send an informational copy of any SIR to the Informational Recipients indicated.

AFI33-138 28 NOVEMBER 2005 Table 7.3. Unscheduled Service Interruption (USI) Action Matrix. If the originator / recipient of information on a USI is a WM or FSA NCC NOSC PMO or SPO Actions 1 2 Troubleshoot and resolve the identified problem when possible. then take the indicated Actions 1, 2, 8 3-6, 8 3-6, 8 7, 8

91

and the Primary Recipient will be NCC NOSC AFNOSC NOSC or AFNOSC

and Informational Recipients will be locally determined

Upon detection or notification of an USI that cannot be resolved at the WM-/FSA-level, notify the servicing NCC through the Help Desk. Provide all available information to assist the NCC with troubleshooting the source of the service interruption. Make an initial voice report to the Primary Recipient in accordance with Table 7.4. Prepare and submit an initial UEC4N to the Primary Recipient in accordance with Table 7.4. The initial UEC4N will contain as much detail as possible. Prepare and submit update UEC4Ns to the Primary Recipient in accordance with Table 7.4. Each update UEC4N should clearly indicate any changes that have occurred since the previously report. Prepare and submit a final UEC4N to the Primary Recipient in accordance with Table 7.4. The final UEC4N should summarize the root cause and any mission impact that resulted from the unscheduled service interruption. Report USIs to the servicing NOSC (MAJCOM PMO/SPO) or to the AFNOSC (USAF PMO/SPO) as specified by applicable AFIs, or the governing service level agreement, memorandum of understanding, or memorandum of agreement. Send an informational copy of all UEC4Ns to the Informational Recipients indicated.

3 4 5 6

7

8

92

AFI33-138 28 NOVEMBER 2005

Table 7.4. Unscheduled Service Interruption (USI) Reporting Timelines. R U L E A If the reporting category is (Note 1) Critical Core Service B and the reporting individual or unit is a WM/FSA NCC NOSC C D and (Note 2) an initial voice report will be made immediately immediately immediately an initial UEC4N is submitted N/A = 30 mins = 30 mins hourly every 2 hrs once restored to normal operations update UEC4Ns submitted the final UEC4N is submitted E F G

then report to NCC NOSC AFNOSC

1 2 3

4 5 6 7

Core Service

WM/FSA NCC NOSC

NCC NOSC AFNOSC

immediately = 30 mins = 1 hour

N/A = 1 hour = 2 hours every 4 hrs every 8 hrs once restored to normal operations

E n d - U s e r WM or FSA NCC Equipment

w h e n W M / N/A, a trouble ticket will be opened at FSA the NCC resolution not possible

8

Functional system user f u n c t i o n a l as specified by functional system controlling authority System system help desk or support center PMO SPO or NOSC AFNOSC o r as specified by applicable AFIs, service level agreements, memorandums of understanding, or memorandums of agreement.

9

Information

AFI33-138

92 pages

Report File (DMCA)

Our content is added by our users. We aim to remove reported files within 1 working day. Please use this link to notify us:

Report this file as copyright or inappropriate

7527


Notice: fwrite(): send of 207 bytes failed with errno=104 Connection reset by peer in /home/readbag.com/web/sphinxapi.php on line 531