InContext Solutions
Network & InfrastructureLast reviewed: 2025-04-01

Network Security Policy

1. Overview

InContext Solutions recognizes that ensuring information security is a critical responsibility of management and a corporate social obligation. All personnel engaged in the organization's operations are expected to be committed to this goal. We have established an information security management system (ISMS) to protect our information assets, and this Network Security Policy serves as the operational foundation for securing all network infrastructure, communications, and connectivity across the organization.

This policy defines the technical and procedural controls required to protect network infrastructure from unauthorized access, misuse, disruption, and data exfiltration. It supports the confidentiality, integrity, and availability of information assets transmitted or accessible across InContext Solutions networks.

2. Scope

This policy applies to all network infrastructure owned, operated, or managed by InContext Solutions, including but not limited to:

  • Firewalls (hardware and virtual, including next-generation firewalls)
  • Switches and routers (physical and virtual)
  • Load balancers and application delivery controllers
  • Wireless access points and wireless LAN controllers
  • VPN gateways and remote access concentrators
  • Cloud virtual networks (Azure Virtual Networks, network security groups, and related cloud-native networking components)
  • DNS systems (internal resolvers, authoritative servers, and filtering services)
  • Network monitoring and management infrastructure

This policy applies to all employees, contractors, and third parties who manage, administer, or connect to InContext Solutions network resources.

3. Network Architecture

3.1 Defense-in-Depth

InContext Solutions implements a defense-in-depth network architecture in which multiple layers of security controls are deployed to protect information assets. No single point of failure or compromise should result in unauthorized access to critical systems or data.

3.2 Network Segmentation

The network must be segmented into distinct security zones with controlled traffic flows between them. At minimum, the following zones must be maintained:

  • Production — Hosts production application workloads and databases. Access restricted to authorized services and administrative personnel only.
  • Development / Staging — Isolated from production. Used for development, testing, and pre-production validation. No production data may reside in development environments unless anonymized or masked.
  • Corporate — End-user workstations, office productivity systems, and internal collaboration tools.
  • DMZ (Demilitarized Zone) — Internet-facing services such as web servers and API gateways. Traffic from the DMZ to internal zones must pass through a firewall with explicit allow rules.
  • Management — Network management, monitoring, and administrative access systems. Access restricted to authorized network and systems administrators.

All inter-zone traffic must pass through a firewall or equivalent filtering device. Direct routing between zones without inspection is prohibited unless explicitly approved by the Information Security team with a documented risk acceptance.

3.3 Azure Virtual Network Architecture

Cloud-hosted infrastructure in Microsoft Azure must use Virtual Networks (VNets) with network security groups (NSGs) enforcing segmentation. Subnet-level NSGs must be applied to all subnets, and flow logs must be enabled for audit and troubleshooting. Azure Private Endpoints should be used for PaaS services wherever supported to minimize public exposure.

3.4 Micro-Segmentation

Where technically feasible and warranted by the sensitivity of the workload, micro-segmentation should be applied to restrict lateral movement within a zone. This is particularly recommended for production database tiers and systems processing sensitive or regulated data.

4. Firewall Management

4.1 Default-Deny Policy

All firewalls must be configured with a default-deny ingress rule. Only explicitly authorized traffic is permitted. Outbound traffic must also be restricted to known, required destinations for production and management zones.

4.2 Rule Documentation

Every firewall rule must include:

  • A description of the business or technical purpose
  • The requestor and approver
  • Source and destination addresses or ranges
  • Ports and protocols permitted
  • An expiration date for temporary rules

4.3 Quarterly Firewall Rule Review

All firewall rule sets must be reviewed at least quarterly by the network security team. During each review:

  • Rules no longer required must be disabled and subsequently removed
  • Overly broad rules (e.g., "any" source or destination) must be narrowed or justified with a documented exception
  • Temporary rules past their expiration must be removed

4.4 Change Management

All firewall rule changes must follow the Change & Patch Management process. Emergency changes must be documented retroactively within 48 hours.

4.5 Next-Generation Firewall Capabilities

Where deployed, next-generation firewall (NGFW) features such as application-layer inspection, TLS decryption (where legally and contractually permitted), and threat intelligence feed integration should be enabled and maintained with current signatures.

Firewall rules permitting inbound access from the public internet to internal resources must receive explicit approval from the Information Security team prior to implementation. Any "allow all" rules on perimeter firewalls are strictly prohibited.

5. Intrusion Detection and Prevention

5.1 Deployment

Intrusion detection and prevention systems (IDS/IPS) must be deployed on:

  • All network perimeters (internet-facing boundaries)
  • Boundaries between security zones handling sensitive data
  • Critical internal network segments as determined by risk assessment

5.2 Detection Methods

IDS/IPS solutions must employ both signature-based and anomaly-based detection methods. Signature databases must be updated automatically, no less frequently than daily.

5.3 Alert Integration

All IDS/IPS alerts must be forwarded to the centralized SIEM platform for correlation, investigation, and response. High-severity alerts must generate immediate notifications to the security operations team.

5.4 Tuning and False Positive Management

IDS/IPS rulesets must be tuned on a regular basis (at least quarterly) to reduce false positives while maintaining detection effectiveness. Suppressed or disabled signatures must be documented with justification and reviewed during quarterly tuning cycles.

6. Network Access Control

6.1 Wired Network Authentication

802.1X port-based authentication must be implemented for wired network access in corporate and management zones. Devices that fail authentication must be placed in a quarantine VLAN with limited or no network access.

6.2 Device Compliance

Network admission control mechanisms should verify device compliance (e.g., current OS patches, active endpoint protection, valid certificates) before granting full network access. Non-compliant devices must be restricted to a remediation network.

6.3 VLAN Segmentation

VLANs must be used to logically segment network traffic by function (e.g., workstations, VoIP, printers, IoT devices, servers). Inter-VLAN routing must be controlled by firewall or ACL rules.

6.4 MAC Address Filtering

MAC address filtering may be applied as a supplementary control where appropriate, but must not be relied upon as a primary access control mechanism.

6.5 Guest Network Isolation

Guest network access must be completely isolated from corporate, production, and management networks. Guest networks must provide internet-only access with no visibility into internal resources. A captive portal or acceptable-use acknowledgment is required before granting guest access.

7. Wireless Security

7.1 Encryption Standards

Corporate wireless networks must use WPA3 Enterprise authentication. Where WPA3 is not yet supported by all required devices, WPA2 Enterprise (with AES-CCMP) is the minimum acceptable standard. WPA2 Personal (PSK), WEP, and open (unencrypted) networks are prohibited for corporate use.

7.2 Guest WiFi

Guest WiFi must be on a dedicated SSID, segregated from all internal networks, and rate-limited to prevent abuse. Guest networks must not use the same authentication infrastructure as corporate wireless.

7.3 Rogue Access Point Detection

Wireless intrusion detection must be enabled to identify rogue or unauthorized access points. Detected rogue devices must be investigated and remediated promptly. Periodic physical site surveys should supplement automated detection.

7.4 Wireless Monitoring

Wireless network performance, utilization, and security events must be centrally monitored. Alerts for authentication failures, deauthentication attacks, and unusual client behavior must be configured.

7.5 SSID Management

Corporate SSIDs should not broadcast network names that reveal organizational identity in shared or public spaces where this would present a targeting risk. Unused SSIDs must be disabled.

8. VPN and Remote Connectivity

8.1 Encryption Standards

VPN connections must use strong encryption protocols. Approved protocols include IKEv2/IPsec and WireGuard. Legacy protocols such as PPTP and L2TP without IPsec are prohibited.

8.2 Split Tunneling

Split tunneling is disabled by default for corporate VPN connections. Exceptions for split tunneling may be granted with Information Security approval and must be documented with compensating controls (e.g., DNS filtering, endpoint protection verification).

8.3 Session Timeout

VPN sessions must enforce a maximum session duration of 8 hours, after which re-authentication is required. Idle timeout must be set to no more than 30 minutes.

8.4 Multi-Factor Authentication

Multi-factor authentication (MFA) is mandatory for all VPN connections. Single-factor authentication (password only) for remote access is strictly prohibited.

8.5 VPN Logging

All VPN connection events (connect, disconnect, authentication success/failure) must be logged and forwarded to the SIEM. Logs must include the authenticated user identity, source IP address, connection timestamp, and duration.

9. DNS Security

9.1 DNS Filtering

DNS filtering must be implemented to block resolution of known malicious, phishing, and command-and-control domains. Filter lists must be updated automatically from reputable threat intelligence feeds.

9.2 DNSSEC

DNSSEC validation must be enabled on internal DNS resolvers where supported by the infrastructure. Authoritative DNS zones for externally published domains should be DNSSEC-signed where registrar and hosting support is available.

9.3 DNS Query Logging

DNS query logs must be retained and forwarded to the SIEM for security analysis, threat hunting, and incident investigation. Logs must be retained in accordance with the organization's data retention requirements.

9.4 Internal DNS Architecture

Internal DNS must be configured to prevent information leakage. Internal zone data must not be resolvable from external networks. DNS servers must be hardened, with zone transfers restricted to authorized secondary servers only.

10. Network Monitoring and Logging

10.1 Traffic Monitoring

Network traffic must be monitored continuously for anomalous patterns, unauthorized connections, and indicators of compromise. Monitoring must cover both north-south (perimeter) and east-west (inter-zone) traffic.

10.2 NetFlow / sFlow Collection

NetFlow, sFlow, or equivalent traffic telemetry must be collected from core network devices and retained for at least 90 days to support incident investigation and forensic analysis.

10.3 Bandwidth Monitoring

Bandwidth utilization must be monitored on all critical network links. Capacity thresholds must be established and alerts configured to notify the network operations team when utilization exceeds 80% of available capacity.

10.4 Performance Baselines

Network performance baselines must be established and maintained for critical links and services. Deviations from baselines must trigger investigation to distinguish between operational issues and potential security incidents.

10.5 Anomaly Detection

Automated anomaly detection should be applied to network traffic patterns to identify potential data exfiltration, lateral movement, or denial-of-service activity. Detected anomalies must generate alerts for security team review.

Network monitoring data, including flow records and packet captures, may contain sensitive information. Access to monitoring systems and data must be restricted to authorized network and security personnel. Refer to the Disaster Recovery Summary for network infrastructure recovery procedures and priorities.

11. Compliance and Enforcement

11.1 Network Security Assessments

Network security assessments, including vulnerability scanning of network infrastructure devices, must be performed at least quarterly. Critical and high-severity findings must be remediated within 30 days.

11.2 Penetration Testing

Penetration testing of network infrastructure must be conducted at least annually by qualified internal or external assessors. Testing scope must include perimeter defenses, segmentation effectiveness, and wireless security.

11.3 Compliance Measurement

The Information Security team will verify compliance with this policy through periodic audits, configuration reviews, automated compliance scanning, and monitoring of security controls.

11.4 Exceptions

Any exceptions to this policy must be approved in advance by the Information Security team. Exception requests must include a risk assessment, proposed compensating controls, and a defined expiration date. Approved exceptions must be reviewed at least annually for continued necessity.

11.5 Enforcement

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment. Contractors and third parties found in violation may have their access immediately revoked and their engagement reviewed for potential termination.

Related Policies

Revision History

Date of ChangeResponsibleSummary of Change
December 2024ICS InfoSec TeamInitial publication
April 2025ICS InfoSec TeamExpanded to include operational network security standards, segmentation, and monitoring requirements
March 2026ICS InfoSec TeamPublished to Trust Center