10 Logging, Audit and Discreet Monitoring
33.1803GPPRelease 17Security of the Mission Critical (MC) serviceTS
10.1 Logging and audit of service metadata
10.1.1 Overview
The MC system should generate service metadata. This may include system events, management events, security events and user events. The full range of events that may be logged by the MC system is out-of-scope of the current specification. Furthermore, the mechanism that is used to audit MC system metadata is also out-of-scope of the current specification.
This clause defines the security and communications-related data associated to user events that are required to enable the audit of MC user actions within the MC system. User event logs are required to support discreet monitoring or audit.
To ensure the privacy of MC users’ data, where this information is collected it shall be protected as defined in Clause 10.1.2.4.
10.1.2 User events
10.1.2.1 Types of events
When user events are collected within the MC System, the following events (based on the deployed MC services) are recorded
Class A: Common signalling events. Sending or receiving a common signalling message as defined in TS 23.280 [36].
Class B: MCPTT signalling events. Sending or receiving an MCPTT signalling message as defined in TS 23.379 [2].
Class C: MCVideo signalling events. Sending or receiving an MCVideo signalling message as defined in TS 23.281 [37].
Class D: MCData signalling events. Sending or receiving an MCData signalling message as defined in TS 23.282 [38].
Class E: Interworking signalling events. Sending or receiving an Interworking signalling message as defined in TS 23.283 [48].
10.1.2.2 Location of recording function
SIP events may be recorded at the CS and IS Proxies and/or MCX Servers. Depending on the configuration of the MC system, the SIP events may also be recorded within the SIP core.
HTTP events may be recorded at the HTTP Proxy(s).
10.1.2.3 Security content within user event logs
When a user event occurs, the following security-related information is required:
– The class and type of a user event
– IP addresses (source and destination)
– Signalling layer identifiers
– SIP URI (source and destination).
– HTTP target URL
– The initiating user or server
– The receiving user, group, server or [set of multicast users]
– Security parameters (if present in signalling):
– MIKEY message
– Access or Security Token
– Identifiers for related media bearers (if applicable).
NOTE: These logs are required to support disceet monitoring or audit of user content.
10.1.2.4 Protection of user event logs
User event logs need to be protected as they contain information that impacts the user’s privacy. User event logs shall be encrypted and integrity protected while stored. Access to user event logs shall only be granted to authorised persons and such access shall be logged.
10.2 Audit and Discreet Monitoring of user content
10.2.1 Overview
Disceet Monitoring is access to user content at a network element within the MC Domain. Where Discreet Monitoring is used to access to user voice communications, it is known as Discreet Listening. Discreet Monitoring includes access to voice, video and data communications. For the purposes of this document, discreet monitoring and audit are equivalent processes. For discreet monitoring the access to media is in real-time. For audit, the access to media is at some point after the recording. The systems which support audit or discreet listening are out of scope of this document.
Disceet Monitoring and Audit are required functions of a public-safety network. For non-public safety services, these functions shall not be implemented in the network without explicit consent from all users of the MC system.
10.2.2 Collection of user media
It is assumed that collected Mission Critical media is held in its encrypted form within mass data storage. The storage solution is out-of-scope of this document.
User media is collected from the media paths within the MC Domain. It is expected that the encrypted media shall be collected at the media gateway into the MC system or by the MCX server .
Where SDS messages are routed within a signalling path, media will need to be extracted from within MCData signalling paths by the MC Domain. It is expected that the encrypted media routed over the signalling path shall be recorded by the CS and IS Proxies or by the MCData server.
To identify and process the collected and encrypted user media, user event logs associated with the media are required, as defined in Clause 10.1.2.
10.2.3 Storing of user media
User media in the MC System is end-to-end encrypted by default. Consequently, media can be recorded without modificiation and without additional protection. Media should be recorded alongside:
– a unique identifier for the collected media
– a unique identifier for a user event (with which the media is associated).
NOTE: Collected associated user event metadata may or may not be stored with the media.
10.2.4 Decryption of user media
To decrypt a specific target user’s media for audit or discreet listening at a specific time ‘T’, the following process should be used for decryption of user media. The controlling entity shall be either the KMS or a secured logging device.
1. The auditor obtains the target user’s key material and KMS certificate that was active at time ‘T’. This could be performed, for example, using an Audit Client. An Audit Client is a Key Management Client with the special access privilege to request previously-issued user key material for existing clients The provision of user key material by the KMS grants the auditor access to the user’s communication content..
a. Any request made by the auditor shall be controlled and logged(to allow the audit action to be audited) .
b. It is recommended that each release of key material be authorised by a secondary auditor (e.g. a double-lock mechanism).
c. It is recommended that the number of requests from each auditor within a time-period be limited. It is also recommended that the total number of requests from all auditors within a time-period be limited.
NOTE: The release of key material for a user at time ‘T’ only allows the auditor access to content for the defined ‘key period’ associated to time ‘T’. By limiting the total number of requests (e.g. to 0.1% of users), this limits the auditor’s access to communications. These controls help to ensure that the granted access to user content is time-limited and proportionate.
2. The auditor extracts the user events associated with the user at time ‘T’.
3. The auditor extracts the MIKEY messages from the signalling events and use the audited user’s KMS-supplied key material to decrypt the media encryption keys held within the MIKEY messages.
4. The auditor is now able to associate media with user events and use the media encryption keys extracted from MIKEY message to decrypt the media.