Network Security Policy

Document Control

Revision history

1. Introduction

1.1 Purpose

The purpose of this policy is to define the requirements for the secure design, operation and use of the networks through which Hamurlabs delivers the HaROS platform and conducts its business. Hamurlabs operates a cloud-native environment: production workloads run on Google Cloud, and personnel work from Hamurlabs offices (Istanbul and Leuven) and remotely. This policy protects Hamurlabs and its customers from risks including unauthorised access, malware, compromise of network systems and services, and the legal consequences of a breach.

1.2 Scope

This policy applies to all networks owned, operated or contracted by Hamurlabs, including: (a) cloud network environments (VPC networks, subnets, load balancers, VPNs and related services) in Google Cloud and any other cloud provider; (b) office networks at Hamurlabs locations; (c) remote access connections used by personnel and authorised third parties; and (d) all devices connecting to any of the above. It is binding on all Hamurlabs personnel and on third parties granted network access.

1.3 Maintenance, Enforcement and Exceptions

This policy is reviewed by the ISM annually, or as needed based on changes in technology, architecture or regulatory requirements. Violations may result in suspension or loss of access privileges, disciplinary action up to and including termination of employment or contractor status, and civil or criminal remedies where applicable. Exceptions must be approved in writing by the ISM, formally documented with a risk assessment and compensating controls, and reviewed periodically for continued appropriateness.

2. General Network Access Rules

1. Only authorised persons may access Hamurlabs networks. All users must be positively identified with individual accounts and strong authentication before using Hamurlabs systems.
2. User IDs must uniquely identify a single user to ensure individual accountability in system logs. Shared or group accounts are not permitted.
3. Interactive log-in with service accounts is prohibited. Where personnel require privileges inherent in a service account, the need must be approved by the ISM, assigned to the individual on an as-needed basis, and revoked when no longer necessary.
4. Multi-factor authentication (MFA) is mandatory for all remote access, for all access to the Google Cloud console and APIs, for the identity provider, and for all administrative interfaces.
5. Users must lock their workstation or log off before leaving any device unattended, especially where privileged access rights are in use.
6. All network and system access attempts, successful or failed, must be logged and retained for auditing in accordance with the log retention standard.
7. No device or software that has the potential to disrupt network service to others may be introduced to Hamurlabs networks without prior arrangement with the engineering organisation.

3. Cloud Network Security (Google Cloud)

The HaROS production environment is hosted on Google Cloud. The following requirements apply:

• Environment segregation: production, staging and development environments must be segregated using separate projects and/or VPC networks. Production data must not be used in non-production environments unless anonymised or explicitly authorised under the Data Classification Policy.
• Least-privilege network design: VPC firewall rules must follow a default-deny approach; only the ports and sources required for the service are opened. "Allow all" (0.0.0.0/0) ingress rules to administrative ports (e.g. SSH, RDP, database ports) are prohibited.
• No direct public exposure of databases or internal services: databases and internal services must use private IP addressing and must not be reachable from the public internet. Public exposure is permitted only for intended service endpoints (e.g. HaROS application and API endpoints) behind load balancers.
• Encryption in transit: all external service endpoints must enforce TLS 1.2 or higher. Administrative access to cloud resources must be performed over secure channels (SSH, IAP, or VPN); Telnet and other unencrypted management protocols are prohibited.
• Infrastructure as code and change control: changes to network configuration (VPCs, subnets, firewall rules, load balancers, DNS) must follow the change management process, be traceable to an authorised individual, and be reviewed before deployment.
• Internal addressing, network topology and configuration details are classified as Internal or Confidential under the Data Classification Policy and must not be publicly disclosed.
• Cloud audit logging (admin activity and access logs) must be enabled and retained; alerts must be configured for high-risk changes such as firewall modifications and IAM changes.

4. Server and Workload Security

All servers, virtual machines, containers and serverless workloads operated by Hamurlabs must meet the following minimum standards:

• Registered and identifiable: each production workload must be identifiable in the infrastructure inventory with an owner, its function, and its environment.
• Hardened configuration: operating system and service configuration must follow approved baseline guidance; services and applications not serving business requirements must be disabled or removed.
• Patched: current security patches must be applied as soon as practicable, prioritised by severity; container base images must be rebuilt and redeployed regularly.
• Protected against malware: anti-malware protection appropriate to the platform must be in place for workloads exposed to user-supplied content or files.
• Authenticated: access must require individual authentication; root or administrator accounts must not be used where a non-privileged account can perform the task.
• Privileged access over secure channels only (e.g. SSH with key-based authentication or identity-aware proxy); trust relationships between systems must be avoided unless documented and approved.
• Physically protected: on-premises equipment, if any, must be located in access-controlled areas; production workloads may only run in the certified data centres of the cloud provider.

5. Office and Endpoint Network Security

• Office networks must be protected by a firewall with a default-deny inbound policy and segmented so that guest Wi-Fi is isolated from the corporate network.
• Corporate Wi-Fi must use WPA2/WPA3-Enterprise or, at minimum, WPA2 with a strong passphrase rotated upon personnel departure; the passphrase must not be shared with guests.
• Only Hamurlabs-managed or authorised devices may connect to the corporate network; endpoints must run supported operating systems with automatic security updates, disk encryption and endpoint protection enabled.
• Personnel must not deploy their own networking equipment (routers, switches, access points, VPN servers, DHCP/DNS servers) on Hamurlabs networks without written approval from the engineering organisation.
• Peer-to-peer file sharing and other high-risk protocols identified by the ISM are prohibited on Hamurlabs networks.

6. Remote Access

• Remote access to production infrastructure is permitted only through approved secure channels (VPN, SSH via bastion/identity-aware proxy, or equivalent zero-trust access) with MFA.
• Personnel working remotely must use trusted networks or a VPN, keep their devices updated and encrypted, and must not allow household members or others to use devices that access Hamurlabs systems.
• Third-party remote access (customers, vendors, support providers) must be individually authorised, limited in scope and duration, logged, and revoked immediately when no longer required.
• Split-responsibility rule: users at remote locations are responsible for ensuring the basic security of their local network (router firewall enabled, default credentials changed) before connecting to Hamurlabs resources.

7. Email and DNS Security

• All corporate email must flow through the centrally managed Hamurlabs email platform; personnel must not configure automatic forwarding of corporate email to personal accounts.
• SPF, DKIM and DMARC must be configured and maintained for all Hamurlabs email domains.
• Email client-to-server communication must use TLS.
• All Hamurlabs public DNS zones must be centrally managed; changes follow change management. Hosts on Hamurlabs networks must use the DNS resolvers designated by the engineering organisation.

8. Monitoring and Logging

Hamurlabs monitors its networks and systems for security events. Network access logs, cloud audit logs, VPN logs and firewall logs must be collected centrally, protected against tampering, and retained in accordance with the log retention standard. There is no expectation of privacy in the use of Hamurlabs networks and systems beyond the protections required by applicable law; monitoring is performed in compliance with KVKK, GDPR and applicable employment law, and personnel are informed accordingly.

9. Related Documents

• HL-ISMS-POL-01 Information Security Policy
• HL-ISMS-POL-03 User Access Control Policy
• HL-ISMS-POL-04 Data Classification Policy
• HL-ISMS-POL-05 Incident Management Policy