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, the OCNWDAF and 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 OCNWDAF
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.
While the model shows a single 5G NF microservice deployed, several NFs are also deployed in individual clusters.
3.2.2 Key Trust Boundaries
Table 3-1 Key Trust Boundaries
| Trust Boundary | Includes | Access Control |
|---|---|---|
| Site Trust Boundary | All the NFs and other supporting elements for a given site. | Cluster Access Policies are implemented using some kind of Access Control Group (or Security Group) mechanism. |
| Cluster Trust Boundary | All the compute elements for a given cluster | Network Policies control Ingress and Egress traffic. Pod Security Policies manage the workloads allowed in the cluster (For example, no pods requiring privilege escalation). |
| DB Trust Boundary | All the cnDBTier elements for a given cluster | Firewall Policies control Ingress and Egress traffic. Database grants access and other permission mechanisms that provide authorization for users. |
| Orchestrator Trust Boundary (Orch Trust Boundary) | The orchestration interface and keys | Firewall Policies control the access to a Bastion server which provides orchestration services. Access to the Bastion host uses Secure Socket Shell (SSH) protocol. The cluster orchestration keys are stored on the Bastion host. |
| CS Trust Boundary | The common services implementing logging, tracing, and measurements. | Each of the common services provides independent Graphical User Interfaces (GUIs) that are currently open. The customer may want to introduce an api-gateway, implement authentication and authorization mechanisms to protect the OAM (Operations, Administrations, and Maintenance) data. The common services can be configured to use Transport Layer Security (TLS). When TLS is used, certificates must be generated and deployed through the orchestrator. |
| NF Trust Boundaries | A collection of 5G Network Functions deployed as a service. | Some 5G NF microservices provide OAM access through a GUI.
5G NF microservices provide Signaling access through a TLS protected HTTP2 interface. The certificates for these interfaces are managed via the certificate manager. |
3.2.3 External Data Flows
Table 3-2 External Data Flows
| Data Flow | Protocol | Description |
|---|---|---|
| DF1: Configuration | SSH | The installer or administrator accesses the orchestration system hosted on the Bastion Server. The installer or administrator must use ssh keys to access the bastion to a special orchestration account (not root). Password access is not allowed. |
| DF2: Logs, Measurements, Traces | HTTP/HTTPS | The administrator or operator interacts with the common services using web interfaces. |
| DF3: 5G Signaling | HTTP2 (w/TLS) | All signaling interaction between NFs at a site and NFs at an external site is sent through TLS protected HTTP2. |
| DF4: Alerts | SNMP (Trap) | Alerting is performed using SNMP traps. |
3.3 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.3.2 Key Trust Boundaries
Following are the key trust boundaries:
Table 3-3 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.3.3 External Data Flows
The following table describes external data flows of OCNADD:
Table 3-4 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. |