Security
A tool that can change every firewall should be hard to misuse
FireSight holds API access to your FortiManagers and FortiGates. Here is how it protects those credentials, who can do what, and how every action is recorded.
Secrets
Encrypted at rest
FortiManager and FortiGate API tokens, the LDAP service password and the OIDC client secret are encrypted with FIRESIGHT_SECRET_KEY. API tokens are never shown again after they're saved.
Or kept out of the database
Tokens can instead be read from an FMG_* environment variable. Changing a connection's address requires re-entering its token.
Backups and snapshots
FortiGate configuration backups and uploaded offline snapshots are encrypted the same way. Downloading a backup is admin-only and audited. Backup passwords are used only to open the file, never stored or logged.
Sessions and hardening
- Sessions are bearer tokens kept in
sessionStorage, so they end when the browser tab closes. - A password change, a disable or Sign out everywhere revokes every session.
- With
FIRESIGHT_ENVIRONMENT=prod(the default), the server refuses to start with the built-in development secrets. - Responses carry strict security headers and a Content-Security-Policy.
X-Forwarded-Foris only trusted fromFIRESIGHT_TRUSTED_PROXIES.- FireSight accounts use bcrypt, a password policy and lockout; session length and password length are set by admins.
- On FortiManager and FortiGate, FireSight uses a dedicated REST API admin whose trusted hosts you restrict to the FireSight server.
Sign-in
| Method | How it works |
|---|---|
| FireSight accounts | Username and password stored in FireSight (bcrypt, password policy, lockout) |
| LDAP / Active Directory | Service-account bind, user search, then a bind as the user. ldaps:// or StartTLS is required. Nested AD groups are optional |
| OpenID Connect | Authorization code flow with PKCE, state and nonce. ID tokens are verified against the provider's published keys. Works with Entra ID, Okta, Google, Keycloak and others |
| SAML 2.0 | SP-initiated. Signed assertions are verified against the IdP certificate, with checks against signature wrapping, replay, audience, recipient and time. Encrypted assertions aren't supported yet |
- Roles come from directory groups, mapped in Settings, and are re-read at every sign-in. People in no mapped group are refused unless a default role is set.
- Administrator can only be granted by an explicit group mapping.
- A directory account can never take over an existing FireSight account with the same username.
- FireSight accounts can be switched off for everyone except administrators, which keeps a break-glass way in.
- Single sign-on hands the browser back with a one-time code (single use, 60 seconds); the session token never appears in a URL.
Roles
| Role | Can |
|---|---|
| Everyone signed in | View requests, packages, findings, regions, IP addressing |
| Requester | Create, edit, submit and cancel their rule requests |
| Team lead, Security, Change board | Approve or reject the stage that needs their role (or names them) |
| Implementer | Deploy and back out, sync connections, manage regions and IP allocations, run audits |
| Auditor | Read and export the audit log, run audits; cannot change anything |
| Administrator | All of the above, plus the Settings area: connections, sign-in methods, users and roles, approval chains, policies and schedules, server status |
Separation of duties
Requesters can't approve their own rules
And they can't choose, change or avoid the approval chains their request goes to. Only administrators set up approval.
One person, one stage
Nobody can approve two stages of the same chain. Optionally, the same person can't approve in more than one chain either.
Approvers don't deploy
Anyone who approved or reviewed a rule can't deploy it. Emergency reviewers must be different people from the emergency approvers and the deployer.
Rejections stick
A rejected request must be changed before it can be resubmitted. Requests already submitted always keep the approvers they started with.
Admins can relax the first three rules in Settings, for example in a small team. Changes to settings are written to the audit log.
Audit log
An append-only record with the person and source IP for every:
- sign-in and failed sign-in;
- approval decision, push, back-out and expiry;
- sync, backup download and IP allocation;
- setting change, and offline snapshot load, replace and delete.
Scheduled work is recorded as firesight-system. The log can be filtered and exported as CSV, and auditors can read it without being able to change anything.
Simulate mode
FIRESIGHT_DEPLOY_MODE=simulate is the default. FireSight records deployment plans without writing anything to your firewalls.
Run the full flow, from request to placement, approval and deployment, against your real rule base, and read exactly what FireSight would have done. Set live once you've tested against a lab FortiManager or FortiGate.
FIRESIGHT_DEPLOY_MODE=simulate
# after testing against a lab FortiManager or FortiGate
FIRESIGHT_DEPLOY_MODE=live
Questions from your security team?
Ask us about deployment, credentials, sign-in or the audit trail. We'll answer from how FireSight works today, including what it doesn't do yet.
