3 Secure Development Practices
Given below are the practices followed for a secure development environment:
3.1 Vulnerability Handling
For details about the vulnerability handling, refer Oracle Critical Patch Update Program. The primary mechanism to backport fixes for security vulnerabilities in Oracle products is quarterly Critical Patch Update (CPU) program.
In general, OCNADD Software is on a quarterly release cycle, with each release providing feature updates and fixes and updates to relevant third party software. These quarterly releases provide cumulative patch updates.
3.2 Trust Model for OCNADD
The following Trust Model depicts the reference trust model (regardless of the target environment). The model describes the critical access points and controls site deployment.
3.2.2 Key Trust Boundaries
Following are the key trust boundaries:
Table 3-1 Key Trust Boundaries
| Trust Boundary | Access Control |
|---|---|
| OCNADD | Kubernetes Namespace for OCNADD where its internal micro-services are deployed. |
| Site | Where the Kubernetes cluster is deployed. |
| Control Plane |
This trust boundary delineates the control plane elements of the clusters, that is, API Server, kubelet, containerd and etcd. The configuration database (ETCD service) is isolated so that only control plane services can access it. |
| Database | MySQL service deployed in a separate Kubernetes namespace. |
| CNE Infra | Namespace containing all the infrastructure related services (like Prometheus). Provided by CNE. |
| Orchestration | Includes the orchestration server and the Code and Image Repository. |
3.2.3 External Data Flows
The following table describes external data flows of OCNADD:
Table 3-2 External Data Flows
| Data Flow | Protocol | Description |
|---|---|---|
| DF1: Management | SSH | Operator will login to the orchestration server through SSH for deploying OCNADD and/or managing the OCNADD Kubernetes deployment using helm. |
| DF2: Browser | HTTPS |
Operator uses CNC Console to create, manage feed configuration and monitor OCNADD. CNC Console is accessed through the browser and the Operator is authenticated with username and password before access is granted. |
| DF3: Kafka | SASL_SSL |
Oracle NFs write the 5G SBI data or messages into the Kafka exposed by OCNADD in the respective topics. OCNADD will then process according to the feed configurations. The communications are encrypted using TLS and Oracle NF will authenticate themselves to Kafka through SASL/PLAIN (username and password). |
| DF4: Consumer NF | HTTP2(w/TLS) | OCNADD forwards the message feed to respective consumer NF/s as HTTP2 (over
TLS) or H2C (HTTP2 clear text) messages according to the feed
configurations.
The traffic segregation is provided using CNLB egress NAD support. The CNLB support has to be enabled in the helm charts for the egress traffic separation in the consumer adapter and corresponding feed configuration should be done. The CNLB route the packets using the layer3/layer4 information from the defined network attachment definition(NAD). |
| DF5: Consumer NF (Synthetic Packet) | TCP | OCNADD forwards the Synthetic Packet to respective consumer NF/s as TCP or TCP_SECURED messages based on the feed configuration. |
| DF6: Direct Kafka Consumer Feed | Kafka (SASL/SCRAM over TLS) | External Kafka consumer can read data directly from authorized Kafka topic. Consumers are authenticated using SASL/SCRAM (SCRAM-256 and/or SCRAM-512). All communications will be encrypted with TLS. |
| DF7: REST | HTTP2 | Non Oracle NF forwards the
messages to OCNAD ingress adapter service using HTTP2 (over TLS) or H2C
(HTTP2 clear text) according to the ingress feed configuration.
The traffic segregation is provided using CNLB ingress NAD support. The CNLB support has to be enabled in the helm charts for the ingress traffic separation in the ingress adapter and corresponding feed configuration should be done. The CNLB route the packets using the layer3/layer4 information from the defined network attachment definition (NAD). |
| DF8: Data Export | SFTP | OCNADD send the exported records to the external third party server using secure file transport service based on the data export configuration. |