You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So far caracara's excellent pagination system only exposes prevention policies and remote response policies. There are a few more (ignore the "global_config" one, it's a setting sent back by the API when querying a host policies (under "device_policies"), but there are no associated APIs, I guess that's some kind of default vendor system-wide per-OS policies or smth.
$ ls ./data/crowdstrike/policies.dev.* -1
./data/crowdstrike/policies.dev.device_control.json
./data/crowdstrike/policies.dev.firewall.json
./data/crowdstrike/policies.dev.global_config.json
./data/crowdstrike/policies.dev.prevention.json
./data/crowdstrike/policies.dev.remote_response.json
./data/crowdstrike/policies.dev.sensor_update.json
Please expose a describe_policies_raw function for all the policy types below :
It's not a critical need of ours, we worked out pagination, but not really properly, and not multithreaded. I'd like to get rid of self.enumerate_paginated_api_endpoint in our own code base , and since there is some bit of knowledge you can't really guess on the type of pagination used behind each API endpoint here I am, asking for per-policy support.
I'm a little bit reluctant to try to hook caracara.common.pagination directly our own code (that does mostly what caracara does, offer management functions over API endpoints) ; mostly because it's tightly integrated with the rest of caracara and that would mean reimplementing a half-baked in-house caracara clone that will get obsolete as soon as these few missing features are implemented.
So far my "developer experience" was enhanced by caracara since I could drop our own pagination function for a few use cases implemented in caracara, assuming pagination is done correctly on caracara's side.
Here's my shopping list on things I'd like to have enumerated through caracara ( just for reading )
All policy types ( todo ⚒️ ( missing : sensor_update, device_control, firewall )
RTRScripts & Putfiles (implemented) 🥳
Queued sessions ( warning, you're listing them using falconpy.RealTimeResponse.list_sessions not falconpy.RealTimeResponse.list_queued_sessions and they have a different schema and "pwd" as command while it's not the case, that's another issue right; RTR_ListAllSessions does list all ids but then real data for queued sessions has to be fetched from list_queued_sessions. 🙃 )
Users ( todo ⚒️)
Hosts ( implemented 🥳 )
Host groups (implemented 🥳 )
IOC ( todo ⚒️ )
IOA (implemented 🥳 )
I'll go open different issues for :
Users enumeration
IOC enumeration
I won't open an issue for the queued session thingy since I'm not comfortable with the issue diagnostic and my associated needs, so far.
Thanks for reading !
The text was updated successfully, but these errors were encountered:
So far caracara's excellent pagination system only exposes prevention policies and remote response policies. There are a few more (ignore the "global_config" one, it's a setting sent back by the API when querying a host policies (under "device_policies"), but there are no associated APIs, I guess that's some kind of default vendor system-wide per-OS policies or smth.
Please expose a
describe_policies_raw
function for all the policy types below :It's not a critical need of ours, we worked out pagination, but not really properly, and not multithreaded. I'd like to get rid of
self.enumerate_paginated_api_endpoint
in our own code base , and since there is some bit of knowledge you can't really guess on the type of pagination used behind each API endpoint here I am, asking for per-policy support.I'm a little bit reluctant to try to hook caracara.common.pagination directly our own code (that does mostly what caracara does, offer management functions over API endpoints) ; mostly because it's tightly integrated with the rest of caracara and that would mean reimplementing a half-baked in-house caracara clone that will get obsolete as soon as these few missing features are implemented.
So far my "developer experience" was enhanced by caracara since I could drop our own pagination function for a few use cases implemented in caracara, assuming pagination is done correctly on caracara's side.
Here's my shopping list on things I'd like to have enumerated through caracara ( just for reading )
falconpy.RealTimeResponse.list_sessions
notfalconpy.RealTimeResponse.list_queued_sessions
and they have a different schema and "pwd" as command while it's not the case, that's another issue right; RTR_ListAllSessions does list all ids but then real data for queued sessions has to be fetched from list_queued_sessions. 🙃 )I'll go open different issues for :
I won't open an issue for the queued session thingy since I'm not comfortable with the issue diagnostic and my associated needs, so far.
Thanks for reading !
The text was updated successfully, but these errors were encountered: