Getting Data In

How to ingest Windows process Command Line arguments?

SplunkUserD
Engager

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?

Labels (1)
Tags (2)
0 Karma
1 Solution

PickleRick
SplunkTrust
SplunkTrust

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.

View solution in original post

0 Karma

PickleRick
SplunkTrust
SplunkTrust

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.

0 Karma

SplunkUserD
Engager

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.

0 Karma

PickleRick
SplunkTrust
SplunkTrust

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.

0 Karma

SplunkUserD
Engager

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

0 Karma
Get Updates on the Splunk Community!

Optimize Cloud Monitoring

  TECH TALKS Optimize Cloud Monitoring Tuesday, August 13, 2024  |  11:00AM–12:00PM PST   Register to ...

What's New in Splunk Cloud Platform 9.2.2403?

Hi Splunky people! We are excited to share the newest updates in Splunk Cloud Platform 9.2.2403! Analysts can ...

Stay Connected: Your Guide to July and August Tech Talks, Office Hours, and Webinars!

Dive into our sizzling summer lineup for July and August Community Office Hours and Tech Talks. Scroll down to ...