Skip to main content

Island

Visualize Island Enterprise Browser users, their managed devices and compromised-credential findings in JupiterOne. Find users with unresolved breached credentials and devices with an end-of-life OS or no anti-malware, and monitor changes through queries and alerts.

Installation​

This integration connects to the Island Enterprise Browser management REST API (/api/external/v1) and ingests browser users, managed devices and compromised-credential findings. 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 and audit events, 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​

This field is optional and controls how much history each run collects.

FieldDefaultDescription
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

This field is a rolling window that ends at the time of each run. 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

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.

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

What the integration does not collect​

  • Audit events. Browser activity and audit logs (timeline navigation, screen-recording and login events, admin actions) are not collected. They record your employees' browsing activity, including visited URLs and locations, and JupiterOne does not ingest audit logs. The integration also never calls Island's SIEM Audits API, a queue shared with your SIEM, so events delivered to your SIEM are left 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. Device OS user names, OS domains, user names and emails are not stored.
  • Island policies. Island policies and rules are not ingested.

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​