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 Change | Responsible | Summary of Change |
|---|---|---|
| December 2024 | ICS InfoSec Team | Initial publication |
| April 2025 | ICS InfoSec Team | Expanded to include operational network security standards, segmentation, and monitoring requirements |
| March 2026 | ICS InfoSec Team | Published to Trust Center |