Skip to main content

Island

Bring your Island Enterprise Browser deployment into the JupiterOne graph — browser users with their status, source and group membership, the managed devices they own with disk-encryption, anti-malware and OS end-of-life posture, compromised-credential findings tied to the user whose credential was breached, and timeline and admin-action audit events linked to the user and device that performed them. Use it to find users with unresolved breached credentials, devices running an end-of-life OS or without anti-malware, and the policy verdicts behind recent browser activity, and to monitor changes through queries and alerts. The integration reads Island's management API only: it never stores breached passwords or the breached account name, and it does not read the SIEM audit queue, so events delivered to your SIEM are left untouched.

Installation​

This integration connects to the Island Enterprise Browser management REST API (/api/external/v1) and ingests browser users, managed devices, compromised-credential findings, and timeline and admin-action audit events. Island is a SaaS platform, so the integration runs in JupiterOne's cloud and needs no collector: it calls your tenant's Island Management Console API over HTTPS, authenticating with an API key sent in the Api-Key request header.

Prerequisites​

  • An Island Enterprise Browser tenant hosted in the US or EU region, with at least one user.
  • An Island API key created in that tenant.
  • Access to JupiterOne with permission to configure integrations.

Configuration in Island​

The integration authenticates with a static API key. There is no token exchange.

To create the key, sign in to the Island Management Console as an administrator and go to Modules > Platform Settings > System Settings > Integrations > API. Click + Create, enter a Name, select a role for the key, click Generate API Key, copy the key, and click Save.

The integration only reads data. Island documents its API key roles behind the customer login, so we have not confirmed which role grants every endpoint the integration reads. Public setup guides from other vendors differ: ConductorOne's Island connector, which reads users only, uses a key with the Read-Only role, while Elastic's Island integration, which also reads devices, compromised credentials, admin actions and audits, uses Full Admin or System Admin. Choose the least-privileged role that can read every data source you plan to enable.

Whatever data sources you enable, the key must be able to list users. The integration validates the key by reading one user from /external/v1/users, and every run reads the tenant ID from the first user to create the island_account entity. A run fails if no user is returned.

Once you have the API key, proceed to JupiterOne to finish the integration.

Configuration in JupiterOne​

To install the Island integration in JupiterOne, navigate to the Integrations tab in JupiterOne and select Island. Click New Instance to begin configuring your integration.

Creating an instance requires the following:

  • The Account Name used to identify the Island account in JupiterOne. Ingested entities will have this value stored in tag.AccountName when the AccountName toggle is enabled.

  • Description to assist in identifying the integration instance, if desired.

  • Polling Interval that you feel is sufficient for your monitoring needs. You may leave this as DISABLED and manually execute the integration.

  • The Authentication fields below.

Authentication fields​

FieldRequiredDescription
API KeyYesThe Island API key created above. It is sent in the Api-Key request header.
RegionNoThe Island Management Console region of your tenant. Options are US (management.island.io) and EU (eu.management.island.io). Defaults to US.
note

Region selects the API host: https://management.island.io/api for the US and https://eu.management.island.io/api for the EU. Pick the region whose console you sign in to. Only US and EU tenants are supported. Island also runs consoles in other regions, and the integration cannot connect to a tenant hosted there.

Filters and Options​

These fields are optional and control how much history each run collects.

FieldDefaultDescription
Audit Events Since (days)7 daysHow many days of timeline and admin-action audit events to collect on each run. Options are 1, 7, 14 and 30 days. Only applies when the Island Audit Events data source is enabled.
Compromised Credentials Since (days)365 daysHow many days of compromised-credential findings to collect on each run. Options are 30, 90, 180, 365 and 730 days. Only applies when the Island Compromised Credentials data source is enabled.
caution

Both fields are rolling windows that end at the time of each run. Anything older than the window is removed from JupiterOne on the next run.

For audit events, that is the intended behavior: the graph holds only recent activity.

For compromised credentials, a credential Island reported as compromised before the window starts is removed from JupiterOne on the next run, even if it is still unresolved. That is why the default is a wide 365 days. If you need older unresolved findings to stay in JupiterOne, choose 730 days.

Click Create once all values are provided to finalize the integration.

Data Sources​

Each data source can be enabled or disabled on its own. All data sources are disabled by default, so enable the ones you want to ingest. The island_account entity is always created, whichever sources are enabled.

Data SourceDefaultDescriptionEntities Created
Island UsersDisabledIsland Enterprise Browser users: status, source, group membership and email verification. A user is active when its Island status is Subscribed.island_user
Island DevicesDisabledIsland-managed endpoints: disk encryption, anti-malware products, OS end-of-life, and Island browser, extension and Chromium versions.island_device
Island Compromised CredentialsDisabledBreached-credential findings with the breach source, impacted domain and resolution status, bounded by Compromised Credentials Since (days). A finding is open unless its status is resolved, remediated or closed.island_compromised_credential
Island Audit EventsDisabledNavigation, screen-recording, login and admin-action audit events with the policy verdict, rule reference, geography and URL web reputation, bounded by Audit Events Since (days). This is the highest-volume source.island_audit_event

Each entity is linked to the island_account entity with a HAS relationship. The relationships between data sources are built only when both sides are enabled:

  • User to device (OWNS) requires Island Users and Island Devices.
  • User to compromised credential (HAS) requires Island Users and Island Compromised Credentials. The breached account is matched against the Island user ID or email address of each user, ignoring case.
  • User to audit event (PERFORMED) requires Island Users and Island Audit Events.
  • Device to audit event (PERFORMED) requires Island Devices and Island Audit Events.

The integration does not create mapped relationships to entities from other integrations.

What the integration does not collect​

  • The SIEM audit queue. Island's SIEM Audits API is a queue shared with your SIEM: events are consumed when they are acknowledged, so reading it would take events away from your SIEM. The integration never calls it. Audit events come from the timeline and admin-actions endpoints instead, which leave your SIEM feed untouched.
  • Breached secrets and accounts. The password hash of a compromised credential and the breached username or email are never stored. The breached account is used during the run only to link the finding to its user.
  • Personal details on devices and events. Device OS user names, OS domains, user names and emails, and audit-event source and public IP addresses, user names, emails and signatures are not stored.
  • Island policies. Audit events carry the ID and name of the rule that produced the verdict, but rules are not ingested as entities.

Next steps​

Now that your integration instance has been configured, it will begin running on the polling interval you provided, populating data within JupiterOne. Continue on to our Instance management guide to learn more about working with and editing integration instances.

Additional resources​