DISA CONUS SOP.doc

FOUO

DRAFT

DISA CONUS STANDARD OPERATING PROCEDURES (SOP)

METHODS AND PROCEDURES

Global NetOps Support Center (GNSC) Network Event Reporting

1. PURPOSE. To outline GNSC procedures to be followed with respect to reporting network events to GNSC and JTF-GNO decision-makers, as well as NetOps Community members.

2. APPLICABILITY. This SOP applies to all government (military and civilian) and contractor personnel assigned to RN3. More specifically, the procedures outlined in this SOP outline actions to be taken by Network Operations Center (NOC) personnel, the Tactical Mission Director (TMD), Systems Control Officers (SCO’s), and any other RN3 personnel with responsibilities directly related to the reporting of DISN events.

3. REFERENCES.

3.1 DISA CONUS SOP 55-100-01, GNSC Trouble Management System (TMS)

3.2 DISA CONUS SOP 06-09, Commander’s Critical Information Requirements (CCIR)

4. GENERAL.

4.1 Two-Phase Impact Assessment. A two-phase impact assessment approach will be used by the SCO’s and NOC’s to ensure accurate and timely event reporting. The first assessment phase is to establish the Network Impact (NI) of a given event and report on the event’s significance based on that NI, if appropriate. The second phase is to attempt to ascertain the Operational Impact (OI). If during the course of building a picture of the OI it becomes clear that an event’s significance was underestimated (or overestimated) based only on its NI, the significance of the event will be adjusted appropriately, and additional actions may be undertaken in response to the new appreciation of the event’s significance.

4.1.1 History has shown that capturing an accurate picture of OI is difficult and time-consuming. It is essentially impossible, given the information accessible to the GNSC, to provide both quick and complete event reporting to GNSC management, where “complete” is interpreted to mean “including an accurate Operational Impact.” Without an accurate OI, however, it is more difficult to estimate the true significance of a particular event. The significance of an event can be evaluated in terms of its NI, but there isn’t always a direct and linear relationship between NI and OI. That is, an event’s NI may be deemed to be “major,” yet the resultant OI may turn out to be insignificant. Conversely, an event’s NI may seem “minor,” but the event’s OI is in fact very serious. Nevertheless, GNSC policy is to initially rate the significance of an event in terms of its NI, given that the NI is often, if not always, a reasonable indicator of what the OI will turn out to be.

5. PROCEDURES.

5.1. Network Impact Assessment (Phase One). The extent of reporting related to a network event is initially determined by its NI. GNSC SCO’s and NOC’s can determine NI through Configuration Management (CM) databases, Element Management Systems (EMS’s) and other resources (e.g., TMS, WWOLS). These resources are immediately accessible and (with rare exceptions) continuously available to members of the GNSC. GNSC personnel will use these information sources, under the guidance of the GNSC TMS SOP and the DISA CONUS CCIR SOP, to determine an event’s NI and report accordingly. This phase concludes with the reporting to the impacted members of the NetOps community, including a request for OI information from those members.

5.2. Operational Impact Assessment (Phase Two). After the initial reporting of a network event to the NetOps community, OI information should be forthcoming from community members impacted by the event. When the NOC or DCCC receives such information, the NOC controller or DCCC representative will document the information in the TMS ticket. Furthermore, the GNSC will be proactive in terms of aggressively seeking OI information. A member of the SCO Team will call NetOps community members thought to be impacted by the event, requesting information regarding impacted missions or capabilities. Any information gathered in this way will be documented by the SCO Team member in the TMS ticket.

5.1.1 Always note the name of the person providing OI information in the Action Log field of the TMS ticket. Contact information is valuable for future reference in terms of validating to whom an event was reported.

5.1.2 When information regarding OI is obtained, to included information confirming the lack of an operational impact, such information will be placed in the Operational Impact Description field of the TMS ticket.

5.1.3 When new OI information is confirmed, the GNSC will provide a follow-up report to the NetOps community in the form of a COMSPOT.

6. REPORTING CRITERIA

6.1. The events listed in the matrices in Appendix A are baselines for events that require reporting to and by the SCO. This list is not all-inclusive. Additional guidelines/references, DISA CONUS management verbal orders, and customer requirements may influence event reporting norms. If there is any doubt as to the reportability of a particular event, the rule should always be to report it.

6.1.1. The SCO’s and NOC’s will use the following definitions to use the matrices.

· Network Impact: A fundamental change in network capability or capacity, as reported by one or more electronic reporting tools, such as Element Management Systems (EMS’s). Examples include downed circuits, sites isolated from DISN services, bandwidth reductions, and failed equipment.

· Operational Impact: A fundamental change in the operational capability or capacity of a NetOps community member or customer of DISN services, as reported by the community member or customer. Examples include degraded command and control capabilities, inability to execute military missions, and reduced security to friendly forces.

· Severe Degradation: A reduction in capability so significant that it is functionally equivalent to a complete loss of capability. A DISN network element is “severely degraded” when it is rendered unusable.

· Customer Complaint: Any concern expressed by a member of the NetOps community or other customer of DISN services relative to the resolution of a network event. Examples include expressions of frustration with troubleshooting actions, the amount of time required to achieve issue resolution, and increasing/ongoing operational impact.

6.1.2. The following guidelines will be used to determine the impact identifier that will be placed in the Operational Impact Description field of TMS tickets at the time of ticket creation. The initial assignment of this identifier is based on the up-front assessment of both NI and OI, with the understanding that the true OI may not emerge for some time. (Note that the value set in a ticket’s Assigned Priority field directly correlates to the impact identifier selected for the Operational Impact Description field.)

6.1.2.1. Operational Impact = SIGNIFICANT (Assigned Priority = 1): This identifier (and associated priority) will be used in cases where one or more of the following is true.

6.1.2.1.1. The NI at the DISN Services layer involves an isolation of any active duty base/camp/post/station (b/c/p/s), a Combatant Command/Service/Agency (CC/S/A) headquarters, a Defense Enterprise Computing Center (DECC), or a NetOps/C2 Center from any three of the following services: DSN, U/IP, C/IP, DVS, DRSN, JWICS, commercial phone service.

6.1.2.1.2. The NI at the DISN Transport layer involves more than one service isolation at more than one customer site, or a reduction of bandwidth of 75% or more to a theater or significant geographical region (e.g., Europe, the Pacific, CENTCOM AOR).

6.1.2.1.3. The OI reported by the affected customer(s) involves the loss of a mission-essential capability, jeopardized safety or security, or any other situation characterized by the customer(s) as “critical.”

6.1.2.2. Operational Impact = MAJOR (Assigned Priority = 2): This identifier (and associated priority) will be used in cases where one or more of the following is true.

6.1.2.2.1. The NI at the DISN Services layer involves a reduction in capability of 75% or more into a single active duty b/c/p/s, CC/S/A headquarters, DECC, or NetOps/C2 Center with regard to one or two of the following services: DSN, U/IP, C/IP, DVS, DRSN, JWICS, commercial phone service.

6.1.2.2.2. The NI at the DISN Transport layer involves a reduction of bandwidth of 50% to 74% to a theater or significant geographical region (e.g., Europe, the Pacific, CENTCOM AOR).

6.1.2.2.3. The NI at the DISN Transport layer involves an unscheduled outage or “severe degradation” related to the DISN Core (OTS, MSPP or ODXC network elements).

6.1.2.2.4. The OI reported by the affected customer(s) involves adverse effects on mission accomplishment or capability, and no known workaround solutions can be implemented.

6.1.2.3. Operational Impact = MODERATE (Assigned Priority = 3): This identifier (and associated priority) will be used in cases where one or more of the following is true.

6.1.2.3.1. The NI at the DISN Services layer involves a reduction in capability of 50% or more into one or more geographically-separated units, part-time customers, federal contractors, National Guard units, or DoD agencies with regard to one or more DISN services.

6.1.2.3.2. The OI reported by the affected customer(s) involves adverse effects on mission accomplishment or capability, and no known workaround solutions can be implemented, but affected customers are not operational 24/7 and/or the customers have deferred maintenance/fix actions until the next duty day.

6.1.2.4. Operational Impact = MINOR (Assigned Priority = 4): This identifier (and associated priority) will be used in cases where one or more of the following is true.

6.1.2.4.1. The NI at the DISN Services layer involves an inconsistency or annoyance to one or more DISN services customer(s).

6.1.2.4.2. The OI reported by the affected customer(s) involves degradation in mission capability, but a known workaround exists and can be implemented.

6.1.2.5. Operational Impact = NONE (Assigned Priority = 5): This identifier (and associated priority) will be used in cases where one or more of the following is true.

6.1.2.5.1. The NI at the DISN Services layer is known to be negligible, such that customers will be unaffected.

6.1.2.5.2. The OI reported by the affected customer(s) is that there is no loss of mission capability.

7. Document Review. This document will be reviewed and updated on an annual basis or as deemed necessary.

8. Document POC. POC for this document is the RN32 – Wayne Harrington, NetOps Branch Chief.

McCarthy, David, LTC, USA

Chief, DISN Operations Division

Appendix A

Matrix Legend:

Yes – As soon as network information is received the SCO desk and/or NOC Controller will take action.

Note 1 – Yes, immediately inform and directly speak to the NetOps Branch Chief by any means and at any time of day or night. Do not just leave a voice-mail; continue to call until the NetOps Branch Chief is directly contacted. If Branch Chief cannot be contact within 1 hour of initial attempt then the SCO desk will proceed to contact and inform the Operations Division Chief of event.

Note 2 – Yes, if OI of network event is SIGNIFICANT or MAJOR, or the NI of network event is SIGNIFICANT, and happens during normal working hours (0300-2100 seven days a week) the NetOps Branch Chief will be notified of network event ASAP. If network event happens during OFF Duty hours (2100-0600) and the below event criteria are met the NetOps Branch Chief will be notified at 0600 the following day. If OFF Duty hours criteria are not met then the NetOps Branch Chief will be notified immediately. OFF Duty hours network event criteria to be met are:

1) There is a defined course of action to resolve network event.

2) The reported NI and OI are not Significant/Major due to time-of-day of event.

3) The JTF-GNO, NetOps Community, and/or customers are satisfied with the progress toward the resolution of network event.

Note 3 – Yes, if there is SIGNIFICANT or MAJOR OI then report ASAP, even if network event/outage is less than 30 minutes. If there isn’t any OI, the NI is SIGNIFICANT or MAJOR, and the outage continues more than 30 minutes, the event will be reported.

Note 4 – Yes, if there is any OI (Significant, Major, or Minor) concerning CONUS to OCONUS back-bones (B/B) the event will be reported. CONUS to OCONUS B/B network events include, but are not limited to:

1) Any OTN, BWM, or ATM B/B to another DISA Theater (Europe, Pacific)

2) Any ATM B/B, equal to or greater-than an OC-3, into CENTCOM AOR (SWA)

3) Promina B/B connectivity into SWA (Romeo Trunks)

Note 5 – Yes, with the following caveats

1) Must be down or not collecting for at least one hour.

2) If previously briefed, move to residual.

Note 6 – Yes, with the following caveats

1) For ArcSight, analysts can use other tools, MINOR impact

2) For ACID/BASE, must COOP to TNC PAC and TNC EUR, MAJOR impact

3) For other tools, no alternate means to monitor, MAJOR impact Note 7 – Yes or No, this requires analyst discretion along with GNSC NDWO approval. If unsure, contact the Operations Lead for recommendation.

� EMBED MSPhotoEd.3 ���

DEFENSE INFORMATION SYSTEMS AGENCY

DISA CONUS

P.O Box 25860

Scott AFB, IL 62225-5860

PAGE

DRAFT

_1275308470.xls Sheet1

SYSTEMS/NETWORKS Mark Local Brief NOC Verbally Notify SCO Mark GNC Brief SCO Verbally Notify JTF-GNO and the appropriate NetOps CommunityJTF-GNO and the appropriate NetOps Community SCO Send COMSPOT SCO Verbally Notify Branch Chief SCO Mark Ticket Web Briefable

PRINCIPAL SUPPORT

DISN issues (JWICS, DRSN, VTC, etc.) and/or systems impacting POTUS, SECDEF, CJCS/JCS, COCOM CG, MNFI, Service Chiefs and 4 Star Officer (or equivalent) Yes Yes Yes Yes Yes Note 1 Yes

Entire Active Duty Base, Post, Camp, Station or Large Agency isolated /severely degraded from DISN service Yes Yes Yes Yes Yes Note 2 Yes

Active duty unit/organization, Guard or Reserve, Government Agency, or Contract site isolated/severely degradation from DISN services Yes, if longer than 30 mins Yes, if longer than 30 mins Yes, if longer than 60 mins Yes, if longer than 60 mins Yes, if longer than 30 mins Note 2 Yes, if longer than 30 mins

TRANSPORT / IP

Customer Complaint Yes Yes Yes Yes Yes Note 2 Yes

SITE/NODE Isolation Yes Yes Yes Yes Yes Note 2 Yes

Backbone Failure Yes Yes Note 3 Note 3 Note 3 Note 2 Note 3 and/or 4

Device Isolations (Router, CCM, Switch,etc..) Yes Yes Yes Yes Yes Note 2 Yes

Edge Devices Yes Yes Note 3 Note 3 Note 3 Note 2 Note 3

(PowerHub, AP-1000, etc)

Node Isolations Yes Yes Yes Yes Yes Note 2 Yes

Core/Hub Isolation Yes Yes Yes Yes Yes Note 2 Yes

IAP Router Yes Yes Yes Yes Yes Note 2 Yes

DRSN

Switch Failure / Isolation Yes Yes Yes Yes Yes Note 2 Yes

RED NODE Yes Yes Yes Yes Yes Note 2 Yes

(Promina-Red)

General Officers (1,2,3 or 4 Stars) Call Failures Yes Yes Yes Yes Yes Note 1 Yes

B/B Trunk between Red Promina/Red Switches Yes Note 3 Note 3 Note 3 Note 3 Note 2 Note 3

Customer Isolations/ including DRSN Red Phones Yes Yes Yes Yes Yes Note 2 Yes

DMS

Site/Facility Isolations Yes Yes Yes NA NA NA DMS - Yes

Regional Node Isolations Yes Yes Yes NA NA NA DMS - Yes

Two Simultaneous Regional Node Outages Causing Multi-Site Isolation Yes Yes Yes NA NA NA DMS - Yes

HIGH INTEREST

SCAMPI Yes Yes Yes Note 3 Note 3 Note 2 Yes

JWICS Yes Yes Note 3 Note 3 Note 3 Note 2 Note 3

DVS Flag Failure/ Flag-level impact Yes Yes Yes N/A N/A N/A Yes

Flag Failure/ Flag-level impact

NOVA / Yes Yes Note 3 Note 3 Note 3 Note 2 Yes

Scope Command Circuits

UAV/Predator Yes Yes Yes Yes Yes Note 2 Yes

Feeds

REL DMZ (HSDN) Yes Yes Yes Yes Yes Note 2 Yes

DSCS

STEP/DSCS/Teleport/Commercial SATCOM facility failure Yes Yes Yes Yes Yes Note 2 Yes

DSCS Earth Terminal Yes Yes Yes Yes Yes Note 2 Yes

DSCS Link Yes Yes Yes Yes Yes Note 2 Yes

DSCS Satellite Anomalies Yes Yes Yes Yes Yes Note 2 Yes

MONITORING CENTERS

GNSC COOP to a JTF-GNO/TNC Yes Yes Yes Yes Yes Note 1 Yes

JTF-GNO/TNC COOP to GNSC Yes Yes Yes Yes Yes Note 1, if the GNSC cannot support COOP Yes

Impact to the functioning of the GNSC. Loss of any System Admin resources / capability. Yes Yes Yes Yes Yes Note 1 Yes

CND EVENTS

Cat 1, Unauthorized Privileged Access Yes Yes Yes Yes NA Note 1 Yes

Cat 2, Unauthorized User Access Yes Yes Yes NA NA NA Yes

Cat 3, Unauthorized Access Attempt NA NA NA NA NA NA NA

Cat 4, Denial of Service Yes Yes Yes Yes NA Note 1 Yes

Cat 5, Poor Security Practice NA NA NA NA NA NA NA

Cat 6, Unauthorized Scan or Probe NA NA NA NA NA NA NA

NIPR, not Mil-to-Mil

Cat 6, Unauthorized Scan or Probe Yes Yes Yes NA NA NA Yes

Mil-to-Mil (SIPR or NIPR)

Cat 7, Malicious Logic NA NA NA NA NA NA NA

Single asset affected

CND SENSOR OR SERVER OUTAGES

Sensor down or failing to collect data Yes NA NA NA NA NA Note 5

Server down Yes Yes Yes NA NA NA Note 6

Sheet2

Sheet3

_1202620807.bin