Customer portal Licenses and support

Release uploads

FireSight staff publish releases under Admin → Releases, and visitors download them from the Downloads page, which groups them under FireSight and FireSight OT.

A release is one file. A FireSight OT version therefore usually has two releases: the Cloud Hub bundle and the Cloud Connector SD card image.

Upload by hand

Under Admin → Releases → Upload a release, choose the product, enter the version and a title, add release notes if you like, and choose the file. It arrives as a draft. Check it, then click Publish.

Upload from a build system

A build system, such as the FireSight OT release workflow on GitHub, can upload releases itself.

1. Under Admin → Releases → Upload tokens, create a token named after what will use it, for example Firesight-OT GitHub releases.
2. Copy the token. It's shown once, and the portal keeps only a hash of it.
3. Put it straight into the build system's secrets. For FireSight OT, that's the GitHub repository secret PORTAL_UPLOAD_TOKEN, entered by the repository's owner. Don't paste it into a chat, a ticket or an email.

The build system then sends:

curl -fsS -X POST https://portal.firesightsystems.com/api/admin/releases \
     -H "Authorization: Bearer $PORTAL_UPLOAD_TOKEN" \
     -F product=firesight-ot -F version=0.3.0 \
     -F "title=FireSight OT Cloud Hub" -F "notes=..." \
     -F file=@firesight-ot-hub-0.3.0.tar.gz

The answer is 201 with the release's id, size and sha256. Other answers:

If the portal is behind a reverse proxy, allow request bodies as large as the biggest release, and a long enough timeout for the upload. For nginx (including Hestia), that's client_max_body_size 4096m; and proxy_read_timeout 600s; for the portal's host name.

FireSight OT rule packs

FireSight OT's CI uploads the signed Detect rule packs with the same upload token:

POST https://portal.firesightsystems.com/api/admin/rules
Authorization: Bearer <upload token>

The portal checks the three files are there and that manifest.json names the same product and version, then answers 201. A version that's already there gets 409.

Unlike releases, a rule pack is served at once to Hubs whose license includes Detect. That's safe because CI signs every pack with a key only GitHub holds, and every Hub checks that signature; the portal stores and serves the file byte for byte. Under Admin → Rule packs, staff see each version, how many Hubs fetched it and every Hub's recent requests, and can Withdraw a version: Hubs then get the previous one.

Component lists and the vulnerability check

Each release should also upload its component list (an SBOM): the open-source packages and versions it's built from. The portal looks every package up in OSV, the open vulnerability database that gathers the CVEs with the GitHub, Go, Python, npm and Debian advisories, as soon as the list arrives and then every day. New findings are emailed to the staff admins and listed under Admin → Vulnerabilities. Only package names and versions are sent to OSV.

POST https://portal.firesightsystems.com/api/admin/components
Authorization: Bearer <upload token>

The answer is 201 with the number of packages read and the result of the first check. Uploading the same product, version and part again replaces the list and keeps staff decisions.

What to upload:

• FireSight OT Hub and Cloud Connector (Go): go version -m on each built binary. It lists the modules really compiled in, with the Go version, so Go standard library advisories are caught too. go.mod works, but misses the Go version unless it has a toolchain line.
• Cloud Connector SD card image (Raspberry Pi OS): a CycloneDX SBOM of the image's root filesystem, for example syft dir:rootfs -o cyclonedx-json, so the operating system packages (OpenSSL, the kernel tools, WireGuard and so on) are checked against the Debian advisories.
• FireSight (Python and the web front end): syft <image> -o cyclonedx-json on the Docker image covers both; otherwise backend/requirements.txt and frontend/package-lock.json as two parts.

For example, in a GitHub Actions release job:

go version -m dist/fsot-hub > hub.txt
curl -fsS -H "Authorization: Bearer $PORTAL_UPLOAD_TOKEN" \
  -F product=firesight-ot -F version="$VERSION" -F part=hub -F file=@hub.txt \
  "$PORTAL_URL/api/admin/components"

Under Admin → Vulnerabilities, a staff admin records a decision for each finding: investigating, affected: fix planned, not affected (with the reason, for example "the vulnerable function isn't used") or fixed in a release. Keep a release's lists watched while customers may still run it, and stop watching them when nobody does. Settings: PORTAL_VULN_CHECK_HOURS (24 by default; 0 = only on Check now); the portal needs outbound https to api.osv.dev.

FireSight OT software updates (Cloud Hub)

FireSight OT's CI builds each Cloud Hub update as a signed package (.fsu) and uploads it with the same token:

POST https://portal.firesightsystems.com/api/admin/ot-updates
Authorization: Bearer <upload token>

The portal checks the manifest names the same version and architecture, stores the file byte for byte as a draft, and answers 201. While a version is a draft, uploading it again replaces it; once published it can't be replaced (409): build a new version instead. If OT_UPDATE_PUBLIC_KEY (base64 Ed25519 public key) is set on the portal, the signature is checked on upload too, to catch mistakes early. Hubs check it either way, with the key built into them; the portal never signs or changes a package.

Nothing reaches a Hub until a staff administrator publishes it, under Admin → Software updates:

• Edit the title, notes (shown on the Hub and in the security e-mail), kind, security fix and channel (beta for versions such as -beta3).
• Offered to: every Hub on an older version by default. Optionally only Hubs from a version, or only a pilot list of Hub installation IDs: publish to one or two Hubs first, then empty the list to widen it to everyone.
• Publish (with a confirmation tick). For a security fix, the portal can e-mail the administrators of companies whose Hub last checked in on an older version, and their portal pages show a banner.
• Withdraw stops offering it at once: Hubs drop it on their next check, and a scheduled install of it is cancelled. Delete draft removes an unpublished version.

Who gets what: a stable Hub is offered stable releases, a beta Hub beta and stable; a hotfix for the version a Hub runs is offered whatever its channel. Hubs with a current FireSight OT license (or an evaluation Hub the portal knows) get every update; Hubs whose license has expired still get security updates. Each version shows how many Hubs were offered it, downloaded it and run it, and Hubs by version lists every Hub's last check-in: the companies to contact when a vulnerability affects a version.

Hubs without internet access: a company's administrator downloads the package from the Cloud Hub's page in the portal, and installs it in the Hub under Software updates → Install from a file.