You are here

Multi-Domain Data Management (MDDM)



OBJECTIVE: With an expected exponential increase in data sources available to the DCGS-N Inc 2 Analyst, the intent of this SBIR topic is to provide an automated data management component within the Multi-Domain Federated Query (MDFQ) architecture to optimize information aggregation of structured and unstructured/heterogeneous data streams coming from multiple security domains into the highest classification domain (e.g., Top Secret/Sensitive Compartmented Information (TS/SCI)), enabling critical and relevant information queries to be rapidly returned, not only to the DCGS-N Inc 2 Analyst working in the TS/SCI domain, but also to users working in other domains (e.g., Secret General Services (GENSER) and Secret Releasable (REL) security domains, etc.). 

DESCRIPTION: To maintain maritime supremacy, the U.S. Navy must collect, understand, and leverage ever-increasing volumes, variety, variability, velocity, and veracity of sensor and intelligence information to ensure proper force application across greater distances under ever-compressing time constraints. Distributed Common Ground System- Navy (DCGS-N) is the intelligence system principally responsible for providing Navy Commanders that understanding. To this end, DCSG-N must quickly aggregate, correlate, and fuse “All Domain/All Source Intelligence” to produce current and predictive, operational to tactical, battlespace awareness required to make better decisions faster. The Distributed Common Ground System- Navy Increment 2 (DCGS-N Inc 2) Program of Record (PoR) seeks to employ novel data management techniques to optimize data query across multiple heterogeneous data repositories (e.g., Accumulo) provisioned at different security levels. Multi-Domain Data Management (MDDM) must aid the DCGS-N Inc 2 system in facilitating multi-domain analytics, real-time analytic processing and multi-domain information dissemination, post event analyses, and perform multi-domain nodal analysis to support a host of Navy Intelligence mission functions (e.g., building Intelligence Preparation of the Environment (IPOE) products, developing Strike Packages, producing Indications and Warnings, etc.). In addition, MDDM will enable Electromagnetic Maneuver Warfare/Integrated Fires (EMW/IF) capabilities which require unprecedented levels of data integration and interoperability between disparate systems fielded by different Office of the Chief of Naval Operations (OPNAV) Resource Sponsors across Command, Control, Communications, Computers, and Intelligence (C4I) and Combat Systems (CS) networks. Current data management methodologies fail to stage, mark-up, and otherwise provision data for multi-domain analytics and subsequent rapid information product dissemination across multiple security enclaves. The MDDM capability must be able to rapidly warehouse an ever-increasing volume, variety, variability, velocity, and veracity of ingested data to allow for analysis and subsequent distribution required of the DCGS-N Inc 2 PoR, this SBIR topic seeks to advance current state-of-the-art data management methodologies to enable this capability. MDDM seeks to solve the ongoing problem of designing architectures for EMW/IF that avoid the enduring costs required to maintain a similar capability enabled by an ensemble of Cross Domain Solutions (CDS). This approach was initiated and guided by the Joint Worldwide Intelligence Communications System (JWICS) accrediting authority (Navy Intelligence Information Assurance (NAVINTEL IA)) as a valid, potentially more cost-effective approach to rapid Multi-Domain Information sharing from the JWICS network to Secret Internet Protocol Router (SIPRNET). While not alleviating the need for network CDS’s, this would allow users to access releasable information in JWICS via a more expedient, cost-effective means Optimally, MDDM will leverage Commercial-off-the-Shelf (COTS) and Government-off-the-Shelf (GOTS) tools and services (e.g., large data storage hardware and analytics processes employed in DCGS-N Inc 2 PoR, such as data engines like Hadoop and MongoDB, queue/topic managers like Kafka, and display tools like CJMTK), as required in developing the database design and ultimate implementation. MDDM data provisioning will enable the automated combining of high volumes of data from differing intelligence communities, National Technical Means (NTM) systems, and multi-domain network feeds to aid DCGS-N Inc 2 in building a more coherent view of the battlespace, while simultaneously staging multi-domain data queries originating from security enclaves below the TS/SCI level (e.g., SECRET GENSER). MDDM must be able to handle multiple data sources arriving simultaneously to differing nodes (ashore and afloat) and accommodate varying volumes, velocities, varieties, to include data bursts/blooms. The capacity to develop and maintain data Object Identification (OID) and Global Unit Identification (GUID) tagging for the MDFQ Relational Data Manager System (RDMS), in order to optimize data analysis and distribution of new and evolving data sources and formats, will be critical to this effort. It must be able to process data use by DCGS-N Inc 2 multi-domain analytics and or other key system functions. The higher security levels’ ingest and analytic functions must have access to all data ingested at lower security levels. Relationships, correlations, and updates need to be consistent—though not necessarily identical—vertically through the environment. Data tagging—not to be confused with security labels—and data normalization must be accomplished through the ingest process in accordance with Extensible Markup Language (XML) Data Encoding Specification for Intelligence Communication (IC)- Enterprise Data Header (EDH) V4 6 Sep 13. This ingest process must send a copy of the original message plus the EDH to be persisted and indexed. Security Domain separation, control, and management must be via a secure type-1 hypervisor with a properly configured Domain 0 to enable Multiple Independent Levels of Security (MILS) control over the hosted virtual machines (VMs). While it would be desirable to have a single physical Multi-Level Security (MLS) data store, the accreditation challenges are effectively show-stopping. Logical separation within a contiguous database would require burdensome, extensive proof. Therefore, data storage for each security domain should be separate with something like the OID/GUID providing any needed high-side linkages. Physical separation is preferred by the accreditors; however, secure VM separation (MDFQ) may be acceptable. The system must implement to basic premises of the Bell-La Padula (BLP) model of computer security—the definition and enforcement of a security classification lattice or matrix. These fundamentals can be summarized as: “Fixed (Trusted) Security Levels”, “Read-Down” and “Write-Across”, and “Downgrade and Release”. It is understood that “Downgrade and Release” is an extremely complex challenge for certification and accreditation. However, it is still a desired capability even in a most basic form. With the eventual goal of full accreditation, the proposal needs to address Navy Risk Management Framework (RMF) security controls for categorization and characterization [Ref 8, 9, 10]: Confidentiality = High, Integrity = High, and Availability = Moderate (Previously PL-4 under the DoD Information Assurance Certification and Accreditation Process). The volume and velocity of data coming into the DCGS-N Inc 2 system varies widely; MDDM must dynamically adjust to the changes in data delivered, with the data provisioning goal not to exceed 30 seconds after ingest to consumer availability. For estimation purposes, ingest data traffic will be measured in “messages” at 10KB per message at DCGS-N Inc 2 specified ingest rates. It is also critical the MDDM mechanism enable rapid retrieval (within 2 seconds) of stored data to meet the demands of operators working in different security enclaves in a tactical environment. MDDM needs to be flexible in handling a combination of streaming, bulk, and standing order data with an importance placed on the expedience of data availability, from data acquisition to consumer availability without system degradation. MDDM must support the ability to cleanse, de-duplicate, and re-ingest data in the event of data ingestion errors. MDDM must also be scalable in a virtualized/cloud environment, capable of managing multiple data sets in parallel, handle inconsistent loads, and have the ability to synchronize, replicate, and federate. Work produced in Phase II may become classified. Note: The prospective contractor(s) must be U.S. owned and operated with no foreign influence as defined by DoD 5220.22-M, National Industrial Security Program Operating Manual, unless acceptable mitigating procedures can and have been implemented and approved by the Defense Security Service (DSS). The selected contractor and/or subcontractor must be able to acquire and maintain a secret level facility and Personnel Security Clearances, in order to perform on advanced phases of this project as set forth by DSS and SPAWAR in order to gain access to classified information pertaining to the national defense of the United States and its allies; this will be an inherent requirement. The selected company will be required to safeguard classified material IAW DoD 5220.22-M during the advanced phases of this contract. 

PHASE I: Working in conjunction with the DCGS-N Inc 2 Government team, generate a feasible novel design or design approach for a MDDM to address automated OID/GUID data tagging for data analytics and distribution in the DCGS-N Inc 2 MDFQ Architecture. The proposed design must be capable of managing and disseminating varying types and formats of multi-domain data in varying volumes, velocities, variability, and veracity, to include multiple data sources (e.g., Navy Message traffic, Electronic Intelligence (ELINT), Communications Intelligence (COMINT), Acoustic Intelligence (ACINT), etc.). The proposed design must account for the Certification and Accreditation (C&A) requirements of the DCGS-N Inc 2 PoR as a primary design constraint, be able to manage and disseminate new multi-domain data types, and address changes in formats/fields of existing data types/feeds. 

PHASE II: Develop, along with the DCGS-N Inc 2 Government team, a cloud-enabled MDDM prototype capability that can demonstrate the following: 1.) Data Management and appropriate OID/GUID tagging of multi-domain data ingested via the DCGS-N Inc 2 system, and 2.) Data distribution of multi-domain information products to users operating at different security levels via the DCGS-N Inc 2 MDFQ architecture. Produce a prototype data management virtual machine for employment within the DCGS-N MDFQ architecture, while also meeting the C&A requirements of the DCGS-N Inc 2 PoR. It is probable that the work under this effort will be classified under Phase II (see Description section for details). 

PHASE III: Continue Phase II efforts to complete necessary engineering, system integration, packaging, and testing to field the capability into the DCGS-N Inc 2 PoR. Make the design construct available to other Navy Program Offices and Programs of Record, and commercialize the capability for technology transition to the wider defense and intelligence communities, as well as the broader commercial Cyber Security and Business Intelligence (BI) sectors. 


1: Kulkarn, A. "Security Model: Bell-lapadula model." Tata Consultancy Service, 2015.

2:  Zheng, Yu. "Methods for Cross-Domain Data Fusion: An Overview." IEEE Transactions on Big Data, TBD-2015-05-0037, pp 1-18,

3:  Li, Y., Shen, D., Nie, T., Yu, G., Shan, J., and Yue, K. "A Self adaptive Cross Domain Query Approach on the Deep Web." Lecture Notes in Computer Science book series (LNCS, volume 6897) (2011), pp. 43-55, +Approach&source=bl&ots=3N5S0DP08o&sig=4Rk9FniejwC2b0gpHvFznDauVhc&hl=en&sa=X&ved=0ahUKEwigvIj59oHVAhUL5mMKHZjGAMYQ6 AEIKjAB#v=onepage&q=A%20Self-adaptive%20Cross-Domain%20Query%20Approach&f=false

4:  Agrawal, H., Karandikar, A. "Study of Multidomain Query Optimization and Answering." International Journal of Computer Science & Engineering Technology (IJCSET), Vol. 4 No.06 Jun 2013, pp. 794-708.

5:  Bkakriax, A., Cuppens, F., and Cuppens-Boulahia, N. "Preserving Multi relational Outsourced Databases Confidentiality using Fragmentation and Encryption." pp. 39-62.

6:  McSherry, F. "Privacy Integrated Queries." SIGMOD’09, June 29–July 2, 2009, Providence, Rhode Island, USA.

7:  eXtensible Markup Language (XML) Data Encoding Specification for Intelligence Communication (IC)- Enterprise Data Header (EDH) V4 6 Sep 13.

8:  Director of National Intelligence. "Intelligence Community Directive Number 503." Intelligence Community Information Technology Systems Security Risk Management, Certification and Accreditation. September 15, 2008.

9:  Committee on National Security Systems (CNSS). "CNSS Instruction No. 1253, Security Categorization and Control Selection for National Security Systems." National Security Agency, March 27, 2014.

10:  National Institute of Standards and Technology (NIST). "Draft NIST Special Publication 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations." U.S. Department of Commerce, August 2017.

11:  Multi-Domain Federated Query (MDFQ) Architecture and individual databases in the supporting Multi-Level Security (MLS) Hypervisor (uploaded to SITIS 11/29/2017)

KEYWORDS: Multi-Level Security; Multi-Domain Cloud Data Services; Data Management; Relational Data Management System; Multi-Domain Query; Cross-Domain Data Distribution; Data Confidentiality 


Jon Brewster 

(619) 221-7703 

Derrick Davis 

(619) 524-5942 

Joaquin Martinez de Pinillos 

(843) 424-6040 

US Flag An Official Website of the United States Government