JSON/Leaf Syslog Formatting for remote logging

[Garrett B]

Can the ability to have the log format of JSON (Key Value Pair)/Leaf be added to password state when setting up forwarding to a remote syslog server? This would assist with building alerting and correlation around password state activity in a SIEM. Currently the log format varies so much and it makes it difficult to extract our field such as: source user, event type, action, resource accessed.

[rookie]

Hello,

is there any progress on this topic yet?
We also need the possibility to forward the syslog messages to a SIEM in a structured way.

 

Currently there is only one ID (110) for all events and the sent text has no clear structure, which makes it cumbersome to filter out the needed information.

So far, only the description from the passwordstate audit log is sent along, which we have to edit via regex to get the desired information.

 

Best regards.

[support]

Hello,

 

Unfortunately there has been no progress on this, as there has not been any customers voting on this feature so far.

Could you be specific about the data you wish to send across, and it what format?

Thanks

Click Studios

[John Berkers]

We would like to request the same.  We have been using PasswordState for a long time (8 or 9 years?), and have added it to our SIEM for correlation.  The major issue is that the Syslog messages are far too "English" to be easily parsed with Regular Expressions.

 

Having an option to send the data in a structured, machine parsable, way would make ingestion into a SIEM much easier.  We don't really care which standard is followed, so long as it is consistent.

 

Formats typically supported by SIEMs are:

 

• LEEF
• CEF
• JSON
• Key Value Pairs (key1='value1' key2='value2' or key1: value1; key2: value2)

We would be looking for the following information in the logs (not necessarily in this order):

 

For password operations:

• Operation Performed
• Who performed it (domain\user or [email protected], display name is optional, or API)
• Client IP/hostname
• Result (Success/Fail)
• Full path to password list (group/folder structure)
• PasswordList ID
• PasswordEntry Title
• PasswordEntry ID
• PasswordEntry Username

 

For authentication events:

 

Authentication could be split across multiple logs

• Authentication against Primary Authentication Server
• Authentication against additional Authentication server (eg. MFA, token, etc)

For these we would expect

 

• Authentication Server Name
• Authentication Method (AD, LDAP, SAML, OAuth, etc)
• Auth status (success/fail)
• Auth status reason (if available) eg. account locked, account disabled, account does not exist, etc

For host operations:

 

• Operation Performed
• Who performed it (domain\user or [email protected], display name is optional, or API)
• Client IP/hostname
• Result (Success/Fail)
• Full path to host (group/folder structure)
• HostEntry ID
• HostEntry Hostname
• HostEntry Site
• HostEntry IP
• Connection Port

Some additional information may be useful, but this would be among the minimum critical information.

 

Hopefully enough people are interested in this to make it happen.

 

Regards,

JohnB

 

[support]

Thanks for the feedback John.

 

With your requirements, that would be quite a large redesign of our auditing feature, as we do not store most of this data in the Auditing table, with some of it being combined in the Description field.

 

We appreciate the feedback though.

Regards

Click Studios

[MarkusR]

We would like to request the same.
Please implement RFC conform Syslog Export following RFC https://datatracker.ietf.org/doc/html/rfc5424#section-6.2.4

[ncrand]

Just wanted to add my support for the addition of this feature. I undertand it would be a large re-design of the way logs are generated, however as others have mentioned, it's very difficult to parse these messages with RegEx in order to get useful data out of them and at least giving the option of generating the messages using a common format (like CEF or LEEF) would make things much easier from an auditing perspective. 

[kokosmasse]

Add my support to this. We are trying to send logs to SIEM to categorize and trigger alarms when certain actions happen. This is not working with todays format of the logs. 

I think this might be a major issue as SIEM and compliance is getting more important in todays threat landscape.

 

[YawnBros]

Would also like to add my support for this. For a security centric product like this, SIEM integration should be seen as essential.

[Mordecai]

+1

[Paul]

+1

[Goossens]

+1

We have also started sending PasswordState's log data to a SIEM.

 

Given PasswordState's support for sending log data to a syslog server, I assumed that the syslog standard would be followed. But, unfortunately, we observe that the data sent over TCP does not comply to RFC 6587 section 3.4, nor does it comply to RFC 5424 section 6.

 

Besides, a more structured log format would be much appreciated, using a modern standard, as described by JohnB above.

 

Thank you.

[atlas]

+1
Integration with Wazuh SIEM.
 

[Philipp]

+1

We are facing the same issue while trying to import the logs to a SIEM. A structured format would be so helpful. Parsing each syslog entry is quite exhausting 😉

Especially or as a minimum a categorization of the event similar to the Audit Log in pwdstate would be really appreciated.

 

Passwordstate belongs to the category of security relevant systems and really should offer a modern and state-of-the-art interface to other Security Tools like a SIEM.

 

Thanks

[YawnBros]

Hi, any progress on this topic as there's been an additional 10 requests for this?

[support]

Hi All, no progress has bene made on this yet, due to developing our next major build Passwordstate 10.  We hope to address it as soon as we can.

[Ben Claussen]

On 3/30/2022 at 5:24 AM, MarkusR said:

We would like to request the same.
Please implement RFC conform Syslog Export following RFC https://datatracker.ietf.org/doc/html/rfc5424#section-6.2.4

+1

[Moiz V]

+1

[Jeremiah]

+1

Even getting the same fields as the audit section of passwordstate into our SIEM would be great.