Q1. What is the problem that you are trying to solve?
Currently, I can only check audit trail of passwords which I have been granted access to. But for a full coverage of user activities for security event correlation, I need logins, logouts, permission changes, role events, and all audit trail of passwords. I don’t need the passwords themselves.
Q2 - Who is impacted?
All the company as lack of proper security of observability affects everyone.
Q3 - Why is it important and/or urgent?
It is related to the secure usage of the Passbolt itself, along with usage in highly regulated environments.
Q4 - What is your proposed solution? (optional)
As a security professional, I would like to have a specific role to access audit trails within Passbolt, preferably in a dashboard where I can quickly query. Within the same dashboard, I would like to have the ability to set up log forwarding in syslog, json or any other well known format, so that I can use any tool of my own to collect. As an alternative way, I would like to have the ability to log to /var/log/secure socket or a file like /var/log/Passbolt-Audit.log. So that the SIEM agent can collect the structured log from these and forward.
Hello and welcome to the forum @zbalkan !
I remember that in the past, in v3.12.0, they announced that you can output the action logs in syslog or a file. Maybe this can help you.
Here is the link to the release announcement, so you have to investigate a bit about how it works
The backend is in PHP, IIRC. If I knew PHP, I would try at least implementing or supporting the cause. Yet, I am not capable of it. I saw the report related process but it’s not ready yet. Also, I mentioned a “security admin” role, which allows access to audit trail but not all the passwords. It would add flexibility for managing the secrets with POLA.
I saw the SSO related prioritization. It’s also valuable whoever needs it. We are using pro version and recommending everyone since we are highly satisfied with Passbolt’s capabilities. This is still okay but we need full access to all passwords to be able to ensure we see all the activities. Which is not a good practice.
We are in finance sector and full coverage of our assets, including passwords are important for us, too. Patiently waiting for the update.
Thanks for the link. I read the link you gave me. But I couldn’t find the blog post they mentioned on how to configure this. Also, I skimmed the documentation but I may have missed that. Do you happen to have the link to the article on how to configure this?
I am interested but I am going for a vacation. I’ll get in touch when I am back. Until then, I will enable syslog and let it collect real data which I can work on. Thanks!
Please do, we were looking for admin like you who can help us shape default “strategies”. As @max mentioned the engine is there but we need to shape the data to meet real use cases
Thanks for the update. I will get in touch. I read the document and saw a couple of points.
Logs include UUID values and in SIEM context the meaningful context can be degraded without proper resolution of usernames and resources.
When somebody removes a resource, we lose the ability to resolve to the resource name. It applies to users too.
In the risk part, I saw ‘N/A’, but there is a risk of accidental leaking of sensitive data. With a well-intended commit can accidentally send passwords into the logs. And, to mitigate the risk, proper checks on QA side can be involved to prevent these kind of leaks, either with technical capabilities or human aspects like mentioning in the code review guide, etc.
I am back from vacation and open for testing the logging capabilities. As I commented above, it’s better to have the log with all the details needed without a translation/enrichment phase. So ideally, all UUIDs should be resolved to assets earlier. Then, you can just pass the whole log object as a valid JSON string. It’s preferable to have both UUID and asset name -not the action- as it provides more context.
Hi. It’s been a while. Yes, the logs in and of itself should be meaningful. UUIDs belong to Passbolt’s internals and forwarding them into logs is a leaky abstraction at best. It is meaningless for the consumer of the logs. Though UUIDs are needed for troubleshooting and name conflict prevention, the best case would be adding resource name along with UUIDs so that both parties can benefit from it. Secrets are valuable and we’d like to audit all the actions on secrets, then be able to correlate them, create them, finding anomalies, etc. That would improve the workflow a lot.
The ability to customize Passbolt to output the action logs in syslog or a file
I wonder how to customize to output to syslog or file.