TR 28.870
Study on Enablers for Security Monitoring
V19.0.0 (Wzip)
2024/12 8 p.
- Rapporteur:
- Mr. Fernandes, Clifton
Nokia UK
Content for TR 28.870 Word version: 19.0.0
1 Scope
2 References
3 Definitions of terms, symbols and abbreviations
4 Concepts and background
5 Use cases
6 Conclusions and recommendations
$ Change history
1 Scope p. 6
The present document presents a study on enablers for security monitoring.
2 References p. 6
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
3 Definitions of terms, symbols and abbreviations p. 6
3.1 Terms p. 6
For the purposes of the present document, the terms given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
3.2 Symbols p. 6
3.3 Abbreviations p. 6
4 Concepts and background p. 6
When a security breach is detected a security alarm is raised. This study investigates if the following aspects, that are relevant for security alarms, are provided by the currently specified alarming concept:
- Filtering of security alarm notifications
- Security alarm reporting
- Retention policies for security alarms
5 Use cases p. 7
5.1 Use case #1: Filtering of security alarm notifications p. 7
Security alarms are reported using the concept of notifications. To receive notifications a subscription needs to be established. As part of the subscription a filter can be specified that filters the content of the notification.
Filtering security alarm (notifications) is hence possible with the existing notification framework. Enhancements are not required.
5.2 Use case #2: Security alarm reporting p. 7
Security alarms are reported using the concept of notifications. A reporting mechanism for security alarms is hence available. Enhancements are not required.
5.3 Use case #3: Retention policies for security alarms p. 7
5.3.1 Description p. 7
Security alarms are maintained, like any other alarm type, in an alarm list. Alarms are removed from this list, when they are cleared and acknowledged. There is no standardized way to keep inactive alarms in the alarm list or in some other store, nor is there a way to specify the retention time of inactive alarms.
5.3.2 Potential requirements p. 7
Req-1:
The 3GPP Management system should retain and store inactive (security) alarms.
Req-2:
The 3GPP management system should allow MnS consumers to specify the retention time of inactive (security) alarms.
Req-3:
The 3GPP Management system should allow MnS consumers to retrieve stored inactive (security) alarms.
5.3.3 Potential solutions p. 7
All inactive alarms should be retained, not only security alarms. Therefore, a general solution for retaining all alarm types should be devised.
It is proposed to do this work in the context of the SBMA enablers enhancement work in Rel-20.
6 Conclusions and recommendations p. 7
It is proposed to work on solutions to retain inactive alarms for later retrieval in Rel-20.
$ Change history p. 8
