Security Model

How Bedrock GRC separates clients and roles, protects accounts, encrypts files and secrets, limits what the browser may do, and records what people do.

Client records in Bedrock GRC can contain sensitive material: risk registers, assessment findings, policies, evidence and, for defense suppliers, documents such as a system security plan that may contain controlled unclassified information (CUI). This page describes how the application handles that data. It describes design choices, not a certification: whether a deployment meets a given requirement depends on how it is run, as well as on the software.

Foxx Cyber hosts Bedrock GRC by default. Organizations can also run it themselves; the application behaves the same either way.

Roles and access

Four roles: admin, consultant, viewer and assessor from a partner firm. A staff account can never become an assessor account, or the reverse.
Everyone except admins reaches only the clients they are on. A consultant edits or only reads each client, as an admin sets it; viewers only read.
Only admins manage the team, the password policy, who is on each client, which firm assesses a framework, branding, single sign-on, restores and permanent deletion.
The team always keeps at least one enabled admin.

See Team and Roles.

Separating clients

Every client page first checks that you can reach that client. A client you are not on behaves as if it does not exist ("not found"), whatever its address.
Every query for client data is limited to that one client, and links between records (a risk to a goal, evidence to a control) are checked to belong to the same client.
People who only read a client get no forms that would change it, and the server refuses any change they send anyway.
Archived clients are read-only to all staff, admins included (only restoring the client, or an admin's permanent deletion, goes through), and closed to assessors.
Search covers only the live clients you can open.

Partner firms

Assessors are denied by default: they reach only an explicit list of pages, and anything else (including pages added later) is "not found".
On a client, they reach only the frameworks their firm holds and the evidence library, plus read-only context: the program documents in effect, the strategy, assets, vendors and calendar. While a firm holds a framework, only its assessors change the answers, and the framework's scope is locked.
Two firms on the same client never see each other's issued assessments or framework events.
Assessors can submit evidence but never accept it.
Assessors must always use two-step sign-in.

Automated tests walk every page and action for every role, including a second firm's assessor and staff who are not on the client, and check that nothing outside the role's reach answers or changes.

See Working as an Assessor.

The client portal

Opened only by an expiring, revocable link. Each link is shown once and stored only as a keyed hash; a passcode is optional.
Read-only, one client, and its own session that never outlives the link. Revoking the link ends that session at once.
It never shows drafts, internal notes, engagement records, the audit trail, issued assessments, or the live answers of a framework a partner firm is assessing.
A link stops working when it expires or is revoked, and when the person who made it is removed from the client or their account is disabled. Archiving a client revokes all of its links, so taking it out of the archive never brings them back. Clients archived before this rule existed had their live links revoked when it was installed. Offboarding lists the person's links and always revokes them.

See The Client Portal.

Passwords are stored as argon2id hashes and must meet the team's password policy, whose settings follow NIST SP 800-171 requirements 3.5.7 and 3.5.8. By default: at least 14 characters (admins cannot set fewer than 12), an uppercase letter, a lowercase letter, a digit and a symbol or a space, at least 4 characters changed from the current password, and none of the last 5 passwords reused. Commonly used passwords, and passwords containing the person's name, email or the firm's name, are always refused.
Every path that sets a password applies the same check: a person's own change, an invitation, and an admin's temporary password, which is also checked against the person's earlier passwords. A refusal never reveals whether a guess is one of someone's earlier passwords unless every other rule passes, and each admin's resets are rate limited and audited.
At each sign-in, the password typed is checked against the policy. One that falls short still signs in, but only as far as choosing a new password, and the account says why. A password an admin sets is temporary in the same way.
Lockout: 10 failed attempts in a row lock an account for 15 minutes, and repeated attempts from one place are slowed down. The lock holds for single sign-on as well as passwords, and a refused sign-in never ends it. A browser the person has signed in from before is not held by the lock, so someone guessing elsewhere cannot keep the owner out.
Two-step sign-in uses an authenticator app. Its secrets are encrypted, the QR code is drawn by Bedrock GRC itself, a code cannot be used twice, recovery codes are stored as hashes and are shown only for a few minutes after they are made. It is required for everyone by default. See Two-Step Sign-In.
Single sign-on (OpenID Connect) finds accounts only by the provider's issuer and the person's identifier there, never by email, and never creates an account. Each person links their own account after proving their password (and two-step code). A firm can require single sign-on for the people who have linked; admins always keep their password, and a deployment that cannot run single sign-on still keeps the rule. See Single Sign-On.
Invitations are one-time links that expire after 7 days and work only while the admin who sent them is still an admin.
Sessions end after a period without activity and a fixed time after sign-in, both set by admins, and when the browser closes. Session cookies are sent over HTTPS only and are not readable by page scripts. See Sessions.
Offboarding disables an account, ends its sessions, removes it from every client, withdraws the invitations it sent and revokes its client access links, all at once.

Files and secrets

Uploaded documents and evidence are encrypted with AES-256-GCM before they are stored, and each file is bound to its client and its SHA-256 hash. Every download is checked against that hash.
Two-step sign-in secrets and single sign-on client secrets are encrypted the same way.
Executable and script files are refused. Files are downloaded as attachments, never opened as pages in the browser.
A client backup contains the client's files decrypted, so it must be kept somewhere encrypted. Restoring one is an admin action.
Deleting a client permanently removes its records and files in one step.

In the browser

A strict Content Security Policy: pages load scripts, styles, images and fonts only from Bedrock GRC itself, run no inline script except one small theme script fixed by its hash, and can be framed by no other site. Forms can only be sent back to Bedrock GRC.
Nothing is loaded from a third party: no web fonts, analytics or content delivery networks.
Every form is protected against cross-site request forgery, and the server checks every field again whatever the browser checked. A refused form comes back with a message under each field and never fills a password or secret back in.
HTTPS is enforced on the hosted service, with HSTS.
Request logs never contain query strings, link or feed tokens, or record content.

Records of activity

Every change, sign-in, wrong password, refused two-step code, refused sign-in (single sign-on included) and file download is written to the audit log with who did it, their firm, the client, the record and the network address, but never the record's content or a password. Only attempts turned away as too many are not recorded, so a flood cannot fill the log. Admins can filter it and export it to CSV. Times are shown in the practice's time zone; the export gives them in UTC. See Audit Log.
Issued assessments cannot be edited or deleted once issued; only deleting the whole client removes them.

Reporting a problem

For security questions, or to report a vulnerability, write to support@foxxcyber.com or see the vulnerability disclosure policy.