This document details the close alignment between AsterionDB and the DoD’s Cybersecurity Reference Architecture available at this link:

https://dodcio.defense.gov/Portals/0/Documents/Library/CS-Ref-Architecture.pdf

1.3 Principles

The following cybersecurity architecture principles are recommended to achieve adequate cybersecurity by mitigating risk to an acceptable level to protect DoD data, assets, applications, and services (DAAS).
The updated list of principles reflects the DoD’s intent to adopt ZTA pursuant to E.O. 14028 and NSM-Protecting information (while processing, in transit, and in storage) is a core function of any security architecture whether it is performed from a network or data perspective.

Principle 1: Reduce risk from the inside out – Risk reduction must focus on protection of the DAAS and a secure path to access them.

• Principle 1.1: Least privilege (CNSSI 4009) – This principle is critical and should be considered at every decision point across all of the ZT pillars and is required to achieve the ZT target state.
• Principle 1.2: Eliminate unnecessary security controls – Building on least privilege, removing excessive controls in the architecture will reduce the attack surface and increase mission assurance.
• Principle 1.3: Isolation – Isolation (both logically and physically) enables control through access and policy restrictions to reduce risk to the networks and applications. This includes the use of network segments, application virtualization, and other technology and methods to enable more granular isolation.

AsterionDB directly aligns with ‘Principle 1.1: Least Privilege’. We achieve this by implementing a granular approach to data access. Business logic governs all access and use of information. Granular security is extended to all data items used by an organization – most critically unstructured data. AsterionDB is an architecture where data can not be accessed without first going through the logic. This is the very essence of granular security.

AsterionDB addresses ‘Principle 1.2: eliminate unnecessary security controls’ by converging all data and logic at the data-layer. This turns the middle-tier into an elastic security isolation layer responsible for the protocol transformation between HTTP and SQL. With no user assets in the middle-tier, we are able to construct a streamlined and secure computing apparatus that removes unnecessary security controls.

AsterionDB’s close integration with the Oracle database and related infrastructure provides the features for ‘Principle 1.3: Isolation’. AsterionDB integrates into advanced Oracle features for access and policy restrictions. Network segmentation, virtualization and other isolation methods are easily adopted by the AsterionDB Zero Trust Architecture.

Principle 2: Increase mission assurance through resilience – Resilience is a key concept that helps quantify the ability of a system to maintain effectiveness and recover, especially during an active cyber event. It is critical to keep the number of components, elements, and controls to the lowest level possible for ease-of-use and resilience.

• Principle 2.1: Deny by default – Evolving the deny all / permit by exception concept beyond network devices and integrating into all aspects of the architecture will mature and modernize the design. Resilience can be increased with greater control over authorized data flows and reducing rogue connections through poor configuration management.
• Principle 2.2: Assume breach – An assumption that a malicious cyber actors (MCA) has access to the environment is a key concept for the evolution of the CSRA to the ZT target state. This principle builds on deny by default to increase mission assurance through implementation of cryptographic mechanisms for all occurrences of data processing, storage, and transmission.
• Principle 2.3: Recover – An assumption of breach should be followed by the capability to recover full functionality within a specified mission-relevant timeframe. This principle enables Cyberspace Survivability through integrated and automated workflows and technical security measures to restore access to the DAAS.

AsterionDB’s granular approach to security implements ‘Principle 2.1: Deny by default’. We enforce a greater control over data flow. Our approach disallows ad-hoc access of unstructured data through the file system. Our patterns are able to detect rogue connections that lack proper credentials and identification. Security-by-default is implemented by the database itself, which holds data locked at all times.

AsterionDB’s architecture turns the patterns and techniques used by MCA’s into anti-patterns that work against them. This allows us to address ‘Principle 2.2: Assume breach’. AsterionDB eliminates lateral discovery through the file system and limits API discovery at the data-layer to a single-point. MCA’s that attempt to locate information through the file system or probe the API will reveal themselves as these are actions that are not supposed to take place in a production system. The result is an architecture that drives down the threshold between intrusion and detection.

AsterionDB centralizes error reporting and response at the data-layer. This provides a converged mechanism to address ‘Principle 2.3: Recover’. Upon detecting a possible intrusion, actions can be triggered and managed in a unified manner. In addition, system recovery is facilitated by reducing the components required to restore service.

Principle 3: Enable modernization – In order to achieve and maintain cybersecurity superiority, decisive and deliberate steps must be taken.

• Principle 3.1: Integrate identity, credential, and access management (ICAM) – To engage in responsible, secure information sharing within and across classified and unclassified security domains, ICAM policy and standards must be established. Integrating ICAM among organizations will enable interoperability and restrict access to authorized users.
• Principle 3.2: Establish and enforce data tagging – The ability to efficiently organize information based on tags is critical to modernizing cybersecurity. Data tagging is necessary to achieve an advanced maturity of all three outcomes listed in Section 1.1.
• Principle 3.3: Accelerate movement to secure cloud services – The ability to accelerate requires an innovative approach to providing secure access to cloud environments for continuous integration and continuous delivery (CI/CD) in the application/workload pillar. Secure cloud services through integration of ZT principles enable authorized user access to cloud resources while limiting unauthorized user access to application interfaces.
• Principle 3.4: Standardize and streamline cybersecurity data analytics – To adapt to new threats and emerging technology, security orchestration should be automated and use a common language for development, analysis, and reporting. Full visibility across all layers is required for effective analytics.

The AsterionDB platform includes an integrated ICAM module. AsterionDB can also work with foreign ICAM implementations. This directly address ‘Principle 3.1: Integrate identity, credential, and access management (ICAM)’. AsterionDB’s generic API and converged design furthers 3.1 by enabling a choke-point at the top of the logic path where credential and identity checks are enforced.

AsterionDB moves away from the limitations of the legacy file system. Instead of an inflexible hierarchical naming convention we embrace a robust keyword/tagging mechanism that allows for multiple ways to classify, secure and look at unstructured data assets. Furthermore, we allow unstructured data to be easily integrated into Oracle Label, an advanced data tagging extension to the Oracle Database. These capabilities enable AsterionDB to robustly support the goals of ‘Principle 3.2: Establish and enforce data tagging’.

‘Principle 3.3: Accelerate movement to secure cloud services’ is enabled by AsterionDB’s tight integration to the Oracle Database and by extension the Oracle Cloud Infrastructure. The Oracle Database is also available for use in other cloud infrastructures which further enhances our ability to address 3.3 . AsterionDB simplifies the process of migrating existing, legacy applications to the cloud. Finally, the AsterionDB architecture is functionally the same in the cloud, on premises and at the edge.

Acting as a central repository for storing platform generated incident information, AsterionDB makes it easy to achieve the goals of ‘Principle 3.4: Standardize and streamline cybersecurity data analytics’. AsterionDB is able to generate structured cybersecurity data for analytics and also serve as a repository for the secure storage of unstructured data generated by other services and devices. Additionally, the converged nature of AsterionDB, highlighted by the tight integration between data and logic, allows for better analytics and coordination of the response to a cyber incident through automated means.