SECURITY CENTER · CONTROL BASELINE 1.2
Security at identity, request, and change boundaries.
NBS applies defense in depth to the interactive control plane: assigned identities, server-side credential verification, multi-factor challenges for privileged roles, opaque sessions, request validation, authorization, hardened response policy, private service bindings, and persistent action auditing.
This page describes implemented service controls and operating commitments. It does not represent a third-party certification, independent audit opinion, or affiliation with a named infrastructure provider.
1. Program scope
The security baseline covers the public HTTPS entry point, authentication and recovery endpoints, authenticated console, Control API, local application service, SQLite control records, Nginx origin, public documentation, and the operational process used to publish changes. Regional storage workers and provider-managed infrastructure remain separate control domains.
Security decisions follow four principles: minimize exposed services, enforce identity on the server, record consequential actions, and avoid presenting unverified controls as evidence. Browser behavior is never the sole authorization boundary.
Least exposed surface
The application API and HTTPS origin bind to loopback interfaces. The control API is not directly reachable on a public application port.
Server-side authority
Identity, session, CSRF, origin, and role decisions are enforced before an operation enters the audit store.
Traceable change
Authenticated mutations produce a request identifier and an audit record containing actor, action, resource, and outcome.
Explicit evidence
Published trust material distinguishes current implementation, operating target, and evidence limitation.
2. Identity and authentication
Credential verification
Passwords are verified using PBKDF2-HMAC-SHA-256 with a unique random salt and a work factor of 210,000 iterations. Plaintext credentials are not stored in the browser bundle, session database, or audit records. Verification uses constant-time digest comparison.
Multi-factor challenge
Privileged identities require a second verification factor after the password succeeds. Challenges are random, short-lived, associated with the initiating source digest, and limited to five attempts. A successful challenge is removed before the session is issued.
Authentication rate control
Password and MFA endpoints apply bounded attempt windows keyed by a one-way source-address digest. Excess attempts receive a structured 429 response. Rate control reduces online guessing risk without placing clear source addresses into the audit table.
Recovery enumeration resistance
Account recovery produces a tracked case reference and does not reveal whether the submitted username exists. Requests are rate limited independently of sign-in attempts. Completion requires the pre-established support path for that identity.
| Control | Implementation | Failure behavior |
|---|---|---|
| Password storage | Salted PBKDF2-HMAC-SHA-256 digest | Generic invalid-credential response |
| Privileged MFA | Five-minute challenge, bounded attempts | Expired or invalid challenge rejected |
| Recovery | Case creation with uniform response | Rate limited; identity existence not disclosed |
| Audit | Authentication outcome and request ID | No password or factor value recorded |
3. Session security
Session tokens contain at least 288 bits of random material. The server stores only a SHA-256 digest of the token together with the resolved user, CSRF secret, creation time, expiry, and last-seen time. Possession of the session database alone does not provide the cookie value required to authenticate.
- Secure: the browser sends the cookie only over HTTPS.
- HttpOnly: scripts in the page cannot read the cookie.
- SameSite=Strict: cross-site requests do not carry the session cookie.
- Bounded lifetime: standard sessions expire after twelve hours; explicitly remembered sessions after thirty days.
- Server revocation: sign-out deletes the server-side session and expires the client cookie.
Changing browser history or client state cannot restore a revoked session. Session validation occurs on every authenticated API request, and expired records are rejected before role resolution.
4. Authorization and change control
Authorization uses resolved server-side roles. Read-only identities are rejected for resource creation, settings changes, alert acknowledgement, pipeline state changes, and change decisions. The interface disables unavailable controls for clarity, but the API performs the authoritative check.
Authenticated mutations must also present the session-specific CSRF token in the X-CSRF-Token header and originate from an allowed same-origin HTTPS surface. A valid session without a valid CSRF token is insufficient.
| Boundary | Enforcement | Recorded evidence |
|---|---|---|
| Session | Opaque cookie resolves to active server record | Session creation and deletion events |
| Request origin | Allowed origin set for state-changing routes | Structured denial with request ID |
| CSRF | Constant-time comparison with session secret | 403 response; no mutation committed |
| Role | Server role checked before operation | Accepted or denied audit outcome |
| High-risk change | Operational safeguards and approval workflow | Change identifier and decision event |
5. Application security
Response policy
The HTTPS origin publishes a restrictive Content Security Policy. Scripts, styles, images, fonts, and API connections are limited to the same origin, with narrowly defined exceptions for inline style required by chart layout. Objects and framing are disabled; form submission is limited to the same origin.
- HSTS is published for two years.
X-Content-Type-Options: nosniffprevents MIME inference.Referrer-Policy: strict-origin-when-cross-originminimizes path disclosure.- Permissions Policy disables camera, microphone, geolocation, payment, and USB access.
- Console and authentication pages use
Cache-Control: no-store.
Input and error handling
JSON request bodies are bounded to 64 KiB. Resource data is schema checked and size limited. Names follow a conservative lowercase identifier pattern. Errors do not include stack traces, file paths, SQL text, secret values, or internal process details. Every structured error carries a request ID for correlation.
6. Infrastructure boundaries
The Control API listens on 127.0.0.1:8090. The Nginx HTTPS origin listens on 127.0.0.1:8443. Neither process owns the public transport ports used by the existing gateway services. Nginx publishes static assets and forwards only /api/* to the local application.
TLS termination for the local origin requires TLS 1.3. Session tickets are disabled and the service does not expose a generic application listener on an additional public port. Deployment validation checks the application health endpoint before the origin is reloaded.
The management surface remains separate from bulk data movement. A regional storage or transfer impairment does not grant access to identity records or bypass control API authorization.
7. Data and secret handling
Secret values are kept outside the static site and are not returned by integration configuration views. Connector cards display only registry alias, endpoint alias, category, and operating state. Provider tenant identifiers, signing keys, passwords, API tokens, and private endpoints are intentionally excluded from the browser response.
Operational records are minimized to fields required for authentication, authorization, recovery tracking, resource state, settings, and audit. Source network addresses are transformed with a keyed HMAC before entering the audit store. Session cookies are not written to application logs.
Retention periods and handling requirements are defined in the Data Retention Standard and Privacy Notice.
8. Logging and audit
Audit events include UTC occurrence time, actor, action, resource, outcome, request ID, and one-way source digest. The event store is append-oriented from the application perspective. Interactive viewers cannot edit or delete events.
Examples of recorded activity include password outcomes, MFA outcomes, session creation and deletion, recovery requests, resource creation, settings changes, alert acknowledgement, pipeline state changes, integration registry checks, and change decisions.
Exports may contain identity, resource, and operating-state information. Store them only in approved review locations and apply the same retention and access controls as the source audit data.
9. Vulnerability management
Application changes are built and tested before publication. The release process includes compilation, API integration tests, static link validation, health checks, service status checks, and verification that public transport ownership and firewall behavior remain unchanged.
Security updates are prioritized by exploitability, exposure, privilege required, data impact, and service availability impact. Critical issues affecting authentication or unauthorized mutation enter immediate containment review. Lower-risk findings are tracked to a scheduled maintenance release.
| Priority | Example impact | Initial handling objective |
|---|---|---|
| Critical | Authentication bypass, remote code execution, unrestricted secret disclosure | Immediate containment and owner notification |
| High | Privilege escalation, unauthorized state mutation, material data exposure | Same-business-day triage |
| Medium | Scoped information disclosure or control degradation | Three-business-day triage |
| Low | Hardening gap with limited practical impact | Scheduled review |
10. Security incident response
Security response follows detection, validation, containment, eradication, recovery, and retrospective review. The incident commander maintains a UTC timeline and links material changes to recorded change requests. Evidence collection should preserve request IDs and audit events without copying active credentials.
- Validate the signal and define the affected identity, route, resource, and time range.
- Contain access or operation scope without destroying relevant evidence.
- Identify the root control failure and remove the condition.
- Restore service through a reviewed change and verify expected safeguards.
- Document impact, contributing factors, corrective actions, and control owners.
Public status communication is based on confirmed service impact. A security investigation that does not affect service availability or user action may remain restricted while evidence is evaluated.
11. Vulnerability disclosure
Security reports may be initiated through the service contact published in /.well-known/security.txt. Include the affected route or component, required conditions, reproducible steps, potential impact, and a safe method for follow-up.
Safe research expectations
- Do not access or modify data outside the reporting identity's assigned scope.
- Do not perform denial-of-service testing, credential stuffing, destructive mutation, or persistence.
- Do not publish active credentials, personal data, private tenant identifiers, or unremediated exploit details.
- Stop testing when evidence of unauthorized access or material service impact is obtained.
Response objectives
Reports are acknowledged within three business days. Confirmed critical issues enter immediate containment review. Status updates are provided when the issue is validated, when remediation is available, and when coordinated disclosure is appropriate.