Capture Client - Remote Shell functionality (through SentinelOne)
In the light of recent supply-chain attacks, a question came up while working in the SentinelOne (native) console.
The SentinelOne Engine that comes with the CaptureClient seems to be a Control SKU (Core, Control, Complete) considering the provided functionality (Device Control, App Vulerability).
This SKU comes with a function called Remote Shell, which can be enabled on Policy level in the SentinelOne Management, which only SonicWall have access to. Therefore as CC user we don't have any control over it if it got enabled by accident or intentional.
The tricky part with Remote Shell is, that the Administrator on the SentinelOne Management can initiate direct shell access to the Endpoint, without requesting any consent. This is great for threat hunting, but raises some data privacy questions, IMHO.
What measures does SonicWall took to avoid abuse of this?
This affects SentinelOne (native) and other RMMs as well and is the topic a discussion I'am having with S1 right now.
Is it just me (as usual) or are others concered as well?
@BWC - we don't offer this feature as part of Capture Client, at this time. We are looking to offer it as part of our next release (3.7) through a new offering (along with Deep Visibility). However, it will only be available via the S1 console and will require separate login directly to the S1 console using a different user that has 2FA enabled.
As you pointed out, pretty much every RMM tool works similarly and I think we'll wait to see where the industry goes with this. We're keeping our ears to the ground.
@SuroopMC thanks for taking the time to give your view on this and provide some Information for the Road ahead.
But the main question still stands, the S1 Agent comes with the Remote Shell and can be abused either by accident or intentional.
It's more than questionable to give an administrator the ability to remote log in to a system without letting the enduser know about it, but giving this power to a third party is IMHO beyond tolerable. At the end of the day this is nothing less than a configurable backdoor.
Did you guys addressed this with S1 to see if there is a better approach for that?