Secure Endpoint API: start a scan and resolve a compromise

[Bunged]

Hello,

we've noticed a shift in the development direction of the official Secure Endpoint web interface, which is unfortunately becoming a challenge for us to work with on a daily basis. As a result, we're considering creating our own administration interface.

However, we identified two tasks for which we couldn't find corresponding API functions:

1. Initiating a flash or full scan on an endpoint
2. Navigating through 'Compromise in the Inbox' without the ability to set "Begin Work" or "Mark Resolve"

We believe these features would be extremely useful, especially in cases where AMP is integrated with a third party SIEM system.

Can you confirm whether these features are currently unavailable? If so, are there any existing workarounds or potential plans to add these missing features to your API?

We look forward to your feedback.

[Ken Stieers]

There isn't a call to start a scan. 

As far as I can tell there isn't anything in the API for the Inbox... gut feel, the inbox is really just a gui artifact built to allow humans to manage a stack of compromises. 

[m2oswald]

I was looking for the scan functionality as well.  I found this post from 2019, but seems like it's still not available.

[cbmvmr]

The closest thing I've found to initiating a manual scan is to create a policy with a really aggressive scheduled scan configuration, say hourly, then using the API calls that do exist to move endpoints in and out of the aggressive group. While not immediate, it is an indirect way to have a full scan "soon" without the chore of navigating through whatever unscheduled console UI changes have been put in overnight. Move the endpoints into the group->let the scheduled scan kick off->evaluate status->move the endpoint back to its normal group.

Cynical business brain suspects this is on purpose, to drive people to purchase more Cisco SKUs with the unfulfilled promise of cross product integration. Only, the integration never materializes.

[Ken Stieers]

No... its based on the philosophy that once the box is scanned, anytime something is moved/touched/whatever its scanned, so why should you need to scan them all?? And you have history of that scan, so if its convicted later it will get retro quarantined..


________________________________

This email is intended solely for the use of the individual to whom it is addressed and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If the reader of this email is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
If you have received this communication in error, please immediately notify us by telephone and return the original message to us at the listed email address.
Thank You.

[cbmvmr]

That may be the design assumption, but that's simply not how the product behaves 100% of the time. There are plenty of times where AMP fails to quarantine, misses things on initial scan, or fails to retro quarantine.

In the past 30 days I have 43 quarantine failed events, and 15 retro quarantine failures. Being able to automate scans through API calls and perform follow ups would be quite nice to have for these events. Administrators can initiate scans on individual endpoints through the console, and end users can initiate scans through the GUI (if enabled), so why not programatically?