Security in Open RAN - Red Hat

Security in Open RAN

White Paper

Contents

1 Overview 5

2 Next Generation RAN Architectures 6

3 Open RAN security based on Zero Trust Architecture 8

4 Secured communication between Network Functions 9

4.1 Secure communication on all interfaces 9

4.2 Establishing trust based on mutual authentication 10

4.3 TrustedCertificateAuthorities 11

5 Secure framework for RIC 12

5.1 Security aspects of Near-Real-Time Radio Intelligent Controller (Near-RT RIC) 12

5.1.1 Secure Interface between Near-RT RIC and the O-gNB 12

5.1.2 ConflictresolutionandxAppauthentication 12

5.1.3 UseridentificationinsidetheNear-RTRIC 12

5.2 Security aspects of Non-Real-Time Radio Intelligent Controller (Non-RT RIC) 13

5.2.1 Secure Interface between Non-RT RIC and the O-gNB 13

5.2.2ConflictresolutionbetweentheNon-RTRICandtheO-gNB 13

6 Secure platform for Network Elements 14

6.1 Secure platform for Cloud Native Network Functions 14

6.1.1 Security of a Container based application software 14

6.1.2 Security of Cloud native software infrastructure 17

6.1.3 Security considerations with a cloud native hardware infrastructure 19

6.2 Secure platform for O-RU 20

7 Key security differentiators in Open RAN 22

8 Conclusion 23

2 ©Copyright2021,Altiostar.Allrightsreserved.

Table of Figures

Figure 1: gNBLogicalArchitecturein3GPP 6

Figure 2: gNBLogicalArchitectureinO-RAN 6

Figure 3: InterfacesandFunctionsplitbetweenO-RANand3GPP 7

Figure 4: 5GRANNetworkSecurityArchitecture 9

Figure 5: CertificatebaseddeviceauthenticationofO-CU,O-DUandO-RU 10

Figure 6: Non-Real-Time RIC declarative policies and objective intents 13

Figure 7: Cloud native platform 14

Figure 8: Security built into all phases of a software development process 15

Figure 9: AutomatedsecuritypracticesbasedonDevSecOps 16

Figure 10: Secure boot using a hardware root of trust 20


Definitions

Network Service (NS): Acompositionofnetworkfunctionsdefinedbyitsfunctionalandbehavioralspecification.IntheRANContext,agNBisaNetwork Service.

Network Function (NF): AfunctionalbuildingblockwithinaNetworkService,withwell-definedinterfacesandbehavior.IntheO-RANAlliance’sRAN architecturecontext,aO-DU,O-CU-CP,O-CU-UP,Near-RTRICandNon-RTRIC are Network Functions.

Cloud Native Network Function (CNF): CNF is one type of manifestation of aNF(likeVNForPNF)deployedasadecomposedsetofcontainerized microservices.InacloudnativerealizationofO-RANAlliance’sRANarchitecture, themanagedentities,O-CU-CP,O-CU-UP,O-DU,Near-RTRIC,Non-RTRICand Service Management and Orchestration (SMO) are CNFs. CNF and NF are interchangeableinthecontextof5Gcloudnativeservices.

Physical Network Function (PNF): This refers to network functions that are notvirtualized.IntheO-RANAlliance’sRANarchitecturecontext,theO-RUs thataredeployedatacellsitecanbeconsideredPNFs.


1 Overview

OpenRANisanopenradioaccessnetwork(RAN)architecturestandardizedbytheO-RAN Alliancebasedon3GPPandotherstandards.O-RANAlliance’sRANfunctionalsplitisbasedon the three key tenets:

• Decouplingofhardwareandsoftware • Cloud infrastructure • Standardizedandopeninterfacesbetweenthenetworkfunctions

In the IT world, hardware-software decoupling happened a long time ago. This decoupling led to theemergenceofsoftwareplayersthatwereexpertsinspecifichorizontallayers.Thesoftware from these players could run on any hardware providing operator customers with a variety of options.Anequallyrichecosystemofhardwareplayersemerged.

VirtualizationtechnologieshavehelpedenterprisesreducetheirTCOthroughefficientuseofcomputeresources,removalofhardwaresilosandincreasedautomation.Todeliver5Gservices,operatorsneedavirtualizednetworkcapableofscalingservicesbasedonpolicy-drivenserviceselections for subscribers. Cloud native architecture allows deployment of network functions (NFs) asaclusterofcontainerizedmicroservices,whereeachmicroservicecanbedeployed,scaled,andupgradedindependently.Insteadofscalingthewholeapplication,onlytherequiredcomponentwithin the NF is scaled.

Openinterfacesbetweenvariousnetworkfunctionsallowbestofbreedequipmenttobeusedin networks enabling operators to distinguish themselves from competition by using bespoke network functions, as needed.

Inthispaperitisdemonstratedhow,byadoptingazero-trustsecurityframework,anOpenRAN architecture provides a path to a more secure open networks and open interfaces over what existstoday.Despitemisconceptions,openinterfaces,definedintheO-RANtechnicalspecifica-tions, provide increased independent visibility and the opportunity for an overall enhanced and more secure system.

5GandOpenRANenablenewcapabilitiesandcontrolpointsthatallowsuppliers,testequipmentmanufacturers, wireless carriers, and network operators to assess, mitigate and manage security risksefficiently.ThispaperdetailshowO-RANenablesoperatorswithfullvisibilityandcontrol oftheirnetwork’send-to-endsecurity.

Thereisavastcloudindustrysolvingsecurityissues,andcloudRANnetworkfunctionsaresimilar toothercloudnetworkfunctions,withsimilarsecurityrequirementsandsolutions.Cloudarchi- tecture ensures resilience, scalability and segmentation and the introduction of features such asAI/MLandMulti-AccessEdgeComputing(MEC).Forexample,leveragingMEC,allowscollection andprocessingofsensortrafficatafactorytoshiftDDoSdetectionandmitigationtotheedge of the network where incidents at the edge can be isolated from the rest of the network. Microsegmentation,containerization,virtualization,andnetworkslicingprovideenhanced security and isolation from the hardware up. The security measures are designed into the system rather than being bolted on afterwards as in traditional systems.


2 Next Generation RAN Architecture

3GPP[1]hasdefinedthefollowingarchitecturefor5GNRgNBasshowninFigure 1.

gNBissplitintotwologicalfunctionscalledCU(CentralizedUnit)andDU(DistributedUnit)asshowninFigure1andthesetwoentitiesareconnectedbyF1-CandF1-Uinterfacesasdefinedin3GPPTS38.473[2].Itmaybenotedthatthe3GPParchitecturedoesnotspecifytheRemoteRadioUnit(RRU)i.e.theinterfacebetweenPHYandRFlayersislefttovendorimplementation.

O-RANAlliance,agroupofleadingvendorsandoperatorsdefiningOpenRANspecifications,furtherdisaggregateCUandDUnetworkfunctions[3]asdefinedby3GPPthatareinter-connectedoveropen,standardized,secureinterfacesasshowninFigure 2.


Figure 1: gNB Logical Architecture in 3GPP

Figure 2: gNB Logical Architecture in O-RAN

Figure 3 showsthefunctionalandinterfacesplitbetween3GPPandO-RAN.TheO-RANAllianceaddsnewinterfacesandfunctionsbeyond3GPP’s5GRANarchitecture.

SinceO-RANAlliancebuildson3GPP’s5GNRarchitecture,itbenefitsfrom3GPP’sadvanced securityfeaturesintroducedfor5G[4]including:

• Enhanceduseridentityprivacyi.e.,SubscriptionConcealedIdentifier(SUCI) • Fullprotectionofcontrol/userplanetrafficbetweentheUEandgNB(encryptionand integrity protection) over the air interface

• FullprotectionofgNBinterfacesincludingtheE1interfacebetweenCU-CPandCU-UP andtheF1interfacebetweenCUandDU

• Enhanced home network control (authentication)

• AdditionalsecurityfornetworkslicesbasedonSLA


Figure 3: Interfaces and Function split between O-RAN and 3GPP


3 Open RAN security based on Zero Trust Architecture

Rooted in the principle of “never trust, always verify,” Zero Trust is designed to protect modern digital environments by leveraging network segmentation, preventing lateral movement, providing Layer 7 threat prevention, and simplifying granular user-access control.

Azerotrustarchitecture(ZTA)isacybersecurityarchitecturethatisbasedonzerotrust principles and designed to prevent data breaches and limit internal lateral movement.ThefollowingistherelevanttextfromNISTpublication800-207-‘ZeroTrust Architecture’[5]-

A “zero trust” (ZT) approach to cybersecurity is primarily focused on data and service protection but can and should be expanded to include all enterprise assets (devices, infrastructure components, applications, virtual and cloud components) and subjects (end users, applications and other nonhuman entities that request information from resources).

In this new paradigm, an enterprise must assume no implicit trust and continually analyze and evaluate the risks to its assets and business functions and then enact protections to mitigate these risks. In zero trust, these protections usually involve minimizing access to resources (such as data and compute resources and applications/services) to only those subjects and assets identified as needing access as well as continually authenticating and authorizing the identity and security posture of each access request.

Supportofazero-trustarchitecturerequireseachO-RANcomponenttocomplywith establishedfunctionalitiesandprotections.O-RANAlliance[6]hasidentifiedseveral guiding principles for its ongoing work, including:

1. Supportintegrationwithanexternalidentity,credentialandaccessmanagement system(ICAM)usingindustrystandardprotocols 2. Requireauthenticationandauthorizationonallaccess 3. Supportrole-basedaccesscontrol(RBAC) 4. ImplementconfidentialityonconnectionsbetweenO-RANandexternalcomponents 5. ImplementintegritycheckingonconnectionsbetweenO-RANandexternal components 6. Support encryption of data at rest 7. Support replay prevention 8.Implementsecurityloggenerationandcollectiontoanexternalsecurityinformation and event management (SIEM)

OpenRANsecurityisbuiltonthefollowingtenets: 1. Secured communication between Network Functions 2. Secure framework for the Radio Intelligent Controller (RIC) 3. Secured platform for hosting the Network Functions

TheanalysisinthefollowingsectionsassumesacloudnativeOpenRANnetworkwith NetworkFunctionsmodeledascontainerizedmicroservices.


4 Secured communication between Network Functions

ThissectionexploresfollowingareasthatrelatetoprovidingsecurecommunicationbetweenallNetworkFunctionsinOpenRAN.

a. Secure communication on all interfaces b. Ensuring trust based authentication of communicating endpoints c. TrustedCertificateAuthoritiesforIdentityProvisioning

4.1 Secure communication on all interfaces

O-RANAlliancespecifiesanopenandsecurearchitecturethatincludessecureinterfaces betweenallitscomponents.Communicationsexchangedontheseinterfacesarecrypto-graphically protected for encryption, integrity protection and replay protection.

Thefollowingtablesummarizestheprotectionmechanismusedforeachinterfaceinan O-RANbasednetwork.

Figure 4: 5G RAN Network Security Architecture

Interface Between nodes Security mechanism Specifiedby

E1 O-CU-CPandO-CU-UP NDS/IP(IPSec)orDTLS 3GPP

Xn Source gNB and Target gNB

NDS/IP(IPSec)orDTLS 3GPP

Backhaul O-CU-CPand5GC(N2)O-CU-UPand5GC(N3)


Midhaul (F1) O-CU-CPandO-DU(F1-C)O-CU-UPandO-DU(F1-U)


Open Fronthaul (M-Plane)

O-RUandO-DU/SMO SSHv2,TLS O-RANWG4

Open Fronthaul (CUS-Plane)

O-DUandO-RU Workinprogress (Dec2020)

O-RANWG1STG

O1 SMOandO-RANManagedelements

Workinprogress (Dec2020)

O-RANWG1STG

E2 Near-RTRIC(xAPPs)andO-CU-CP

Workplanned (1Q21)

O-RANWG1STG

A1 Near-RT RIC and Non-RT RIC

Workplanned (1Q21)

O-RANWG1STG

O2 SMO and O-Cloud Workplanned (2Q21)

O-RANWG1STG


ItshouldbenotedthatseveralO-RANAlliancespecificationsarestillon-goingandaccordingly securityworkishappeninginparallel.ForprotectionoftheCUS-Planemessages[7]onOpen FronthaulLLSinterface,O-RANAllianceiscurrentlyintheprocessofdeterminingallthe threatsandvulnerabilities,andtheirimpactontheCUS-Plane.O-RANAllianceplanstocompletetheanalysisandspecifysecurityprocedurestoprotectCUS-PlanemessagesbyMarch2021.

4.2 Establishing trust based on mutual authentication

Mutual authentication is used for authenticating two entities with each other and setting up a secure encrypted connection between them. Mutual authentication prevents introduction ofrogueNFsorxAPPsinthenetwork.

OperatorX.509certificatesareusedformutualauthenticationwhileestablishingsecure connectionsusingIPsecandTLSprotocols.

AllnetworkelementsinanOpenRAN,i.e.O-CU-CP,O-CU-UPO-DUandO-RU,supportX.509 certificate-basedauthenticationandrelatedfeaturessuchasauto-enrollmentandauto-re- enrollmentwithanoperatorCertificateAuthority(CA)serverusingaprotocolsuch EnrollmentoverSecureTransport(EST)or3GPP-specifiedCMPv2.

ThexAPPsintheNear-RTRICaresecurelyon-boardedlikeanyothermicroserviceandthe O-RANAllianceisexpectedtouseCAsignedX.509certificatestoauthenticatebefore communicating over the E2 interface.

Figure 5 illustratesanexampleflowofhowcertificate-basedauthenticationisusedto authenticateanO-CU,O-DUandO-RUduringcertificateenrollmentwithaCAserver.

Figure 5: Certificate based device authentication of O-CU, O-DU and O-RU


Step 1-2:WhentheO-RUpowerson,theO-CU-CP,O-CU-UPandO-DUinstancesthatareallocated to serve that O-RU are instantiated by the orchestrator, if not already instantiated.

Step 3:anO-CU-CP,O-CU-UPandO-DUperformsESToraCMPv2-basedcertificate enrollmentprocedureincompliancewith3GPPwiththeCAservertoobtainanoperatorcertificate.Theoperatorcertificateisusedforsubsequentauthenticationwhenestablishing anIPSecoraTLSconnection.

Step 4:necessaryOAMactionsareperformedontheO-CU,ifany,includingchangingof default passwords.

Steps 5 thru 9areexecutedaspartoftheO-RUpower-onsequence.Keysecurityrelated stepsareexplainedbelow:

- TheO-RUobtainsitsIPaddress,theEMSorOSSaddressfromaDHCPserver usingoneoftheDHCPoptionsspecifiedinO-RANM-Planespecificationsection3.1.1 and3.1.4[8].

- TheO-RUperformscertificateenrollmentprocedurewiththeCAservertoobtain anoperatorcertificate.Thevendor-provisioneddevicecertificateisusedfor authenticatingwiththeCAserver.

- TheO-RUshallnotifytheEMSorOSSwithaNETCONFcallhome.O-RU’soperator certificateisusedtoauthenticatewiththeEMS.OSS/EMSshallconfiguretheO-RU

withthesecondaryNETCONFcontroller’saddress(i.e.theaddressoftheO-DU).

- TheO-RUshallnotifytheO-DUwithaNETCONFcallhometosecurelyobtainO-RU’s configuration.O-RU’soperatorcertificateisusedtoauthenticatewiththeO-DU.

4.3 TrustedCertificateAuthorities

Itisrecommendedthatthecertificateauthorities(CA)shouldbeauditedundertheAICPA/CICAWebTrustProgramforCertificationAuthorities.

ThispromotesconfidenceandtrustintheCAserversusedinOpenRANforauthenticatingnetwork elements.


5 Secure framework for RIC

5.1 Security aspects of near-real-time radio intelligent controller (Near-RT RIC)

TheNear-RTRICisanSDNcomponentthatcontains3rdpartyextensiblemicro-services(calledxApps)thatperformselectedradioresourcemanagement(RRM) services for the NFs that were traditionally managed inside the gNB. The Near-RT RIC interfaceswiththeO-CU-CP,O-CU-UPandtheO-DUviatheO-RANstandardizedopen E2 interface. The Near-RT RIC also interfaces with the Non-RT RIC and the service managementandorchestrationframeworkviatheA1andO1interfaces.

The key security aspects of the Near-RT RIC include:

• SecureE2InterfacebetweentheNear-RTRICandtheO-CU-CP/O-CU-UP/O-DU • ConflictresolutionandxAppauthentication • UseridentificationinsidetheNear-RTRIC 5.1.1 Secure Interface between Near-RT RIC and the O-CU-CP/O-CU-UP/O-DU Interfacesecurityisexplainedin§4.2

5.1.2 ConflictresolutionandxAppauthentication TheconflictresolutionamongthexAppsisnotnecessarilyasecurityissue but can lead to vulnerabilities if not handled properly.

WhilethexAppsintheNear-RTRICinitiatetheRICsubscriptionprocedurewiththe E2 nodes, the subscription manager in the Near-RT RIC platform, enforces the subscription policiesandkeepstrackofthesubscriptionsinitiatedbythexAppsandtheRANfunctions, and event triggers associated with those subscriptions. The subscription manager can resolvesignalingconflictsamongthexAppsbyoneormoreofthefollowingmeans:

• ThesubscriptionmanagerwillnotallowmorethanonexApptosubscribe to the same NF based on the same event trigger.

• IfmorethanonexAppsubscribestothesameNFandgetsthesameindication messages from the E2 node, then the subscription manager can allow them to simultaneouslycontroltheNFoftheE2node,aslongastheydonotoptimize the same or closely inter-dependent parameters pertaining to the NF.

• IfmorethanonexAppsubscribestothesameNFandgetsthesameindication messagesfromtheE2nodeandiftheyoptimizecloselyinter-dependentparameters, thenthesubscriptionmanagercanallowthemtosimultaneouslycontrolandoptimize thoseparametersbyusinglocksandbackofftimerstoretainmutualexclusivity.

AuthenticationaspectsofxAPPisexplainedin§4.2

5.1.3UseridentificationinsidetheNear-RTRIC MaintainingprivacyoftheusersisofutmostimportanceinsidetheRIC.ORANWG3 isworkingontheUEidentificationinsidetheNear-RTRICthatcanbeaddressed byacombinationof3GPP-definedTraceID,3GPP-definedRANUEID,temporaryRAN networkinterface-specificUEIDs,andbycorrelatingtheseIEswithoneanother. Typically,itisidealfortheNear-RTRICtomaintainpersistenceofUEidentificationfor near-RTgranularities,rangingfrom10msto1s.ThexAppsarenotexposedtoUE permanentID.InvalidationofthetemporaryIDsintheRICwhentheyarereleasedin RANnodeswillbehandledvianormalE2communication.InneithercaseisthisaUE privacyissueoraDoSattackthreat.


5.2 Security aspects of Non-Real-Time Radio Intelligent Controller (Non-RT RIC)

TheNon-RTRICisacomponentinanO-RANsystemfornon-real-timecontroloftheRAN through declarative policies and objective intents. This is illustrated in Figure 6 below.

1. The Non-RT RIC is deployed in a service management and orchestration framework (SMO) andprovidesdeclarativepolicyguidanceforcell-leveloptimizationbyprovidingthe optimalconfigurationvaluesforcellparametersovertheO1interface.

2. TheNon-RTRICalsosendsdeclarativepoliciesforUE-leveloptimizationtothe Near-RTRICviatheA1interface.

3. The Near-RT RIC then translates the recommended declarative policy from the Non-RTRICoverA1interfaceintoper-UEcontrolandimperativepolicyoverthe E2 interface.

4.TheNon-RTRICdevelopsML/AI-drivenmodelsforpolicyguidanceandnon-RToptimi- zationasrAppmicroservices.TheserAppsinterfacewiththexAppsovertheA1interface tooptimizeasetofproceduresandfunctionsintheunderlyingRAN.

The key security aspects of the Non-RT RIC are the following:

• SecureinterfacebetweenNon-RTRICandtheO-CU-CP/O-CU-UP/O-DU • ConflictresolutionbetweentheNon-RTRICandtheO-CU-CP/O-CU-UP/O-DU

5.2.1 Secure Interface between Non-RT RIC and the O-CU-CP/O-CU-UP/O-DU Interfacesecurityisexplainedin§4.2

5.2.2 ConflictresolutionandxAppauthentication Usually,aconflictinRRMariseswhentheRANusespoliciesandobjectiveintents differentfromtheNon-RTRICtomanagetheunderlyingRANnodessuchasthe O-CU.ThismaybethesourceofrAppscausingsignalingconflictswiththe functioningoftheunderlyingRANnodes.However,usingtheRICsubscription policies,mutualexclusivitycanbeenforcedcausingthesubscribedprocedures fromtheRANtobemanagedbytheNear-RTRIC,withoutcausingsignalingconflicts.

Figure 6: Non-Real-Time RIC declarative policies and objective intents


6 Secure platform for Network Elements O-RANAllianceRANarchitectureisbuiltonafullycloudnativearchitecture–thesamecloudarchitecturethatisthebedrockoftoday’sinternetandpubliccloud.Thecloud nativenetworkfunctionsintheO-RANnetworkviz.O-CU-CP,O-CU-UP,O-DU,Near-RTRIC and Non-RT RIC, are hosted on a cloud native platform, very similar to the cloud native platformusedinthecloudcomputingindustry.TheO-RUisaPNFandthushostedona non-virtualizedplatform.

In the following sections we take a holistic look at security aspects of these platforms.

6.1 Secure platform for cloud native network functions

TheO-RANarchitectureusesacloud-nativeplatformtohostO-CU-CP,O-CU-UP,O-DU,Near-RT RIC and Non-RIT RIC network functions. Figure 6 shows a typical cloud native platform with three distinct layers:

1. Container-based application software

2. CloudnativesoftwarestackcomprisinganimmutableOS,Kubernetes and Container runtime

3. Cloud native hardware infrastructure

The following sections look at security features of each of the three layers that make up a cloud native platform.

6.1.1 Security of a container-based application software

Aworkloadisanapplicationoraservicedeployedonthecloud.Containersoffera packaging infrastructure in which applications and dependent libraries are abstracted from the environment in which they actually run.

Figure 7: Cloud native platform


Containersaregenerallyperceivedtoofferlesssecuritythanvirtualmachines.Butit’s worth noting that containers have been in use in the IT industry to build applications such as for banking which are no less critical than telecom applications in terms of security requirements,andtheindustryhasevolveditselfinautomatingitssecurityand establishing best practices.

ThefollowingindustrystandardpracticesareusedinOpenRANtoensuresecurityof the container-based application software:

a. Secure software development based on “secure by design” principles b.AutomatingsecuritytestingbasedonDevSecOps c. Vulnerability management in Open Source and 3rd party libraries

Secure software development based on “secure by design” principles

Asoftwaredevelopmentlifecycle(SDLC)isaframeworkfortheprocessofbuildingan applicationfrominceptiontodecommission.Inthepast,organizationsusually performedsecurity-relatedactivitiesonlyaspartoftesting—attheendoftheSDLC. Asaresultofthislate-in-the-gametechnique,theywouldn’tfindbugs,flaws,andother vulnerabilitiesuntiltheywerefarmoreexpensiveandtime-consumingtofix.Worseyet, theywouldn’tfindanysecurityvulnerabilitiesatall.

AsecureSDLCinvolvesintegratingsecuritytestingandothersecurity-relatedactivities intoanexistingdevelopmentprocess.Figure7showshowastandardSDLCprocessis augmented with security practices at every stage of software development.

UsingasecureSDLCprocessfortheworkloadsdeployedinaO-RANnetworksuchas xAPPsinNear-RTRIC,O-CU-CPandO-CU-UPandO-DUmicroservices,ensuresearly detectionofflawsinthesystem,awarenessofsecurityconsiderationsbyallstakeholders involved in designing, development, testing and deployment of containers, and overall reductionofintrinsicbusinessrisksfortheorganization.

Automating security testing based on DevSecOps

Since the beginning of modern computing, security testing has largely been an independ- entactivityfromsoftwaredevelopment.SecurityfocusedQAprofessionalsperformed testing during the testing phase.

Figure 8: Security built into all phases of a software development process

SDLC Process

Secure SDLC Process


ADevSecOpsapproachtothecontainerdevelopmentlifecycleensuresthatsecurity isbuilt-inateverystageoftheCI/CDpipeline.

ThephilosophybehindDevSecOpsistobeginsecuritytestingearlyintheSDLC. DevSecOpsintegratesvarioussecuritycontrolsintotheDevOpsworkflowsuchassecure codinganalysisusingstaticapplicationsecuritytesting(SAST),automatedunit, functionalandintegrationtesting.Thisenablesdeveloperstofixsecurityissuesintheir codeinnearrealtimeratherthanwaitinguntiltheendoftheSDLC.

O-RANAlliancearchitecturesoftwaretakesadvantageoftheadvancementsin‘security automation’andtrendincloudcomputingtowards“shiftleft.”Thisensuresthatworkloads runintheO-RANnetworkarevalidatedsecurely(duringbuild/deploymentphase)and risk-based timely actions are taken when vulnerabilities are found before they are deployed in operator network.

Vulnerability management of open source and 3rd party libraries

Open source libraries and open source software enable developers to meet the demands oftoday’saccelerateddevelopmenttimelines.However,theycanalsoopenupthe platform to attacks due to unaddressed vulnerabilities in the software.

Softwarecomponentanalysis(SCA)isanopensourcemanagementtoolthathelpsin identifying potential areas of risk from the use of third-party and open-source software. SCAsoftwareautomaticallyscansallopen-sourcecomponents,createsanaccuratebillof materials (BOM), checks for policy and license compliance, security risks, and version updates.SCAsoftwarealsoprovidesinsightsforremedyingidentifiedvulnerabilities, usually within the reports generated after a scan.

Specializedcontainerimagescanningtoolsprovideautomatedvulnerabilitymanagement for containers by identifying and providing remediation paths for all the vulnerabilities intheimage.ThesetoolsareintegratedintotheCI/CDpipelineandprovidecontinuous assessment of the container image.

UseofsoftwarecomponentanalysistoolsinanO-RANnetworkallowsfordeploymentof an advanced vulnerability management process that includes automatic tracking, analysis ofanapplication’sopensourcecomponents,identificationofcomponentvulnerabilities, and tool-based vulnerability remediation.

CompliancewithsupplychainriskmanagementrequirementsfromNISTSCRMand CISAICTSCRM.

Figure 9: Automated security practices based on DevSecOps


6.1.2 Security of cloud native software infrastructure

Acloudnativesoftwareinfrastructureincludesthefollowing:

a.Container-specificoperatingsystem–lightweightandpurpose-builtOS b.Containerruntime–softwarethatexecutescontainersandmanages container images on a node c.Containerorchestration–softwarethatautomatesthedeployment, management, scaling and networking of containers

Container-specificOS

Thecloudnativesoftwareinfrastructurerelies,inlinewiththeNISTSP800-190 recommendations[9],onahostOSbuiltandconfiguredforthesolepurposeofrunning containerizedapplicationsinsteadofgeneral-purposeapplicationsreducingtheOS attacksurface.Inaddition,thecontainer-specificOSfollowstheimmutabilityinfrastructure paradigm by preventing any additional individual software package installation protecting againstvirusesandmalware;theentireOSbeingmanagedasasingleentity.Anyadditional feature has to be installed as a container. The OS implements strong isolation and manda- toryaccesscontrol(MAC)mechanismssuchasSELinuxtolimitwhatacontainercando and thus protecting the OS from the containers and the containers from each other. The OS alsosupportsinbuiltLinuxfeaturessuchascontrolgroups(cgroups)andnamespacesthat provide an isolated environment for the application running inside the container. The OS alsosupportsdiskencryptionincludingtherootpartitionbyleveraginglinuxunifiedkey setup(LUKS)encryption.

Container runtime

Thecloudnativesoftwareinfrastructureincludesalightweight,Kubernetes-specific OCI-compliantcontainerruntimeversionedwithKubernetessuchasCRI-Otoreducethe risk of vulnerabilities.

Thecloudnativesoftwareinfrastructure(container-specificOS,containerruntime,disk…) mustsupportrunninginFIPSmodebyusingFIPS140-2validatedcryptography.

Native security with Kubernetes

Kubernetesprovidesseveralbuilt-insecuritycapabilitiestosecurethecontainer environment including network security, resource isolation, access control, logging and auditing.SomeofthecommonKubernetesbuilt-incontrolsthathelpintighteningsecurity include:

a.Rolebasedaccesscontrol(RBAC) UseofRBACintheclusterprovidesaframeworkforimplementingtheprincipleofleast privilegeforhumansandapplicationsaccessingtheKubernetesAPI.

b.Configurethesecuritycontextforpodstolimittheircapabilities Podsecuritypolicysetsdefaultsforhowworkloadsareallowedtoruninthecluster. These controls can eliminate entire classes of attacks that depend on privileged access.

c.UseKubernetesnetworkpoliciestocontroltrafficbetweenpodsandclusters. Kubernetes’networkpoliciesallowcontrolofnetworkaccessintoandoutofthecontaine- izedapplications.Inadditiontothisfeature,software-basedfirewallsmaybedeployed to control container to container communication within or across different clusters.


d.Usenamespacestoisolatesensitiveworkloadsandcreatesecurityboundaries– separating workloads into namespaces can help contain attacks and limit the impact ofmistakesordestructiveactionsbyauthorizedusers.

e.Assessthecontainerprivileges–Adheringtotheprincipleofleastprivilegeand provide the minimum privileges and capabilities that would allow the container to perform its intended function.

f. Use mutual Transport Layer Security (TLS) for all inter cluster and intra cluster communications.

g. Capability to encrypt the etcd datastore to protect infrastructure and application secretsortosupportintegrationwithexternalvaults.

Leveraging Kubernetes operators for security

KubernetesoperatorsaresoftwareextensionstoKubernetesthatmakeuseofcustom resources to manage services and their components in an automated way. These operatorscanbeleveragedbythecloudnativesoftwareplatformforspecificsecurity purposes: - Hardwaremanagementoperatorstorestricttheneedforapplicationsof elevated privileges - Compliance operators to continuously monitor the compliance of the cluster - File integrity monitoring operators to detect any attacks impacting the platform integrity - Platformmanagementoperatorstofightconfigurationdriftandenforceasecure configurationbyeliminatinghumanerrors - Auditandlogoperatorstomanagetheauditconfigurationandthelogforwarding to a SIEM

Acloudnative-basedO-RANnetworkcanleveragenativesecuritycontrolsincontainer runtimeandcontainerorchestrationplatformssuchasKubernetes,toprovidedefense indepthsecurityforthecontainerizedworkloadthattheyhost.

Secureconfigurationofthecloudinfrastructurebasedonindustrybenchmarks

ThecloudinfrastructureisconfiguredbasedonindustrybestpracticessuchasCIS benchmarksforoperatingsystem,DockerandKubernetes,andNetworkEquipment SecurityAssuranceScheme(NESAS)jointlydefinedby3GPPandGSMAprovidesa consistentframeworkandcommonexternalauditprogramformultiplevendorsand operators. This ensures that appropriate security controls are put-in-place in the platform, thus reducing its attack surface.

Some of the common security controls include disabling unused ports and unused service,principleofleastprivileges(PLoP)forworkloads,protectingdatainstorage, useraccesscontrolusingRBAC,etc.

AllvirtualizedplatformsinanO-RANnetworkarehardenedasper3GPP’ssecurity assurancespecifications[10]andotherwell-knownindustrybenchmarkssuchasthose fromCIS[11].Thisensuresthatsecuritycontrolsareimplementedateverylayerofthe platformthusreducingtheplatform’sattacksurface.


Detectingandremediatingconfigurationerrorswithcloudsecurity posture management

Misconfigurationisthe#1causeofcloud-baseddatabreaches.Amechanismisneeded tomakesuretheconfigurationofthedeployedcloudresourcesiscorrectandsecure on day one, and that they stay that way on day two and beyond. This is referred to ascloudsecurityposturemanagement(CSPM).

ThecloudindustryhasusedCSPMsecuritytoolstocontinuouslymonitorcloudenviron- mentsfordetectionofcloudmisconfigurationvulnerabilitiesthatcanleadtocompliance violations and data breaches.

WiththeadoptionofacloudnativearchitectureinO-RANbasednetworks,anoperator nowhasthemeanstodeployadvancedCSPMtoolstoguardagainstnatural“drift”of onnetworkconfigurationandreducethepotentialforattacks.

Commercial cloud native hybrid platform

Standardizingonacommercialcloudnativehybridplatformenablestheoperatorwith thefollowingsecuritybenefits:

• AKubernetes-certifiedplatformwiththeflexibilitytorunsecurelyon-premorin avirtualprivatecloud,supportingO-RANtopologyvariationsfromtheSMO,RICs, CUs,andDUswithzero-touchprovisioning,

• ExtendedsoftwarelifecyclewithdynamicupdatesthataddressnewCVEsand optimizationsovertimeintodisconnectedenvironments,

• Support for multi-tenancy so that multi-vendor software can be securely hosted in the same cluster,

• Supportforinfrastructurecompliancescanning(OpenSCAP)andremediation, • Acontainerregistrywithvulnerabilityscanningtoeliminatevulnerabilitieson O-RANplatforms(e.gNearReal-TimeRIC)andassociatedxAppsandrApps.

6.1.3 Security considerations with a cloud native hardware infrastructure

O-RANenablesdecouplingofhardwareandsoftware,allowingforaplatformtobe built from different vendors.

6.1.3.1 Secure storage of credentials and data at rest

ItisrecommendedthatO-RANhardwarecomeswithahardware-basedsecuritymodule likeTPMtomanage,generate,andsecurelystorecryptographickeys.Hardware-based security modules are also meant to provide a hardware root of trust to enable secure computing by providing a secure key storage enclave with minimal cryptographic functionsprimarilyinthesigningandsignatureverificationspace.Thedataatrestmust be encrypted using keys generated from hardware-based security modules.

6.1.3.2 Establishing software chain of trust

Zero-trust cannot be achieved without the full participation of all the elements in the trust chain for a network. Figure 9 illustrates key aspects of establishing chain of trust whenadheringtozero-trustindigitalsystems.


Trusted hardware

The hardware is built with a tamper resistant “hardware root of trust” device that provides asecureenvironmentforstoringcryptographickeysandforattestationofcertificatesand allthesoftwarerunningonthathardware.Thedevicewillexposeasimpleuserinterface for the application to use when it needs to use the device for storing keys, retrieving certificatesetc.

Trusted software

Softwaresigningisenforcedatallsoftwarelayersincludingthefirmware,cloudnative software stack and container workloads at time of deployment, as well as authenticated versionupgradestomakeitmoredifficulttointroducemalicioussoftwareintooperator- controlled elements.

Establishing end-to-end chain of trust with secure boot

Securebootrequiresthateverybootupisstartingfromapieceofsoftwarethatcannot beupdatedinthefield.ThispieceofsoftwareisreferredtoasCoreRootofTrustfor Measurement (CRTM).

Thereafter, during the boot process every software program in the platform will be integrityverifiedbeforeitsexecutionbythesoftwareatthelowerlayer.Thisestablishes an end-to-end software chain of trust. The trust anchor for the software integrity verificationissoftwaresigningcertificate.

IntheO-RANnetwork,itisrecommendedtousesecurebootbasedonhardwareroot of trust and software signing to establish an end-to-end chain of trust.

6.2 Secure platform for O-RU

AnattackerwithunauthorizedaccesstothemanagementinterfaceofanunprotectedO-RU couldallowanattackertostealunprotectedprivatekeys,certificates,hashvaluesand/orinjectmalwaresand/ormanipulateexistingO-RUsoftware.Anattackercouldfurtherlaunchdenial-of-service,intrusion,andreplayattacksonothernetworkelementsincludinganO-DU.

Figure 10: Secure boot using a hardware root of trust


Therefore,hardeningoftheO-RUplatformwillensureenoughequipmentsecurityto substantiallyreducetheattacksurfacethatwouldotherwiseexistinanunprotectedO-RU. Security precautions on the O-RU can be divided into three aspects.

1. Supply chain security 2. Physicalsecurity 3. Network security

Supply chain security ensures that throughout the supply chain process of manufacturing, fromO-RUtoitsfinalinstallationsiteandcommissioning,acontrolledsecurechainof custody process is followed. This ensures that the O-RU is properly tracked and tagged.

PhysicalsecurityensuresthatthephysicalO-RUissealedwithnon-tamper-ablescrews that cannot be easily broken or opened and in the event of tampering or forced opening, all O-RU functionality will be disabled so that the O-RU becomes inoperable. This is in addition to all the physical and logical ports being secured and isolated, so that they cannotbeusedasavulnerabilityentranceintotheextendedRANnetwork.

From a network security point of view, O-RU ensures that all authentication and communication security protocols are correctly performed and followed. To ensure reliableandsecuresoftwareupgrades,theTPMproceduresareimplementedsothat rogue software downloads are prevented. Finally, hardening features, such as disabling unnecessary software components and interfaces when not in use, running software at thecorrectprivilege-level,scrambling/encryptionofdatainstorage,andsecurebootand hardware-based security module, are part of the comprehensive security processes onthetypicalO-RUtowardoffaswellaspreventunauthorizedaccesstotheO-RU.


7 Key security differentiators in Open RAN

ThefollowingtablehighlightssomeofthekeydifferentiatorsthatOpenRANprovides comparedtoaclosedRANortheclassicalgNB.

Differentiator OpenRAN ClosedRAN

Security of open fronthaul

Providesvisibilitytothesecuritymeasure taken to protect this interface.Open,standardizedinterfaces remove vulnerabilities or risk that comes with proprietary and potentially untrusted implementation.

ProtectionmeasuretakentoprotectCPRIinterfaceinaclosedRANisnotknown

Operator has full control in building a secure platform

OpenRAN’sdisaggregatedarchitectureallows network operators to build cloud-native platforms by selecting suppliersthatmeetalltherequiredindustry security standards and certifications.

Operator has no control of howthevirtualizedplatformis assembled. It is fully vendor driven.

Better enforcement of security controls in cloud infrastructure

Acloudinfrastructuresupplierwillbedirectly under an agreement with the operator and will be responsible for security of the cloud infrastructure.

Operator has no direct visibility of the cloud infrastructure provider

Disaggregatedplatform allows for better visibility and automated monitoring of the network

Acloudnativearchitectureallowsoperators to deploy the latest security tools for monitoring vulnerabilities and automated remediation measures asrequired

Operator has no visibility to this information. The operator is fully dependent on the vendor to detect and remediate vulnerabilities in the network

Adoptionofindustrybest practices in development ofcontainerizedapplications

Allowsadoptionofindustrybestpractices such as “secure by design” DevSecOps,automatedtestingindevelopmentofcontainerizedapplications. Operator also has an option to work with the supplier todetermineandinfluenceCI/CDprocesses used by the supplier.

It is fully vendor driven, and an operator has no mechanism to verify the software development process used by the vendor.

Protectionofcryptographic key

NG-RANcryptographickey(KgNB)is stored in CU, which is located in acentralizeddatacenterinsidethenetwork.

Stored at the cell site and can be potentially stolen especiallywhenHSMisnotimplemented in gNBs.


8 Conclusion

AttheheartofOpenRANistheuseofcloudnativearchitecture,thesamearchitecturethatis thebedrockoftoday’sinternetandpubliccloud.Securitypracticesinvirtualizeddeployments arematureandusedacrossthecloudcomputingindustry.Virtualizeddeploymentintelecom networksisnotnew.Operatorsalreadyhavevirtualizedinfrastructureintheirdatacenters and many have deployed virtual workloads for other components in the network including: packetcore,IMS,andotherapplicationssuchasCDN.Withadisaggregatedarchitecture, operatorswillnowadditionallybenefitfromsecurityexpertiseandexperienceoftoday’slargecloud infrastructure suppliers in managing the security of large IT cloud environments.

Operatorregainscontrolastheoperatornowunderstandswhatisrequiredtobuildand maintainasecureinfrastructure.OpenRANisbuiltonacloudnativeplatformwithclear responsibilitiesandaccountabilityestablishedbetweenhardware/infrastructuresuppliers, ahybrid-cloudplatformsupplier,andRANsoftwaresuppliers.Itenablesnetworkoperatorsto selectsuppliersthatmeetalltherequiredindustrysecuritystandardsandcertifications.

OpenRANleveragesseveralsecurityindustrybestpracticesusedinthecloudcomputingindustry. A“shift-left”strategyinthesoftwaredevelopmentprocessintegratessecuritycontrolsand practicesintoeveryphaseofthesoftwaredevelopment.WithDevSecOpsintegratedintothe CI/CDpipeline,thisalsobringsautomationintosecurecodereviewsandsecuritytesting. Use of automated tools for detection, remediation of vulnerabilities in open-source software anddetection,andmanagementofsecurepostureprovidesanoperatorwithquickdetection and resolution of anomalies in the network.

O-RANAlliance’sarchitectureforRANisbuiltonthesecurefoundationofzerotrustwherenetwork elements mutually authenticate with each other in order to communicate. Allcommunicationbetweenthemistransportedoverasecureinterfaceperindustrybest practicesspecifiedbyO-RANAlliance’ssecurityspecifications.Whilestandardsarestillevolving,theOpenRANpioneersandecosystemvendorslikeAltiostar,Mavenir,FujitsuandRedHat, aswellasearlyadopterslikeRakuten,Vodafone,Telefonica,NTTDocomoandDISHhave ensuredthatalltheinterfacesaresecuredusingcertificatebasedsecurity.

EverynetworkelementintheOpenRANnetworkundergoesplatformhardeningasper3GPP’s securityassurancespecificationsandotherwell-knowncloudcomputingindustrybenchmarks suchasCIS.Thisprotectsthenetworkfromanattackergainingunauthorizedaccessand subjectingthenetworktoDenial-Of-Service(DOS)attacksorgainingillegalaccess.

Insummary,open,standardizedinterfacesremovevulnerabilitiesorriskthatcomeswith proprietary and potentially untrusted implementation and provides an operator full visibility and control over the cloud environment and network in general.


References

1 3GPPTS38.401:NG-RAN;Architecturedescription

2 3GPPTS38.473:NG-RAN;F1ApplicationProtocol(F1AP)

3 O-RANArchitectureDescription(O-RAN.WG1.O-RAN-Architecture-Description)

4 3GPPTS33.501:Securityarchitectureandproceduresfor5Gsystem(Release16)

5 NISTSpecialPublication800-207:ZeroTrustArchitecture

6 O-RANArchitectureDescriptionChapterX–O-RANSecurity

7 O-RANControl,UserandSynchronizationPlaneSpecification(O-RANWG4.CUS)

8 O-RANManagementPlaneSpecification(O-RAN.WG4.MP)

9 NISTSpecialPublication800-190:ApplicationContainerSecurityGuide

10 3GPPTS33.511:SecurityAssuranceSpecification(SCAS)forthenextgeneration Node B (gNodeB) network product class

11 CISbenchmarks:https://www.cisecurity.org/cis-benchmarks/


Acronyms

3GPP 3rdGenerationPartnershipProject5G 5thGenerationCA CertificationAuthorityCI/CD ContinuousIntegration/Continuous DeliveryCIS Center for Internet SecurityCMPCertificateManagementProtocolCNF Cloud native Network FunctionCP ControlPlaneCPRI CommonPublicRadioInterfaceCRI-O Container Runtime Interface for OCI compatible runtimesCRMT Core Root of Trust MeasurementCSP CloudServiceProviderCU Central UnitCUS Control,User&SynchronizationDOS DenialofServiceDDOS DistributedDenialofServiceDTLS DatagramTransportLayerSecurityDU DistributedUnitEST Enrollment over Secure TransportFIPS FederalInformationProcessing StandardsGSMAGlobalSystemforMobile CommunicationsAssociationHSM HardwareSecurityModuleICAM Identity,CredentialandAccess ManagementLLS Lower Layer SplitLUKS LinuxUnifiedKeySetupMAC MandatoryAccessControlMEC Multi-access Edge ComputingMITM Man-in-the-MiddleNDS NetworkDomainSecurityNESASNetworkEquipmentSecurity AssuranceSchemeNF Network FunctionNIST National Institute of Standards and TechnologyNR New RadioNR-RIC Near Real Time RICOCI Open Container InitiativeO-CUO-RANCentralUnit

O-DU O-RANDistributedUnitO-RAN OpenRadioAccessNetworkO-RU O-RANRadioUnitPDCP PacketDataConvergenceProtocolPNF PhysicalNetworkFunctionRAN RadioAccessNetworkRBAC RoleBasedAccessControlRIC Radio Intelligent ControllerRLC Radio Link ControlRT-RIC Real-Time Radio Intelligent ControllerRRM Radio Resource ManagementRRU Remote Radio UnitSAST StaticApplicationSecurityTestingSCRM Supply Chain Risk ManagementSDAP ServiceDataAdaptationProtocolSDLC SoftwareDevelopmentLifeCycleSIEM Security Information and Event ManagementSLA ServiceLevelAgreementSMO Service Management and OrchestrationSSH SecureShellSTG SecurityTaskGroupSUCI SubscriptionConcealedIdentifierTCO Total Cost of OwnershipTLS Transport Layer SecurityTPM TrustedPlatformModuleUE UserEquipmentUP UserPlaneVNF VirtualizedNetworkFunctionZTA ZeroTrustArchitecture

About AltiostarBasedintheU.S.,Altiostarprovides4Gand5GopenvirtualizedRAN(OpenvRAN)software thatsupportsopeninterfacesandvirtualizesthebasebandunittobuildadisaggregated multi-vendor, web-scale, cloud-based mobile network. Operators can add intelligence, quicklyadaptthenetworkfordifferentservicesandautomateoperationstorapidlyscale thenetworkandreduceTotalCostofOwnership(TCO).Altiostarcollaborateswitha growingecosystemofpartnerstosupportadiverseOpenRANsupplychain.TheAltiostar OpenvRANsolutionhasbeendeployedglobally,includingtheworld’sfirstcloud-nativecommercial-scale mobile network with Rakuten Mobile in Japan.

200AmesPondDrive|Tewksbury,MA01876|Office:855.709.0701

www.altiostar.com | [email protected]

https://www.altiostar.com

mailto:info%40altiostar.com?subject=Security%20in%20Open%20RAN%20White%20Paper

Security in Open RAN - Red Hat

Documents

Transcript of Security in Open RAN - Red Hat