AAS Security requirements

Before granting access to protected data represented by the AAS or restricted services, the AAS interface SHALL ensure the identification and authentication of the AAS user application user. Authentication of the AAS user application user SHALL be based on the authentication of information provided by the AAS user application on behalf of a user. The subject attributes conveyed to authenticate the AAS user application user SHALL uniquely determine the subject credentials used for subject authentication. The identity vetting process used to issue subject credentials SHOULD be sufficient to hold the identified AAS user application user accountable (see Integrity, Public key infrastructure).

If the AAS user application user is a NPE the AAS user application MAY be considered as the user. This especially accounts for AAS user applications with unattended operation. If there is no distinction between AAS user application user and AAS user application the identification and authentication of the AAS user application user MAY be replaced by the identification and authentication of the AAS user application (Identification and authentication of AAS user applications and AAS interface).

Additional information provided by the AAS user application can be used to provide extended information on the usage context. All information provided by the AAS user application can be used for authorization decisions.

Attributes describes an approach to provide information for authorization via ABAC attributes in an authenticated way.

Identification and authentication of AAS user applications and AAS interface provides a basis for integrity protection (Integrity) and confidentiality protection (Confidentiality) for data represented by the AAS exchanged via the AAS interface.

Identification and authentication of the AAS user application and the AAS interface can be achieved by different means, depending on the underlying communication technology and required security level (Public key infrastructure).

If an AAS user application is under the complete control of the AAS user application user, the identification and authentication of the AAS user application MAY be replaced by the identification and authentication of the AAS user application user (Identification and authentication of AAS user application users). This especially accounts if a commodity application (e.g., web browser) which functions as AAS user application.

The AAS interface SHALL be able to use accounts for AAS user applications and AAS user application users from an existing service or provide a built-in account database.

If a built-in account database AAS implementation SHALL provide means to properly protect account information and enforce authorization for the modification of account information. If a detached service is used to authenticate the user, the AAS responsible SHALL ensure that the account information is aligned between the AAS and the detached service (e.g., user roles assigned by a dedicated service need to match the roles evaluated by the AAS interface).

Account management MAY be made accessible via the AAS interface.

All entities within the AAS or interacting with the AAS SHALL be well defined and have unambiguous identifiers. The definition of an identifier includes its syntax/format and namespace management. The AAS responsible SHALL define a policy for identifiers used for:

Authentication of AAS user applications and AAS user application users SHALL support and facilitate the use of secure identities for authentication (Identification and authentication of AAS user application users, Identification and authentication of AAS user applications and AAS interface) and provide the capability to integrate into a system used to manage these secure identities across security domains of the different stakeholders interacting along a value chain.

Examples for secure identity infrastructures are:

In case a request sent from the AAS user application to the AAS interface cannot be processed, AAS interface SHALL NOT disclose any information that would allow conclusions to be drawn about the content or structure of the AAS nor conclusions on why a specific request was rejected.

Additional information to support trouble shooting or debugging MAY only be made available after additional authorization for this function.

Authorization enforcement happens at the AAS interface. The authorization of AAS user application users accessing the AAS interface SHALL be based on a defined set of rules. Authorization rules MAY be based on ABAC attributes provided by the AAS user application during authentication.

Details on how this requirement is to be met by the information model are outlined in Access Rule Model.

The AAS interface SHALL create audit events. As a minimum the events listed in Table Table 1 SHALL be kept in an AAS interface audit trail.

If accountability is a concern, the events listed in Table Table 2 SHALL be reported. Each accountability related event SHALL provide:

Each auditable event SHALL contain a time stamp of the event with precision at least to seconds.

Each auditable event shall contain information to determine which AAS user application took a particular action on the AAS. Providing detailed information on a particular event (e.g., actual user identity) may be delegated to the AAS user application. Depending on the intended use case the AAS responsible shall ensure that the available information is sufficient to resolve any emerging dispute.

The integrity of the structure of the AAS itself and information represented by the AAS, for example, Submodels, SubmodelElements SHALL be protected.

This requirement is relevant for two aspects of the AAS security model:

The AAS metamodel, Submodel templates, and concept repositories provide information supporting input validation checks for asset related information. The AAS interface SHOULD implement checks to ensure that data handed into or retrieved from the Asset Administration Shell for either storage or further processing meets those constraints.

From a security perspective, the AAS Responsible SHOULD discourage the deployment of Submodels which are not guided by a Submodel template.

Strict use of Submodel templates for Submodels and concept repositories for Submodel template elements respectively SubmodelElements can support the validation of the AAS structure and content.

An AAS constitutes a large aggregation of data and even the acquisition of meta-information is considered a potential goal of attackers. A potential attack is sending brute-force trial-and-error requests and using the error codes returned as oracle for business relevant information. Examples are information on whether a specific asset exists, amount of assets, existence of a specific Submodel.

In case a request sent from the AAS user application to the AAS interface cannot be processed, AAS interface SHOULD NOT disclose any information that could be exploited by adversaries to attack the AAS. Especially, the AAS interface SHOULD NOT disclose any information that would allow conclusions to be drawn about the content or structure of the AAS.

The AAS interface SHALL only accept ABAC attributes from the AAS user application (Identification and authentication of AAS user application users) which are properly bound to the respective communication context/channel (Identification and authentication of AAS user applications and AAS interface, Information integrity) and the information returned needs to be bound to that same communication context/channel (channel binding).

AAS Submodels can be used to distribute roots of trust to facilitate the authentication and communication with respect to the managed assets. For instance, an AAS Submodel can contain current root certificates of product suppliers or asset owners to support authentication of assets equipped with cryptographic credentials like manufacturer device certificates or IEEE 802.1AR device identifiers.

AAS Responsible SHALL define roots of trust for:

The confidentiality of information represented by an AAS SHALL be protected. This information includes both meta-information, e.g., which Submodels are available, and content provided via AAS, for example, Submodels, SubmodelElements.

This requirement is relevant for two aspects of the AAS security model:

Confidentiality for data at rest can be implemented by different means, depending on the required security level.

Measures include:

If no details are mentioned on required cryptographic algorithms or strength used to implement AAS security functionality, the latest version of [ENISA Report] or [NIST SP 800-78-5] SHOULD be used as a reference.

The definition of AAS structures SHOULD consider separation of content based on associated risk, relevant security objectives, or other criteria, operational function, required access (for example, least privilege principles) or responsible organization.

Restricted data flow is an important concept of IEC 62443.

Structuring of AAS information is described in IDTA 01001 [1]. AAS, Submodels, and SubmodelElements SHOULD be structured in a way that reflects different security levels applying to individual information offered by the respective substructure, e.g., by confining sensitive information into separate Submodels or SubmodelElements.

Security attributes such as access control rules (Access Rule Model) SHALL be assignable at the level of the entire AAS, individual Submodels, and SubmodelElements.

The elements of the AAS can be distributed across different entities (e.g., local device, edge device, on-premise cloud service, public cloud) according to their sensitivity. Each entity providing a different level of protection according to its security capabilities.

Access to the AAS interface can be restricted to defined AAS user applications.

Auditable events (Authorization enforcement) can be made available via the AAS interface, e.g., as a dedicated Submodel.

Auditable events (Auditable Events) SHALL be provided in a machine processable format.

In order to provide the capability to operate in a degraded state in case of a denial-of-service attack, the AAS interface:

The AAS can provide information about the actuality (e.g., last update received) of the information to allow AAS user applications.

The AAS can support the AAS user application to detect whether information provided is current. The AAS user application can use this information to determine whether recent updates have been lost due to denial-of-service (DoS) or AAS recovery or reconstitution after an attack.

The AAS interface SHALL provide the capability to restrict the discovery, exploration, and use of the AAS itself and Submodels contained therein.

The discovery, exploration, and use of Submodels is addressed by Authorization enforcement and Access Rule Model.