TACTICAL CROSS-DOMAIN SOLUTIONS: CURRENT STATUS AND THE NEED FOR CHANGE
Kevin Plyler
General Dynamics C4 Systems
kevin.plyler@gdc4s.com
Brian C. Tague
NGC-TASC
brian.tague@ngc.com
Dr. Roshan Thomas
Cobham Analytic Services
roshan.thomas@cobham.com
ABSTRACT l
The rapid migration of system high 2 information sharing
to the tactical edge has made it imperative that the DoD
reexamine tactical Cross Domain Solutions/Enterprise
Services (CDS/ES) 3. Prior to Operation Iraqi Freedom
(OIF), information sharing requirements at the tactical
edge were relatively few in number and nominal in terms
of data throughput, data types, and users. Cross Domain
Solutions (CDS)4 deployed back then were specialized,
hardened, and resistant to hacking in the event of enemy
overrun. Since OIF, both the volume ofbattle field system
high tactical networks 5 as well as the operational
requirements to support each of these networks (i.e.,
increased data throughput, data types and variety ofusers)
have significantly increased [On Point]. When combined
with additional constraints inherent to the battle space
such as low latency, Size, Weight and Power (SWaP), the
current approach to addressing information sharing
requirements in a tactical network breaks down. Taking
the traditional, point-to-point approach by making a CDS
smaller and more robust in the tactical environment may
be adequate in the near term. However, this approach will
not support the requirements levied upon next generation
warfighting systems. In the future, interdependent tactical
Prepared through collaborative participation in the
Communications and Networks Consortium sponsored by the U.
S. Army Research Laboratory under the Collaborative
Technology Alliance Program, Cooperative Agreement
DAAD19-01-2-0011. The U. S. Government is authorized to
reproduce and distribute reprints for Government purposes
notwithstanding any copyright notation thereon.
2 The highest classification level of the data on an Information
Sharing system.
3 Term referring to either a point-to-point Cross Domain
Solution (CDS) or Cross Domain Enterprise Service (CDES).
Each of these is further defmed in the paper.
4 A form of controlled interface that provides the ability to
manually and/or automatically access and/or transfer
information between different security domains.
5 Tactical Networks: Mobile ad hoc networks that can operate
with full mobility, self-configuration, robustness, survivability,
and scalability.
978-1-4244-5239-2/09/$26.00 ©2009 IEEE
Dr. Simon Tsang
Telcordia
stsang@telcordia.com
networks will be required to exhibit a dynamic (self
organizing) nature, supporting adaptability and quick
response to data ingress and egress. Nodes on these
future networks will also need to operate with severely
limited bandwidth and other operational and/or
environment constraints. Therefore it is necessary to
examine current and future information sharing
requirements at the tactical edge from both the CDS/ES
developer as well as user perspective. This position paper
will discuss both perspectives in order to allow a better
understanding ofthe current CD problem space, as well as
gain insight into building the next generation CDS/ES.
1
INTRODUCTION
In the accelerated pace of combat operations since
Operation Iraqi Freedom (OIF), the ability to securely
move data between system high networks via CDS/ES has
been outstripped by the deployment of tactical networks to
the battle space. During the period leading up to OIF,
system high information sharing systems deployed at the
tactical edge were relatively limited in terms of data
throughput, fixed data types, number of users, and
information assurance risk exposure. CDS/ES consisted of
installing and supporting a finite number of guards" that
were specialized, hardened, and resistant to information
assurance threats. The fundamental security risk was
enemy overrun.
Since OIF, deployments of system high tactical networks
in the battle space have proliferated along with the
digitization' of information by the armed services [On
Point]. Current security requirements (Le., JDISS 8 ) call
Guard: A device or collection of devices that mediate
controlled transfers of information across security boundaries
(e.g., between Security Domain "A" and Security Domain "B")
7 Digitization initiatives include Army's Force XXI, the Air
Force's Effects-Based Operations, the Navy's Cooperative
Engagement, and Marine Corps Sea Dragon.
8 Joint Deployable Intelligence Support System (JDISS) one of
several sources of security requirements related to deployable
systems provides a family of hardware and software capabilities
6
Page 1 of7
Authorized licensed use limited to: Defence Science and Technology Group (DSTG). Downloaded on January 25,2023 at 00:00:24 UTC from IEEE Xplore. Restrictions apply.
for advancing deployment of CDS/ES from operation
centers to become integrated into vehicle based, hand held,
and other portable devices [On Point].
However,
developing CDS/ES to support these requirements at the
tactical level (see figure 1) is a difficult problem without a
near term solution.
Existing Tactical CDS
V.
- Fixed data formats
- Simple filters/hardwired
- Centralized security controls
- Non configurable
Evolving Tactical CDS
- Evolving data formats
- Complex software filters
- Few admin rules
- Reduced administrative access
- Complex admin rules
- Broad administrative access
Figure 1-1
Computing)
Changing
Requirements
CROSS-DOMAIN SOLUTIONS (CDS) SOME
DEFINITIONS
Multiple Security Levels (MSL) - An architecture where
system high networks exchange information via a
controlled mediating device (e.g., CDS) [MITRE].
Multi-Level Security (MLS) - Concept of processing
information with different classifications and categories
that simultaneously permits access by users with different
security clearances and denies access to users who lack
authorization [MITRE].
- Distributed security controls
- Configurable
CDS/ES
2
(Owl
In addition to the risk of enemy overrun, tactical networks
also pose additional key security risks with regard to:
o Increases in data throughput via multiple networks
o Evolving and more complex data formats
o Number and variety of users
o Multiple opportunities for malicious data
injection/attack.
The current approach to addressing CDS/ES for
information sharing requirements for networks in a nontactical environment breaks down when applied to the
tactical environment. The low latency, Size Weight and
Power (SWaP) constraints inherent to tactical networks,
combined with risk of enemy overrun, further exacerbate
the already complex and intricate security challenges
posed by these new requirements.
It may be feasible to continue to make CDS/ES smaller
and more robust in the near term to support the full set of
information sharing requirements in a tactical
environment. However it would be prohibitively difficult,
risky and expensive to deploy and operate thousands of
such CDS/ES to support next generation warfighting
systems in the long term.
In order to share information in a robust and secure fashion
at the tactical edge in the near term, CDS/ES
configurations must resolve risks under declining SWaP
constraints. In order to achieve this, next generation
information sharing systems must deliver some type of CD
Enterprise Service (CDES) scalable to tactical networks.
that allow connectivity and interoperability with intelligence
systems supporting forces, in garrison, and deployed.
Multilevel Security
(MLS)
vs
Figure 2-1 MLS V. MSL
(MITRE)
Mandatory Access Control/Discretionary Access
Control (MACIDAC) - MAC: Means of restricting
access to objects based on the sensitivity of the
information contained in the objects and the formal
authorization (i.e., clearance, formal access approvals, and
need-to-know) of subjects to access information of such
sensitivity. MAC is commonly used in MLS to prevent
subjects from circumventing data flow policy.
DAC: Means of restricting access to objects based on the
identity and need-to-know of users and/or groups to which
the object belongs. Controls are discretionary in the sense
that a subject with certain access permission is capable of
passing that permission (directly or indirectly) to any other
subject.
Cross Domain Access (CDA)
These provide
simultaneous visual access to multiple security domains
via a single workstation (i.e., client/workstations) [CD
Inventory].
Cross Domain Transfer (CDT) - These interconnect
networks of information systems that operate in different
security domains, and mediate transfer of information
between them [CD Inventory]. Information is 'transferred'
Page 2 of7
Authorized licensed use limited to: Defence Science and Technology Group (DSTG). Downloaded on January 25,2023 at 00:00:24 UTC from IEEE Xplore. Restrictions apply.
across domains via accredited transfer devices (Le.,
"guards"),
Cross Domain Multi-level Environment (CDM) - These
are used to store data in multiple security domains at
varied security levels and allow users to access the data at
an appropriate security level [CD Inventory]. CDMs
enable access based upon authorization to data from a
managed label-aware environment (Le., "servers").
Communities of Interest (COl) - As U.S. joint
operations are leveraged, and international cooperation
continues to advance, communities of interest continue to
form. These communities need to share information in a
well controlled fashion while maintaining protection of
other information. Examples of these communities are
JWICs,
TS/SCI,
SIPRNet, NIPRNet,
TacticalUnclassified, Coalition, NATO, and other ad-hoc
relationships. Compounding this problem is that each
enclave" to enclave interconnect requires a unique cross
domain solution. The result in some cases can be a mesh of
networks with a CDS/ES at each point of intersection. As
CDS/ES needs move to the battlefield, the number of
instances of each of these CDSIES networks expands as
well (Le., ship networks, space nets, ground vehicle
groups, operation centers, etc) [CJCSI]. If COIs overlap
(Le., users are members of multiple COIs), this further
complicates the task of CDSIES that are managing
information flows as even simple information sharing
policies can become difficult to evaluate effectively, and
policy enforcement may need to be applied at even greater
granularity - to the per user/node level[IAMANET].
3
CROSS-DOMAIN SOLUTIONS/ENTERPRISE
SERVICES (CDS/ES) - STRATEGIC ISSUES
3.1
CDS/ES ARE EXPENSIVE
While there is no question that CDS/ES is required for the
tactical edge, CDSIES is expensive in terms of both
development and deployment costs.
Development & Production Costs: Current CDS/ES are
custom solutions with limited ability to architect solutions
by leveraging common off-the-shelf components.
Consequently, such solutions are expensive and slow to
develop. Reasons for this include the following:
An enclave is a collection of computing environments
connected by one or more internal networks under the control of
a single authority and security policy, including personnel and
physical security - NSTISSI-4009
9
•
•
•
•
There is currently a lack of standards for CDSIES, in
particular CDSIES architecture and interfaces. This
leads to custom solutions that are monolithic or stovepiped solutions that can lead to integration issues.
The CDS/ES certification process is cumbersome and
slow, increasing overall development costs and leading
to production delays.
Current solutions must be deployed with pre-defined
and certified CDSIES security policies, delaying
overall production.
There is a lack of standards for CDS/ES policy
languages, so policies are custom-developed for
particular platforms, and policies developed for one
platform are incompatible with other platforms or
solutions. This lack of policy re-use leads to increased
costs for policy definition and verification. General
adoption of existing policy standards such as the IETF
Policy Core Information Model [PC1M] will improve
the current situation. However, further research is
needed to develop policy languages that are tailored
for cross-domain security policies [CDL 08].
Deployment Costs: Due to their specialized nature,
current CDS/ES incur high deployment costs. These costs
must be considered and weighed against other deployment
costs. Reasons for high CDS/ES deployment cost include
the following.
• The current generation of CDSIES requires specialized
hardware (primarily to meet assurance requirements)
that is several times more expensive than general
purpose computing solutions.
• CDS/ES that require special hardware are harder to
deploy, manage and maintain.
• CDSIES is a "special solution" that does not interact
easily with common windowing platforms and
applications, leading to a lack of integration,
administration, and usability.
• CDSIES may require modification of existing fielded
software or software configurations so that they can be
used with the CDSIES.
• CDS/ES maintenance requirements are typically more
stringent that general computing and single level
computing systems. This leads to longer maintenance
cycles and additional maintenance costs.
3.2
SECURITY AND ROBUSTNESS IN A
TACTICAL ENVIRONMENT
As difficult or daunting the notion of developing solid,
robust CDS/ES to share information, more recent
examples only serve to highlight the problem. These
include the misuse of removable media (e.g., thumb
Page 3 of7
Authorized licensed use limited to: Defence Science and Technology Group (DSTG). Downloaded on January 25,2023 at 00:00:24 UTC from IEEE Xplore. Restrictions apply.
drives), and cross connecting cabling which presents
serious security concerns and introduces instability to the
attached networks as the connections are added and
removed.
The scale and scope at which information sharing needs to
be accomplished today cannot be sustained by manual
(i.e., "sneaker net") methods. When manual methods of
information sharing are used in place of electronic
methods, oftentimes many critical procedures are
bypassed, knowingly or unknowingly, introducing
significant, often incalculable risk to the overall mission.
This is exacerbated even more in wartime [MITRE].
In the past, cross domain transfers were made using 'air
gap' separation between information systems with
inexpensive media (e.g., tape, disks, flash drives), and
human review as the popular solution. This approach is
fraught with opportunities for failure and inconsistent
results [MITRE]. The more modern approach has been for
information systems to perform automated procedures for
mediating upgrades and downgrades of data. These
systems mitigated inadvertent disclosure of information
and data poisoning issues. The method used is strict
adherence to fixed format and known vocabulary data
restrictions. These automated transfers are augmented by
human review for more complex and subjective data forms
(e.g., video, imagery, etc... ).
controls designed into the CDSIES system solution to be
appropriately mitigated.
In addition, a tactical environment typically also has
additional constraints on a CDS/ES. A CDS/ES may be in,
or near the weapons fuse chain or between a sensor and
warfighter, demanding a higher degree of real-time
determinism than in an enterprise setting.
While there will always be a dynamic dissonance between
what is required versus what is available to meet ongoing
operational requirements, CDSIES pose particular
difficulties for the warfighter who relies heavily upon
secure, timely and available information from tactical
networks. Several causes for this lag include:
• The level of complexity involved with developing a
'trusted product' that supports the warfighter with both
rapidly evolving capabilities as well as a high level of
assurance [MITRE].
• The relatively few 'trusted products' that are currently
available to meet these evolving warfighter
requirements [MITRE].
• The lack of commercial incentives and infrastructure
to balance the desire to share with the need to protect
the information that is shared [MITRE].
3.3
WARFIGHTER NEEDS
The common and traditional location of a CDSIES is in an
enterprise setting. Weapon system laboratories, research
facilities, joint operations centers, regional operations
offices, and academic facilities are examples of these
environments. These locations are physically secure, but
are none-the-Iess still at risk from information disclosure
by authorized and unauthorized personnel either
intentionally or inadvertently. Mis-configuration, traffic
analysis, malicious code, inappropriate use and inherent
information systems vulnerabilities are all risks that must
be factored into the use of all CDSIES.
Coping with high stress and cognitive load. The
warfighter is typically in a high stress environment dealing
with very difficult and rapidly evolving task orders. This
may involve multitasking and imposes high cognitive load.
Accordingly, the environment has to provide multiple
modalities in terms of input and output devices. He may
thus be interacting with the CDS/ES wearing
environmental gloves, helmet-mounted displays all while
bouncing in a moving vehicle and dealing with the
constraints of a recent affliction or impairment. The war
fighter may commonly be in a hurry due to the timely need
of such data.
Tactical environments present additional concerns to the
application of a CDSIES. In a tactical setting, a CDSIES is
more likely to be exposed to the physical rigors of the
environment. Increased risks of access by unauthorized
personnel and a realistic possibility of overrun by an
adversary are genuine concerns. A tactical environment
also exposes the attached networks and infrastructure to
attack. There is also a legitimate risk that these assets, both
hardware and software (e.g., security and flow policy)
could be subverted in the field, or even removed and taken
back to an adversary's lab for further and detailed
exploitation. All of these concerns need to have proper
Intuitive and safe user interface design. CDS/ES need to
accommodate the dynamics of the above conditions and
provide a human level interface that meets several criteria.
The interface needs to be clear and certain and reduce the
overall cognitive load. User interface management systems
that factor in psycho-physiological input may be
applicable here. Such a system could monitor stress level,
heart rate, error rate, etc, and adapt the data presentation,
data input, data output, and menu navigation techniques. A
war fighter performing human review needs to clearly see
what data is being re-graded, what the source and
Page 4 of7
Authorized licensed use limited to: Defence Science and Technology Group (DSTG). Downloaded on January 25,2023 at 00:00:24 UTC from IEEE Xplore. Restrictions apply.
destinations are, and any analysis the CDS/ES has
performed (e.g., dirty word identification), with a simple
and clear indication stating that the re-grade request is
approved/disapproved.
Enhance data security and reduce the risks of data
leakage. The computing and user interface environment
must enhance data safety and reduce risks of accidental or
malicious leakage. Data and indicator markings need to be
large and obvious so that decisions are made intentionally
and the results are well understood. The design challenge
here is to provide the correct tradeoffs between ease of use
and data security. Lastly, the data must remain safe. For
example, ease of use may be enhanced by oversimplifying
the interface to provide cut/copy/paste type features
between domains. However such an action should not
compromise the sender and recipient security policies and
should not bypass security controls. Too many steps in a
"render useless" procedure will contribute to a potential
compromise of valuable information. All of these
determinants should be considered in the data security and
human factors analysis in the development of the CDS/ES.
4
ASSESSMENT OF TECHNICAL CHALLENGES
We now identify some of the key technical challenges that
must be addressed in deigning and deploying the next
generation of cross-domain solutions.
Real-time processing. Delays in the sanitization and
approval processes today impact mission effectiveness.
Thus classical batch-oriented processing modes where
information release request are queued up and sent in
batches are severely limiting. What is needed are
technologies and processes for the real-time processing of
information release requests so as to increase their
efficiency and timeliness. This involves eliminating
multiple processing steps in the workflow where potential
bottlenecks can appear.
Automated risk-aware processing. Related to the above,
is the need to increase the degree of automation in
information analysis and release. Ideally, the system
should be tuned so that time-consuming (but highly
assured) human review etc, can be adjusted based on prespecified tradeoffs between efficiency and the risk of
accidental leakage (from false negatives). So what is
needed is a risk-aware information processing model
which based on content sensitivity, environmental threat
posture and recipient risk, will balance the degree of
automation vs. human review so as to increase efficiency
of workflows.
Support for dynamic and efficient policy updates. We
need to increase the flexibility, speed and efficiency with
which policy changes can be incorporated and certified
within CD devices. This requires (1) the ability to rapidly
update policy rules without necessarily going back to the
device manufacturer or vendor and (2) to get such rules
validated and certified without laborious manual review.
Higher-level
and
more
interoperable
policy
specification and analysis. Policy specification is still
relatively low-level, cumbersome and requires knowledge
of vendor-specific filter specification languages etc. So
there is a crucial need to raise the level of abstraction for
policy specification so as to enable vendor-neutral and
interoperable specification of cross-domain policies. This
will also be a catalyst for the creation of automated policy
analysis and validation tools and for more efficient
certification
approaches.
Initial
approaches
to
standardizing and making policy specification have been
pursued from a bottom up [BRAY] as well as top-down
[CDL 09] direction. However, further work needs to be
done to integrate such approaches.
Need to support complex (compound) data types. The
goal here is to support complex data types such as
compound documents so that the process of sanitization
does not break the original data model. Traditionally many
cross-domain devices such as guards and filters have
assumed a simple flat data model consisting of simple
messages. This has to evolve so that XML schemas and
other tagged data representations and metadata can be
supported. Individual elements in a complex structure need
to be sanitized and regraded and access controlled at the
recipient end.
Need to improve traceability and accountability. The
ability to provide post-release traceability and
accountability to the sender of previously released
information will go a long way in providing the flexibility
and control some organizations desire, but cannot obtain
from current technology. Also important is for the sender
to have the ability to control the redissemination of the
released information as well as revoke previously released
information.
Distributed and federated processing with miniaturized
devices. Cross domain devices today are largely
centralized devices placed at central egress and ingress
points in the network topology of individual organizations.
On the tactical edge, a more distributed and lightweight
cross-domain device architecture may be more appropriate
so as to provide the necessary flexibility and agility.
Individual devices carried by the warfighter may have to
Page 5 of7
Authorized licensed use limited to: Defence Science and Technology Group (DSTG). Downloaded on January 25,2023 at 00:00:24 UTC from IEEE Xplore. Restrictions apply.
analyze and sanitize information. This brings to the
forefront the challenges related to management and
coordination of such devices.
Remote management. Inherent to any distributed
architecture is the need for remote management. Thus the
technical challenge here is to design the remote
management protocols and the necessary management
plane that can be rapidly deployed over a mixture of wired
and wireless networks in the battlefield. Remote
management may include routine administrative functions
such as security administration and patch updates, but also
include the push of policy updates to devices and semiautomated recertification of such devices.
Multi-party and third-party release and dissemination
scenarios. The challenge here is to go beyond point-topoint cross-domain information release scenarios and
support situations where there are varying and
asymmetrical trust relationships between the various
parties. This will be common place as coalition partners
increasingly share information in real time. For example,
A may release to B but B may not release that information
to C without further sanitizations etc.
A traditional cross domain solution providing services is
depicted in Figure 4-1.
Single Domain
.
,
-,
We also need to explore the use of the Service Oriented
Architecture (SOA) framework. The use of SOA for policy
distribution,
providing centralized DoD policy
management could be leveraged. This approach has the
advantages of avoiding some of the issues of proper
protection of data flow policy when the system is off or
being transported. Methods of caching and distribution
could also be investigated. There are many applications
today where a warfighter and associated equipment at an
unclassified level have data that need to be processed by
classified algorithms. SOA or CORBA type interfaces
could be used to provide the ability to upgrade the data,
have it processed, and then down graded for use in the
unclassified environment. This would provide valuable
classified processing without exposing the classified
algorithms to the unclassified environment.
Standard architecture and interfaces for CDSIES would
facilitate CDS/ES development and interaction. The
SELinux initiative has proven to be a good starting point
for providing a foundational architecture through a set of
Linux Security Modules that enforce MAC and security
policy enforcement that can be readily leveraged to
develop CDSIES. More work still needs to be done to set
standards for CDSIES interfaces. Interface standards
including mutual authentication and service discovery
need to be established.
A standard policy language with a method of rich
constraint expression should be established. This would
provide the benefits of policy development to be
conducted independent of CDSIES system development
and would permit a more DoD centric management of
CDS/ES policy [PCIM, CDL 08].
Figure 4-1 Existing CDS deployments
5
tactical networks, we cannot effectively fight. As our
information systems provide increased reach back to
intelligence and information, we in tum extend and expand
the attack surface to the battlefield as well. As
communications architectures evolve to support the
warfighter, the number of avenues of refinement for
CDS/ES evolution will naturally precipitate out.
CONCLUSIONS
Information systems used to process information and
automate tasks have evolved from standalone computers
the size of a building to networked, mobile, even to
wearable devices at the tactical edge. In order to ensure
the
confidentiality,
integrity,
availability,
and
nonreputability of this information for the warfighter at the
tactical edge, CDSIES must evolve as well. The need for
information assurance is no more important than on the
battlefield. As reliance upon information increases, so
does need for automation. Without secure and available
Continued work on standardizing data flows including the
integration of newer DoD message formats would benefit
producers and consumers of information that need to be
transferred between domains. Joint Variable Message
Format (JVMF) has been used in the past, and would be a
good starting point. To support a common understanding
of military command and control data the Multilateral
Interoperability Program (MIP) has defined a data model
to allow consistent sharing of command control and
situational awareness data. This data model is called the
Page 60f7
Authorized licensed use limited to: Defence Science and Technology Group (DSTG). Downloaded on January 25,2023 at 00:00:24 UTC from IEEE Xplore. Restrictions apply.
Joint Consultation, Command and Control Information
Exchange Data Model (JC3IEDM). The development of a
XML based encapsulation of NMF and JC3IEDM has
introduced significant improvement in facilitating and
standardizing message transfer between domains
[JC3IEDM].
CDS/ES standards for more real-time determinism (as
much as can be afforded given CDSIES constraints) across
the CDSIES. Standard network features as Resource
Reservation Protocol (RSVP) or Quality of Service
extensions in the policy and data languages as well as
CDS/ES architecture should be explored .
Lastly, current DoD infrastructure is plagued with single
point failures, inefficiencies, and a lack of scalability
methods for CDSIES. Methods to combat these issues
should be researched. CDSIES brokerage , a CDSIES
specific extension to routing protocols, and other network
approaches should be examined. Recent advances in
virtualization technology could also provide some relief to
CDSIES in the areas of deployment, scalability, SWaP,
mobility, and reliability . The emerging direction for
tactical CDS is shown in Figure 5-1.
..,.
"
__
Multiple
_Domains
~_
,.
.<-~
advances in the ability to deal with complex data and lastly
improved user interfaces to enable the war fighter to make
timely, safe and secure decisions.
REFERENCES
[BRAY] Boyd Fletcher, Bray: A Configuration and
Validation Tool for DFCFs, CDS Technical Forum June
2009
[CJCSI] CJCSI 6211.02C Defense Information System
Network (DISN): Policy and Responsibilities
[CDL 09] Roshan K. Thomas, Giovanni Russello , Simon
Tsang, Realizing the CDL Cross-Domain Language in the
Ponder2 Policy Framework: Experiences and Research
Directions, IEEE Policies for Distributed Systems and
Networks 2009, July 2009
[CDL 08] Roshan K. Thomas and Simon Tsang, CDL: A
Language for Specifying High-level Cross-Domain
Security Policies, MILCOM, 2008
[IAMANET] D. Scott Alexander, Brian DeCleene , Jason
Rogers, Pete Sholander, Requirements and architectures
for Intrinsically Assurable Mobile Ad hoc Networks
MILCOM 2008, November 2008
y~
[JC3IEDM] Joint Consultation, Command and Control
Information Exchange Data Model 3.1, December 2006
[On Point] Gregory Fontenot, E.J. Degen, David Tohn,
Operation IRAQI FREEDOM Study Group, The United
States Army in Operation IRAQI FREEDOM, 2004
[MITRE] Elaine Caddick, Nancy Reed, Cross Domain
Solutions : An Overview of Technology, Policy and
Process , October 2005
[Owl] Owl Computing Cross-Domain Forum, Dr. Ron
Mraz, Owl President & CTO, April 15, 2009
Man agemenUReview
[PC1M] Policy Core
Engineering
Task
Figure 5-1 Emerging CDS/ES solutions of the future
Information
Force,
Model,
RFC
Internet
3060,
http://www.ietf.org/rfc/rfc3060.txt
This paper will hopefully serve as a starting point to
explore new directions for the next generation of CDSIES
solutions. These new directions will have to tackle issues
ranging from higher-level and more interoperable policy
specifications, more efficient policy updates and
management, real-time processing, scalability and faulttolerance improvements through distributed processing,
miniaturization of cross-domain platforms and devices,
[CD Inventory] Unified Cross Domain Management
Office, Cross Domain Inventory ver 3.0, May 2009
[Sim] R. Simmons, XML Schema Guidance for Cross
Domain
Security
Policy
Enforcement,
MP
04W0000204, September 2004
Page 7 of7
Authorized licensed use limited to: Defence Science and Technology Group (DSTG). Downloaded on January 25,2023 at 00:00:24 UTC from IEEE Xplore. Restrictions apply.