Enhanced Threat Prevention System Query: Set a Column Profile to Match Your Log Query

[DeletedUser]

Have seen a few update fails lately, but when I looked at the pre-defined Threat Prevention System query the Column Profile didn't match what I was looking for. The fields were mostly empty...

... so created my own. Right click on the column heading and select Edit Profile.Click Save As.. .and give it an appropriate name. 

Not sure these fields are the best, but are closer to what I'm looking for. If you're not sure what to add, you can open one of the log cards and then try to match the fields shown there with the ones from the Available Fields list. Note: not all of the fields are in the Available Fields list. Have to figure that one out. Also for some reason there are 2 Description fields. By trial and error selected the one that had the most info. Click Save Changes. 

Click Queries -> Add to Favorites. Give it a nice name. Change the Columns Profile to the new one created above, then Add.

This is what it looks like in Organize Favorites.

Wouldn't say it has the information I want to see exactly now, but at least it is relevant to what I'm looking for. Now to fix my connection to the Internet. 

[Vladimir]

Thanks for sharing!

BTW: What is the deal with duplicate fields? It is the same with "Resources" and choosing a "wrong" one yields blanks.

[DeletedUser]

It's a good question. Not to throw Yonatan Philip‌ under the bus, but yeah <lol>. If anyone has an answer, would bet Yonatan does or knows someone that does. Expect it's part of a project to improve logging from different products. For instance R80.20 now includes schemas for endpoint and mobile logs. In R80.20 there's no need to manually apply a hotfix as in sk106662. 

[Yonatan_Philip]

Hi,

This isn't exactly a bug. More along the lines of... shortsightedness on the part of some developers.

The logging team creates and maintains an infrastructure that other R&D teams use when they develop features. 

In the past, we've had teams developing new features without checking to see if specific fields already exist (sometimes with slightly different names) or how their new fields integrate with existing fields. This has led to some inefficiencies and a bit of confusion. The same data uses different name conventions in different blades, etc.
in the past year+, this has been getting more focus and we do plan to address much of this in future releases (some fixes are already in R80.20, and there are a few other ongoing projects - fixing this can have a negative backwards compatibility impact so it needs to be handled with care).

To conclude - this isn't exactly a software bug, but is definitely less than ideal user experience, which will hopefully be (gradually) fixed going forwards.

HTH,

 Yonatan 

[Oren_Koren]

Hey,

what do you think on the following?

[DeletedUser]

Very nice. Is it a View that you've built? Do you have template we can import? Thanks.

[Oren_Koren]

Hey Bob,

yes - attached.

if you can send me your inputs, i can check them and update the version if needed.

https://ufile.io/7z3s7 

Thanks,

Oren