Cloud and SaaS activity stops being a blind spot
Audit and sign-in activity from the services you rely on is collected in the same place as everything else.
- SOC 2 Readiness
- 24/7 Security Monitoring
- Canadian-Based SOC
GuardsArm Platform · Detect
Cloud & SaaS Connectors
Bring cloud, identity and SaaS audit activity into the same detection pipeline as your endpoints.
An attacker who signs in with a valid account leaves no trace on a server. The evidence is in the audit logs of the services that account can reach. The connectors poll those services and land their activity in the platform as normalised events.
- AWS, Azure, Google Cloud
- Microsoft 365, Okta, GitHub
- Status per provider
Cloud & SaaS Connectors
Monitoring- AWS, Microsoft Azure, Google CloudCloud
- Microsoft 365, Google WorkspaceProductivity
- Okta, Microsoft Entra IDIdentity
- GitHubCode
One pipeline for cloud, identity, endpoint and network activity.
What is at stake
The accounts with the most access live in services you cannot install an agent on.
One investigation instead of seven consoles
An analyst follows an account across providers from one search, without signing in to each service to export logs.
Broken collection is visible
Status per provider means a connector that has gone quiet is noticed before the gap matters.
Who carries this
Carried by the security lead, with the cloud and identity administrators who own each provider.
The problem
Half of your environment is not on a machine you can install an agent on
Identity providers, cloud control planes, code hosting and office suites hold the accounts and the data attackers want, and none of them can run an endpoint agent. What they do have is audit logs: who signed in, from where, and what they changed.
Those logs are only useful when they sit next to everything else. A sign-in from a new country means little by itself. The same sign-in followed by a new access key and an unusual process on a server is an intrusion.
The connectors bring that activity into the platform as normalised events, so cloud and SaaS activity is searched, correlated and reported on with the same tools as endpoint and network data.
A valid login is invisible on the endpoint. It is written down in the audit log.
Capabilities
What the connectors do
Seven providers in the console
AWS (CloudTrail, GuardDuty, IAM), Microsoft Azure (activity logs, Entra ID sign-ins), Google Cloud (audit logs, IAM), Microsoft 365 (audit, sign-ins, mail), Google Workspace (admin and login audit), GitHub (organization audit log, access) and Okta (identity, SSO, MFA).
Ingestion status per provider
Each provider shows its own status, read from the events actually arriving, so a connector that has gone quiet is visible instead of assumed healthy.
Set up and managed in one place
Connectors are added and managed from a single Integrations Center, so onboarding a new service does not mean a new tool.
The same sources identity and email detection use
ITDR has provider connectors for Microsoft Entra ID, Okta, Google Workspace, Active Directory, GitHub and Microsoft 365, and Email Security connects to Microsoft 365, so identity and mail detection work from audit and sign-in data.
How it fits the platform
Connector events are normalised like every other source. A cloud sign-in, an endpoint process and a firewall record can be searched, correlated and reported on together.
How it works
From a connector to a correlated incident
What happens after a provider is connected.
Add the connector
A connector is created for the service in the Integrations Center.
The connector polls
Audit, sign-in and admin activity is collected from the provider on a schedule.
Events are normalised
Activity lands as events with the same fields as every other source: user, address, action and category.
Status is reported per provider
The provider page shows whether events are arriving, so a broken connector is found from the console and not from a missed alert.
Detections and correlation apply
Detection applies to these events like any other source, and correlation can join them to endpoint activity in the same incident.
Questions
Common questions
Which services can be connected?
The console lists AWS, Microsoft Azure, Google Cloud, Microsoft 365, Google Workspace, GitHub and Okta, each with the data it brings, such as CloudTrail and GuardDuty for AWS or audit and sign-ins for Microsoft 365.
How do we know a connector is still working?
Each provider page shows ingestion status based on the events arriving for that provider, so a connector that has stopped delivering is visible in the console.
Works with
The modules next to this one
Every module runs in the same self-hosted stack and shares the same telemetry, severity model and response engine.
ITDR — Identity Threat Detection & Response
Detect identity-based attacks across your directories and cloud identities.
ExploreEmail Security
Detect account takeover, mailbox exfiltration and phishing in Microsoft 365, and respond with approval.
ExploreSIEM & Log Analytics
Collect, normalise and search security events from your entire environment — on infrastructure you control.
ExploreSee Cloud & SaaS Connectors running on your own infrastructure
We will walk through the console, the deployment model and what it takes to stand it up in your environment.
24/7 SOC Monitoring Available