https://github.com/osquery/osquery logo
Join Slack
Powered by
Been wondering for a while - since i know osqpery ...
# general
d
Been wondering for a while - since i know osqpery is meant to be turned to what you ultimately want for it (why waste resources) - but is there a best of breed most people adopt? I am thinking the SwiftOnSecurity Sysmon XML equivalent for osquery? This the info "most" want, now have your system alert on it.
I have spent time looking at other peoples flag files, but ultimately verbose is te only flag I am really avoiding as it becomes an ingress nightmare for me. Over 200mb/hr per system.
s
Yeah 
--verbose
flag is only meant to be a debugging flag, not to keep in production
d
yea but i see it DAMN near every config i google, and then mentioned again on the alessandrogario post.. so thanks for validating its removal - feel like i must be doing 1% correct : )
s
I cannot speak for other cases but Alessandro was trying to investigate on an issue, so it's useful in that context
z
Typically you are only interested in the status logs as far as they are telling you that there is an issue generating results. This means you would typically want verbose off, as it generates orders of magnitude more status logs for the same results.
s
What everyone said. IMO verbose is for debugging 🙂
(When I notice debug oriented log noise in the info logs, I PR them to the verbose ones)
TBH I think the flags are kinda boring. I think there’s a better question around what the query schedule/configs are. And that seems very nebulous. Threat hunting is different than metrics gathering is different than security monitoring is different than compliance… Each vendor seems to have their own take. There’s space for a solid community effort here, but it’s a lot of work to maintain
d
Very good way of saying it & Thank you @seph @zwass @Stefano Bonicatti
I have been just trying to tune the ingress, get data, and forward to Splunk to decide what to alert / dashboard later.
I am going in with a mindset the query packs will get the info - but its true the agents have to be started in a way to get that info - so it might be a try for now - adjust for later as i discover the goal I am aiming for
s
The be honest, I think the packs are crap.
https://github.com/osquery/foundation/issues/28 came out of office hours and a couple of big slack threads.
d
I have been downloading and adjust them from DFIR blogs, or do you mean out of box ones specificaly, or the nature of upstream aggregation?
s
All the public packs I’m aware of (and often even queries) are not very good. Sometimes out of date. Sometimes performance impacting. Sometimes useless….
The idea of aggregation is great, tho.
d
ah ok - so use them if i need to but like you said - if i can classify my tasks and metrics, I should focus on what i know i want?
Thanks for that github post it is insightful
s
The distributed packs? I’d avoid them unless you understand and know what a query is doing.
I should focus on what i know i want
Yes, that
d
So is there a recommended reading point to start with?
s
I don’t have one. I’m sorry.
d
No worries, i appreciate it as you said, its broad and there is many directions, so I dont feel their is a specific source, but always worth asking
s
Totally.
d
@DG Alot of my scheduled queries have come from specific visibility gaps I have in my environment - This blog post covers a recent one: https://defensivedepth.com/2019/12/16/detecting-internet-exposed-services-that-shouldnt-be/
d
Thank you i also referenced this in my building docs
i know things changed but it hlped me piece the process together
d
ah ya, I need to get that updated. Will put it on the docket for this week 🙂
d
Awsome since i am still using the old MSI method, have yet to find a cpack MSI
3 Views
Open in Slack
PreviousNext
Powered by