N181-089
|
TITLE: Multi-Domain Data
Management (MDDM)
|
TECHNOLOGY AREA(S):
Information Systems
ACQUISITION PROGRAM: PEO C4I,
PMW 120, Distributed Common Ground Station � Navy Increment 2 (DCGS-N Inc 2)
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 DUAL USE
APPLICATIONS: 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.
REFERENCES:
1. Kulkarn, A. �Security
Model: Bell-lapadula model.� Tata Consultancy Service, 2015. https://securitycommunity.tcs.com/infosecsoapbox/articles/2016/02/25/security-model-bell-lapadula-model
2. Zheng, Yu. �Methods for
Cross-Domain Data Fusion: An Overview.� IEEE Transactions on Big Data,
TBD-2015-05-0037, pp 1-18,� https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwiLhL6__NnVAhXJ8YMKHccIA3wQFggmMAA&url=https%3A%2F%2Fai2-s2-pdfs.s3.amazonaws.com%2Ffe9d%2F375dd02a8504b7c5c011e3696e6e6f63f537.pdf&usg=AFQjCNGquUei392zVcqklMn9E5QMIVwMPQ
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, https://books.google.com/books?id=S_2qCAAAQBAJ&pg=PA43&lpg=PA43&dq=A+Self-adaptive+Cross-Domain+Query
+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. http://www.ijcset.com/docs/IJCSET13-04-06-121.pdf
5. Bkakriax, A., Cuppens, F.,
and Cuppens-Boulahia, N. �Preserving Multi relational Outsourced Databases
Confidentiality using Fragmentation and Encryption.� pp. 39-62. http://isyou.info/jowua/papers/jowua-v4n2-3.pdf
6. McSherry, F. �Privacy
Integrated Queries.� SIGMOD�09, June 29�July 2, 2009, Providence, Rhode Island,
USA. https://people.eecs.berkeley.edu/~raluca/cs261-f15/readings/sigmod115-mcsherry.pdf
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. https://www.dni.gov/files/documents/ICD/ICD_503.pdf
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. http://www.dss.mil/documents/CNSSI_No1253.pdf
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. https://csrc.nist.gov/csrc/media/publications/sp/800-53/rev-5/draft/documents/sp800-53r5-draft.pdf
KEYWORDS: Multi-Level
Security; Multi-Domain Cloud Data Services; Data Management; Relational Data Management
System; Multi-Domain Query; Cross-Domain Data Distribution; Data
Confidentiality
** TOPIC NOTICE **
These Navy Topics are part of the overall DoD 2018.1 SBIR BAA. The DoD issued its 2018.1 BAA SBIR pre-release on November 29, 2017, which opens to receive proposals on January 8, 2018, and closes February 7, 2018 at 8:00 PM ET.
Between November 29, 2017 and January 7, 2018 you may talk directly with the Topic Authors (TPOC) to ask technical questions about the topics. During these dates, their contact information is listed above. For reasons of competitive fairness, direct communication between proposers and topic authors is not allowed starting January 8, 2018 when DoD begins accepting proposals for this BAA.
However, until January 24, 2018, proposers may still submit written questions about solicitation topics through the DoD's SBIR/STTR Interactive Topic Information System (SITIS), in which the questioner and respondent remain anonymous and all questions and answers are posted electronically for general viewing until the solicitation closes. All proposers are advised to monitor SITIS during the Open BAA period for questions and answers and other significant information relevant to their SBIR/STTR topics of interest.
Topics Search Engine: Visit the DoD Topic Search Tool at www.defensesbirsttr.mil/topics/ to find topics by keyword across all DoD Components participating in this BAA.
Proposal Submission: All SBIR/STTR Proposals must be submitted electronically through the DoD SBIR/STTR Electronic Submission Website, as described in the Proposal Preparation and Submission of Proposal sections of the program Announcement.
Help: If you have general questions about DoD SBIR program, please contact the DoD SBIR Help Desk at 800-348-0787 or via email at [email protected]
|