SecurityInsight -- Security review pack

1. Architecture

SecurityInsight turns your Microsoft security data into one ranked list of what to fix first: every asset in Defender XDR, Entra ID and Azure is profiled, merged into one configuration item (CI) per real asset, given a privilege tier, and every finding is scored by consequence, probability and the business criticality of the asset it sits on. It runs entirely in your own Azure subscription, in a resource group you choose. Invardia does not host the product, your data or its runtime.

Components (all in your subscription)

• Engine jobs -- Azure Container Apps jobs: the collections (endpoint, identity, Azure, public IP, the privilege-tier classifier), correlation (the CI build), Risk Analysis, the data sync, the connectors (vulnerability close-loop, CMDB hand-off, ServiceNow), verification and data health, asset tagging (opt-in), and the pipeline job that runs them in order every day.
• Web app -- an ASP.NET Core Container App: findings, collection views, tier board, exemptions, management views, settings, access, jobs, guards, data health.
• MCP server -- a separate Container App that answers MCP clients with the same curated read-only tools as the web app's chat, to callers that present an Entra token with a SecurityInsight app role.
• Updater job -- pulls signed releases from Invardia, builds the image inside your registry, applies the database changes, rolls the jobs and apps, verifies and rolls back.
• Azure SQL -- the Pro database (settings and their history, templates, exemptions, access, the CIs, vulnerability state, the copies of findings the web app reads) and the identity ledger (object identifiers only). Entra-only authentication, Standard tier.
• Log Analytics workspace -- the SecurityInsight tables (profiles, Risk Analysis, trend, run health), the container logs and the SQL audit.
• Key Vault -- the licence, the install key, connector secrets and optional keys (Azure OpenAI, Shodan, SMTP). Purge protection on.
• Storage account and container registry -- run logs, staging and the work queue; the image built in your subscription. Shared-key access and the registry's admin user are off.

What Invardia hosts

• invardia.com: the guided install's wizard, the standalone setup scripts, the documentation, licences, the signed update manifests and releases, and the receiver of the status reports (chapter 4). None of these is needed for the product to keep running: the engines run without any call to Invardia.
• Invardia never hosts your directory data, your findings, your database or your runtime.

Network exposure options

• The web app: from the internet behind Entra sign-in (add Conditional Access), or from your network only (internal ingress). Your choice at install. Every page except a health probe requires a signed-in user with an app role.
• The network shape is your choice at install. *Public* (the default): Entra-only public endpoints for SQL, Key Vault, storage and the registry; the SQL server admits Azure services, because a Container Apps environment without a virtual network has no fixed outbound address, and accepts Entra identities only. *Private*: the guided install builds a virtual network with private endpoints and private DNS for SQL, Key Vault, storage and the registry, turns public network access off and makes the web app internal.
• Outbound only. Nothing connects in to your environment. The engines call Microsoft Graph, Defender, Azure Resource Manager and Log Analytics, optionally your Azure OpenAI resource and Shodan, and -- the updater only -- Invardia's update and licence endpoints.

The design rules a reviewer can hold us to

• Read only towards your tenant; the one writer (asset tagging) has its own identity and writes only after you switch writing on.
• One identity per role; no secrets in settings; no identity shared between components with different jobs.
• The engine is one-way: the web app writes requests, the engine pulls and verifies them before it acts.
• Damage that does not heal is stopped before it happens (guards), and nothing leaves SecurityInsight while its own data is not healthy.

2. Identities

Every identity SecurityInsight creates or uses. No runtime identity holds a secret or a certificate. Installs made before the current naming keep their names (Azure cannot rename a managed identity); the earlier name is given in brackets.

3. Permissions with justification

Every permission, where it is held, why, and what stops working without it. The engines check their own permissions at the start of every run: a missing one is shown in Get Started > Permissions and on the run's health record with the command that fixes it, and every other part of the run goes on.

Least-privilege alternatives considered

• Defender for Endpoint Machine.ReadWrite.All on the engine -- refused: collection is read only (Machine.Read.All). Tag writes belong to asset tagging's own identity, opt-in.
• A tenant-wide Microsoft Graph Mail.Send -- refused: SecurityInsight sends from one shared mailbox with Exchange RBAC for Applications scoped to that mailbox, and the setup script removes a tenant-wide Mail.Send it finds.
• Reader at the tenant root -- not the default: the guided install defaults to one subscription; a management group or the tenant root only when you choose it.
• db_datareader / db_datawriter / db_owner on the whole database -- replaced by one custom role per component (chapter 7).
• db_securityadmin on the updater -- replaced by EXECUTE on one certificate-signed grant procedure.
• Container Apps Jobs Contributor on the web app -- replaced by Container Apps Jobs Operator on the named jobs: the web app can start a job but never change it.
• A client secret for the web app's sign-in -- replaced by a federated credential (the web app's managed identity).

4. Data

What is read

Microsoft Graph (directory, roles, PIM, identity risk, Intune device details, access reviews, alerts), Defender XDR and Defender for Endpoint (devices, advanced hunting, vulnerabilities, recommendations), Azure Resource Graph and Resource Manager (resources, Defender for Cloud assessments), your Sentinel / Defender Log Analytics workspace when named (sign-in and security logs), and optionally Shodan for your own public IP addresses. All read only (chapter 3).

What is stored, where, how long

• Log Analytics (your workspace): the profiles, Risk Analysis results, trend, run health, tag activity, container logs and the SQL audit. 90 days when setup creates the workspace; an existing workspace keeps its own retention. SecurityInsight never sets a table's retention, except the SQL audit table (at least 90 days).
• The Pro database (your subscription): settings and their history, templates and your overrides, exemptions (ended, never deleted), access mappings, the CIs, vulnerability state, the identity ledger, and the copies of findings the web app reads. Copied collections and assets no longer seen: 90 days (setting). The audit trail: forever by default, at least 13 months when you set a retention; the database refuses any other change or deletion.
• Storage (your subscription): run logs 30 days (setting), staging shards 7 days when the lifecycle rule is applied, exports until you delete them.
• Key Vault: the licence, the install key, the update state, secrets you supplied. Purge protection on.
• Azure SQL backups: Azure SQL's defaults; SecurityInsight changes none.

Encryption and residency

Everything is stored in Azure services in your subscription, in the region you chose. At rest: Azure SQL Transparent Data Encryption and storage service encryption with Microsoft-managed keys by default, or, as an option at install, customer-managed keys held in your own Key Vault. In transit: TLS on every call, HTTPS only. Storage uses Entra identities only (shared keys off); SQL uses Entra identities only.

Sent out

• To Invardia: the status reports below (on by default; SI_Telemetry_Enabled = false turns every report off), the licence request (product, version, the tenant from the identity's own token, an install id, optionally an edition and a contact address) and the update pull (the licence and the install key). Nothing else about your estate.
• To your own outputs, only those you configure: mail, ServiceNow, your CMDB, your SQL targets, Excel and JSON files in your storage.
• To Azure OpenAI, only when you switch AI on, to your own resource.
• To Shodan, only when you switch it on: your own public IP addresses.

Deletion on uninstall

Delete the resource group: every resource, the database and the data in them go with it (a Key Vault is kept soft-deleted for its retention days, then purged by Azure). The workspace keeps data you sent to an existing workspace until its retention ends. See chapter 10.

5. Access by the vendor

Invardia (the vendor) can reach your install only through the Invardia Support app: an app registration you create in your own tenant with Invardia's published script, at the level you choose. Without it Invardia has no access. Most installs never create it: SecurityInsight updates and repairs itself without contact.

The levels

• Troubleshoot -- read only: read-only Microsoft Graph permissions; Reader and Log Analytics Reader on SecurityInsight's resource group; Key Vault Reader (metadata, never a secret value); a read-only database role (database admin only just in time, during a support session you asked for).
• Setup -- runs SecurityInsight's setup scripts to install, repair and upgrade: Contributor on SecurityInsight's resource group with role assignment limited to the roles SecurityInsight's own identities use (to service principals only); Key Vault Secrets Officer; a read-only database role, with database admin only just in time (at most 8 hours, at most this level); the Graph permissions the setup scripts need.

The exact permission list per level is on the documentation page of Invardia's script: https://invardia.com/docs/invardia/scripts/New-InvardiaSupportApp/.

When it is used

Only when you ask for help, and for release spot checks on rings 0-2 (read only, counts only, only while your environment's switch "release spot checks allowed" is on -- on by default for rings 0-2; chapter 6).

How it is controlled and audited

• Its client secret is stored at Invardia. In Invardia's customer portal you set it Enabled or Disabled, its lifetime (1-730 days) and its renewal: Automatic (default on rings 0-2), Approval required (default on ring 3) or Off. Automatic renewal adds a new secret, proves a sign-in with it and only then removes the old one. A secret with a lifetime under 7 days is never renewed. A disabled or removed app is never renewed.
• A Conditional Access policy for this app only, blocking its sign-in from anywhere but Invardia's support address, is created with it -- switched off, for you to switch on.
• Every support session starts with a recorded reason or ticket. Every SQL statement goes through Invardia's audited call: the audit row (server, database, the statement's SHA-256, the purpose) is written before it runs. Every Azure call goes through the session's recording commands. You see them in your activity log at Invardia; the SQL audit also lands in your own workspace.
• Changes to an install are made only with SecurityInsight's published scripts, each with a plan first and a rollback record (chapter 11).

How you remove it

Grant-SISupportAccess -Remove takes SecurityInsight's part away (Key Vault role, the database user and consent, any group membership or ownership left from an earlier release); disable or remove the app in the customer portal, or delete the app registration in Entra ID.

What the vendor cannot do

Reach your install without the app; read a secret value at the Troubleshoot level; use the engine identity; change SecurityInsight's code outside a signed release; keep what it read during a spot check (counts and verdicts only).

6. Supply chain

Signed releases

• The vendor publishes each release to Invardia; Invardia signs, per update ring, a manifest that names the release and its SHA-256 (RS256).
• Your updater accepts a manifest only when its signature verifies against Invardia's update-signing public keys that ship inside SecurityInsight (a key list fetched over the network is never trusted on its own; keys are rotated by shipping old and new side by side), the product, the kind and your ring match, its sequence is not lower than the one applied, and the download's size and SHA-256 match. A failed check applies nothing.
• The image is built inside your own registry from the verified source. No prebuilt image is shipped. A failed roll goes back to the previous image.

Rings, waves and approval

• Rings 0 Dev, 1 Test, 2 Design partners, 3 Broad, in that order. SecurityInsight decides which version goes to which ring.
• A release to rings 2 and 3, and every early-release wave, needs the APPROVED state, set only by the vendor's release owner, with a reason, recorded; Invardia refuses the release without it. A setup-only release (no engine code) is the exception, shown and logged on the release.
• A version is not promoted while an install that took it turned Unhealthy (data health, chapter 7) or stopped reporting for 48 hours.
• After a release that changed engine code: 24 hours of halved safety-check limits, 12 hours of 30-minute counts to Invardia, and every changed component is Testing until 3 good daily runs.

Who can release

Only the vendor, signed in to Invardia as its publisher application with a certificate; ring 2 and 3 releases additionally need the release owner's APPROVED. Invardia relays and signs; it does not change the content.

How you pin or delay updates

Stay on ring 3 (the default) to take releases last; a release that needs a manual step is held until you accept it on the updater job; template packs that would change templates in force wait for an Admin's release, per detection method; *Pro updates from Invardia* can be switched off.

Source availability and dependencies

• The source of each release is delivered to your install (the image is built from it in your registry) and can be read there.
• No PowerShell modules and no Azure CLI in anything that ships: Azure, Graph, SQL and Log Analytics are called over REST with SecurityInsight's own code. The web app and MCP server are .NET, built in your registry.
• A software bill of materials (SBOM) comes with every signed release, so you can check every component and dependency it contains.
• Every script is listed with its SHA-256 in SHA256SUMS.txt (chapter 11).

7. Change control and audit

In the web app

• Tier moves, documents (exclusions, weights, rules) and settings are staged and written only on Review & commit, each in one transaction with an audit row. Nothing is deleted; an exemption is ended.
• Governed exemptions: owners and approvers per security domain and per department, request -> approve / reject with a comment, standard periods, a monthly owner review, mail.
• Signed requests: a decision that leads to a change outside SecurityInsight (connector settings, exemptions, asset tagging, data-out decisions) carries the signed Entra token of the person who made it and of the approver; the engine verifies signature, issuer, audience, lifetime, user and role before it acts, and refuses what it cannot verify.
• A change a job carries out names the person who asked for it and the approver, under one correlation id from the web request to the job's rows.

The audit trail

• cfg.AuditEvent and cfg.ChangeLog refuse UPDATE and DELETE to every database user (a DENY to public, enforced by the database). No runtime identity holds DDL or ownership, so it binds all of them. The one way rows leave is the retention procedure (never younger than 13 months, recorded).
• SQL auditing of the server to your Log Analytics workspace, 90 days.
• Run health of every engine run, container logs and run transcripts in your workspace and storage.

Guards (safety checks)

• On by default: the CI retire brake (a run or hand-off batch is held when far more CIs would disappear than allowed; a CI retires only after 7 days unseen), the duplicates brake (a connector that could read its target only in part writes nothing), the asset-drop check, and two review checks. Every other check can be switched on.
• Integrity stops are not switchable: a database change that could remove data, a failed database update, a collection that could not be read in full.
• Guard modes: for 24 hours after a release that changed engine code, every numbered limit is halved from the configured value; a SuperAdmin may end it early with a recorded reason.
• Every event is written in plain words (what happened, why, consequence, what to do), mailed at most once a day while it repeats, shown on Operations > Guards and reported to Invardia.

Data health

Every day SecurityInsight samples 10 % (at least 50) of each source's records at random, asks the source again and compares. After three anomalous days the data is Unhealthy and every data-out channel is held (vulnerability closes, CMDB hand-off, ServiceNow, tagging, outputs) until one good cycle; a SuperAdmin can let one channel through with a recorded reason until the data is healthy again.

Undo and backup

Nothing is deleted in the web app; template releases can be rolled back per detection method; every cut-over script writes a rollback record; Azure SQL keeps its point-in-time backups (Azure defaults).

One deviation report

Every override, exemption, exclusion, disabled detection, tier move and changed setting with its owner, reason and expiry.

8. Threat model and hardening

The top risks of running SecurityInsight, the control for each, and the residual risk with the choice you have. Then a hardening checklist you can apply.

9. Compliance mapping

How SecurityInsight supports your own controls. This is support for your controls, not a certification: SecurityInsight and Invardia do not hold ISO 27001, SOC 2 or similar certification for the product.

10. Uninstall and exit

Remove everything SecurityInsight created

1. If you created the Invardia Support app: run Grant-SISupportAccess -Remove, then remove the app with Invardia's script (-Action Remove) or delete it in Entra ID.
2. Delete the SecurityInsight resource group. This removes the jobs, the web app, the MCP server, the updater, the identities, the registry, the storage account, the database server with both databases, the Key Vault (kept soft-deleted for its retention days, 90 by default, then purged by Azure -- purge protection prevents an earlier purge) and a workspace setup created.
3. Remove the role assignments SecurityInsight's identities had outside the resource group (Reader where it collected, Log Analytics Reader on your Sentinel workspace) -- Azure removes assignments of a deleted identity's principal, but lists them as unknown until then.
4. Delete the enterprise applications' API permissions (they go with the deleted managed identities) and the sign-in app registration *SecurityInsight*.
5. Delete the SQL admin group grp-si-sql-admins.
6. If SecurityInsight sent mail from a shared mailbox: remove the Exchange management scope and role assignment, and the mailbox if it was created for SecurityInsight.
7. If asset tagging wrote tags: they stay on your devices, resources and identities (they are yours); remove them if you want.

What remains

Data SecurityInsight wrote to an existing Log Analytics workspace stays until that workspace's retention removes it. Tickets, CMDB records and files SecurityInsight handed to your systems stay there. Invardia keeps your licence and the status reports it received under its own retention; nothing of your directory or findings.

11. Scripts

Scripts are run by highly privileged people, so every script a person runs follows the same rules:

• A documentation page per script at https://invardia.com/docs/si/scripts/<Script>/: purpose, when to run it, the rights it needs, every change it makes (create / update / grant / remove, the object, the permission and scope, why, how to undo it), its parameters, what it only reads, every host it calls, what its preview shows, how to undo the whole script, its version and SHA-256. The page shows the manifest only while it matches the published script exactly.
• Preview first: every script supports -WhatIf or plans by default; under a preview it reads and prints what it WOULD change and writes nothing. The product's tests run every script this way with every outside call replaced and fail on any write.
• A transcript of every run on the machine it ran on (no secret is ever printed or written); the last line printed is its path.
• No second download: a standalone script carries everything it runs, each part checked against its SHA-256; nothing is fetched and executed at run time.
• Save, then run -- never pipe into PowerShell. Every command shown is two lines: download the file, run it. Verification is described next to the block.
• No secrets in, no secrets out: browser sign-in or a managed identity; secret parameters are secure strings or Key Vault secret names.
• Listed: every published script is listed with its SHA-256 in SHA256SUMS.txt next to it. Compare the file with that list before you run it; the documentation page shows how.
• Cut-over scripts for existing installs (Set-SISecurityBaseline, Move-SIEngineToLeastPrivilege, Install-SIGrantProcedure) run only inside a recorded Invardia support session, send every SQL statement through Invardia's audited call, write a rollback record, add before they remove, and remove broad rights only in a second, later run after a green pipeline.

Published scripts and their checksums

Every SecurityInsight script Invardia publishes at invardia.com/support/si/, with its documentation page (what it does, the rights it needs, every change it makes, -WhatIf and undo) and the SHA-256 of the exact published file, computed when this page was built.

Always check the SHA-256 before you run a script.

Download, read, run

Never pipe a script into Invoke-Expression. Download it to a file (line 1), read it, preview with -WhatIf (line 2), then run the same line without -WhatIf:

Invoke-WebRequest https://invardia.com/support/si/<Script>.ps1 -OutFile <Script>.ps1
.\<Script>.ps1 -WhatIf

To check a download, compare its SHA-256 (Get-FileHash) with the publishedSHA256SUMS.txt or the table above.

Each script's page shows these commands with its own name. All scripts: SecurityInsight scripts · Every setting explained: SecurityInsight settings