Integrations and alerting

Tenvara can read the EDR and antivirus consoles you already use, connected with your own console accounts. Their alerts become detections alongside the ones Tenvara's own rules find, and their agents' health shows on each device's protection. Tenvara can also act through them (isolate, scan, deal with threats, manage exclusions and deploy the agent): see EDR actions. This page covers connecting a console and how detections turn into alerts and tickets.

Supported consoles#

Defender's sensor health comes from the Tenvara agent on each device. With the Defender for Endpoint permissions consented, the machines, their isolation and tags are read from Defender too.

Defender for Endpoint permissions#

Defender for Endpoint has its own API (WindowsDefenderATP), separate from Microsoft Graph, so it needs permissions of its own:

1. On your app registration: Update the app registration on the Connection tab of Settings > Microsoft 365, or Fix it for me on the App registration tab, adds them. The registration health check names any that are missing and the features that fail without them. See App registration health and Fix it for me.
2. In each customer tenant: the tenant's Defender for Endpoint feature consents to just those permissions. It is on where the tenant's licences include Defender for Endpoint or Defender for Business. See Choosing features and consent.

Open the Microsoft Defender console on the Integrations tab to see, per tenant, why its machines are not read: Defender not set up in the tenant, a permission not granted, or Defender for Endpoint switched off for it. Tenants that need the permissions are listed under Turn on Defender for Endpoint for these tenants, with one button that turns the feature on for each of them. Through partner access it is granted straight away; otherwise you get the consent link for the tenant's administrator, or why it could not be granted. A tenant whose licences have no Defender for Endpoint or Defender for Business is counted apart ("N tenants have no Defender for Endpoint licence") and is not asked. Defender alerts keep arriving through Graph for every tenant either way.

Connecting a console#

1. Go to the Integrations tab of Settings > Security monitoring and press Connect a console.
2. Choose the Console and give it a Name.
3. Under Whose console, switch on One customer's console if it belongs to a single customer. Otherwise its sites or organisations are matched to your customers.
4. Enter the credentials (not needed for Defender).
5. Under Severities, choose how the console's severities become detection severities. High and above raise alerts by default.
6. Choose whether to Resolve the detection when the console resolves its alert (keeps both lists in step when the console is worked first), and whether to Keep its alerts as security events so they can be searched and used by rules.
7. Press Test connection, then Connect. Tenvara pulls from it straight away and then every few minutes.

Note: Tenants that were consented before SecurityAlert.Read.All was added to the app registration need consenting again before Defender alerts can be read.

Looking after a console#

The integrations list shows each console with its State, the Customers it covers, its Agents (with how many are unhealthy) and its Open detections. Click one to open it:

• Pull now reads it straight away; Change edits its settings and credentials (leave a secret blank to keep it).
• Exclusions, Deployment and Requests manage exclusions, deploy the vendor's agent and list everything asked of the console: see EDR actions.
• Sites and agents shows each site or organisation, the customer it is mapped to and which devices are expected to have its EDR agent. Change a mapping if the guess was wrong; your choice is kept. It also lists each agent with its health (for example Healthy or infected) and the Tenvara device it is matched to, by serial number then hostname. Use Change or Link to a device to fix a match.

A console whose credentials are refused raises an alert at once, and so does one that fails several pulls in a row (set under Timings and thresholds on the same tab, with how long an agent may be silent before it counts as offline); the next good pull clears it. Removing a console keeps the detections it made.

How console alerts are handled#

• Each vendor alert becomes one detection, once, with the vendor's severity mapped, the device and user it concerns, and the vendor's own words, file, process and link in the evidence. While it is open, each pull refreshes its title, subject and evidence from the vendor.
• An alert already resolved when first seen is kept as history, not a new detection.
• A console's alert and a rule's detection of the same action become one detection found by both: see Working detections. How close in time they must be is Merge a vendor alert with a rule's detection of the same action within (10 minutes by default) under Timings and thresholds.
• Microsoft Defender detections are told with what the Microsoft 365 audit log says, for example "admin.priya gave priya.shah Full Access to Marketing (shared mailbox) at 09:22", and the device is named as the agent, Intune or Entra knows it. Exchange's own housekeeping is kept at information level.
• When the vendor resolves an alert or marks it a false positive, the detection follows with a note.
• For SentinelOne, resolving the detection in Tenvara can resolve the threat in the console too, and the detection's In SentinelOne card offers the console's threat and device actions.
• Devices that should have the console's agent and do not get a protection finding, EDR agent missing. See Which devices should have the EDR agent.

Un-mapping an organisation#

An organisation in a console that is not one of your customers (a test site, a customer that left, someone else's) can be taken off the customer it was matched to. On Sites and agents, open its customer picker and choose No customer (not ours) at the top, or press the clear button on the mapped customer. Tenvara asks first and says what changes: its agents leave the customer, new alerts from it are no longer raised for the customer (open ones stay to be closed), and the customer no longer expects that EDR agent from it.

An organisation un-mapped by hand is remembered as not ours, so the next pull does not match it again by name. The list's Not ours filter shows them, and mapping one to a customer by hand clears it. Every map and un-map, by hand or automatic, is in the audit log. The same picker, with No customer (not ours), maps companies from connectors and licence sources and accounting ledger contacts.

Which devices should have the EDR agent#

Linking a console that lists agents, such as SentinelOne, does not mean every device of the customer should run it. A customer may buy EDR for its servers alone, or a product for identity protection only. So which devices should have the agent is set per organisation mapped to a customer, on Sites and agents or on the customer's Security tab under Expected EDR:

1. Press Change beside the organisation's expectation.
2. Under Expect the agent on, choose All devices, Servers (servers and virtual machines), Workstations (desktops and laptops), These device groups, or None (ITDR or other products only).
3. Optionally limit it On these operating systems (empty means every system the vendor supports).
4. Press Save. Saving confirms the expectation, and "EDR agent missing" alerts no longer expected are resolved.

Until someone confirms, each organisation has a safe default: none when it has no agents in the console, and otherwise devices like those its agents already run on. Nothing is expected of a newly linked organisation for 24 hours (Expect the EDR agent after linking, under Expected EDR on the Integrations tab of Settings > Security monitoring) or until someone confirms. Instead of an alert for every device, the first pull raises one warning per customer and console, for example "SentinelOne isn't on 14 of 31 devices: confirm what's expected". It names exactly the devices concerned, and resolves with why once the expectation is confirmed or the 24 hours are over, when each device without the agent gets its own alert instead. The two never stand together.

EDR agent missing is a warning by default: change it with How loud "EDR agent missing" is in the same place, or per customer under the customer's Settings. EDR agent unhealthy (an agent the device had is now stopped or unhealthy) stays critical. A device that should never have the agent, such as a kiosk or a lab machine, can be excepted on its protection panel with Not expected on this device and a reason: its alert resolves with that reason, and the change is audited. Expect it again undoes it. Hypervisor hosts and appliances are never expected to run it: see Device protection. Whenever an "EDR agent missing" alert resolves because the agent is no longer expected, it says why, and so does its ticket.

Which detections raise alerts#

Go to the Alerting tab of Settings > Security monitoring (administrators).

1. Under Which detections raise alerts, choose Raise an alert for: Info and above to Critical and above, or Never. The default is Medium and above. Detections below it stay on the Detections list only.
2. Choose which alert severity each detection severity raises. By default critical and high detections raise critical alerts, medium ones warnings, and low and info ones information alerts.
3. Leave High and Critical detections alert in takeover mode on (the default) so a customer you are taking over still raises alerts for its serious detections; everything else at that customer goes to its findings report.
4. Under Customers that differ, press Add a customer to give one customer its own setting (for example fewer alerts for a customer with its own security team).

Alerts go to the Alerts list, on-call, automation rules and, through your alert rules, tickets.

Turning detections into tickets#

Under How detections become tickets, Tenvara shows whether an alert rule for source Security exists. If not, one button adds the suggested rule: critical and warning security alerts open a ticket, which resolves when the detection closes. Use Alert rules (it opens Settings > Alert rules) to change which queue and who gets them.

Rules and detections#

The same page sets how the rule runner looks after itself:

• Switch a rule off after a number of failed runs in a row (5 by default), with an alert saying why, which offers Try again: see Detection rules and suppressions.
• Related detections from the last so many days, shown on each detection.
• Keep the run log for so many days.
• Notable events on the device page: which actions are listed in a device's Security block for the last 24 hours (for example logon-failed, account-created, malware-detected, log-cleared).