Activity Auditing - how it works
The activity auditing is designed to give information on any activity inspected by the EW
By default it will write the activity that was blocked, Every record will include the From field value to be the user that has performed the operation and the activity type (for example File sharing, Desktop sharing etc)
Which activities are registered in the auditing ?
Auditing all activities
In order to audit all activities, go to settings> Auditing and enable “Monitor all communication traffic”
Now, while working the proxy, all activities will be monitored with the following flow:
P2P
Desktop sharing , Audio and Video in P2P will create a record for each activity done
Conference (meeting & group chat )
Meeting can include both managed (Always internal) users and non managed users (external or internal)
Once a managed user joins the meeting, the engine will audit all of the combinations with existing users that are in the meeting.
The following example uses M (=UPN) as managed User and E (=UPN) as Non managed user
For example , if in the meeting there are M1,M2, E1, E2. Now, once user E3 will join, the following records will be added to the auditing:
From | To | Policy |
|---|---|---|
M1 | E3 | Pb |
M2 | E3 | Pa |
The From value always contains a managed user when auditing record Scope is Meeting and the Activity Type is Audio.
This is the users reporting the event.
In desktop sharing the From value can be both
When activity is Chat - the From value is the user writing the message . This can be a managed or non - managed user
Managed property in users table is updated by the MNTS periodically.
Currently (Nov 2020)- the system detects joining a meeting as Audio . To simplify the handling, no direction are enforced while joining a meeting . Only block all or allow all
Another example of 3 managed users joining one after the other:
At first M1 does not report as no one is in the meeting
When M2 joins , both M1 will report and M2 will report
From | To |
|---|---|
M2 | M1 |
If now M3 will join the table will appear as follow:
From | To |
|---|---|
M2 | M1 |
M3 | M1 |
M3 | M2 |
If M3 will be blocked from joining because of M1 he will appear in the To value
From | To |
|---|---|
M2 | M1 |
M1 | M3 |
M3 | M2 * |
This record will not always appear as it depends how quick was M3 removed
The system will not write additional reports of M3 as well as additional reports of M1 and M2 telling about M3 joining as they are already covered by pervious records.
When allow is reported, we only have one record per joined user.
user@nonmanaged.teams & Anonymous@anonymous.team
If meeting has only users that are non managed, and a managed anonymous user is joining, the proxy gets notification on the anonymous user joining and not information on other users.
The value of “user@nonmanaged.teams” represents the other users that we are not aware of their details. This user should only be audited if there is an anonymous in the meeting.
The anonymous user is represented with the value of “Anonymous@anonymous.team”.
These 2
The policy that will be returned is build in policy “Block Anonymous join” (only if anonymous is not allowed as set in the EW settings:
Chat and files transfer
Theses operations will not be written by proxy as they are covered by CASB API
Auditing of Governance events by TP Filter
Done directly by the filter to the DB