# 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

| Scan Type | Frequency | Scope |
|---|---|---|
| Automated dependency scanning | Continuous (on every build via CI/CD) | All application dependencies (npm, pip) |
| Web application vulnerability scan | Quarterly | All public-facing endpoints and applications |
| Cloud configuration review | Quarterly | Cloud platform security settings, IAM policies, exposed services |
| Manual penetration testing | Annually (or after major architecture changes) | Full application and infrastructure scope |

### 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**

| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | 15 April 2026 | Digital Benefits Pte Ltd | Initial release |