FAQs
Topics on this page:
General
Data collected will only be used for protection against security threats.
Access to information is limited to authorized parties (e.g., administrators of the platform).
S1 data is stored in the cloud within their software as a service (SaaS) service in Canada.
S1 data is stored for up to 30 days at the S1 cloud service and 90 days within our Security Information and Event Management (SIEM) environment.
Your unit joined the pilot to enable advanced anti-virus protection for end users within the unit. As a unit member, you were chosen to receive this critical security protection. This is one of the steps to protect individuals against security threats.
Privacy
The University does not use S1 to watch an individual’s personal use of the University networks or devices. The University will not use this data to support investigations related to employee productivity, attendance/activity and any other general monitoring of behaviour not directly associated with security threat protection at the University.
Designated Information Security staff will interact with the data only if a security threat alert has been triggered. S1 uses artificial intelligence to analyze basic file data such as file name, size and file hashes to find potentially malicious files. Still, it does not analyze content data beyond threat detection. This is consistent with best practices to mitigate against constantly evolving cyber threats.
SentinelOne does not record keystrokes. In addition, it does not access or record the contents of:
- Documents
- Email messages
- IM/chat communications
- Login credentials (e.g. bank, ROSI, etc.)
If a security alert is triggered, SentinelOne agent (if set up in Protect mode) will automatically block the threat and quarantine any malicious files. The alert and the associated actions performed by the agent can be found on the SentinelOne user interface under threat history and quarantined files. In a few cases, when the tool is not successful at remediating the threat, designated information security staff at your unit may take further actions such as isolating the device from the network. In such cases, you will be informed by your unit’s IT team.
SentinelOne monitors all applications and files for signs of malicious activity. Data files, being inactive, are ignored unless they contain malicious code. Additionally, SentinelOne compares hashes and other markers of all files against those of known malicious files. Malicious files found on systems may be downloaded individually for further analysis, with the knowledge of the end user. These downloads are encrypted and recorded in the activity log. Search results for a specific suspicious file may also be downloaded in this manner; any file that is not part of a cybersecurity investigation is ignored.
Information collected is only used for protection against security threats. It is not used to support investigations related to employee productivity, attendance/activity and/or any other general monitoring of behaviour not directly associated with security threat protection at the University.
SentinelOne does not have access to data within your files. It can only read information about your file (metadata) such as filename, author and file path. As such, we recommend that you do not include any personal/sensitive information in the filename and other metadata for your file.
However, if a security alert is triggered, designated information security personnel may request remote access to a file that is flagged as malicious. Such access will be time-bound and will occur with your knowledge and permission. Access is limited to authorized information security staff who are required to sign a confidentiality agreement with the University as part of a formal access request and approval process.
SentinelOne does not specifically monitor users’ browser activity. However, as it looks for malicious activity, it captures information about sites and files accessed via browsers by users, devices and automated processes. Typically, majority of these records pertain to automated processes, with user activity constituting only a small fraction.
SentinelOne cannot access the virtual machines on your system unless you have specifically deployed SentinelOne agent on the virtual machine itself.
SentinelOne monitors all applications on your system for signs of malicious activity, but it cannot access those applications. It tracks the names and versions of installed applications to identify security vulnerabilities on them. In addition, SentinelOne maintains a log of activities related to services and applications running at any given time. This is needed to track progress of malicious activity and, ideally, roll back any unauthorized changes. Information about process/application activity is only used for the purposes of security threat detection and is automatically deleted in accordance with the retention policy.
SentinelOne provides remote console capabilities that allow information security personnel to use command-line prompts for accessing endpoints remotely. This capability is available to a limited number of security personnel and is solely used for cybersecurity investigations. Remote access is conducted with the knowledge and permission of the end user (for end-user devices) or IT administrators (for infrastructure assets).
SentinelOne does not collect login credentials for websites. At most, it collects URLs for websites visited by you, your device or automated processes running on your device.
The likelihood of something like this happening is very low. In 2023, there were 26,447 new vulnerabilities but only 97 zero-day exploits. It is more probable that a vulnerability on an unprotected device would be exploited, potentially leading to data loss, rather than a zero-day exploit specifically targeting SentinelOne and causing a data breach.
Technical
No. S1 is a SaaS solution and always requires access to the internet. If a machine has a virus/malware, it may be placed in “quarantine” mode depending on the policy applied against a particular set of machines.
The advice is to start with an advanced license first for managed endpoints. However, if the testing machine only deals with non-sensitive data, then a case can be made for the use of enhanced licenses.
Yes. Otherwise, it might interfere with the performance of the machine.
Yes. However, careful consideration needs to be given to how this would be paid for, deployed and supported by the different divisions. Another consideration might be privacy.
The project team will be looking at deploying endpoint detection and response to some student computer labs, which run on Windows, Mac and Linux, each having its system administrator.
Not yet. This is part of the documentation provided by professional services (i.e., the vendor).
If it’s UTORauthed, then yes, Duo is inherited.
It is web-based.
Yes, S1 supports VMware host server, but it would require a separate license.
You can watch the SentinelOne product tour.
Onboarded SentinelOne administrators can also navigate the built-in help feature.
In addition to the operating systems listed below, SentinelOne also provides dedicated agents for K8s and NetApp.
Platform | OS | Version |
---|---|---|
Windows | Windows Server Core | 2022, 2019, 2016, 2012 |
Windows | Windows Server | 2022, 2019, 2016, 2012 R2, 2012, 2008 R2 SP1 |
Windows | Windows Storage Server | 2016, 2012 R2, 2012 |
Windows | Windows 7 SP1, 8, 8.1, 10, 11 | 32/64-bit |
Windows Legacy | Windows XP | SP3 or later (KB968730), 32/64-bit NTFS/FAT32 |
Windows Legacy | Windows Server 2003 | SP2 or later, or R2 SP2 or later, (KB968730), 32/64-bit |
Windows Legacy | Windows 2008 | (Pre-R2) |
Windows Legacy | Windows Server 2008 | x64 - Only with Agent version 2.1.0.93, (KB4474419) |
Windows Legacy | Windows Embedded POSReady 2009 | |
Linux | CentOS | 8.0 - 8.4, 7.0 - 7.9, 6.4+ |
Linux | Red Hat Enterprise Linux (RHEL) | 9.0 - 9.1, 8.0 - 8.7, 7.0 - 7.9, 6.4+ |
Linux | Ubuntu | 22.04, 20.04, 19.10, 19.04, 18.04, 16.04, 14.04 |
Linux | Amazon | Amazon Linux 2, AMI 2018, AMI 2017 |
Linux | SUSE Linux Enterprise Server | 15.x, 12.x |
Linux | Debian | 11, 10, 9, 8 |
Linux | Virtuozzo | 7 |
Linux | Scientific Linux | 7.6 |
Linux | AlmaLinux | 9.0 - 9.1, 8.4 - 8.7 |
Linux | RockyLinux | 9.0 - 9.1, 8.4 - 8.7 |
Linux | Oracle | 9.0, 8.0 - 8.7, 7.0 - 7.9, 6.9 - 6.10 |
Linux | Fedora | 32 - 37, 31 (starting with kernel 5.5.x), 25 - 30 |
Linux ARM | RHEL | 9.0 - 9.1, 8.4-8.7 |
Linux ARM | Amazon Linux | 2 |
Linux ARM | Ubuntu | 22.04, 20.04, 18.04 |
Linux ARM | SUSE | 15.x |
Linux ARM | CentOS | 8.3 |
Linux ARM | Alma Linux | 9, 8.7, 8.6 |
Linux ARM | Rocky Linux | 9, 8.7, 8.6 |
Linux ARM | Debian | 11, 10 |
MacOS | Ventura | 13.0 - 13.2 |
MacOS | Monterey | 12.0 - 12.6.3 |
MacOS | Big Sur | 11.0 - 11.7.3 |
Vigilance service
Malicious alerts are considered urgent when they require security administrators’ immediate attention and action. This includes ransomware incidents, which necessitate quarantining affected devices or networks, and where manual intervention such as restoration of files, rebuilding endpoints or resetting accounts must be done.
Information Security will notify the unit through their designated incident response channel, which is commonly email. In past incidents, we have endeavored to escalate the matter efficiently, often by contacting security personnel through Teams or, in cases where only help desk information was available, by directly emailing the impacted individuals.
Only in urgent, high-priority breach cases that require aggressive action. In these cases, the vigilance analyst will disconnect machine(s) from the network to isolate the machine and prevent further spread. The analyst will first send a proactive notification, alerting Information Security of the situation and requesting immediate response.
Devices in detect mode will not be remediated or disconnected by Vigilance without approval. Vigilance will contact Information Security for permission to act on these devices. Information Security will also attempt to contact someone at the affected unit before acting.
However, as a guiding principle, Information Security will always favour protecting the environment from the spread of the incident and will act before getting permission if the threat is obviously genuine.
No, the detect vs. protect mode policies will remain, as this is part of the SentinelOne engine itself. Detection mode is only recommended at the beginning after installing the agent to capture false positives. After the initial analysis, we recommend that units activate protect mode on all devices with SentinelOne. The Vigilance service acts on significant alerts flagged by the SentinelOne agent after they review and confirm that the threat is real.
No, units won’t be able to opt out as the action feature is an on/off option for the entire institutional service.
Vigilance’s view of U of T’s data remains the same. Vigilance currently has access to the logs of deployed endpoints to conduct threat hunting and investigations as necessary; this does not change.
As Vigilance’s view of U of T’s data remains the same, there isn’t a new privacy agreement. Please refer to the existing SentinelOne privacy notice.
Last modified: November 1, 2024