Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Audit Log #2579

Open
evilaliv3 opened this issue May 29, 2019 · 21 comments
Open

Audit Log #2579

evilaliv3 opened this issue May 29, 2019 · 21 comments

Comments

@evilaliv3
Copy link
Member

During the life of this project many has been the requirements collected in many project that deals with an auditing log of events happened on the system or actions of users on the system and on submissions (like for example #1956).

This ticket is to track the main implementation for an audit log able to track

  • automated operations executed by the system on the system
  • actions performed by users on the system
  • actions performed by users on submissions
@evilaliv3
Copy link
Member Author

evilaliv3 commented May 30, 2019

From a preliminary analysis i consider that the starting for an AuditLog table should include the following attributes:

  • id: to give a unique id to the log entry
  • date: to give a date reference to the log entry
  • event: to log the type of the activity logged
  • user_id: to log the user_id for log entries related to an user action
  • object_id: to log the id or key of the target object of the operation (a tip id for operations on tips, a user id for operations on users, etc)
  • data: a json variable to hold additional specific variables for the specific log entry

@fpietrosanti
Copy link
Contributor

maybe i'd just change event to event_type (to be more explitcit that it doesn't contain the event but describe the type of event) and i'd add a severity-level that exist in any logging/auditing facilities (like syslog uses 7 severity levels)

@fpietrosanti
Copy link
Contributor

It has been suggested from Cybersecurity community to look also at CEF (Common Event Format) standard, that's the one used by all SIEM (Security Information and Event Management) systems, for direct integration of GlobaLeaks into the existing corporate security infrastructure.

Worth having a look at CEF data format, if achieving compatibility, is something that doesn't add burden.

@evilaliv3
Copy link
Member Author

@fpietrosanti: as for the log level I'm still evaluating if to add it or not. It is in fact a redundant implicit information already part of the event_type, but probably this redundancy could help performing a general raw audit.

I would suggest to keep the topic of this ticket specifically focused on the internal database structure and visualization in the context of the whistleblowing as topic with the typical data that need to be and specifically in relation to the software properties and open a new ticket for the topic of the integration with SIEM systems with an export of the logged informations with a coin export data format (like CEF/LEEF/Syslog). Specifically on this topic I think we should evaluate the integration of a python library able to convert from a format to an other.

@evilaliv3
Copy link
Member Author

The format of the internal event logging has been updated to be:

    id: to give a unique id to the log entry
    event_date: to give a date reference to the log entry
    event_type: to log the type of the activity logged
    event_severity: to log the type of the activity logged
    event_data: a json variable to hold additional specific information to the log entry
    user_id: to log the user_id for log entries related to an user action
    object_id: to log the id or key of the target object of the operation (a tip id for operations on tips, a user id for operations on users, etc)
    object_value: a json variable where eventually store the value of the object

@schris-dk
Copy link

Hello! I've got a request for the logging feature.
Currently reportings that are deleted from the reciepient interface are also deleted from the Audit log which I find troublesome for a couple of reasons
1: You cannot track the total number of reportings to the site (and report this to the customor)
2: You cannot prove, that you have been following the deadlines of reply regarding reception within 7 days and final reporting within 3 months. (according to the EU directive Article 16 section 1, it is required to register all reportings and also make sure, that you delete the reportings in due time. The latter is only possible to prove by having the log showing this)
Would you consider to keep all the entries in the audit log?

@evilaliv3
Copy link
Member Author

Thank you @schris-dk for the valid feedback.

Absolutely your points are valid and we would keep them into consideration for next development.

in order to keep an audit log that is 'privacy preserving' i think what we could track is:

  • an event 'NEW submission on date $date
  • an event 'OPENED' report to track the access by user $userid
  • an event CHANGE STATE from STATE-X to STATE-Y by user $userid on date $date
  • an event 'DELETE submission by userID on date $date

Do you think this would be enough? What would you add?

@creativeanalyst
Copy link

From a preliminary analysis i consider that the starting for an AuditLog table should include the following attributes:

  • id: to give a unique id to the log entry
  • date: to give a date reference to the log entry
  • event: to log the type of the activity logged
  • user_id: to log the user_id for log entries related to an user action
  • object_id: to log the id or key of the target object of the operation (a tip id for operations on tips, a user id for operations on users, etc)
  • data: a json variable to hold additional specific variables for the specific log entry

Can any audit log entry impact multiple objects?
If yes, we need to consider about recording and associating multiple object_id(s).

@schris-dk
Copy link

Hi!
Any news on adding the "persistent anonymized event log"?

@evilaliv3
Copy link
Member Author

Yes. I will update this ticket shortly as we are preparing for the release of a new stable version 4.2.0 that will be released next week and will include this.

@schris-dk
Copy link

This is fantastic news :-) Thnx for all your work :-)

@schris-dk
Copy link

Hi!
Just read the change log of v 4.2.0 - can't see any references to the "persistent anonymized event log" - was it omitted or just not mentioned?

@evilaliv3
Copy link
Member Author

Thank you @schris-dk , actually the release you saw is currently just an internal release for retesting of the major update.

We will complete the changelog before releasing.

@evilaliv3
Copy link
Member Author

Here is a list of some new audit logs that we shall consider to add:

  • Activation and deactivation of 2FA by users or administrators
  • Addition and removal of users
  • Relevant changes to contexts (additions/removal of users, changes of data retention policies)

@elbill
Copy link

elbill commented Jul 11, 2021

In addition it would be useful to add user modifications by the admin (forced password change, email change, user name change) as an admin could in this way gain access to reports.

@evilaliv3
Copy link
Member Author

Here is the exhaustive list of the list of the events currently tracked:

  • submission of a new report
  • whistleblower login
  • user login
  • access to reports
  • grant of access to reports
  • change of report status
  • revocation of access to reports
  • deletion of a report by recipients
  • reset of all reports by administrators
  • changes of passwords

@elbill
Copy link

elbill commented Sep 29, 2021

@evilaliv3 Very useful, thanks!

@schris-dk
Copy link

schris-dk commented Sep 29, 2021 via email

@evilaliv3
Copy link
Member Author

@schris-dk: on some of the previous versions, due to a software bug, the login information was incorrectly logged on the root tenant. try to see if you could find there the logings log that you are looking for.

@schris-dk
Copy link

schris-dk commented Sep 29, 2021 via email

@evilaliv3
Copy link
Member Author

The current audit log that preserve data indefinitely has been implemented in March 2021. The previous log entries were preserved for three months only as the previous feature was just a debug facility used to discover anomalies and software failures.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants