Business Use Case

1. Use Case Identification

1.1. Use Case Name: Incident Detection and Coordination

Incident Detection and Coordination

1.2. Agency

Semantic Technology for Intelligence, Defense, and Security (STIDS), with individual project contributions from member partners and agencies including Industries, Federally Funded Research and Development Centers (FFRDCs), Universities, the Unified Cross Domain Management Office (UCDMO), Department of Defense (DoD), Department of Homeland Security (DHS), Department of Justice (DoJ), and numerous members of the Intelligence Community (IC).

1.3. Model Matrix

Identify which intersections of the service/deployment matrix the use case addresses.

Cloud Service Models

Software as a Service (SaaS)

Platform as a Service (PaaS)

Infrastructure as a Service (IaaS)

Cloud

Deployment

Models

Private X X X

Community X X X

Public X X X

Hybrid X X X

ADD: DaaS: Data as a Service: Synchronously time tagged, predictable state meta data snapshots by ORD ID / URN (Organizational Identification, Uniform Resource Name) enabling filtering by subscription logic / subscriber preferences as a service: a single, authoritative track, event, alert, blip derived from n cloud providers e.g., deriving the Single Integrated Operational Picture from the Family of Interoperable (Common) Operational Pictures SIOP / FIOP “The Grail of DoD”

1.4. Created By

Kathleen M. Moriarty, EMC Office of the CTO

Date Created: March 11, 2011

Last Updated By: Katherine Goodier

1.5. Date Last Updated

Created By: Kathleen M. Moriarty, EMC Last Updated By: Katherine Goodier, L-3

Date Created: March 11, 2011 Date Last Updated: March 23, 2011

Version 1.0 Changes

Prepared by EMC April 10, 2023

2. Background

Rapid incident detection and coordination requires automation as a direct result of today’s threat landscape. With the increase in outsourcing via the usage of cloud services, agencies will require tighter security and knowledge on how well their data is protected and possible incidents that could affect their data. It is critical to have automated means to both detect and mitigate/stop attack traffic while augmenting the governance of our cloud-based enterprise. Enterprise data standards that secure cyberspace particularly within cloud-based private and hybrid networks require new governance methodologies that enable a workforce who has a responsibility to locate and retrieve data in support of Lines of Businesses (LoBs) and specific missions.

3. Definitions

Cyberspace is a global domain within the information environment consisting of the interdependent network of information infrastructures, including the Internet, telecommunications networks, computer systems and embedded processors and controllers. (Presidential Directives on Cybersecurity NSPD-54, HSPD-23Jan 8, 2008)

Computational sharing leverages remote procedure calls and semantic web tools to get answers from the many worlds of enterprise data. Existing databases and the proprietary data structures must be capable of providing discovery data in order to augment the governance of incident data. Semantic tools are leveraged to eliminate the need to build yet another data warehouse. While this improves the ability to get needed incident information, regardless of where the data lives, it cannot delay incident response time.

Data represents resources that provide information in a given context or use. Federal Data Reference Model (DRM)

Information is defined as any type of knowledge that can be exchanged, and this information is always expressed (i.e., represented) by some type of data. Federal Data Reference Model (DRM)

Standards are agreements across particular communities of interest, to achieve mutual benefit, based on the best available knowledge and technology. (NIST)

The enterprise is composed of commonly shared functions across both the US Government (DNI, DHS, DoD, DoJ) and their many industry, research, and global partners as summarized in the illustration below:

Prepared by EMC April 10, 2023

4. Concept of Operations

4.1. Current System

Augmented Governance provides near real-time automated incident management by integrating three key concepts within a suite of interoperable Commercial Off The Shelf (COTS) and Government Off The Shelf (GOTS) tools. These key concepts are as follows:

1. Standards: Standards that govern the detection of incidents must be computationally shared and maintained by governing communities.

2. Controls: Security controls that govern the response to incidents must be computationally shared and maintained by governing communities.

3. Reporting: Usable reporting that augments both the system and its administrators’ capabilities to respond to incidents while also informing the governing communities’ capabilities for maintaining standards and controls as incidents are reported.

Augmented governance’s most critical capability is an enhanced knowledgebase that enables routine integration with other systems while simultaneously maintaining service level agreements for timely incident response.

4.1.1 Standards and Security ControlsThere are several mature standards and supporting security controls that support this use case. In order to be recognized by augmented governance, these standards and security controls must be computationally shared and maintained by governing communities. The following is not a complete list.

The CYBEX effort in the ITU.T is aimed at solving this set of problems using a set of protocols. The protocols within the ITU.T’s CYBEX effort incorporate the Security Content Automation Protocols (SCAP), the Incident Object Description and Exchange Format (IODEF) from RFC 5070, Real-time Inter-network Defense (RID) from RFC6045, and several transport protocols including the use of HTTPS for incident response coordination defined in RFC6046. Implementations are in research and development phases. DHS is leading the incident coordination effort for the US government implementation via US CERT. DHS is also involved and monitoring the developments within ITU.T’s CYBEX effort.

At a high-level, SCAP protocols may be used to gather information on the current state of a network including any software OS levels, application levels, patch information, configurations, vulnerabilities, the severity level of vulnerabilities, policy information, compliance information, etc.. This information may be used to identify potential incidents, which would then be represented in an IODEF document. The incident management system may use a proprietary format for storing incident information, but would leverage the IODEF document to provide a standard format for sharing incident information. RID provides a wrapper for IODEF and a standard set of communication message exchanges to securely share incident information as well as track down and mitigate/stop attacks related to those incidents. The RID protocol provides policy, security, and privacy consideration options for the exchange of this potentially sensitive information.

NOTE: The DHS alert / event system is now two levels: elevated and imminent: the above paradigm fits neither the old model of five levels of message precedence (e.g., DEFCON, COGCON, INFOCON, NASA five level step tone based system or Naval Undersea NURC five level bases system) -- however, this three level system fits the Coast Guard (only entity not belonging to the DoD)

Actions that can be taken to prevent, reduce, or transfer the risk.

The Severity of effect *could* be based on events exceeding a given threshold and emulated geospatially geographically by multicast zone -- if the severity of effect levels were UNIFORM / STANDARD: Countermeasures

The National Information Exchange Model (NIEM) and the efforts of DHS/OMB via US CERT have begun work on incident coordination through the exchange of IODEF documents. This is in initial pilot phases where they were most concerned with the ability to exchange IODEF documents to parse and use those reports. The transport used in the tests was email and PGP for the first pilot. Further work is needed to incorporate the full spectrum of CYBEX capabilities for both the detection of incidents leveraging the SCAP protocols as well as the ability to incorporate security, privacy, and policy considerations via RID to automate the communication exchanges.

Prepared by EMC April 10, 2023

ADD: DaaS: Data as a Service: Synchronously time tagged, predictable state meta data snapshots by ORD ID / URN (Organizational Identification, Uniform Resource Name) enabling filtering by subscription logic / subscriber preferences as a service: a single, authoritative track, event, alert, blip derived from n cloud providers e.g., deriving the Single Integrated Operational Picture from the Family of Interoperable (Common) Operational Pictures SIOP / FIOP “The Grail of DoD”

Organizational Identification ORG ID: https://www.arin.net/resources/request/org.html An Organization ID (Org ID) represents a business, nonprofit corporation, or government entity in the ARIN database. The Org ID is defined by a legal name, postal address, and points of contact. IP addresses and AS numbers directly assigned or allocated by ARIN must be associated with an Org ID. Internet Service Providers and other direct allocation holders may also reassign or reallocate [spontaneously organize / reorganize e.g., Net Enabled Operations / Net Centric Warfare)

URN Uniform Resource Names (URNs) RFC 2141

• A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that uses the urn scheme, and does not imply availability of the identified resource. Both URNs (names) and URLs (locators) are URIs, and a particular URI may be a name and a locator at the same time.http://tools.ietf.org/html/rfc2141

• RFC 2141 International Engineering Task Force IETF: The Functional Requirements for Uniform Resource Names are described in RFC 1737. The URNs are part of a larger Internet information architecture which is composed of URNs, Uniform Resource Characteristics (URCs), and Uniform Resource Locators (URLs). Each plays a specific role:

• URNs are used for identification,

• URCs for including meta-information.

• URLs for locating or finding resources.

RFC 6045: IODEF Information: Time Stamps (DetectTime, StartTime, EndTime, ReportTime). p32 line 12

<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN"> name = ORG ID (TF_HELP) / URNCERT-FOR-OUR-DOMAIN#208-1 "Cert for our Organization"</iodef:IncidentID><iodef:DetectTime>2004-02-05T08:13:33+00:00</iodef:DetectTime><iodef:StartTime>2004-02-05T08:13:31+00:00</iodef:StartTime><iodef:EndTime>2004-02-05T08:13:33+00:00</iodef:EndTime><iodef:ReportTime>2004-02-05T08:13:35+00:00</iodef:ReportTime>

• Synchronous, reliable and predictable time stamps to enhance event tracing, net analytics, forensics: IEEE® 1588 Precision Time Protocol : timestamp and send a follow up message.

– 6.2.2 IEEE 1588 Receive Packet Parser and Timestamp HEARTBEAT function

NCDXF/IARU International Beacon Project - Tools for Listeners: collection of tools to display BEACON information, analog clocks, maps, solar terminator, propagation, NIST time and almanac information. ...www.ncdxf.org/beacon/beaconprograms.html http://www.ncdxf.org/pages/beacons.htmlhttp://www.iaru.org/iaru-index.html#beacon

www.ustiming.org » Deploying NIST time across the Globe: the US Time Server make the first singular digital heartbeat across the US.

4.2. Desired Cloud Implementation

The cloud implementation of the system begins by establishing the need to augment the governance of incidents in a detailed Memorandum of Understanding (MOU) that is computationally shared with the Augmented Governance system. This MOU defines the specific Standards, Controls, and Reporting requirements needed for a detailed Use Case.

Prepared by EMC April 10, 2023

For example, CSIRTs should be equipped with the tools to communicate incident information following the international standards. IODEF is the standard in use today for the format of incident information. RID provides a wrapper on the IODEF document to assist with security, privacy, and policy concerns as that incident information is shared with other parties. Federal Agencies will require the ability to communicate with the CSIRTs of their cloud providers as well as with US CERT. This will enable Agencies with the ability to exchange incident information in a mode where they learn about new threats and leverage the information sharing capabilities to track down and either stop or mitigate attack traffic (provided by RID). Transport of IODEF and RID rely upon HTTPS as defined in RFC6046, however the ITU.T CYBEX project is extending the support for the use of additional protocols.

Methods that may raise concern include those that involve storing packets for some length of time in order to trace packets after the fact.

5. Primary Actors

The Primary Actors needed to augment the governance of incidents must be defined in a detailed Memorandum of Understanding (MOU) that is computationally shared with the Augmented Governance system. The Primary Actors in the MOU must define the specific Standards, Controls, and Reporting users in the detailed Use Case. This level of detail must include details on enterprise level reporting points of contact and responsible party phone numbers and call trees that must be maintained in both normal and emergency conditions. Some example actors are listed below, but this is not a complete list.

Provider CSIRT: The Computer Security Incident Response Teams (CSIRT) of cloud providers would be responsible for the continuous monitoring capabilities of their service offering, which can be leveraged for the detection of incidents. If an incident were detected by the CSIRT of a cloud provider, they would be responsible for creating an incident report in the IODEF and managing any communications of it via the RID protocol and appropriate transport.

CSIRT of Agency: The agency who may be outsourcing services from a cloud provider may detect an incident within the hosted environment from their monitoring reports, from a change in service, or from a detected loss or corruption of information assets, etc. The Agency would be responsible to report this occurrence to the CSIRT of the Cloud Provider via an IODEF document to gain assistance in tracking down the incident details and any follow on actions that may be appropriate. The IODEF report would be communicated to the Provider CSIRT, and possibly other CSIRTs like US CERT, via the RID protocol and the appropriate transport.

US CERT: Provides a central coordination point for US Federal Agencies for incident response. US CERT will require the ability to communicate with the CSIRT of Agencies as well as CSIRTs of Cloud Providers and other CSIRTs nationally and globally.

6. Business Goal

Augmented governance will provide the ability to coordinate incident handling across a muti-tenant and loosely coupled enterprise. From a business case standpoint, this ability will assist greatly in the identification, awareness, and mitigation of attack types including Advanced Persistent Threats, Fraud, Denial of Service, loss or compromise of information assets, across security domains. In addition, augmented governance will provide the capability to securely share information with mission partners while safeguarding both mission partner and US information assets and services.

Prepared by EMC April 10, 2023

7. Service model

The detection and communication of security incidents could occur within any cloud model as well as within any agency’s own network. Incidents may not be limited to computer security, but may also include IT Operations, management, and data. The relevance of augmented governance for cloud services is the need for continuing coordination between governance bodies and Cloud Service Providers as well as US CERT and National Threat Operating Centers (NTOC). When information assets that are hosted require digital rights or security protection, the affected services must be mapped to their applicable layers and data must be appropriately shared so that situational awareness of incidents can be maintained by governing systems and information exchanges. For example, the CSIRT capabilities may be provided through a service model (SaaS). Agencies exchanging data with CSIRT might use an outsourced model for this function.

Mapping Across All Layers

Layers ( Vertical Orientation)

Business

Technical

Mission

Strategic Goal

Initiative

Objective

Strategy

Information Sharing

Enhance Collaborative Analytics

Create Decision Advantage

Integrate Intelligence Capabilities

OutcomesPerf/Mgmt Framework

Enterprise Competency

Enterprise Component

Technical Service

System Function

Enterprise Service

Data Entity

Data Struct

Data Area

Customer Relationships

Customer

Forms Entry

Modify Customer Profile

Software Engineering

IT Application Services

Mission & Business Results, Customer Results, Process & Activities

Software Development

Services

Customer EntityData Model

Data

Data Attributes

Met

rics

Metrics

System

Enterprise Entity

Enduring Functional Exchange

Met

rics

Enterprise Commodity

Thread

Customer Profile

UNCLASSIFIED

UNCLASSIFIED

Prepared by EMC April 10, 2023

8. Deployment model

The use case is ubiquitous since the topic is incident detection and coordination. Possible deployments are depicted below:

Prepared by EMC April 10, 2023

Enables mapping of Governance/Management/Resource data to Enterprise & Technical Services 6 “Global”

5 “Joint ”

4 “Community”

2 “Shared Element”

3 “Domain”

1“Private Element”

IC, DoD, Coalition, Industry

IC & DoD only (Joint Governance)

Internal only (Community Governance)

Managed/resourced/governed by an Element (e.g.,, Agency, Program, etc.) but exposed and made available to the greater community

Represents joint management/resourcing/governance by one or more Elements to meet a specific need (e.g., a Community Of Interest) or an enduring function

Managed/resourced/governed by an Element (e.g.,, Agency, Program, etc.) for utilization only by that Element

9. Reference Architecture

All reference architectures and the missions they support are applicable because incident detection and coordination is ubiquitous.

An example is depicted below:

Prepared by EMC April 10, 2023

DRM

Meta-Model

Mission

Strategic Goal

Initiative

Objective

Strategy

Perf/Mgmt Framework

Enterprise Competency

Enterprise Component

Technical Service

System Function

Enterprise Service

Data Entity

Data Struct

Data Area

Customer Relationships

Customer

Forms Entry (e.g. Oracle Forms)

Modify Customer Profile

Software Engineering

IT Application Services

Mission & Business Results, Customer Results, Process & Activities

Software Development

Services

Customer EntityData Model

Data

Data Attributes

Met

rics

Information Sharing

Metrics

Enhance Collaborative Analytics

Create Decision Advantage

Integrate Intelligence Capabilities

Outcomes

Operational Path: Line of Sight)

Role Workflow Service Contract. . .Customer

Product

SRM Service ComponentsService Domain

Service Type

Service Component

BRM Sub-FunctionsBusiness Area

Sub-function

Line of Business

ECM

PRM Framework

Technical Process (Service Spec)

Enterprise Process (Service Spec)

TRM Elements

System

Enterprise Entity

Enduring Functional Exchange

Met

rics

Enterprise Commodity

Thread

Customer Profile

Agency Specific

Agency Specific

10. Necessary Conditions

Computational sharing MOUs and augmented governance systems must be established across security domains.

10.1. Security

Security and accreditation requirements for multiple protection levels as required by the MOU must be met.

For example, the augmented governance system could receive a computationally shared version of the specification in the ITU.T X.1500 CYBEX work that provides a wrapper to leverage the use of SCAP, IODEF, RID, and associated transport protocols. References are provided to the various protocols when they have been standardized in other International Standard bodies such as those in the Internet Engineering Task Force (IETF) including IODEF, RID, and transport. Security and other considerations are fully outlined in the specifications.

10.2. Interoperability

Augmented governance’s most critical capability is an enhanced knowledgebase that enables routine interoperability and integration with other systems while simultaneously maintaining service level agreements for timely incident response.

For example, the augmented governance system must be capable of integrating the requirements in IODEF, RID, and the specified transport protocols to enable their exchange of incident information. The exchange of information and ability to easily import incident information requires a set of standard formats. These standard formats will also enable enhanced incident tracking as reporting moves between parties identified in the MOUs. These capabilities also enhance the generation of metrics to determine the impact of incidents over a period of time or for specific types of incidents.

Continuing with this illustrative example, the reporting standards identified in the MOU provide an automated and computational means for maintaining communications between an IODEF document via RID. This enables agreed upon communication exchanges and to inform parties involved in incident investigations of the status of those incidents as they evolve. It also facilitates methods to consider privacy, security, and policy information of individual incidents. RID can enable the information contained in an incident request/response to expand or be limited based on the privacy considerations for that incident. The privacy determination of the response may be to only provide the necessary information. The range of information on the incident may be from a simple statement that the problem was addressed to providing a complete report of what transpired including the result of an investigation.

Add: Temporal Interoperability: http://www.igi-global.com/bookstore/article.aspx?titleid=51189

Add: Cross Cloud Synchronous Data Exchanges and depiction of event by exceeding / decrement of events / alerts by severity / threshold depicted geospatially as multi-color radius by router/switch/server hop count (see Real-time Inter-network Defense 6.4.1 Multi-hop TraceRequest Authentication Extended Incident Handling Working Group Kathleen M. Moriarty Internet-draft EMCIntended status: Informational July 6, 2010 draft-moriarty-post-inch-rid-12.txt http://tools.ietf.org/pdf/draft-moriarty-post-inch-rid-12.pdf)

10.3. Portability

Augmented governance’s enhanced knowledgebase enables portability of incident standards, controls, and reporting requirements while maintaining a master data management capability that permits community members to adjust for changing mission requirements while managing their incident reporting capabilities, e.g., CSIRT capabilities.

Prepared by EMC April 10, 2023

10.4. Other

Augmented governance enables secure information exchanges while safeguarding both public and private data across security domains. This enables information security in a variable trust environment that is responsive to dynamically changing conditions.

11. Priorities and Risks

Augmented governance priorities and risk assessments are as varied as the data and information being protected. Therefore, priorities and risk best assessed at the detailed mission level.

12. Essential Characteristics

The augmented governance system meets four of the five essential characteristics of a cloud computing system along with the benefits provided by each of these characteristics.

Broad network access – Yes, augmented governance services would be provided via protected channels (by protocols) over the broadband of the service provider and/or agency.

Resource pooling – Yes, for example, CSIRT activities will require some coordination with US CERT, which will be primary for resource pooling. Agencies may also outsource their CSIRT to enable further resource pooling capabilities.

Rapid elasticity – Yes, augmented governance protocols can be expanded and in fact enable elasticity in incident handling that has not been adequate in the past.

Measured service – Yes, by moving to computationally shared standard formats to manage incidents across multiple parties, the capability to track metrics and Key Performance Indicators (KPIs) for incident management is measurable.

The augmented governance system partially meets the fifth essential characteristics of a cloud computing as follows:

On-demand self service – The ability to detect incidents would be partially on-demand. For example, if standard formats are used as defined in the MOU, then the ability to interact with a system that generates and submits an IODEF report to a CSIRT on demand for incidents will be realized. However, incidents including loss of data or unusual behavior outside of the augmented governance standard formats must also be detected. A semantic data parser, the Automated Compliance Tool (ACT), provides an as-needed rather than on-demand tool that enables the augmented governance system to predict incidents outside of the standard on-demand and self-service reporting. ACTs predictive incident detection supports both proactive and reactive knowledgebase development.

Prepared by EMC April 10, 2023

13. Normal Flow

The normal augmented governance data flow is partially illustrated by the notational diagram below. Beginning with the computationally shared and maintained standards, use cases feed an automated compliance tool (ACT) knowledgebase. ACT maintains a master data management record of applicable events that are fed by a semantic query tool. This semantic query enhances the standard incident knowledgebase with additional predictive incident information. These incidents are related back to the real-time dynamic policy engine that supports the security controls as identified in the use cases. Reporting is then distributed to the augmented governance community who is identified in the computationally shared MOU. Detailed examples are depicted in the example Use Cases.

Prepared by EMC April 10, 2023

37 37

ACT Notional model

policy violations

ACT database

state of the

system

ACTUse cases

Dynamic policies related to auditing

applicable events

Augmented Governance

ACT Module

Example normal flow for use cases supported by the standard RID specification, RFC6045, are shown in some detail. A brief synopsis is provided here for the each type of the messaging communications, described by use case flows.

Use Case 1:

Information Sharing: An incident type is identified and CSIRTs would like to share that information with other CSIRTs. The incident information may be a list of IP addresses known to be malicious or a type of an attack described (for example) in MAEC and imbedded in an IODEF document. In this use case, a central authority, US CERT, may have knowledge of several instances of an attack type for which the supported community should be notified to increase awareness and detection capabilities for the attack type or sources.

Information Sharing Flow: US CERT generates an IODEF document, using the relevant SCAP and other information sources, and sends a RID Report message out to all Agency CSIRTs with one or more attack type descriptions or information about malicious entities. No response is required for this communication type.

Use Case 2:

Incident Query: An incident query communication is used when one CSIRT would like to know if a type of attack has been detected by other CSIRTs. The information provided back can be limited to descriptions of the attack without providing source and destination information if that is sensitive. This use case is sending the request to US CERT because they may have a broad knowledge set of attack types within the government sector to share with Agency CSIRTs.

Incident Query Flow: An Agency CSIRT sends an IncidentQuery to US CERT. US CERT responds with a Report message.

Use Case 3:

Investigation Request: An incident is detected by a CSIRT and further investigation is required to identify and mitigate or stop the attack. In this use case instance, the Agency CSIRT will detect the incident. It could be identified by any CSIRT including US CERT or the Provider CSIRT in other use cases.

Investigation Request Flow: An Agency CSIRT detects an incident. The source of the incident is identified using SCAP and event information and an IODEF document is generated. The IODEF document is sent to the Provider CSIRT in a RID Investigation message using the appropriate transport protocol. The Provider CSIRT decides to work on the incident investigation, then sends the proper response, a Result message when the investigation is complete. Note: The Result message can contain the information deemed appropriate for sharing with the Agency CSIRT (as much or as little as policy and privacy considerations permit). In this use case, the Provider CSIRT sends the full investigation Report including the source of the attack and the action taken to stop the attack, traffic from the source address was blocked.

Use Case 4:

Investigation Request: An incident is detected by a CSIRT and further investigation is required to identify and mitigate or stop the attack. In this use case instance, the Agency CSIRT will detect the incident. It could be identified by any CSIRT including US CERT or the Provider CSIRT in other use cases.

Investigation Request Flow: An Agency CSIRT detects an incident. The source of the incident is identified using SCAP and event information and an IODEF document is generated. The IODEF document is sent to the Provider CSIRT in a RID Investigation message using the appropriate transport protocol.

The Provider CSIRT is unable to work on the Investigation request, a RequestAuthorization message is sent to the Agency CSIRT to notify them of the inability to respond at this time. The Agency CSIRT takes an action to block the source address from accessing the application that was targeted using the tools available to them from the Provider.

Use Case 5:

Trace Back Request: In the case where the source of an incident is unknown (possibly spoofed), the ability to iteratively track an incident through providers or networks may be necessary. This communication flow is similar to the Investigation request, but could involve multiple CSIRTs until a source is found or a party does not have the resources to participate. The actions taken in this case may be close to the source of an attack or downstream

Prepared by EMC April 10, 2023

provider from the depending on who cooperates. This use case just describes one of the many possible flows that could occur in the trace back request.

Trace Back Request Flow: An Agency CSIRT detects an incident using event information and the appropriate SCAP information for that event (application server is targeted in a DDoS attack). The Agency CSIRT generates an IODEF document and encapsulates it in a RID wrapper for a TraceRequest. The TraceRequest is sent to the upstream to their Provider’s CSIRT. The Provider CSIRT confirms receipt with a RequestAuthorization message indicating that this can be looked at now by the Provider CSIRT. The investigation begins at the Provider CSIRT, and the next upstream provider has been found (where the traffic is originating), a TraceRequest message is sent to the next Provider CSIRT. The next Provider CSIRT sends a RequestAuthorization response to both the Agency CSIRT (originator of request) and the Provider CSIRT who sent the TraceRequest.

The response provided in the AuthorizationRequest is yes and the incident will be investigated. The investigation has completed and a Result message is sent to the Agency CSIRT. The amount of information provided in the report is up to the CSIRT that sends the report. In this use case, the information provided is limited to a description of the actions taken, the traffic has been rate limited with no information on the true source of the attack. The traffic had originated in a foreign nation and the provider in that nation’s policy limited the amount of data that should be provided in this use case.

14. Frequency of Use

Hundreds of time a week.

15. Special Requirements

The systems performing these functions MUST be considered mission critical and be protected appropriately with security and resiliency in mind.

16. Notes and Issues

The augmented governance tool is currently a reference implementation available only in public domains.

CYBEX is still working on the standards. The IODEF and RID protocols are fully defined already in the IETF standards listed in this document.

17. Risk Register

See Section 11.

REFERENCES / LINKS:

Features/OpenSCAP - FedoraProject: Sep 14, 2010 Provide open-source Security Content Automation Protocol (SCAP) ... basic set of applications and OVAL/XCCDF security content for Fedora 14. ...fedoraproject.org/wiki/Features/OpenSCAP

Heartbeat - FedoraProject : May 24, 2008 Fedora Extras package. heartbeat is a basic high-availability subsystem for Linux-HA. Runs scripts at initialization fedoraproject.org/wiki/Heartbeat

Summer Coding 2010 proposal - beacon wiki integration - FedoraProject: May 21, 2010 ... The name of my project is Beacon. It started off as GSoc Project for Gentoo under the name Web Based XML Editor. ...fedoraproject.org/.../Summer_Coding_2010_proposal_-_beacon_wiki_integration

RPM Search beacon: Fedora 11, archive.fedoraproject.org/fedora/linux/updates/11/i386/beacon-0.5-3.fc11.noarch.rpm rpm.pbone.net/index.php3?stat=3&search=beacon&srodzaj=3

#1580 (Request for Resources for Beacon- A WYSIWYM DocBook editor Aug 7, 2009 ... demo at http://publictest1.fedoraproject.org/beacon/php/beacon.php integrates FAS into beacon: https://fedorahosted.org/fedora-infrastructure/ticket/1580 - Red Hat The Linux Beacon: www.itjungle.com/tlb/tlb061405-story01.html

Prepared by EMC April 10, 2023

Load balancing on Fedora with Heartbeat (MySQL Cluster .. Load balancing on Fedora with Heartbeat (MySQL Cluster www.howtoforge.com

Heartbeat - FedoraProject: http://fedoraproject.org/wiki/Heartbeat

HEARTBEAT is a basic high-availability subsystem for Linux-HA.

It will run scripts at initialization, and when machines go up or down. This version will also perform IP address takeover using gratuitous ARPs. It supports "n-node" clusters with significant capabilities for managing resources and dependencies.

You may optionally install these sub-packages as well:

- ldirectord

- pils

- stonith

- ldirectord

ldirectord is a stand-alone daemon to monitor services of real or virtual services provided by The Linux Virtual Server (http://www.linuxvirtualserver.org/).

The STONITH module (Shoot The Other Node In The Head) provides an extensible interface for remotely powering down a node in the cluster. The idea is quite simple: When the software running on one machine wants to make sure another machine in the cluster is not using a resource, pull the plug on the other machine. It's simple and reliable, albeit admittedly brutal.

PILS is an generalized and portable open source Plugin and Interface Loading System. PILS was developed as part of the Open Cluster Framework reference implementation, and is designed to be directly usable by a wide variety of other applications. PILS manages both plugins (loadable objects), and the interfaces these plugins implement. PILS is designed to support any number of plugins implementing any number of interfaces.

Fedora 1.4 includes: OpenSCAP, an open-source framework for the Security Content Automation Protocol, which provides a framework and approach to maintaining system security backed by NIST standards

Library Files ≈ Packet StormMar 21, 2011 ... The openscap project is a set of open source libraries that .... with thread synchronization primitives (mutexes, condition variables, and r/w locks). ... in addition to avoiding timing and cache-based side channel ...

packetstormsecurity.org/files/tags/library/ openscap.git/commitdiff Sep 16, 2009 ... projects / openscap.git / commitdiff remote NTP Server for time synchronization should be specified or not as ...

git.et.redhat.com Packages beginning with letter Oopenntpd-3.9p1-6mdv2010.1, OpenNTPD - NTP Time Synchronization Client/Server ... openscap-0.5.7-1mdv2010.1, Set of open source libraries enabling ...

fr2.rpmfind.net/linux/RPM/mandriva/devel/.../OByName.html - Cachedopenntpd-3.9p1-7mdv2011.0.i586.rpm - Mandriva Cooker - DownloadOpenNTPD - NTP Time Synchronization Client/Server. openscap pkgs.org/mandriva.../openntpd-3.9p1-7mdv2011.0.i586.rpm.html

-----------------------------------------------------------------------------------------------------------------------------------------

# Reliability in grid computing systems by C Dabrowski activity has been the Open Grid Forum (OGF) [1], but other standards development deterministically, using heartbeat techniques in which resources www.nist.gov/itl/antd/upload/Dabrowski-GridReliabilityEarlyView.pdf

ETSI CLOUD - initial standardization requirements for cloud services by K Oberle - 2010 Open Grid Forum (OGF) Europe, http://www.ogfeurope.eu/ .... control of license usage at application runtime, e.g. heartbeat control by the license server .

portal.acm.org/citation.cfm?id=1884558 #High availability using virtualization by F Calzolari - 2010These strategies involve systems such as heartbeat and cluster computing - ..... E-sciencE EGEE, Open Grid Forum OGF - 4th EGEE User Forum/OGF 25 and OGF iopscience.iop.org/17426596/219/5/.../1742-6596_219_5_052017.pdf

Prepared by EMC April 10, 2023