Printed from CheckTick DSPT Compliance Documentation
Network Security & Configuration Standard (Section 9)
1. Password Management for Network Devices
CheckTick enforces a "Zero-Default" policy for all networking hardware and software.
- Immediate Change: Vendor-supplied default passwords (e.g., 'admin', 'password') must be changed during the initial setup of any networking device (routers, modems, switches).
- Strength Requirements: New passwords must meet our "High-Strength" criteria (minimum 12 characters, complex mix) and be stored in the corporate password manager.
- Unique Identities: Wherever the hardware supports it, default 'admin' accounts are disabled in favor of individual named accounts for the CTO and SIRO.
- Cloud Boundary Controls Our primary network boundary is managed via Northflank's Infrastructure-as-Code (IaC) settings. Access to change these "firewall-equivalent" settings is protected by the same MFA and unique-identity standards as our code repository.
2. Remote Access & Management
- Management Interfaces: Local management interfaces for networking hardware must not be accessible from the public internet (WAN side).
- MFA: Any cloud-based networking console (e.g., Northflank, Domain Registrars) must have Multi-Factor Authentication (MFA) enabled.
- Just-In-Time (JIT) Management We do not leave administrative ports (e.g., database ports) open for management. Any direct database access for maintenance is conducted via temporary, authenticated proxy connections that bypass the public internet boundary.
3. Annual Review
The CTO performs an annual audit of all registered hardware assets to ensure that firmware is updated and administrative passwords remain unique and secure.
4. Protection of Administrative Interfaces
As CheckTick utilizes cloud-managed boundaries, the following controls are mandatory for the Northflank and Domain Management consoles:
- MFA Enforcement: Every administrative account must utilize TOTP or FIDO2 hardware keys.
- Audit Logging: We rely on the provider's immutable audit logs to monitor for configuration changes. These logs are reviewed by the SIRO quarterly.
- Infrastructure as Code (IaC): To ensure 'Roll-back' capability, network ingress rules are documented in our repository. Any manual change in the console must be reconciled with the repository within 24 hours to ensure the 'Source of Truth' remains valid.
- Session Security: Management sessions must be conducted over encrypted TLS 1.2+ connections and are configured to auto-terminate after 60 minutes of inactivity.
5. Inbound Connection Verification (Default Deny)
Last Verified: 03/01/2026 Verified By: [SIRO Name] (CTO)
The following inbound protocol checks have been performed on the production boundary:
| Protocol / Port | Status | Justification |
|---|---|---|
| HTTP (80) | Blocked | Redirected to 443 at Load Balancer |
| HTTPS (443) | Open | Required for Production Web Traffic |
| SMB/NetBIOS (137-139, 445) | Blocked | High Risk - Not utilized |
| Telnet/SSH (22, 23) | Blocked | SSH managed via Northflank internal console |
| Database (5432) | Blocked | Database is on a private subnet; no WAN access |
| TFTP/RPC/Rlogin | Blocked | Not installed in container images |
Note: All container images are based on minimal distros (e.g., Alpine or Distroless) to ensure that even if a firewall rule failed, the underlying OS does not contain the binaries for these insecure protocols.
6. Authorized Inbound Rule Register
The following rules represent the only permitted exceptions to our 'Deny-All' boundary policy.
| Rule ID | Port | Protocol | Source | Destination | Business Justification | Approved By |
|---|---|---|---|---|---|---|
| FW-01 | 443 | TCP (HTTPS) | Any (Public) | Load Balancer | Primary application ingress for users. | [SIRO Name] (CTO) |
| FW-02 | 80 | TCP (HTTP) | Any (Public) | Load Balancer | Redirect only; to force upgrade to TLS. | [SIRO Name] (CTO) |
Note on Internal Traffic: All other service communication (e.g., App to Database) occurs over a private, non-routable service mesh and does not require boundary firewall exceptions.
Review Date: 03/01/2026 Next Review: 03/04/2026