Systems architecture · Data integration · Decision support

C2IM

From Fragmented Telemetry to Mission-Centered Information Architecture

A federated reference architecture and operating concept that converted cyber telemetry distributed across organizations, networks, and classification environments into theater-level situational awareness tied to mission consequence.

Role
Reference architecture and CONOPS contributor
Period
Defense service, 2008–2018
Domain
Systems architecture / Decision support
Methods
Source-to-decision mapping · CEF normalization · Correlation · Mission-dependency modeling · DoDAF

01Operational question

U.S. Indo-Pacific Command needed theater-scale cyber situational awareness from telemetry distributed across service components, regional networks, local security systems, enterprise platforms, organizational authorities, event schemas, and classification environments. A local security organization understood activity inside its own boundary; the command needed to know how distributed cyber events related to mission systems and operational risk.

The architecture had to answer one question: how do independently owned systems contribute to shared cyber and mission awareness while preserving local ownership, classification boundaries, network constraints, and mission context? The decision it served: what mission capability is degraded, how severe the consequence could be, and what response is required.

02Why the problem was difficult

  • Fragmentation was the starting state. Equivalent events arrived in different vendor schemas from organizations with different authorities and classification levels.
  • Centralizing logs was insufficient. A firewall alert is not a mission consequence; the transformation from technical event to affected asset, dependency, mission function, and operational consequence had to be designed.
  • Bandwidth and ownership. Wide-area links, local operational needs, and data exposure made unrestricted centralization inappropriate.
  • Security boundaries were first-class constraints. What information belonged in which environment, who could access it, and what could move between environments determined tool placement, retention, and interfaces.
  • Accreditation in transition. The pilot ran under an Interim Authority to Test during the DIACAP-to-RMF transition, so security evidence and technical design progressed together.
  • Configuration risk. Correlation rules, filters, active lists, and connectors could destabilize a production SIEM; change control was part of the architecture.

03My role

I contributed to the Common Cyber Integration Model reference architecture and operating concept as part of the J63 effort.

  • I produced capability-gap analysis, data-source mapping, DoDAF definitions, logical and physical reference-architecture material, and the classified C2IM CONOPS content, and co-authored elements of the ArcSight CONOPS with the program manager. The material was published at the Secret level.
  • I supported the Enterprise Operations Center–Pacific pilot, where ArcSight was the principal SIEM implementation, as the architecture entered an operational environment under an Interim Authority to Test.
  • I mapped each data source to the information it produced, the analytical purpose it served, the mission it affected, and the decision it supported.

04Data architecture

Telemetryflow · endpoint · identity · DNS · proxyvulnerability · payload · indicatorsNormalizationvendor event → connector → common formatCorrelation and enrichmentrules · active lists · host, identity, indicatorsMission dependency modelevent → asset → dependency → mission functionOperational visualizationrole-specific views, analyst to commanderDecisioncapability impact · response priorityRESPOND → EVALUATE → LEARN → COLLECTFederation patternCollect and retain near the sourcePreserve local ownership and analysisForward selectively by mission and policyAggregate at theater level for awarenessPeer and fail over for resilienceSecurity boundaries as architectureUnclassified, secret, and private enclavesPlacement by classification and releasabilityNeed-to-know and least privilegeIn-band paths where policy allowsOut-of-band monitoring throughone-way data diodesTagged information objects carrymission, user, device, trust contextTwo time horizonsReal-time: detect and correlateHistorical: reconstruct and investigate
Sanitized to pattern level. Federation, not centralization, was the governing choice: bandwidth, organizational ownership, classification, and security made unrestricted aggregation inappropriate.

Source-to-decision traceability

Collecting more telemetry had no value unless it contributed to a defined analytic or operational requirement, so the data-source mapping connected every sensor and repository to a decision.

sensor or repositoryinformation producedanalytical purposeaffected missionuser decision

Sources included flow and session data, endpoint events, identity records, DNS activity, proxy logs, vulnerability findings, authorized payload data, and adversary indicators, from ArcSight, NetWitness, SourceFire, NetFlow collectors, identity platforms, proxies, and vulnerability scanners.

05Methodology

Operating model

collectnormalizeretaincorrelateenrichanalyzemap to missionvisualizedecidetaskrespondevaluatelearn

Normalization

SmartConnectors ingested vendor-specific data and translated it into Common Event Format, so a correlation rule reasoned over consistent concepts, source, destination, user, device, event type, severity, time, outcome, instead of every vendor's proprietary representation. This is the most transferable pattern in the project: shared semantics before shared analysis.

vendor eventSmartConnectorcommon event fieldscorrelation and enrichmentcontextualized incidentmission consequence

Two time horizons

Logger retained and indexed normalized events for historical search and forensic reconstruction; Enterprise Security Manager performed real-time correlation, prioritization, investigation, and incident workflow. Separating detection from reconstruction let the system serve immediate operations and deeper investigation without treating every function as the same workload.

Correlation and mission mapping

An authentication anomaly, suspicious network activity, a known vulnerability, and threat intelligence can matter more together than any one alone. Correlation connected those signals; mission mapping converted the correlated incident into what a commander needs: which mission system is affected, which operational function depends on it, what capability may be degraded, how severe the consequence could be, and what decision is required. Analysts kept event-level detail; mission owners and commanders received capability impact and response priority.

Federation and boundaries

Collection and retention sat near source systems; mission-relevant information was forwarded selectively for theater-level correlation. Approved in-band paths and isolated out-of-band monitoring paths coexisted, with one-way data diodes moving telemetry from sensitive mission systems into analysis environments without a reciprocal path back. Tagged information objects carried mission, user, device, identity, trust, and organizational context for attribution, routing, filtering, and access decisions. C2IM organized awareness as perception, comprehension, and projection: what is happening, what it means for missions, and what is likely next.

06Validation

  • Accreditation-aware engineering. System boundaries, data flows, identity and access, audit logging, security domains, configuration baselines, change control, and test evidence were produced with NIST SP 800-53-aligned inputs under the Interim Authority to Test.
  • Separated environments. Test, production, and disaster-recovery functions were distinct; every change moved through develop, test, evaluate, approve, and promote, supporting repeatability, rollback, stability, recovery, and auditable evidence.
  • Traceable integration. Each source carried a verified relationship through security boundary, processing location, analytical purpose, authorized user, and mission decision.
  • Operational sequence. The Cyber-Defense Playbook fixed the workflow the architecture had to support: event identification, correlation, hypothesis development, mission assessment, escalation, containment, forensic analysis, remediation, lessons learned.
  • Role-based visualization. Administrators needed configuration and health; responders needed timelines, evidence, and containment status; analysts needed adversary context; mission owners needed dependency and degradation; commanders needed capability impact and priority.

data sourcesecurity boundaryprocessing locationanalytical purposeauthorized usermission decision

07Output

  • Reference architecture describing components, interfaces, services, environments, and information exchanges, in logical and physical views.
  • Classified C2IM CONOPS content and co-authored ArcSight CONOPS elements connecting mission, organization, user role, system behavior, information flow, decision, and response.
  • DoDAF definitions representing operational activities, organizations, systems, services, interfaces, exchanges, and mission dependencies.
  • Capability-gap analysis and data-source mapping tied to decisions.
  • Cyber-Defense Playbook sequence and role-specific visualization requirements.

08Result

  • Cyber operators, engineers, program leadership, mission owners, and commanders shared one implementation model.
  • The ArcSight-centered pilot entered operations at the Enterprise Operations Center–Pacific as the architecture moved from reference design into an operational environment.
  • Federation preserved local ownership, controlled exposure, and wide-area bandwidth while enabling theater-level awareness.
  • The purpose was never better dashboards: it was faster conversion of cyber evidence into mission-relevant decisions.

09Tradeoffs and limitations

  • Federation versus completeness. Selective forwarding means the theater view is deliberately incomplete; the design accepts that in exchange for ownership, bandwidth, and exposure control.
  • Normalization loses detail. A common schema flattens vendor-specific fields; forensic reconstruction depends on local retention of the original event.
  • Content maintenance. Correlation rules, active lists, and the asset-to-mission dependency model require curated upkeep; the model is only as current as its last update.
  • Boundaries limit aggregation. Some information cannot cross environments at all, so mission mapping must work with partial views.
  • Public presentation. Enclave names, configurations, and network details are generalized here; the architectural patterns are the transferable content.

10What this demonstrates

  • Systems architecture
  • Data integration
  • Security-aware design
  • Decision support
  • Technical documentation