About tom_porter

tom_porter · ‎04-03-2024

This worked.......I was able to develop a data model that included the following as a constraint: NOT (TERM(proc1) OR TERM(proc2) OR ...........OR TERM(procn)) Thanks, Tom

tom_porter · ‎04-03-2024

Hhmmm......here's my dilemma. My field called proctitle has the entire command in it. One example is where I have proctitle="/bin/chmod 440 /etc/sudoers" and I want to exclude the chmod term. I have 32 such terms I need to exclude. I'll share with you that I am attempting to develop a Linux auditd detection for Account Manipulation per the Mitre Attack Framework https://attack.mitre.org/techniques/T1098/. This search will look for attempts to modify the sshd_config, passwd, groups, shadow and sudoer file. In examining existing data, I have determined there are legitimate processes (the 32 terms mentioned) in the proctitle field for the event data that will trigger this alert. (It was a tedious effort, but I traced through the parent process IDs to come justify this list.) If I eliminate these 32, my noise is 99% filtered out. Most of my terms are bounded by major breaks. The example I used is not, but if I use /bin/chmod instead of chmod, it would work. Let me try this and report back.

tom_porter · ‎04-02-2024

I have a search for which I need to tune out a large number of values (about 25) in a proctitle command field. Currently using: NOT proctitle IN ("*<proc1>*", "*<proc2>*", ......., "*<proc25>*") I'm worried about performance on the search head and am looking for ways to lower the CPU and memory burden. I have two possible solutions: 1) Create a data model and place this search as a constraint. 2) Tag events on ingest with proctitle IN ("*<proc1>*", "*<proc2>*", ......., "*<proc25>*") and use this tag as a constraint in the data model. I've played with #1. Is #2 possible, and is there a more efficient way to do this? Thanks in advance.

tom_porter · ‎12-13-2023

Yes!!! That second table. Thank you....will try out your solution later this week. Much appreciation to you all for chiming in on this.

tom_porter · ‎12-12-2023

I was trying something along the lines of dynamic field creation. At issue is that we have multiple dot notation field names with different prefixes, but a common suffix. (e.g.: file_watch.sgid and execve.sgid). There are about 40 prefixes and 50 or more suffixes. Not all prefixes have all suffixes. What I wanted to do was to create a dashboard that would show the prefixes as rows, and the suffixes as columns, with x marking cells with non-null values for prefix.suffix based on a search over the last 24 hours.

tom_porter · ‎12-08-2023

I have Linux audit records that have a field called type and fields with the naming convention lower(type).field. I want to be able to combine type, as a prefix, and a set of suffixes to create new field names that exist in the data. For example, I have a type called FILE_WATCH and fields called file_watch.exe, file_watch.egid, file_watch.comm, etc. I want to develop a dashboard table by type and suffix in Splunk to show if a particular field exists for a type. So going back to my example using type=FILE_WATCH, how can I create a new field name along these lines? base = lower(type) exe={base}.".exe" # does not work, but you get the idea. with exe now equal to the field name, I want to be able to de-reference the new field name to see if it exists.

tom_porter · ‎12-07-2023

I am working with Linux auditd events based on the auditd message and field dictionaries, that we call type and field. (You can access the github site for the .csv files that define message and fields.) For example, the macro name AUDIT_ADD_GROUP would be type=add_group and the macros name AUDIT_EXECVE would be type=execve. Now we have fields by type. SGID is the set group ID, so we could have fields called execve.sgid or add_group.sgid depending on the type value of the event. These are just 2 of more than 40 types we are tracking. Now each type will have its own set of applicable fields. For example, there would also be add_group.tty and add_group.proctitle. Is there a way to automatically lop off the prefix of a dot notation field on ingest? We need to standardize these fields to make them CIM compliant for our data model. The only alternative I see for now would be to use COALESCE to solve this problem. (e.g.: eval sgid = coalesce('group_add.sgid', 'execve.sgid')) Doing it this way would see COALESCE expressions with numerous paraeaters.

tom_porter · ‎11-06-2023

Thank you...will try it out this week. We actually have 40 unique type values (ouch), so this may take a while.

tom_porter · ‎11-05-2023

I have events that return different structured fields depending on the value of a field called TYPE. This all comes from the same sourcetype. For example: if type=TYPE1, I might have fields called: TYPE1.exe, TYPE1.comm, TYPE1.path, TYPE1.filename if type=TYPE2, I might have fields called: TYPE2.comm, TYPE2.path, TYPE2.host As you can see, each type brings a different set of base fields. We are using data model searches so I want to get these base fields into CIM compliance. Is there a way to create stanzas in props.conf or transforms.conf that will allow me to field alias these values based on the type value? I tried straight-out field aliasing in props.conf only to find I was actually overwriting values due to precedence/order of my field alias commands. Thanks in advance,

Posts	9
Solutions	1
Karma Given	2
Karma Received	0
Member Since	‎07-24-2023

Online Status	Offline
Date Last Visited	‎04-03-2024 01:59 PM

Searching a Field with Large Number of Selectors -...

Create and De-reference New Field Names

Lopping Off Dot Notation Field Names

Create Props Stanzas Based on Field Value

Re: Searching a Field with Large Number of Selecto...