Which Apps Can Change the Controller?

An approved application presents valid credentials to a network controller, then asks for information it has no reason to use. That is a hypothetical threat scenario in NIST’s O-RAN security report: code added to an otherwise approved app could collect and export information outside its normal work. The credentials could still check out. NIST describes a possible attack, not a reported incident.

The distinction is useful when evaluating an application for a controller. Establishing which app sent a request leaves another decision: whether that app should be able to make that particular request. A product demonstration may show the useful result while leaving the extent of the access difficult to see.

When a controller accepts third-party applications, the buying conversation needs to reach the permissions of each application. Which information may it read? Which commands may it issue? How closely do those capabilities match the job it was installed to perform?

Start with the request

The report concerns the RAN Intelligent Controller in Open Radio Access Networks, a mobile-network architecture. It describes specialized applications that obtain information or influence network operation through the controller. Section 2, printed page 6, separates a request from an impersonator from an unnecessary request made by an approved component. That second possibility supplies the example above.

The enterprise comparison here is narrower than the telecom architecture: examine the authority attached to an application. Consider the following illustrative building-control purchase. An organization wants a weekly report identifying rooms whose temperatures fall outside a chosen range. The proposed reporting app reads measurements and produces that report. Changing the building’s operating schedule would be a separate capability.

For this example, the first permission review can stay close to those two actions. The buyer asks the integrator to identify the measurements the report consumes and to show whether the app can also submit schedule changes. If the integration requires a broad service account, the proposal should explain which additional actions that account permits and why they are needed.

Read access and command access have different consequences

An app that reads measurements can expose the information it receives. An app that changes a schedule can affect when equipment operates. In our hypothetical purchase, allowing both would enlarge the app’s authority beyond the stated reporting task. The organization could choose a narrower integration, accept a documented limitation, or decide that a different feature justifies additional access.

Those are decisions about a specific capability. A general statement that the application is trusted or comes from an approved supplier leaves them unanswered. The useful evidence would connect the requested permission to a named function: this information is needed to calculate the weekly report; this command is needed only if automated schedule adjustment is purchased.

The distinction also makes a demonstration more informative. In a safe test environment agreed with the integrator, the organization could ask to see the reporting workflow succeed and an out-of-scope schedule-change request refused. A screenshot of the finished report establishes the output. The second observation tests the proposed access boundary.

Revisit permissions when the job changes

Suppose the organization later adds automatic schedule adjustment. In this illustrative extension, the app’s job has changed, so write access may now have a purpose. The decision needs to specify the schedules it may alter, the conditions under which it may act, and how an operator can restore an acceptable setting. Keeping the earlier reporting-only description would conceal that expansion.

If the platform cannot separate those permissions, that constraint belongs in the purchase decision. The buyer may need an additional control, a restricted deployment, or a different integration. A demonstration can then end with a concrete record: the app can read these measurements, issue these commands, and is blocked from these other actions. Any capability the test could not establish remains an open item.

Source: NIST IR 8625, section 2, printed page 6; NIST publication record and report scope.