How to ingest Windows process Command Line arguments?

[SplunkUserD]

We are about to start ingesting Windows process command line arguments. Within the Microsoft article, it states that "Command line arguments can contain sensitive or private information such as passwords or user data."

How did anyone resolve this? Did you just restrict who can open the security logs? Did you clear the security logs after a certain timeframe?

[PickleRick]

Well, it's not a splunk question as such but more like organizational security and/or compliance question. Limiting access on a need-to-know basis is always a good practice around security so I'm surprised if you're not doing it already.

[SplunkUserD]

I never stated if we are or if we are not; which we are.

The original question is asking if there is a better way to prevent access or is the stated way the recommended route?

Thank you for your response.

[PickleRick · Accepted solution]

Sorry, I might have sounded a bit too harsh which was not my intention.

Anyway, if you collect "sensitive" data you of course, let's think what we can do with it

Typical approaches to such sensitive data are:

- mask/filter - obviously not applicable here since you want to be able to read/analyze that data so you don't want to replace it with some XXXX entry because it defeats the whole purpose. But you may want - for example - to filter only some part of that command line to see what kind of command the user ran but you wouldn't see the exact arguments. But I supposed it's not what I want.

- encrypt - well, not really something you can reasonably do with splunk - you could encrypt the data on ingest (you'd need a custom scripted/modular input for that) and have some custom command to decrypt the data on the fly. Can be done but it's not a very  convenient or useable solution. And, as you keep the data in encrypted form, you can't do any form of searching or analytics on that

- limiting access - in case of splunk, the only really feasible solution is limiting access to indexes. Some user-monitoring solutions do it pretty nicely with mechanisms requiring, for example, confirmation of access to raw data, recording justification provided by the system's operator and so on but in Splunk even if you managed to create some fancy dashboard with any fancy functionality like that, the operator in the end still would have to have direct access to the undelying index and data stored there.

So from technical point of view - if you're storing that data in splunk, limiting access to index is the only really "working" solution, I think. Retention is a completely different thing - in general you should only process such data for as long as it's needed.

[SplunkUserD]

Thank you for the detailed answer, this has been very helpful!