Pleasant Password Server extraction improvements

[WildDogOne]

Proposed commit message

Improvements to the extraction of logfiles from the pleasant password server.
Added new proprietary pps fields for password entry information eg. username in a password entry changed (not to be confused with the username of a person who initiated the change)

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.
• I have verified that any added dashboard complies with Kibana's Dashboard good practices

Author's Checklist

I have noticed that the logfiles have a maybe important inforamtion after "changing the".
For example:

• changing the name
• changing the expiry date

I propose to extract this information.
But grok is not a good option for this since these values are very dynamic hence would make a huge list of groks for every possible case.
Maybe someone could ruby script this for me?
Or any other cool ideas?

<134>Jan 23 14:05:54 SRV-PPS-001 Pleasant Password Server:192.168.1.3 - [email protected] -  - Success - Entry Updated - User <[email protected]> updated entry <TOP/SECRET/PASSWORD> changing the name from <PASSWORD> to <PASSWORD2> changing the username from <entry_username> to <entry_username2> changing the password changing the notes changing the expiry date from <> to <2027-09-23 00:00>
<134>Jan 23 14:05:54 SRV-PPS-001 Pleasant Password Server:192.168.1.3 - [email protected] -  - Success - Entry Updated - User <[email protected]> updated entry <TOP/SECRET/PASSWORD> changing the username from <entry_username> to <entry_username2> changing the password changing the expiry date from <> to <2027-10-02 08:00>

---

There is also an error message in the build that does not seem to stem from this pull request:

2025/10/16 12:41:57  INFO Skipped errors: found 1 validation error:
   1. references found in dashboard kibana/dashboard/pps-66ae8483-4391-4554-a223-11e5c6c98653.json: pps-e1373589-225f-4d6e-8751-fc846f726b10 (search) (SVR00004)

[elasticmachine]

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

[efd6]

Can you provide a reference for the changes here?

[efd6]

Final new line.

[efd6]

Final new line.

[WildDogOne]

Can you provide a reference for the changes here?

I am not quite sure what you mean.
The changes are basically adding more extractions so that the data is more usable compared to the past :)

[efd6]

I am not quite sure what you mean.
The changes are basically adding more extractions so that the data is more usable compared to the past :)

The changes depend on an understanding of the expected layout of the data. It would be nice to have a reference for that for future maintenance.

[WildDogOne]

We have added the following fields and why:
(I hope this helps)

event.reason:
https://www.elastic.co/docs/reference/ecs/ecs-event#field-event-reason
We would like to fill this field with the reason on why an event triggered.
Before now that data was in the message field, so it was available but not really searchable.
Examples: Entry Created, Entry Duplicated, Sign-in Failed
When we talk about "Entry" in the context of the application "Pleasant Password Server" we mean a password element inside of the password server. This is quite important to understand the custom fields we added

pps.*
We added this as an object that holds all Pleasant Password Server specific fields because we where not able to find a proper mapping to ECS.
Of course if you have ideas for mapping, we are open to them since we prefer ECS to custom fields.

pps.entry.*
We added the entry object which should hold all the information about what en Entry is or what happened to an Entry. We tried to make it similar to for example the ECS field "user"
Important is that as stated before, "Entry" is the name that the Pleasant Password Server uses to describe a Password Object in the database.

pps.entry.path
We added Path so that the Path of where an Entry is situated can be extracted into it.

pps.entry.reason
We added Reason so that the reason for, for example a modification of an Entry can be extracted into it.
Reason is not often seen in logs though.

pps.entry.name
This is the name of an "Entry" that was accessed or modified, deleted etc.

pps.entry.target.name
This field is only relevant on changes to the name of an "Entry"
It is very similar to user.name and user.target.name in function.
Hence this field always comes together with the old name of an entry (pps.entry.name) and the new one.

pps.entry.username
This field is a bit difficult to understand, this is not the User who is accessing or modifying an "Entry" but the username of that password entry in the password safe.
So it will almost always differ from user.name

pps.entry.target.username
This field just like pps.entry.target.name is only relevant on changes, but this time to the username within an "Entry"

Why we didn't put all the entry information directly into pps.* is basically to anticipate that maybe in the future other fields could become important that would not mix well with the entry fields.

[efd6]

Is there a reference for the field syntax in the log lines that we are consuming?