Question: Plans to support Pipeline in future releases?

[datorr2]

From what I can tell, it doesn't appear that any many of the PSFalcon cmdlets support pipeline. This would made chaining commands together easier, such as taking filtered detections from Get-FalconDetection and relaying the aids to Invoke-FalconRTR or other such things.

Do you have plans on supporting Pipeline in future releases? Is it on a roadmap, perhaps?

[bk-cs]

Several of the commands do support the pipeline, signified by ValueFromPipeline and ValueFromPipelineByPropertyName parameter properties defined at the beginning of the functions.

The general issue with pipeline support is that many of the CrowdStrike Falcon APIs support multiple "ids" per request, and pipeline support by nature is dealing with single objects (e.g. single "ids"). For instance piping Get-FalconHost to Invoke-FalconHostAction would performing actions on one host per request, instead of the 100 or 500 allowed by the API--leading to potentially hundreds or thousands of unneeded requests, rate limiting and drastically slower scripts.

Whenever a particular API restricts to a single identifier, (Invoke-FalconHostGroupAction, Get-FalconUninstallToken, etc.) I added pipeline support.

[bk-cs]

Yes, that's true--PowerShell does prefer the singular, however--we're ultimately dealing with the Falcon APIs. For example, HostId and HostIds call two entirely different APIs using Start-FalconSession:

HostIds: POST /real-time-response/combined/batch-init-session/v1
HostId: POST /real-time-response/entities/sessions/v1

In general, the reason I chose to use singular and plural is because there are many cases like these, where you can submit a single identifier to perform an API call to one endpoint, and multiple identifiers to perform an API call to another endpoint.

Supporting the pipeline can be done in the case of HostId, but not in the case of HostIds, since PowerShell is ultimately going to submit one identifier a time, defeating the efficiencies provided with the batch (multi-host) Real-time Response APIs.

[datorr2]

In the case of the HostId and HostIds with RTR, would it not be easier to use the batch logic/workflow even for single hosts, as opposed to having to maintain compatibility with two different API endpoints?

[bk-cs]

Absolutely; that's why the Invoke-FalconRtr command uses the batch APIs only (as of v2.1.0).

The downside--the multi-host APIs are less resilient to poor quality network connectivity. They're also harder to use with the get command, since multi-host sessions have a specific endpoint for batch get operations.

This was my rough thought process during the development of PSFalcon:

1. Adhere to the PowerShell Best Practices and Style Guide when possible
2. The commands in PSFalcon should directly map to the endpoints published by CrowdStrike, using the public swagger documentation as a template
3. Create as few commands as possible to make it easier for users to find what command they need
4. When multiple APIs exist that could fall under the scope of a single command, use parameter sets to define which API is being used
5. Commands (e.g. cmdlets/functions listed in Public) should be as repetitive as possible, making new commands easy to add
6. The Private functions will perform most of the API interaction, with their capabilities being as simple and repetitive as possible

Over time, due to user and internal CrowdStrike requests, I added additional "special" functions that perform several API steps. These are commands like Invoke-FalconRtr, or Invoke-FalconDeploy. I also added some helper commands when I found limitations in PowerShell (or was unable to find a way to do what I wanted), to allow users to manipulate data (Export-FalconReport) or easily validate information (Test-FalconToken, Show-FalconModule). All these commands are under the Public folder, and as of the next release of PSFalcon, will be prefixed with psf- in the file name.

I'm excited that you've come up with these questions, and I can see that you're going through a lot of the same thoughts that I did in the initial development of PSFalcon. Admittedly, the module itself is not an exact fit for PowerShell based on how some of the APIs work (and don't get me started with GraphQL in the future...), but I think I've managed to find a good balance between supporting how things are "supposed to be done" both with PowerShell and the Falcon APIs.

[datorr2]

... but I think I've managed to find a good balance between supporting how things are "supposed to be done" both with PowerShell and the Falcon APIs.

No, absolutely.

I was actually thinking of developing an orchestration tool that would make it easier for non-power users or users unfamiliar with PowerShell to leverage the APIs to perform some of the actions that are not available in the current UI. I was going to develop this tool leveraging PSFalcon, but that's when all of these questions and concerns came to me.

Sample use-case / playbook:

1. Retrieve detections based on a criteria, such as a Custom IOA rule ID
2. Gather current facts about the hosts in the detections
3. Determine which hosts are most likely to be online
4. Start a batch session with all hosts that are currently online
5. Perform a short series of commands
6. Retrieve log files created by any tools that were ran in step 5
7. Determine which hosts the series of commands ran successfully, and then update all of the detections that pertain to those hosts

That's where I was thinking something along the lines of:

$Hosts = (Get-FalconDetection -Filter criteria).device.device_id |
    Get-FalconHost -Detailed # -Ids does not support pipeline input as of 2.1.4

# Do logic to filter hosts based on $_.last_seen

$FilteredHosts.device_id |
    Start-FalconSession # No pipeline for HostId or HostIds as of 2.1.4

# You get the idea...

This is more likely to be considered syntactic sugar, since the same could be achieved with:

$Detections = Get-FalconDetection -Filter criteria
$Hosts = Get-FalconHosts -Ids $Detections.device.device_id -Detailed

# Do logic to filter hosts based on $_.last_seen

$BatchId = Start-FalconSession -HostIds $FilteredHosts.device_id <other params>

Also, pipeline only improves performance if you aren't having to somehow unroll the objects in the pipeline, such as having to send a bulk amount of Ids to an API endpoint in a single call, like you mentioned.

[bk-cs]

I'm not aware of any way to "unroll the objects" in the pipeline, because as far as I understand it, PowerShell sends the objects one at a time. If it's through the pipeline, it's only going to see one value with no way to "know" that there are more coming (to "unroll").

I think the complexity of what you're doing can also be solved other ways. For instance:

• Why get the host information? Detections include the same information that is provided with a Get-FalconHost -Detailed result under the device property
• last_seen is not particularly relevant if you -QueueOffline (with a few exceptions)

$Detections = Get-FalconDetection -Filter "my_criteria" -Detailed -All
Invoke-FalconRtr ... -HostIds ($Detections.device.device_id | Group-Object).Name -QueueOffline $true

Invoke-FalconRtr ... -HostIds ((Get-FalconDetection -Filter "my_criteria" -Detailed -All).device.device_id | Group-Object).Name -QueueOffline $true

The only downside with pipelining it is that you lose out on an opportunity to add in logic to check for where your script is failing. If you explicitly call each step and filter to the data you want, you can create more explicit error messages if something breaks along the way.

[bk-cs]

From what I can tell, it doesn't appear that any many of the PSFalcon cmdlets support pipeline. This would made chaining commands together easier, such as taking filtered detections from Get-FalconDetection and relaying the aids to Invoke-FalconRTR or other such things.

Do you have plans on supporting Pipeline in future releases? Is it on a roadmap, perhaps?

The next release of PSFalcon will have full pipeline support. I'd appreciate your feedback and testing if you have the chance! You can download the current source from GitHub.