@@ -176,6 +176,7 @@ For the purposes of the present document, the following abbreviations apply:
`GUI Graphical User Interface`
`NE Network Element`
`MDM Mobile Device Management`
`IAM Identity and Access Management`
# 4 Product context
@@ -624,6 +625,10 @@ Following list of essential functions keep the NMS self-secure and correct funct
The technical requirements of the present document apply under the environmental profile for operation of the product with digital elements, which shall be in accordance with its intended use. The product with digital elements shall comply with all the technical requirements of the present document at all times when operating within the boundary limits of the operational environmental profile defined by its intended use.
As necessary functions as identification and authorisation are, a NMS can still serve traffic without perfroming an identification routine as long as that traffic is authorised in another way.
For example, residential routers are often configured in a way that physical access to a local port is sufficient to identify a Service Requesting User (SRU) authorisation is provided by proximity and a user with physical access becomes the beneficiary of the provisioned configuration.
This does not mean that every access channel should provide authorisation with physical access. A managed device can have a configuration port, a management API, a firmware update channel, and even a debugging interface, all of them classified as privileged and requiring complex authorisation depending on the device, and its use.
## 4.9 Users
Human users of the system are natural persons, trained and qualified at NMS administrators, and authorised to manage the NMS and the connected managed elements. Administrators typically access the system through a HTTPS GUI, console, or by VPN connection.
@@ -791,62 +796,89 @@ These requirements are generally binding, and there is no low-medium-high tierin
-**[REQ-SBOM-1b]:** The SBOM identifier format shall be consistent with common vulnerability handling standards.
-**[REQ-SBOM-2]:** The SBOM shall be consistent with [5.3.4 Secure updates] practices.
### 5.2.6 Identity and authorisation
### 5.2.6 Identity and access management
The identity and access management (IAM) and authorisation grants are essential pieces in the larger puzzle of cybersecurity.
A secure product confirms the identity and authority of all users and performing an action.
As there natural user and machine user can sometimes be used interchangeably in the context, both are referred as subjects from now on.
The identity management is an essential piece in the larger puzzle of cybersecurity.
A secure product confirms the identity and authority of all users performing an action.
Depending on the design of the product, authorisation to execute a single or a set of commands and general identity management can use the same system or two distinct systems.
The choice to use a single or sepertate systems often relates to system and network size and in smaller systems identity management and authorization are often combined.
As necessary functions as identification and authorisation are, a NMS can still serve traffic without perfroming an identification routine as long as that traffic is authorised in another way.
For example, residential routers are often configured in a way that physical access to a local port is sufficient to identify a Service Requesting User. authorisation is provided by proximity and a user with physical access becomes the beneficiary of the provisioned configuration.
This does not mean that every access channel should provide authorisation with physical access. A managed device can have a configuration port, a management API, a firmware update channel, and even a debugging interface, all of them classified as privileged and requiring complex authorisation depending on the device, and its use.
Machine users can often have more exact limits on what functions they require. [\[i.13\]](#_ref_i.13)
The same interfaces can be used by the machine users and the privileged users.
As adminstrator is a priviledged users, but the machine user making changes is not an administrator, this document refers to both as privileged users whom are often connecting to privileged interfaces.
The product can serve traffic that is not meant to be identified.
For example, an in-home router often trusts that the physical access to its port is enough to identify the subscriber line.
In addition, the managed device can have a configuration port, management API, firmware update channel, or debugging access, which are classified as privileged.
The operative context is described in more datail in the section [4.8 Operational Environment](#48-operational-environment).
#### Identity management
An identity management system is a mechanism to assure the identity of each privileged user or entity.
It provides that an entity is not only authorised to interact with the system, but has given the NMS the correct information to perform a specific action.[\[i.12\]](#_ref_i.12)
To function Identity management systems maintain a list of trusted sources and only a well maintianed trusted source list can provide functional identity.
An identity management system is a mechanism to assure the identity of each subject which can be privileged or non-privileged within the system deployment context.
Identity management system maintains a list of trusted sources, one or more, that describes what subjects are valid.
This means that an up to date source of identity credentails is essential. If the source identity is a company internal directory, its functionality is dependent on the accuracy of its content in reflecting the status of persons granted current access.
An up-to-date source of identity is essential.
If a company internal employee directory is the source of the identity, its functionality is dependent on the accuracy and timeliness of its content.
If an employee exits the company, the identity is expected to vanish or at least reflect the contractual status of the employee.
The idenity management is often assessed as part of certification processes, and is outside of this document. [\[i.12\]](#_ref_i.12)
Identity management system design and implementation is outside of the scope of this standard.
These requirements apply to all network management systems, regardless of the product's use case and without variation for different tiers or risk.
These requirements apply to the product, regardless of the product's use case and without variation for different tiers or risk.
-**[REQ-AUTH-0]:** The product shall support identity management through at least one of the following approaches: (a) integration of the NMS into an external state-of-the-art Identity Management System, (b) integration of an external Identity Management System into the NMS, or (c) a dedicated Identity Management module built into the NMS.
-**[REQ-AUTH-0]:** The product shall support identity management through at least one of the following approaches: (a) integration of the product into an external state-of-the-art Identity Management System, (b) integration of an external Identity Management System into the product, or (c) a dedicated Identity Management module built into the product.
-**[REQ-AUTH-1]:** Product shall use multi-factor authentication to confirm the identity of a natural user appropriate to the intended and reasonably foreseeable use.
-**[REQ-AUTH-2]:** Product shall limit a natural user's authorisation validity of a session via a configuarble setting that shall be initially limited by factory default of one day.
-**[REQ-AUTH-2]:** Product shall limit a natural user's authorisation validity of a session via a configurable setting that shall be initially limited by factory default of one day.
Depending on the product design, the identity management referred in [REQ-AUTH-0] can be either part of the deliverable product, part of the deployment context as outside source or both, where redundancy is deseriable or necessary.
Integration into 3rd party identity management systems is preferred due to the higher likelihood that a dedicated indentity management system is more likely to properly update or invalidate subjects credentials when necessary.
Integration into 3rd party identity management systems is preferred due to the higher likelihood that a dedicated indentity management system is more likely to properly update or invalidate users credentials when necessary.
If the same system is used to grant the subjects access roles, for example through group membership, due diligence is required to assure that it meets the target security requirements in the intended or likely implementations of the product.
If the same system is used to grant the user access roles, for example through group membership, due diligence is required to assure that it meets the target security requirements in the intended or likely implementations of the product.
Role based authentication has been established to be a reasonable method to control a large pool of subjects by grouping them together for example to task based sub-groups that grants access to partial set of functions.
These groups can be for example _billing reader_ or _project admin_ to grant access to related operations in the product.
It is more rare, that a person who focuses on financials would need access grants related to _project admin_ group, but it is reasonable to assume, that _project admin_ would need to understand how much the performed actions costs while assessing if projects is withing the budget.
When the identity of a user is established, the system grants the user access rights based on the users' role.
The system can have multiple distinct roles, each is tailored to the users' perceived needs.
#### Attribute-Based Access Control
Role based access control might be too coarse for some applications, like machine user access grants.
Therefore industry has started to adopt more granular controls like Attribute-Based Access Control (ABAC), where subject's authorisation to perform a function is determined by attributes assosiated with the request.
This ABAC is also know as policy-based access control that compliments Identity and Access Management (IAM).
The attributes that formulate the identity portion of the grant are often matched with a target action.
> **ABAC Example:**
> An identified wokflow execution A in a trusted environment B can ammend the OCI registry C, under a project D, with a new container if the workflow is launched under trusted environment B organisation E, repository F.
In the above example, how the trust between the policy holder and the source environment is established can vary and there are different implementations in the market.
Attribute-Based Access Control design and implementation is outside of the scope of this standard.
#### Role based authorisation
When the identity of a subject is established, the system grants the subject access rights based on the subjects' role.
The system can have multiple distinct roles, each is tailored to the subjects' perceived needs.
There are many possible roles, with examples such as: monitoring data reader, interconnectivity administrator, or administrator.
If the product's deployment context calls for an all-powerful superuser, this can be accomplished either with a single role with numerous responsibiltiies or by aggregating many available roles to that single user.
In many systems identity information includes a group assignment matched to a role inside the system.
If the product's deployment context calls for an all-powerful superuser, this can be accomplished either with a single role with numerous responsibiltiies or by aggregating many available roles to that single subject.
Role Based Access Control design and depth is outside of the scope of this standard.
Both natural users, machine users, or any privileged action performing entities needs roles or comparable control structures like Attribute-Based Access Control, to limit individual access credentials to the smallest possible set.
This is the reason for [REQ-AUTH-3], but as the evaluating the fit of the implementation to the intented use, the design validation is only vaguely specified in [REQ-AUTH-4].
Machine users can often have more exact limits on what functions they require. [\[i.13\]](#_ref_i.13)
The same interfaces can be used by the machine users and the admin users.
As adminstrator is a priviledged users, but the machine user making changes is not an administrator, this document refers to both as privileged users whom are often connecting to privileged interfaces.
#### Generic requirements
The product can serve traffic that is not meant to be identified.
For example, an in-home router often trusts that the physical access to its port is enough to identify the subscriber line.
In addition, the managed device can have a configuration port, management API, firmware update channel, or debugging access, which are classified as privileged.
The operative context is described in more datail in the section [4.8 Operational Environment](#48-operational-environment).
All subjects require roles or comparable control structures like Attribute-Based Access Control, to limit individual access credentials to the smallest possible set of requested operations.
This is the reason for the requirement [REQ-AUTH-3], but as the evaluating the fit of the implementation to the intented use, the design validation is only vaguely specified in the requirment [REQ-AUTH-4].
-**[REQ-AUTH-3]:** When a user or system identity has been authenticated, the product shall apply authorisation controls based on assigned roles or equivalent access-control attributes.
-**[REQ-AUTH-3]:** When a subject has been authenticated, the product shall apply authorisation controls based on assigned roles or equivalent access-control attributes.
-**[REQ-AUTH-4]:** The authorisation model shall enforce separation of privileges appropriate to the intended and reasonably foreseeable use of the product.
-**[REQ-AUTH-5]:** The product technical documentation shall describe the identity and authorization model implemented by the product.
-**[REQ-AUTH-6]:** All access to privileged interfaces, control functions, and sensitive operations shall be subject to strong authentication of users, services, or integrated components.
-**[REQ-AUTH-6]:** All access to privileged interfaces, control functions, and sensitive operations shall be subject to strong authentication of subjects, services, or integrated components.
-**[REQ-AUTH-7]:** Privileged interfaces shall be protected with [5.2.4 State-of-the-art cryptographic libraries].
-**[REQ-AUTH-8]:** The product shall report all relevant events related to authorisation including, but not limited to, successful and unsuccessful use of identity, object access, policy change, privileged function use, data access and deletions, data changes and permission changes.
-**[REQ-AUTH-9]:** The product shall record the source of the identity in authoritative event monitoring data.
The requirement [REQ-AUTH-5] is itentionally vague.
The model can be complex, and there can be multiple different overlapping mechanisms in place that can used to enable the same function.
#### Machine users
Credential rotation addressed by [REQ-AUTH-11], is one of the key elements, that enable organisation to build resilience in a compromised network.
