@@ -795,60 +795,61 @@ These requirements are generally binding, and there is no low-medium-high tierin
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, identity management and the authorisation to execute a single or a set of commands 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.
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, an 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. Identification is provided by proximity and the user with physical access is the beneficiary of the provisioned configuration. (EDIT NOTE: I AM UNSURE WHAT IS BEING SAID HERE? - AB)
This does not mean that every access channel should provide authorization because of phsycial 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 proper authorisation depending on the device and its 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. 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.
An identity management system provides a mechanism to assure the identity of each administrative user.
It provides that an entity has authorization for access but has also given the NMS the correct information to perform a specific action.[\[i.12\]](#_ref_i.12)
Only a well maintianed trusted source list can provide functional identity.
An identity management system is a mechanism to assure the identity of each administrative user.
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.
This means that only an up to date source of idnetity credentails is essential. If the source identity is a company internal directory, it can only function if its content reflects the status of persons granted current access.
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.
These requirements apply to all network management systems, regardless of the product's use case and without variation for different tiers or risk.
-AB EDIT END 28-4-26
-**[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-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 to one by by factory default.
-**[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. [NOTE: Was the period for initial session length ever resolved?]
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.
For forensic needs, the product shall record the source of the identity in authoritative event monitoring data. [NOTE: Should this be its own requirement? Is it optional?]
Depending on the product desing, 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, if redundancy is needed.
For forencis needs, is important to include the source of the identity into the authoritative event monitoring data.
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.
Integration to 3rd. party identiy management systems is preferred due to high likelihood of other integrations that invalidates the users credentials faster, when changes are made due to credential misuse or person leaving the company for example.
If the same system is used to grant the user access roles, for example through group memebership, the implementation needs to be reviewed in the deployment context if it meets the target security requirements.
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.
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 are tailored to the users' perceived needs.
The system can have multiple distinct roles, each is tailored to the users' 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.
Role Based Access Control design and depth is outside of the scope of this standard, but the product must use some form of RBAC.
Both natural users, machine users, or equivalent structures need roles, despite often performing differently. Machine users can often have more exact limits on what functions they require. [\[i.13\]](#_ref_i.13)
Role Based Access Control design and depth is outside of the scope of this standard, but the productshall use some form of RBAC.
Both natural users, machine users, or equivalent structures shall be assigned roles, despite often performing differently. Machine users can often have more exact limits on what functions they require. [\[i.13\]](#_ref_i.13)
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.
-**[REQ-AUTH-3]:** When a user or system identity has been authenticated, the product shall apply authorization controls based on assigned roles or equivalent access-control attributes.
-**[REQ-AUTH-4]:** The authorization model shall enforce separation of privileges appropriate to the intended and reasonably foreseeable use of the product.
-**[REQ-AUTH-5]:** The technical documentation shall describe the authorization model implemented by the product.
-**[REQ-AUTH-6]:** The product shall implement and document authorization controls, like RBAC or APAC, suitable for privileged interfaces and sensitive operations.
-**[REQ-AUTH-7]:** All access to administrative interfaces, control functions, and sensitive operations shall be subject to strong authentication of users, services, or integrated components.
-**[REQ-AUTH-8]:** Privileged interfaces shall be protected with [5.2.4 State-of-the-art cryptographic libraries].
In addition, the managed device can have a configuration port, management API, firmware update channel, or debugging access, which are classified as privileged. [NOTE: Repeats above]
[NOTE: I am unsure is the above text should be here at all - while useful it is descriptive of the nature of identity managment practices rather then providing requirements for products? Should this be in another section e.g. functions or architecture?]
-**[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-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 authorization model implemented by the product.
-**[REQ-AUTH-6]:** The product shall implement and document authorization controls, like RBAC or APAC, suitable for privileged interfaces and sensitive operations. [NOTE: Document in what context - for user, as a security log or in the technical documentation?]
-**[REQ-AUTH-7]:** All access to administrative interfaces, control functions, and sensitive operations shall be subject to strong [Note: Define?] authentication of users, services, or integrated components.
-**[REQ-AUTH-8]:** Privileged interfaces [NOTE: Needs definition?] shall be protected with [5.2.4 State-of-the-art cryptographic libraries].
-**[REQ-AUTH-9]:** 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-10]:**Audit events shall include the source of the identity.
-**[REQ-AUTH-10]:**Product audit events shall include the source of the identity [Note: which identity?].
#### Machine users
-**[REQ-AUTH-11]:** The product shall not implement a design where default machine user credentials are used.
-**[REQ-AUTH-12]:** The product shall support machine credential rotation or comparable structure.
-**[REQ-AUTH-13]:** The product shall implement passwordless authentication for machine users such as certificates, tokens or APAC.
-**[REQ-AUTH-13]:** The product shall implement passwordless authentication for machine users such as certificates, tokens, or APAC.
-**[REQ-AUTH-14]:** The served API desing shall support minimal access grants for the machine user.
