Deployment & Security
A dedicated environment for every MSSP. Nothing shared, nothing guessed.
Prairie is a managed service, hosted and operated by BisonCyber on Google Cloud Platform. Each MSSP gets an isolated GCP project — application, database, storage, and network edge — and end-customer credentials never leave the MSSP’s own organization.
Source: Prairie Whitepaper — Security & Privacy, version 1.2, July 2026.
Security architecture
One isolated GCP project per MSSP. Nothing shared at the data layer.
The application runs on Cloud Run, Google’s managed serverless container platform, from a container image identical for every MSSP. The data layer is Cloud SQL for PostgreSQL — one database instance per MSSP — and the web interface is served from Cloud Storage, both fronted by a Global External Load Balancer with a Google-managed TLS certificate and a Cloud Armor security policy. A single shared project, prairie-platform, holds the container registry, deployment identity, and infrastructure state — and holds no customer data and no customer credentials.
Click the diagram to enlarge. Orange marks the trust boundary: the project where end-customer credentials actually live — inside the MSSP’s own GCP organization, never BisonCyber’s.
Credential ownership
Prairie never holds your customers’ SecOps or SOAR keys.
Each key is held in Secret Manager, in a dedicated project the MSSP creates and owns within its own GCP organization. BisonCyber holds no permission to read those secrets. Instead, Prairie is granted one narrow capability — the right to impersonate a single service account owned by the MSSP (roles/iam.serviceAccountTokenCreator on that account alone). That service account, not Prairie, holds the secret-access permission. Prairie assumes that identity only at the moment a credential is required, and the value is used and discarded.
What this means in practice
- The MSSP revokes BisonCyber's access entirely by removing one IAM binding, without BisonCyber's involvement.
- Every access is recorded in the MSSP's own Cloud Audit Logs, within the MSSP's organization.
- Blast radius is a single project.
Dataflow
A request follows a fixed path, authorised before any data moves.
- 1An operator authenticates against the MSSP's identity provider by OpenID Connect. Prairie never receives a password.
- 2The request arrives at the Global Load Balancer, where TLS terminates and the Cloud Armor policy is evaluated.
- 3The load balancer forwards to Cloud Run. Cloud Run ingress is restricted to the load balancer — the application cannot be reached directly from the internet.
- 4The application authorises the request against the operator's role and instance permissions before any data is read or returned.
- 5Where the request requires end-customer data, Prairie impersonates the MSSP's service account to resolve the relevant credential, then queries the customer's SecOps or SOAR tenant live. The response is transformed and returned to the browser.
- 6Configuration and operational records are read from and written to Cloud SQL over Google's Cloud SQL connector via a Unix socket. The database has no authorised public network.
Retrieved telemetry is held in the application’s memory only for the life of a short cache window (see Data retention below) and is never written to disk or database.
Tenant separation
Separation is a property of the deployment, not of application logic.
Prairie uses a separate GCP project per MSSP, which eliminates the possibility of cross-customer data access. No code path could return one MSSP’s data to another, because no other MSSP’s data is present in the environment.
Its own Cloud Run service and runtime service account
Its own Cloud SQL database instance
Its own load balancer, static IP, and Cloud Armor policy
Its own credential project, within its own organization
There is no shared database, no shared cache, and no multi-tenancy layer.
Regional deployment
Deployed in a single region, fixed at creation.
All persistent data — database, storage, credential references, and logs — stays in that region. Prairie can be deployed in any region where Google SecOps offers data residency:
| Region / multi-region | Location |
|---|---|
| United States | South Carolina, Oklahoma, Iowa |
| Europe | Belgium, Netherlands, Finland |
| northamerica-northeast2 | Toronto, Canada |
| southamerica-east1 | São Paulo, Brazil |
| europe-west2 | London, United Kingdom |
| europe-west3 | Frankfurt, Germany |
| europe-west6 | Zurich, Switzerland |
| europe-west9 | Paris, France |
| europe-west12 | Turin, Italy |
| europe-central2 | Warsaw, Poland |
| me-west1 | Tel Aviv, Israel |
| me-central1 | Doha, Qatar |
| me-central2 | Dammam, Saudi Arabia |
| africa-south1 | Johannesburg, South Africa |
| asia-south1 | Mumbai, India |
| asia-southeast1 | Singapore |
| asia-southeast2 | Jakarta, Indonesia |
| asia-east1 | Taiwan |
| asia-northeast1 | Tokyo, Japan |
| asia-northeast3 | Seoul, South Korea |
| australia-southeast1 | Sydney, Australia |
The Global Load Balancer is anycast: TLS terminates at the Google edge nearest the client, which concerns traffic in transit rather than storage.
Access control
Who can reach what, on both sides of the service.
Access to the Prairie application (MSSP users)
Users authenticate exclusively through the MSSP’s identity provider using OpenID Connect — Prairie issues no passwords and stores none. Authorisation is role-based and configurable: a user’s permissions and the set of customer environments they may access are resolved from the union of their direct grants and group memberships, established at sign-in. Predefined groups cover administrator, analyst, and read-only use. Because permissions are established at sign-in, a change takes effect on next sign-in — to revoke access immediately, the account needs to be disabled.
Administrative access to infrastructure (BisonCyber personnel)
- Single sign-on with enforced MFA. Internal access is federated through BisonCyber's identity provider; multi-factor authentication is mandatory.
- Named, least-privilege access. Production access is limited to a named group of authorised engineers, each holding only the roles their function requires — never shared or anonymous.
- Change control. Production cannot be modified without approval.
- Audit. BisonCyber's administrative actions are recorded in Google Cloud Audit Logs within the MSSP's project.
End customers’ credentials are outside this boundary — stored in the MSSP’s own organization, revocable unilaterally.
Software delivery
An automated pipeline — no manual access to production for routine deployment.
Staged promotion
Changes flow through an integration environment that mirrors production before any production release.
Federated deployment identity
Deployment authenticates through Workload Identity Federation using short-lived tokens — no long-lived deployment keys.
Production is manually gated
A deployment does not occur automatically on a code merge; each release is a deliberate, authorised action.
Forward-only, validated migrations
Schema changes are forward-only and validated by automated checks before release, against a production-like dataset.
Identical image
Every MSSP runs the same reviewed container image from the shared registry — environments differ only in configuration and data.
Infrastructure security
Hardened by managed platforms. Protected at the edge.
System hardening & patch management
The application is delivered as a container image built from a maintained base image and deployed to Cloud Run, a managed platform — Google patches the underlying host and runtime. Application images are rebuilt and redeployed on release.
Network & perimeter security
Protected by Google Cloud Armor, providing DDoS protection and WAF capability at the edge. The policy enforces the OWASP Core Rule Set 3.3, mitigating OWASP Top 10 risks — SQL injection, XSS, file inclusion, remote code execution, protocol attacks, scanner detection, and session fixation — with per-source-address rate limiting. Rules are enforced, not monitor-only; new rules ship in preview mode and are promoted after false-positive review.
Logging & monitoring
Application and infrastructure logs are generated within the MSSP’s dedicated environment and retained in the MSSP’s region (Google Cloud Logging), recording operator actions, request metadata, and system/security events. Credentials, keys, and tokens are never written to logs. Log access is limited to the same named, least-privilege personnel described under Access control.
Backup & recovery
Cloud SQL is configured with automated backups and point-in-time recovery. The recovery window is 7 days.
Data encryption
Encrypted in transit, at rest, and never stored in readable form.
In transit
The service accepts only HTTPS. TLS terminates at the load balancer using a Google-managed certificate; internal traffic between the application, the database, the credential project, and Google APIs uses Google’s TLS-protected interfaces.
At rest
All customer data hosted in GCP — Cloud SQL databases and Cloud Storage — is encrypted at rest using Google’s platform-managed AES-256 encryption.
Credentials & secrets
No credential is stored in readable form in the Prairie database — only a Secret Manager resource path. If a credential cannot be written to the MSSP’s credential project, the operation fails. Prairie never falls back to storing key material in the database.
Data retention & deletion
What Prairie stores, what it never stores, and for how long.
Data stored by Prairie
| Data | Contents | Retention |
|---|---|---|
| Operator accounts | Email address, display name, profile image reference, account status, last sign-in | While the account exists |
| Audit records | Acting user's email address, source IP address, action, outcome, affected resource | 12 months |
| Threat-hunt history | Query text, timestamps, environments queried, result counts | 90 days |
| Saved queries | Name, description, query text | Until deleted by the MSSP |
| Configuration | End-customer names and connection details | Until deleted by the MSSP |
| Automation content records | Metadata; authorship stored only as an opaque identifier | Until the item is removed |
A threat-hunt query may contain an identifier — an address, username, hostname, or IP — where the investigation concerns a specific entity. Such a query is retained as part of the MSSP’s hunt history for 90 days, within the MSSP’s dedicated environment, and deleted on that schedule. The MSSP controls what is entered; the retention window is fixed; query results are never stored.
Data explicitly not stored
| Data | Held for |
|---|---|
| Case lists and alert statistics | ≤ 20 seconds, in memory |
| Dashboards, health and status views | ≤ 5 minutes, in memory |
| Content catalogues | ≤ 10 minutes, in memory |
| Analyst names (for display) | ≤ 1 hour, in memory |
| End-customer credentials | Duration of the request, in memory |
None of the above is written to disk or database — all of it is discarded when the application instance recycles or a new version deploys. Cached entries are scoped to the requesting user’s permissions and evaluated after authorisation, never before. A threat hunt records how many results were returned, not what they were.
Data deletion
Removing an end customer deletes the dependent records in the same operation and destroys the associated credential in the MSSP’s credential project. Deletion is immediate in the live system; deleted records persist in backup media until the 7-day recovery window passes. On termination of the service agreement, the MSSP’s environment and all data within it is destroyed — the end customers’ credentials require no action, since they were never in BisonCyber’s organization.
Support & maintenance
Support is provided at support@bison-cyber.com.
BisonCyber operates and upgrades the service through the automated pipeline described above. Bug reports submitted from within the application are delivered by email to BisonCyber’s support address, and contain the reporting operator’s name and email address, the report text, and any attachments the operator includes — commonly screenshots, which may contain end-customer information. Bug reports are not stored by the application.
Privacy
Limited to what a management tool requires.
Prairie is designed so that the personal data it processes is limited to the MSSP’s own operators, an audit trail of their actions, and the queries they run. BisonCyber processes this data as a processor on the MSSP’s instruction. Security teams requiring assurance beyond this page — architecture review, control-level detail, or a completed security questionnaire — should contact info@bison-cyber.com. BisonCyber is glad to provide it under a confidentiality agreement.
Security questions
Talk to us about your security requirements.
Architecture review, a completed questionnaire, or a walkthrough with your security team — request one when you book a demo.