Zero Trust security is being adopted across companies and government organizations to continually verify cybersecurity requirements. This paper investigates architecture development methodologies that can develop a Zero Trust architecture that implements the missions of an enterprise. An enterprise architecture depends on an organization’s strategic priorities and should reflect the organization’s critical decisions. These decisions can be evaluated according to criteria such as interoperability, speed of operations tempo, and cyber-resilience to failures. Zero-Trust architectures must define alternatives tailored to missions. An enterprise architecture can then be developed that describes the context, operations, and resources associated with a strategic implementation decision. A multi-criteria decision-making method such as the Analytic Hierarchy Process can help guide the development and implementation of Zero Trust strategy. Zero Trust criteria are defined according to quality attributes associated with the DoD Reference Architecture Pillars, and security solutions are evaluated against how well they meet these criteria.
KEYWORDS: Systems engineering, Chemical elements, Systems modeling, Software development, Process modeling, Information technology, Knowledge management, Integration, Computer architecture, Telecommunications
Planning future Multi-Domain Battle (MDB) missions requires extensive, complex, and real-time collaboration and coordination between many Warfighting Functions and Domains such as Electronic Warfare (EW), Positioning, Navigation and Timing (PNT), Network Operations, and Cyber Operations. This collaboration and coordination requires synchronization of the associated domain processes and activities. Large Infrastructure projects for Command and Control (C2) are designed to integrate and align these processes through Information Technology (IT) services, such as decision aids, collaboration tools, and communication tools. New acquisition initiatives are driving infrastructure development to support the rapid fielding of capabilities through a modular software development approach. State-of-the-Art Shared Infrastructure Services can be developed using Agile Software Development (ASD) methods such as Scrum, Kanban, or Extreme Programming. However, the integration of these IT services cannot be easily planned since they are developed at the technology (i.e., software implementation) level according to the selected ASD method. Engineering the Infrastructure as Code (IaC) results in a gap between doctrinal processes and required system functionality since developers quickly code and configure small functional modular units at the technology level, while bypassing the traditional top-down waterfall flow from requirements to design. Furthermore, IaC does not explicitly require consulting a systems architecture. To improve the alignment of configured IT infrastructure services with doctrinal processes, this paper seeks to determine the extent to which agile Development Operations (DevOps) process can implement C2 doctrine while supporting dynamically-changing mission requirements and an operational environment. This paper proposes an automated Systems Engineering workflow to realize IT infrastructure services using Model-Driven Architecture (MDA) and a military DevOps.
KEYWORDS: Internet, Systems modeling, Clouds, Network architectures, Signal processing, Data modeling, Computer architecture, Systems engineering, Process engineering, Standards development
The future Tactical Internet is becoming increasingly virtualized with increasing variation in the type and number of network resources. Capabilities developers offer many choices of technical solutions to implement service requirements. Technology approaches such as software-defined networks, cloud computing and the internet of things enable many different usage scenarios. Network behavior will increasingly be determined through a configuration strategy that determines how resources will be placed in service. As a result, acquisition of and realization of infrastructure to meet demands of network services depends on effective configuration validation solutions. This paper discusses opportunities for applying assurance-driven design to validate the correctness of behavioral requirements for network capability insertion in the Army’s networks.
This paper explores challenges in implementing an end-to-end communications architecture for Condition-Based Maintenance Plus (CBM+) data transmission which aligns with the Army's Network Modernization Strategy. The Army's Network Modernization strategy is based on rolling out network capabilities which connect the smallest unit and Soldier level to enterprise systems. CBM+ is a continuous improvement initiative over the life cycle of a weapon system or equipment to improve the reliability and maintenance effectiveness of Department of Defense (DoD) systems. CBM+ depends on the collection, processing and transport of large volumes of data. An important capability that enables CBM+ is an end-to-end network architecture that enables data to be uploaded from the platform at the tactical level to enterprise data analysis tools. To connect end-to-end maintenance processes in the Army's supply chain, a CBM+ network capability can be developed from available network capabilities.
Future unmanned systems will be integrated into the Global Information Grid (GIG) and support net-centric
data sharing, where information in a domain is exposed to a wide variety of GIG stakeholders that can make
use of the information provided. Adopting a Service-Oriented Architecture (SOA) approach to package reusable
UAV control station functionality into common control services provides a number of benefits including enabling
dynamic plug and play of components depending on changing mission requirements, supporting information
sharing to the enterprise, and integrating information from authoritative sources such as mission planners with
the UAV control stations data model. It also allows the wider enterprise community to use the services provided
by unmanned systems and improve data quality to support more effective decision-making.
We explore current challenges in migrating UAV control systems that manage multiple types of vehicles to
a Service-Oriented Architecture (SOA). Service-oriented analysis involves reviewing legacy systems and determining
which components can be made into a service. Existing UAV control stations provide audio/visual,
navigation, and vehicle health and status information that are useful to C4I systems. However, many were
designed to be closed systems with proprietary software and hardware implementations, message formats, and
specific mission requirements. An architecture analysis can be performed that reviews legacy systems and determines
which components can be made into a service. A phased SOA adoption approach can then be developed
that improves system interoperability.
KEYWORDS: Data modeling, Data integration, Visibility, Web services, Data processing, Databases, Integration, Data conversion, Computer security, Defense and security
An enterprise data strategy outlines an organization's vision and objectives for improved collection and use of data. We
propose generic metrics and quantifiable measures for each of the DoD Net-Centric Data Strategy (NCDS) data goals.
Data strategy metrics can be adapted to the business processes of an enterprise and the needs of stakeholders in
leveraging the organization's data assets to provide for more effective decision making. Generic metrics are applied to a
specific application where logistics supply and transportation data is integrated across multiple functional groups. A
dashboard presents a multidimensional view of the current progress to a state where logistics data shared in a timely and
seamless manner among users, applications, and systems.
There are an increasing number of ways optical network devices and IP routers can interact with each other
during a network fault. To provide continuity of service, the interactions between each component in a network
must be cooperative. Consequently, the effect of recovery processes cooperating are the network configurations
that have certain structural relationships, which can be elaborated. A conflict detector can prove that service
will be restored during a fault scenario by checking whether these structural properties hold.
We are using simulation as a method to study the coordination of recovery strategies and whether different
coordination strategies will achieve recovery goals attached to a network service. The network service carries a
traffic stream, which is injected into and extracted from a network. For multilayer recovery to complete, the
cumulative effect of device actions during a failure must be (1) a connected path between the endpoints of a
service and (2) a flow traffic delivered to a destination at a quality that matches a service level agreement.
We represent Optical and Multiprotocol Label Switching (MPLS) recovery actions as graph-maintenance
operations that change the state of a digraph. For example, the actions of forwarding traffic between an access
port and a trunk port and selecting traffic from a new trunk port and forwarding it to an access port can
be modeled as a sequence of edge additions and deletions. The state of the digraph represents the current
configuration of a multilayer network as actions of recovery are performed. In this paper, we define some
structural properties that can be observed during a simulation as the network evolves to a final state from an
initial state before a failure occurs.
A multilayer network is a complex system composed of many devices which in turn are composed of many subsystems. A failure event changes the configuration of the multilayer network, triggering recovery at more than one layer. Proving that a circuit will work after provisioning operations is an important step to preventing misconfiguration of network devices. We have been working on implementing the consistency checker for one layer. It creates a network representation and adds changes to the network. To verify operation of the system, graphical representation of packets are exchanged between different ports. To understand such a systems, we describe them with a block diagram representing important resources.
Networks add recovery to deliver reliable service between a source and destination. Reliable service is an uninterrupted data transfer between nodes, even if certain links or nodes are faulty. Recovery processes in multilayer networks might operate at the same time when faults propagate between layers during a common-cause failure. We propose an architectural model, that represents point-to-point networks as a grid, where the decisions of recovery can be represented as the replacement of ports. Since a connection is a path through the grid, we can easily determine if multiple connections are repaired. Repairing connections is the goal of multilayer recovery, even if they are repaired at different layers. Since the operations of recovery are the result of preplanned provisioning, a model-checking algorithm could be implemented to check for conflicts in the provisioning. As a first step, this paper decouples the protocols for implementing the actions of recovery from an actual resource-based model. Therefore, no signaling between nodes is treated. Since the provisioning of recovery processes will create decisions of recovery after a catastrophic common-cause failure, we can map the configurations that satisfy goals into provisioning commands sent to recovery processes.
Limited attention has been paid to the interactions of service restoration protocols that operate during a fiber cut to restore connectivity between communications equipment. Historically, restoration protocols were deployed only at the SONET layer in telephony networks. SONET frames that carried voice-grade signals such as a T1 or T3 would be redirected to protection path over architectures that supported bidirectional communication. With the advent of new communication technologies such as ATM, IP and WDM, a cable cut can affect multiple routing processes at each of these layers even if a particular network region only supports a few of these technologies. For example, restoration processes at an arbitrary layer in adjacent networks might trigger if lower-layer protocols don't finish within specific deadlines. With the growth of data traffic and a wide range of service offerings, the telecommunication networks of the future are growing more complex, requiring multiple interactions between software systems. Failures will be difficult to pinpoint and the cooperation of the repair processes will be key to ensure that services traversing multiple networks are not interrupted.
We propose a programmable automatic protection switching (APS) protocol to repair an impaired lightpath traversing an optical link. Recovery agents repair impaired flows by searching through a space of policies before attempting a protection switch and after switching impaired traffic. A policy manager disseminates a changeable set of policies to each agent and ensures consistent interpretation end-to-end QoS. QoS policies are structured to be interpreted in the same way by developing a model of end-to-end QoS over which logic formulae can be checked for satisfaction.
Protection switching interactions in wide-area networks need to interoperate with each other in order to restore a wide variety of services, provide survivability to mission-critical applications and accommodate an evolving network infrastructure. Without some coordination between restoration mechanisms, an outage duration would be lengthened as methods assigned to each layer interfere with each other or the network would be locked up in a deadlocked state that never converges to a new topology. A set of control policies can be specified to coordinate between restoration mechanisms in a network that spans multiple layers and regions. These control policies are expressed as rules, and are collectively denoted as the escalation strategy. The escalation strategy can be provisioned by a network manager and is implemented as a distributed coordination protocol between peer recovery agents in the nodes. As rules for coordinating between restoration mechanisms are formalized, a mathematical proof could be provided to prove that the network does indeed converge to a new topology.
This paper integrates a functional transport and control layer network architecture for MPLS emphasizing Traffic Engineering concepts such as the specification and provisioning of end-to-end QoS service layer agreements. MPLS transport networks are provisioned considering administrator-defined policies on bandwidth allocation, security, and accounting techniques. The MPLS architecture consists of the transport and control layer networks. The transport layer network is concerned with configuration, packet forwarding, signaling, adaptation to higher layers, and support of higher layers. The control layer network is concerned with policy configuration, management, distribution, definitions, schemas, elements, settings, and enforcement.
Access to the requested content is limited to institutions that have purchased or subscribe to SPIE eBooks.
You are receiving this notice because your organization may not have SPIE eBooks access.*
*Shibboleth/Open Athens users─please
sign in
to access your institution's subscriptions.
To obtain this item, you may purchase the complete book in print or electronic format on
SPIE.org.
INSTITUTIONAL Select your institution to access the SPIE Digital Library.
PERSONAL Sign in with your SPIE account to access your personal subscriptions or to use specific features such as save to my library, sign up for alerts, save searches, etc.