Network Security Policy

Digital Benefits Pte Ltd (WiBiz) Version: 1.0 Effective Date: 15 April 2026 Owner: CEO / Head of Operations Review Cycle: Annual (next review: April 2027) Classification: Internal

1. Purpose

This policy defines the requirements for securing network communications, infrastructure, and access points across WiBiz operations. WiBiz operates a cloud-first architecture with no on-premise data centres. This policy addresses the specific security requirements of a distributed SaaS platform with cloud-hosted services and a remote workforce.

2. Scope

This policy applies to:

• All cloud-hosted services and platforms used by WiBiz (hosting, CRM, automation, payments)
• All devices used to access WiBiz systems (company-issued and personal)
• All network connections used for WiBiz work (office, home, public)
• All API endpoints and integrations between WiBiz services
• All team members, contractors, and partners with access to WiBiz systems

3. Network Architecture Principles

3.1 Cloud-First Model

WiBiz operates primarily on cloud and SaaS infrastructure. There are no WiBiz-owned data centres or co-located servers. Production services are hosted on:

• Cloud hosting platforms for web applications and API endpoints
• SaaS platforms for CRM, automation orchestration, and payment processing
• CDN and edge networks for content delivery and DDoS protection

3.2 Separation of Environments

• Production and development/staging environments must be logically separated.
• Production credentials, API keys, and database connections must never be used in development or testing.
• Environment variables are managed per-environment in the deployment platform. No production secrets in source code or local configuration files.

3.3 Least Privilege

Network access follows the principle of least privilege. Systems and users are granted only the minimum access required for their function. Default-deny is the baseline for all access controls.

4. Firewall and Access Controls

4.1 Cloud Security

• All cloud-hosted services must use the security controls provided by the hosting platform (e.g., edge firewalls, WAF, IP restrictions where available).
• Administrative access to cloud platforms is restricted to authorised personnel and protected by MFA.
• Unused ports, services, and endpoints must be disabled or removed.

4.2 Local Infrastructure

• The Mac Mini automation server operates on the local network only. No services are exposed to the public internet.
• SSH access to the Mac Mini is restricted to the local network and requires key-based authentication. Password-based SSH is disabled.
• No tunnelling services (ngrok or similar) are used to expose local services externally.

4.3 Access Control Lists

• Cloud platform access is managed via platform-native IAM (identity and access management) controls.
• Service accounts use dedicated credentials with minimum required permissions.
• Access is reviewed quarterly and revoked immediately upon role change or departure.

5. Wireless Network Security

5.1 Office Networks

• Office Wi-Fi networks used for WiBiz work must use WPA3 or WPA2-Enterprise encryption at minimum. WPA2-Personal (PSK) is acceptable only for networks with a strong, unique passphrase rotated every 90 days.
• Open (unencrypted) Wi-Fi networks must never be used for WiBiz work.
• Guest networks must be segmented from the network used for WiBiz operations.

5.2 Home and Remote Networks

• Team members working remotely must use a secured Wi-Fi network with WPA2 or WPA3 encryption.
• Default router passwords must be changed.
• Open or public Wi-Fi networks must not be used for accessing WiBiz systems unless a VPN is active.

5.3 Public Networks

• If WiBiz work must be performed on a public network (airport, hotel, cafe), a VPN must be used for all connections to WiBiz systems.
• File sharing and network discovery must be disabled on devices connected to public networks.

6. Remote Access Security

6.1 Authentication

• All remote access to WiBiz systems requires authentication.
• MFA is mandatory for:
  • Cloud platform admin consoles (hosting, CRM, payment processors)
  • Source code repositories (GitHub)
  • Email accounts used for WiBiz business
  • Any system storing customer or client data
• SSH access uses key-based authentication only. Password authentication is disabled.

6.2 Secure Connections

• All remote connections to WiBiz services must use encrypted protocols (HTTPS, SSH, TLS 1.2+).
• Unencrypted protocols (HTTP, FTP, Telnet) are prohibited for any connection involving WiBiz data or credentials.

6.3 Device Security

• Devices used to access WiBiz systems must have:
  • Operating system kept up to date with security patches
  • Disk encryption enabled (FileVault on macOS, BitLocker on Windows)
  • Screen lock enabled with a maximum 5-minute idle timeout
  • Antivirus/endpoint protection active (macOS built-in protections at minimum)

7. Network Monitoring and Logging

7.1 Logging Requirements

The following events must be logged:

• Authentication attempts (successful and failed) to all WiBiz cloud platforms
• Administrative actions on cloud platforms (user creation, permission changes, configuration changes)
• API access logs for production endpoints
• Deployment events (who deployed, when, which commit)
• SSH access to infrastructure (Mac Mini)

7.2 Log Retention

• Security-relevant logs must be retained for a minimum of 90 days.
• Authentication and access logs must be retained for a minimum of 12 months.
• Logs must be stored in a location separate from the systems they monitor where technically feasible.

7.3 Log Review

• Automated alerts must be configured for:
  • Multiple failed login attempts (5+ within 10 minutes)
  • Administrative access from unrecognised locations or devices
  • Unusual API traffic patterns (rate limit breaches, unexpected volume spikes)
• Logs are reviewed manually at least monthly for anomalies not covered by automated alerts.

8. Intrusion Detection and Prevention

8.1 Cloud Provider Capabilities

WiBiz leverages the intrusion detection and prevention capabilities built into its cloud hosting and CDN providers:

• Web Application Firewall (WAF) rules for common attack patterns (SQL injection, XSS, path traversal)
• Automated bot detection and mitigation
• Rate limiting on all public endpoints
• DDoS mitigation at the edge network level

8.2 Application-Level Detection

• All API endpoints validate input and reject malformed requests.
• Authentication endpoints implement rate limiting and account lockout after repeated failures.
• Application error rates and response times are monitored. Sudden changes trigger investigation.

8.3 Incident Escalation

Any suspected intrusion or security breach is escalated immediately per the Incident Response Policy. The CEO must be notified within 1 hour of a confirmed or strongly suspected breach.

9. Network Segmentation

9.1 Environment Separation

• Production services are isolated from development and staging environments at the platform level.
• Production API keys, database credentials, and service accounts are never shared with non-production environments.
• Development and testing use separate accounts, projects, or namespaces within cloud platforms.

9.2 Service Isolation

• Each client sub-account in the CRM platform operates in its own logical partition, with no cross-account data access.
• Payment processing is handled by PCI DSS-compliant third-party processors. WiBiz does not store, process, or transmit card data directly.
• Third-party integrations access only the data and endpoints required for their function.

9.3 Local Network

• The Mac Mini automation server is on the local network only, not exposed externally.
• Development machines and the automation server are on the same LAN but SSH access is key-authenticated.

10. DNS Security

10.1 DNS Management

• DNS records for all WiBiz domains are managed through a reputable DNS provider with DNSSEC support.
• Access to DNS management is restricted to authorised personnel and protected by MFA.
• Changes to DNS records follow the Change Management Policy.

10.2 DNS Configuration

• All public-facing services use HTTPS. HTTP requests are redirected to HTTPS.
• SPF, DKIM, and DMARC records are configured for all domains used to send email, to prevent spoofing and improve deliverability.
• CAA (Certificate Authority Authorization) records are configured to restrict which CAs can issue certificates for WiBiz domains.

10.3 DNS Monitoring

• DNS records are monitored for unauthorised changes.
• Domain registrar accounts are protected by MFA and registrar lock where available.

11. API Security

11.1 Authentication and Authorisation

• All API endpoints require authentication. No anonymous access to any endpoint that reads or writes business data.
• API authentication uses tokens (Bearer tokens, API keys) transmitted only over HTTPS.
• API keys are scoped to the minimum permissions required and rotated at least annually.
• Expired or revoked tokens must be rejected immediately.

11.2 Rate Limiting

• All public-facing API endpoints implement rate limiting to prevent abuse.
• Rate limits are configured per-endpoint based on expected legitimate usage patterns.
• Rate limit breaches are logged and trigger automated alerts if persistent.

11.3 Input Validation

• All API inputs are validated on the server side. Client-side validation is not a substitute.
• Inputs are validated for type, length, format, and range before processing.
• API responses do not expose internal system details, stack traces, or database structures in error messages.

11.4 API Documentation

• All internal and partner-facing APIs are documented with expected inputs, outputs, and error codes.
• API versioning is used to manage breaking changes without disrupting existing integrations.

12. DDoS Protection

12.1 Cloud-Native Protection

WiBiz relies on the DDoS protection capabilities of its cloud hosting and CDN providers:

• Edge network absorbs volumetric attacks before they reach application servers.
• Automatic traffic analysis identifies and filters malicious traffic patterns.
• Geographic rate limiting can be applied during an active attack.

12.2 Application-Level Mitigation

• Rate limiting on all endpoints (see Section 11.2).
• Bot detection and challenge mechanisms on public-facing forms and endpoints.
• Auto-scaling is configured where supported by the hosting platform to absorb traffic spikes.

12.3 Response Plan

• If a DDoS attack overwhelms automated defences, escalate immediately per the Incident Response Policy.
• Contact cloud provider support for manual mitigation assistance.
• Communicate service status to affected clients via the designated communication channel.

13. Vulnerability Scanning

13.1 Schedule

13.2 Remediation

• Critical vulnerabilities: Remediated within 48 hours. If remediation is not possible, a compensating control must be applied within 48 hours and full remediation completed within 14 days.
• High vulnerabilities: Remediated within 14 days.
• Medium vulnerabilities: Remediated within 30 days.
• Low vulnerabilities: Remediated within 90 days or accepted with documented justification.

13.3 Dependency Management

• All third-party libraries and dependencies are tracked.
• Automated alerts for known vulnerabilities in dependencies (e.g., GitHub Dependabot, npm audit) must be enabled on all repositories.
• Dependencies with known critical or high vulnerabilities must be updated or replaced within the remediation timelines above.

14. Compliance

Failure to follow this policy may result in:

• Revocation of network and system access
• Disciplinary action
• Mandatory security awareness retraining

15. Related Policies

• Information Security Policy
• Access Control Policy
• Change Management Policy
• Incident Response Policy
• Data Protection and Privacy Policy

Document Control