TRUST CENTER · CONTROL SUMMARY 1.2
Clear commitments and explicit evidence boundaries.
The Trust Center maps public service statements to implemented controls and observable evidence. It distinguishes operating targets from measured results and avoids claiming provider affiliation, independent certification, or audit coverage that has not been established.
Authentication, MFA, server sessions, role enforcement, request IDs, structured errors, health endpoints, audit persistence, documented policies, and release recovery are implemented and directly testable.
1. Service commitments
| Area | Commitment | Current evidence |
|---|---|---|
| Availability | 99.95% monthly objective for the interactive control plane | Public origin health, API health, status endpoint, service supervision |
| Authentication | Assigned credentials and MFA for privileged roles | Password and MFA endpoints, session records, authentication audit |
| Authorization | Server-side role enforcement for every authenticated mutation | Read-only API denials, CSRF validation, action outcomes |
| Traceability | Consequential control operations receive a request ID and audit event | Structured responses, audit table, authenticated CSV export |
| Privacy | No advertising or behavioral analytics on sign-in and control surfaces | Content Security Policy, static application dependencies, Privacy Notice |
| Disclosure | Published security reporting procedure | Security Center and RFC 9116 security.txt |
| Recovery | Recoverable application and database release process | Consistent SQLite backup, application archive, post-release verification |
An objective is a service target. Historical attainment is published only when an adequate measurement period and source are available. A green status indicator describes current observed state and is not, by itself, evidence of historical availability.
2. Control matrix
| ID | Control objective | Implementation | Evidence class |
|---|---|---|---|
| IAM-01 | Credentials are not stored in plaintext | Salted PBKDF2-HMAC-SHA-256 digests | Configuration and verification behavior |
| IAM-02 | Privileged access requires a second factor | Short-lived MFA challenge before session creation | Authentication outcome audit |
| SES-01 | Session tokens resist browser disclosure | Secure, HttpOnly, SameSite=Strict opaque cookie | Response headers and session schema |
| APP-01 | State changes are same-origin and session bound | Origin allowlist and CSRF token validation | Structured denial and accepted request records |
| RBAC-01 | Observation is separated from mutation | Server-enforced read-only role | 403 response and denial audit |
| AUD-01 | Consequential activity is attributable | Actor, action, resource, outcome, time, request ID | Audit API and export |
| NET-01 | Application services are not directly public | Loopback API and origin listeners | Listener inventory and architecture record |
| REL-01 | Releases are validated and recoverable | Build tests, consistent backup, health and invariant checks | Release notes and backup manifest |
| PRV-01 | Operational data is minimized | One-way source digest, no secret display, no tracking tags | Database schema, CSP, Privacy Notice |
3. Evidence model
NBS classifies evidence so that readers can understand the strength and scope of a statement.
Evidence is time-bound. A configuration verified at release does not guarantee that it has never changed; recurring checks and change records provide continuity between release points.
4. Shared responsibility
| NBS service responsibility | Assigned user responsibility |
|---|---|
| Authenticate identities and enforce resolved roles | Protect assigned credentials and complete MFA only for intended sessions |
| Validate, persist, and audit control-plane operations | Submit accurate scope, owner, region, retention, and change information |
| Publish current controls, policy, status, and release information | Review applicable policy before handling exports or approving changes |
| Protect session and secret material from browser disclosure | Use managed devices, sign out when access is no longer needed, and report suspected compromise |
| Maintain release backup and service health validation | Do not treat a control-plane acknowledgement as proof of data-plane completion |
Third-party provider controls remain governed by the applicable provider account and agreement. A connector registration does not transfer provider administration into the NBS console.
5. Continuity and recovery
Each application publication is preceded by a consistent control database backup and an archive of the previous application and origin configuration. The deployment process verifies the API health endpoint before reloading the HTTPS origin.
Post-release checks cover application and Nginx service state, public and local health responses, transport listener ownership, private application bindings, gateway service unit hashes, network interface state, and canonical firewall and NAT rules. A failure in the release path triggers restoration of the previous origin configuration.
| Recovery asset | Purpose | Validation |
|---|---|---|
| SQLite backup | Restore sessions, audit, resource, settings, and recovery records | Created through the database backup interface |
| Application archive | Restore compiled frontend and Control API | Release checksum and health check |
| Origin configuration | Restore proxy routes, headers, and static root | Nginx configuration test before reload |
| Network invariant record | Confirm release did not alter existing public transports | Listener, interface, unit hash, and rule comparison |
6. Certifications, providers, and limitations
NBS does not currently claim SOC 1, SOC 2, ISO 27001, PCI DSS, HIPAA, FedRAMP, CSA STAR, or another independent certification. It does not claim that its public documentation has been audited by a named accounting or certification body.
References to Oracle Cloud Infrastructure, Sentry, OpenTelemetry, Redpanda, or other products describe connector categories or link to public technical documentation. They do not state ownership, sponsorship, partnership, certification, or endorsement.
Product names, endpoint aliases, status labels, and documentation links are not substitutes for a provider agreement, tenant evidence, penetration test, certification report, or independent audit.
The published control set is limited to the NBS web control plane and its deployment boundary. It does not attest to the security of user-managed devices, external provider accounts, regional payload content, or systems outside the described architecture.
7. Control review process
The control summary is reviewed quarterly and after a material change to authentication, authorization, persistence, public exposure, network topology, retention, or third-party processing. Review compares documented statements with current code, configuration, API behavior, and release evidence.
- Confirm service inventory and trust boundaries.
- Test authentication, session, recovery, role, and error behavior.
- Inspect security headers, listener scope, and proxy routing.
- Reconcile database schema, retention statements, and audit fields.
- Review change history, backup evidence, and known limitations.
- Publish corrections when a statement is incomplete or no longer accurate.
Material changes are recorded in the Changelog. Security control changes also update the revision history in the Security Center.