Jump to content

JSON/Leaf Syslog Formatting for remote logging


Garrett B

Recommended Posts

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.

Link to comment
Share on other sites

  • 1 year later...

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.

Link to comment
Share on other sites

  • 4 weeks later...

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 user@domain.net, 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 user@domain.net, 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

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 1 month later...
  • 3 months later...

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. 

Link to comment
Share on other sites

  • 1 month later...

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.

 

Link to comment
Share on other sites

  • 4 months later...
  • 6 months later...
  • 4 weeks later...
  • 1 month later...

+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.

Link to comment
Share on other sites

  • 2 weeks later...
  • 5 weeks later...

+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

Link to comment
Share on other sites

  • 2 months later...
  • 4 weeks later...
  • 2 weeks later...
  • 3 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...