ISO 27001 A.8.21: Security of Network Services

Quick Reference (60 Seconds)

Bottom Line: Network services are the doors and windows of your digital infrastructure. DNS, email, web, file sharing, and remote access are all critical services that attackers target daily. A.8.21 requires organizations to secure these services with proper configuration, authentication, encryption, monitoring, and access controls. A single misconfigured service, an open DNS resolver, an unauthenticated SMTP relay, a public file share, can be the entry point for a devastating breach.

What the Standard Actually Requires

Figure · Process

What A.8.21 asks you to do

ISO 27001:2022 Annex A.8.21 states:

ISO 27001:2022 Annex A 8.21 asks organizations to identify, implement, and monitor the security mechanisms, service levels, and requirements of network services.

ISO 27002:2022 expands this into practical guidance covering:

1. Service identification, Identify all network services and their security requirements
2. Security mechanisms, Define authentication, encryption, access control, and monitoring for each service
3. Service levels, Define availability, performance, and recovery requirements for each service
4. Management requirements, Define who manages the service, how changes are controlled, and how incidents are handled
5. Service agreements, Document security requirements in service agreements, whether internal or external
6. DNS security, Secure DNS infrastructure against poisoning, hijacking, and amplification attacks
7. Email security, Protect email services against spam, phishing, malware, and unauthorized relay
8. Web services security, Secure web servers, APIs, and web applications
9. File sharing security, Control access to file shares and prevent unauthorized data exposure
10. Remote access services, Secure VPN, remote desktop, and other remote access services
11. Monitoring and logging, Monitor network services for anomalies, attacks, and misuse

Why Security of Network Services Matters

The Network Services Threat Landscape

Network services are the most attacked components of any infrastructure. DNS is used for command-and-control (C2) communication. Email is the primary vector for phishing and malware delivery. Web services are constantly scanned for vulnerabilities. File shares are a common target for data exfiltration. Remote access services are brute-forced daily. Every network service that is exposed, misconfigured, or poorly secured is an open door for attackers.

Key Statistics

• 91% of cyber attacks begin with email (phishing, malware attachment) (Verizon DBIR)
• DNS is used in 85% of malware for C2 communication (Cisco Talos)
• Open SMB/file shares are involved in 40% of ransomware attacks (CISA)
• 70% of web applications have at least one critical vulnerability (OWASP)
• RDP brute force attacks increased 300% in recent years (ESET)
• India ranks 2nd globally in phishing attacks (APWG)
• CERT-In reports 1,500+ DNS and email security incidents annually
• RBI mandates email security, DNS security, and secure remote access for banking systems
• PCI DSS requires secure network services for cardholder data environments

Real-World Consequences

• A Mumbai bank (2024): Had an unauthenticated SMTP relay on their email server. An attacker discovered the open relay and used it to send phishing emails impersonating the bank to 50,000 customers. The emails directed customers to a fake banking portal that stole credentials. The bank had no email authentication (SPF, DKIM, DMARC), no SMTP relay restrictions, and no email filtering. RBI imposed a penalty of INR 1.5 crore and required the bank to implement email security controls within 30 days.
• A Delhi IT company (2023): Had an open DNS resolver on their public-facing DNS server. The attacker used the open resolver in a DNS amplification DDoS attack against a third-party target. The company's DNS server was flooded with 100 Gbps of traffic, causing a complete outage of their DNS-dependent services (website, email, VPN). The company had no DNS rate limiting, no DNSSEC, and no monitoring. The incident caused a 12-hour outage, affecting 200 client projects. The company faced SLA penalties of INR 20 lakh.
• A Bangalore e-commerce company (2024): Had an S3 bucket (file sharing) misconfigured with public read access. The bucket contained customer order data, including names, addresses, and phone numbers for 2 million customers. An attacker discovered the bucket using automated scanning tools and exfiltrated all data. The company had no cloud security monitoring, no bucket policy review, and no data classification. The company faced DPDP Act penalties and a class-action lawsuit.
• A Hyderabad healthcare provider (2023): Had a web-based file sharing portal for doctors to share patient reports. The portal had no MFA, weak password policy, and no session timeouts. An attacker brute-forced a doctor's account, accessed all patient reports, and sold them on the dark web. The provider had no web application firewall, no access logging, and no intrusion detection. The incident was reported to the National Human Rights Commission and the Ministry of Health.
• A Chennai logistics company (2024): Had an FTP server for vendor file exchange with anonymous access enabled. The FTP server contained shipping manifests, customer invoices, and financial data. An attacker accessed the FTP server anonymously, downloaded all data, and used the information to target customers with social engineering attacks. The company had no file transfer security, no access controls, and no monitoring. The company lost 3 major clients and faced legal action.

Regulatory and Business Drivers

• RBI Cyber Security Framework mandates email security, DNS security, and secure remote access for banking systems
• SEBI Cybersecurity Circular requires secure network services for trading systems and market infrastructure
• PCI DSS v4.0 requires secure network services for cardholder data environments (Requirements 1.x, 2.x, 4.x, 8.x)
• CERT-In Guidelines recommend email security, DNS security, and secure file sharing for critical infrastructure
• DPDP Act 2023 requires data fiduciaries to protect systems, including network services handling personal data
• IT Act 2000 requires reasonable security practices for systems handling sensitive data
• ISO 27001 requires A.8.21 as part of the ISMS
• SOC 2 requires secure network services as part of system operations (CC6.1, CC6.6, CC7.1)
• Cyber Insurance increasingly requires secure email, DNS, and remote access as a condition of coverage

Scope and Applicability

What Is Covered

• DNS services: Internal DNS, external DNS, recursive DNS, authoritative DNS, DNSSEC, DNS filtering, DoH/DoT
• Email services: SMTP, POP3, IMAP, webmail, email gateways, email security (SPF, DKIM, DMARC, ARC), email filtering, email archiving
• Web services: HTTP/HTTPS web servers, reverse proxies, load balancers, CDNs, web APIs, web sockets, web application firewalls (WAF)
• File sharing services: SMB/CIFS, NFS, FTP/SFTP, cloud file sharing (S3, Azure Blob, Google Cloud Storage), enterprise file sync and share (EFSS), document management systems
• Remote access services: VPN (IPsec, SSL/TLS, WireGuard), remote desktop (RDP, VNC), SSH, Telnet (should be disabled), bastion hosts, jump servers, ZTNA
• Directory services: LDAP, Active Directory, Kerberos, RADIUS, TACACS+, NIS, NIS+
• Time services: NTP, NTS (Network Time Security), see A.8.17
• Certificate services: PKI, CA, certificate management, ACME (Let's Encrypt), HSM-backed certificate services
• Network management services: SNMP, syslog, NetFlow, sFlow, IPFIX, network monitoring protocols
• Collaboration services: VoIP, video conferencing, instant messaging, team collaboration platforms
• Database services: SQL, NoSQL, database access protocols, database proxies
• API services: REST, GraphQL, gRPC, SOAP, API gateways, API security
• Cloud services: IaaS, PaaS, SaaS network services, cloud-native networking (AWS, Azure, GCP)
• Container services: Kubernetes API, container registries, service meshes
• IoT services: MQTT, CoAP, LoRaWAN, Zigbee, Z-Wave, Bluetooth services
• Multicast and streaming services: IPTV, RTSP, RTP, RTMP, HLS, DASH

Applicability by Organization Type

Key Definitions

Relationship to Other Controls

Implementation Roadmap

Phase 1: Service Inventory and Assessment (Weeks 1–2)

• Week 1: Inventory all network services (DNS, email, web, file sharing, remote access, APIs, etc.) using automated discovery and manual verification
• Week 2: Assess each service for security gaps (authentication, encryption, access control, logging, patching). Create a risk-ranked list of services to secure
• Deliverables: Service inventory, risk assessment, prioritized remediation plan

Phase 2: Core Service Security (Weeks 3–6)

• Week 3: Secure DNS (DNSSEC, DoH/DoT, rate limiting, filtering). Implement email security (SPF, DKIM, DMARC, email gateway, DLP)
• Week 4: Secure web services (HTTPS enforcement, HSTS, CSP, WAF, security headers). Secure APIs (authentication, rate limiting, gateway)
• Week 5: Secure file sharing (access controls, encryption, DLP, cloud storage hardening). Remove anonymous FTP and open SMB shares
• Week 6: Secure remote access (VPN hardening, MFA, bastion hosts, disable Telnet, restrict RDP/SSH)
• Deliverables: Secured DNS, email, web, file sharing, and remote access

Phase 3: Advanced Controls (Weeks 7–10)

• Week 7: Implement certificate management (PKI, Let's Encrypt, certificate monitoring, expiry alerts)
• Week 8: Deploy CASB/SWG for cloud service security. Implement cloud storage monitoring and misconfiguration detection
• Week 9: Harden directory services (LDAP/Kerberos/RADIUS). Implement centralized authentication with MFA
• Week 10: Secure collaboration services (VoIP, video conferencing, messaging). Implement eavesdropping protection and access controls
• Deliverables: Certificate management, CASB, directory hardening, secure collaboration

Phase 4: Monitoring and Documentation (Weeks 11–12)

• Week 11: Integrate service logs with SIEM. Configure alerts for anomalies, unauthorized access, and misuse
• Week 12: Document all service configurations, security policies, and procedures. Create service agreements for internal and external services
• Deliverables: Service monitoring, SIEM integration, complete documentation, service agreements

Ongoing: Operations and Improvement

• Monthly: Review service logs, update security configurations, patch service software
• Quarterly: Service security assessments, penetration testing, vulnerability scanning
• Annually: Full service architecture review, policy update, disaster recovery testing

Detailed Implementation Guidance

DNS Security

Objective: Secure DNS infrastructure against poisoning, hijacking, amplification, and eavesdropping.

Key Controls:

1. DNSSEC: Deploy DNSSEC on all domains to prevent DNS spoofing and cache poisoning. Sign zones with proper key management (ZSK/KSK rollover). Validate DNSSEC on recursive resolvers
2. Rate Limiting: Implement DNS response rate limiting (RRL) to prevent DNS amplification DDoS attacks. Limit queries per IP and per second
3. Query Logging: Log DNS queries for analysis and threat detection. Monitor for suspicious query patterns (excessive queries, tunneling patterns, C2 domains)
4. DNS Filtering: Block known malicious domains, phishing sites, and C2 infrastructure at the DNS level. Use threat intelligence feeds (OpenDNS, Quad9, Cloudflare Gateway)
5. Encrypted DNS: Deploy DNS over HTTPS (DoH) or DNS over TLS (DoT) to prevent eavesdropping and tampering. Configure clients to use encrypted DNS resolvers
6. Split DNS: Use internal DNS for intranet resources and external DNS for public-facing services. Prevent internal resource exposure
7. Recursive Resolver Security: Restrict recursive queries to authorized networks only. Do not allow open recursive resolvers (they can be used for amplification attacks)
8. Anycast: Use Anycast DNS for redundancy and DDoS resilience. Distribute DNS servers across multiple locations

Tools: BIND, Unbound, PowerDNS, Knot DNS, Cloudflare DNS, Google Cloud DNS, AWS Route 53, Azure DNS, Infoblox, BlueCat, DNSFilter, Quad9, NextDNS, Pi-hole

Indian Context: Many Indian organizations use their ISP's DNS or Google DNS (8.8.8.8) without filtering. Implementing DNS filtering with Quad9 or Cloudflare Gateway (free) blocks malicious domains before connections are established. For BFSI, DNSSEC is mandatory under RBI guidelines.

Email Security

Objective: Protect email services from spam, phishing, malware, unauthorized relay, and data exfiltration.

Key Controls:

1. Email Authentication (SPF, DKIM, DMARC):
   • SPF: Publish SPF records for all domains to specify authorized mail servers. Use -all (hard fail) for strong protection
   • DKIM: Sign all outgoing email with DKIM signatures. Verify incoming DKIM signatures. Rotate keys regularly
   • DMARC: Publish DMARC policy with p=reject (after monitoring phase). Review DMARC reports weekly to identify unauthorized senders
   • ARC: Implement ARC for forwarded email to preserve authentication results
2. Email Gateway / Filtering:
   • Deploy a secure email gateway (SEG) for inbound and outbound filtering
   • Block spam, phishing, malware, and malicious attachments
   • Use sandboxing for suspicious attachments
   • Implement URL rewriting and click-time protection for links
   • Implement greylisting for unknown senders
3. SMTP Relay Security:
   • Disable open SMTP relay. Require authentication for all outgoing email
   • Implement SMTP TLS (STARTTLS) for all server-to-server communication
   • Implement MTA-STS to enforce TLS for inbound email
   • Monitor for relay abuse and unauthorized email sending
4. Email Encryption:
   • Enforce TLS 1.2+ for all email transmission
   • Use S/MIME or PGP for sensitive email content encryption
   • Implement DLP for outbound email to prevent data exfiltration
5. Webmail Security:
   • Enforce MFA for all webmail access
   • Implement session timeouts and IP restrictions
   • Use HTTPS with HSTS and secure cookies
   • Monitor for brute force and credential stuffing attacks
6. Email Archiving:
   • Archive all email for compliance and legal hold
   • Encrypt archives and restrict access
   • Implement retention policies per regulatory requirements

Tools: Microsoft Defender for Office 365, Proofpoint, Mimecast, Barracuda, Fortinet FortiMail, Cisco Email Security, Trend Micro, Sophos Email, Virtru, Zix, OpenSMTPD, Postfix, Exim, Mailcow

Indian Context: Indian organizations are heavily targeted by phishing. Implementing DMARC with p=reject prevents domain spoofing, a common tactic used in BEC (Business Email Compromise) attacks against Indian companies. For value-focused organizations, Postfix with OpenDKIM, OpenDMARC, and SpamAssassin provides enterprise email security free.

Web Services Security

Objective: Secure web servers, applications, and APIs against attacks, data breaches, and misuse.

Key Controls:

1. HTTPS Enforcement:
   • Enforce HTTPS for all web services. Redirect HTTP to HTTPS
   • Implement HSTS (HTTP Strict Transport Security) with max-age of at least 1 year and includeSubDomains
   • Implement preload for HSTS to be included in browser preload lists
   • Use TLS 1.2+ only. Disable SSL, TLS 1.0, and TLS 1.1
2. Security Headers:
   • Content-Security-Policy (CSP): Define allowed sources for scripts, styles, images, etc. Start with report-only mode, then enforce
   • X-Frame-Options: Set to DENY or SAMEORIGIN to prevent clickjacking
   • X-Content-Type-Options: Set to nosniff to prevent MIME-type sniffing
   • Referrer-Policy: Set to strict-origin-when-cross-origin or stricter
   • Permissions-Policy: Restrict browser features (camera, microphone, geolocation) as needed
   • X-XSS-Protection: Deprecated; rely on CSP instead
   • Expect-CT: Enforce Certificate Transparency
3. Web Application Firewall (WAF):
   • Deploy WAF for all public-facing web applications
   • Configure OWASP Core Rule Set (CRS) or vendor-specific rules
   • Implement virtual patching for known vulnerabilities
   • Monitor WAF logs for blocked attacks and false positives
4. API Security:
   • Implement API authentication (API keys, OAuth 2.0, JWT, mTLS)
   • Implement API rate limiting to prevent abuse and DDoS
   • Implement API authorization (RBAC, ABAC) for fine-grained access control
   • Use API gateways for centralized security, logging, and throttling
   • Validate all API inputs (schema validation, parameter validation, type checking)
   • Implement API versioning to manage changes securely
5. Reverse Proxy and Load Balancer:
   • Use reverse proxies to hide back-end servers and provide additional security layers
   • Implement load balancing for availability and DDoS resilience
   • Use health checks to remove failed servers from rotation
   • Implement SSL/TLS termination at the load balancer with secure backend communication
6. CDN Security:
   • Use CDN for DDoS protection, caching, and geographic distribution
   • Implement origin authentication to prevent direct origin access bypassing CDN
   • Configure CDN security features (WAF, DDoS protection, bot management)
   • Use signed URLs/cookies for restricted content access
7. Session Management:
   • Use secure, HttpOnly, SameSite cookies for session management
   • Implement short session timeouts (15–30 minutes for sensitive applications)
   • Implement session invalidation on logout and password change
   • Use CSRF tokens for state-changing operations

Tools: Cloudflare, AWS WAF, Azure WAF, GCP Cloud Armor, ModSecurity, Nginx, Apache, HAProxy, F5, Imperva, Akamai, Fastly, KeyCDN, AWS CloudFront, Azure CDN, Google Cloud CDN, Kong, Apigee, AWS API Gateway, Azure API Management, Tyk, Zuul, Envoy

Indian Context: Many Indian e-commerce and fintech companies use cloud-native WAFs (AWS WAF, Cloudflare) for efficient protection. For on-premise applications, ModSecurity with Nginx or Apache provides free WAF capabilities. The Bangalore e-commerce case (see Section 3) demonstrates the critical need for WAF and API security.

File Sharing Security

Objective: Control access to file shares and prevent unauthorized data exposure or exfiltration.

Key Controls:

1. Access Controls:
   • Implement principle of least privilege for all file shares (SMB, NFS, cloud storage)
   • Use NTFS/ACL permissions in combination with share permissions
   • Regularly review and audit access permissions (quarterly access reviews)
   • Remove anonymous access, guest access, and everyone access from all shares
2. Encryption:
   • Encrypt data at rest on file servers (BitLocker, LUKS, EFS)
   • Encrypt data in transit (SMB 3.0+ encryption, NFSv4 with Kerberos, SFTP, FTPS)
   • Use cloud-native encryption (AWS SSE, Azure Storage Service Encryption, GCP CMEK)
3. DLP Integration:
   • Integrate file shares with DLP to prevent sensitive data exfiltration
   • Monitor file access patterns for anomalies (unusual download volumes, off-hours access)
   • Block or alert on sensitive file transfers to external locations
4. Cloud Storage Security:
   • Implement bucket policies with least privilege (no public access unless explicitly required)
   • Use IAM policies for fine-grained access control to cloud storage
   • Enable versioning and logging for all cloud storage buckets
   • Implement object lock / legal hold for compliance
   • Use CSPM tools to detect misconfigurations (public buckets, overly permissive policies)
5. Secure File Transfer:
   • Replace FTP with SFTP or FTPS for all file transfers
   • Use managed file transfer (MFT) solutions for enterprise file exchange
   • Implement PGP encryption for sensitive file transfers
   • Audit all file transfer activities with logging and monitoring
6. Shadow IT Discovery:
   • Scan for unauthorized file sharing services (personal cloud storage, peer-to-peer sharing)
   • Implement CASB to monitor and control cloud file sharing usage
   • Block unauthorized file sharing services at the network level (firewall, proxy)

Tools: Varonis, Netwrix, Stealthbits, Microsoft SharePoint, Box, Dropbox Business, Google Drive for Work, AWS S3, Azure Blob, Google Cloud Storage, IBM Aspera, GoAnywhere, GlobalSCAPE, SolarWinds Serv-U, WinSCP, FileZilla, Cyberduck, rclone, Mountain Duck

Indian Context: The Bangalore e-commerce case (S3 bucket misconfiguration) is a textbook example of cloud storage risk. Indian organizations must implement CSPM tools (Prisma Cloud, Orca, open-source alternatives) to detect public buckets and misconfigurations. For on-premise file shares, regular access reviews with tools like Varonis or Netwrix are essential.

Remote Access Service Security

Objective: Secure VPN, remote desktop, SSH, and other remote access services.

Key Controls:

1. VPN Security:
   • Use strong encryption (AES-256, SHA-256, DH Group 14+)
   • Implement MFA for all VPN connections
   • Use full tunneling (not split tunneling) to ensure all traffic is inspected
   • Implement client posture checks (antivirus, patches, encryption) before VPN access
   • Use certificate-based authentication where possible
   • Limit VPN session duration and implement idle timeouts
2. RDP/SSH Security:
   • Never expose RDP or SSH directly to the internet
   • Use bastion hosts or jump servers for remote access
   • Implement MFA for all RDP and SSH access
   • Use SSH keys (not passwords) for SSH authentication
   • Implement session recording for privileged SSH/RDP sessions
   • Disable RDP on systems that don't need it
3. Telnet and Legacy Protocols:
   • Disable Telnet everywhere. Replace with SSH
   • Disable FTP. Replace with SFTP or FTPS
   • Disable SNMPv1/v2c. Use SNMPv3 with encryption
   • Disable legacy web management interfaces (HTTP, unencrypted web UIs)
4. ZTNA Implementation:
   • Consider ZTNA (Zero Trust Network Access) as a replacement for traditional VPN
   • Implement application-level access control (not network-level)
   • Use identity-aware proxies for web application access
   • Implement continuous verification and session monitoring

Tools: Palo Alto GlobalProtect, Cisco AnyConnect, Fortinet FortiClient, WireGuard, OpenVPN, Zscaler Private Access, Cloudflare Access, Microsoft Azure AD App Proxy, AWS Client VPN, Teleport, StrongDM, BastionZero, AWS Systems Manager Session Manager, Azure Bastion, Google Cloud IAP, CyberArk, Delinea (formerly Thycotic), BeyondTrust

Indian Context: Post-pandemic remote work is permanent in India. Many organizations still use basic VPNs without MFA. Implementing MFA (Duo, Microsoft Authenticator, Google Authenticator) is the single most impactful remote access security improvement. For cloud-first organizations, ZTNA (Cloudflare Access, Azure AD App Proxy) is often more efficient than traditional VPN appliances.

Directory and Authentication Service Security

Objective: Secure LDAP, Active Directory, Kerberos, RADIUS, and other authentication services.

Key Controls:

1. LDAP Security:
   • Use LDAPS (LDAP over SSL/TLS) on port 636. Disable unencrypted LDAP (port 389)
   • Implement certificate validation for LDAPS connections
   • Restrict LDAP queries to authorized users and systems
   • Monitor LDAP logs for unauthorized queries and brute force attempts
2. Active Directory Security:
   • Implement tiered administration model (Tier 0, Tier 1, Tier 2)
   • Secure Domain Controllers with restricted access and hardened configurations
   • Implement PAM (Privileged Access Management) for AD admin accounts
   • Use ADAudit Plus or similar tools for AD change monitoring
   • Implement password policies with complexity, history, and expiration
   • Regularly review and clean up stale accounts, unused groups, and excessive permissions
3. Kerberos Security:
   • Protect Kerberos tickets (TGT) with AES encryption. Disable RC4 and DES
   • Monitor for Kerberoasting attacks (service ticket requests for SPNs)
   • Implement PAC validation and constrained delegation where possible
   • Use Windows Defender Credential Guard to protect credentials
4. RADIUS/TACACS+ Security:
   • Use strong shared secrets (minimum 20 characters, complex)
   • Implement RADIUS over TLS (RadSec) where supported
   • Use TACACS+ for device administration with encryption enabled
   • Centralize authentication and implement MFA for all administrative access

Tools: Microsoft Active Directory, OpenLDAP, FreeIPA, Red Hat IDM, JumpCloud, Okta, Azure AD, Google Workspace, Cisco ISE, Aruba ClearPass, Fortinet FortiAuthenticator, Duo Security, RSA SecurID, YubiKey, Ping Identity, OneLogin, Auth0

Certificate and PKI Security

Objective: Secure certificate infrastructure to prevent man-in-the-middle attacks and ensure trust.

Key Controls:

1. Certificate Management:
   • Maintain an inventory of all certificates (web, email, VPN, API, code signing)
   • Implement automated certificate renewal (ACME/Let's Encrypt for public, internal CA for internal)
   • Monitor certificate expiry and alert before expiration (30, 14, 7, 1 days)
   • Use HSMs or cloud KMS for private key protection
2. Certificate Validation:
   • Validate certificate chains on all TLS connections
   • Implement OCSP stapling for real-time revocation checking
   • Monitor for certificate transparency logs for unauthorized certificates issued for your domains
   • Implement certificate pinning for mobile applications where appropriate
3. Internal CA:
   • Secure internal CA with offline root and online subordinate CAs
   • Implement strict certificate issuance policies and approval workflows
   • Monitor and audit all certificate issuance and revocation
   • Implement CRL and OCSP responder with high availability

Tools: Let's Encrypt, Certbot, ACME clients, DigiCert, Sectigo, GlobalSign, AWS Certificate Manager, Azure Key Vault, Google Cloud Certificate Manager, HashiCorp Vault, Smallstep, OpenSSL, Easy-RSA, Dogtag, EJBCA, AD CS (Active Directory Certificate Services), Venafi, Keyfactor, AppViewX

Collaboration and Communication Services

Objective: Secure VoIP, video conferencing, messaging, and team collaboration platforms.

Key Controls:

1. VoIP Security:
   • Use SIP/TLS (SIPS) and SRTP for encrypted signaling and media
   • Disable SIP ALG on firewalls (it often causes more problems than it solves)
   • Implement strong authentication for SIP trunks and endpoints
   • Monitor for toll fraud, unauthorized registrations, and eavesdropping
   • Segment VoIP traffic on a separate VLAN or network segment
2. Video Conferencing Security:
   • Require passwords or waiting rooms for all meetings
   • Restrict screen sharing to hosts only (or authorized users)
   • Disable "join before host" for external meetings
   • Implement end-to-end encryption where available (Zoom E2EE, Teams E2EE)
   • Monitor for meeting bombing and unauthorized participants
3. Messaging and Collaboration:
   • Implement data loss prevention (DLP) for chat messages and file sharing
   • Control guest access and external sharing permissions
   • Retain and archive messages for compliance (legal hold, regulatory)
   • Monitor for unauthorized data sharing and sensitive data exposure
   • Implement eDiscovery capabilities for investigations

Tools: Cisco Webex, Microsoft Teams, Zoom, Slack, Google Meet, Jitsi, Mattermost, Rocket.Chat, 3CX, Asterisk, FreePBX, Avaya, Genesys, Twilio, Vonage, RingCentral, Mitel, Ribbon Communications

Tools and Technologies

DNS Security

Email Security

Web Services Security

File Sharing and DLP

Remote Access and VPN

Certificate Management

CASB and Cloud Security

Policy Templates

Network Services Security Policy (Template)

1. PURPOSE
   To establish requirements for securing all network services (DNS, email, web,
   file sharing, remote access, APIs, etc.) against unauthorized access, misuse,
   and attacks.

2. SCOPE
   This policy applies to all network services provided in-house or outsourced,
   including DNS, email, web services, file sharing, remote access, directory
   services, APIs, and collaboration services.

3. POLICY STATEMENTS
   3.1 All network services shall be identified, documented, and included in the
       asset inventory.
   3.2 Security requirements (authentication, encryption, access control, monitoring)
       shall be defined for each network service.
   3.3 Service level agreements (SLAs) shall define availability, performance, and
       recovery requirements for each service.
   3.4 DNS services shall be secured with DNSSEC, rate limiting, and encrypted queries.
   3.5 Email services shall implement SPF, DKIM, and DMARC with a reject policy.
   3.6 Web services shall enforce HTTPS, security headers, and WAF protection.
   3.7 APIs shall implement authentication, rate limiting, and input validation.
   3.8 File sharing services shall enforce least privilege access, encryption, and DLP.
   3.9 Remote access services shall require MFA and encrypted connections.
   3.10 Directory services shall use encrypted protocols (LDAPS, Kerberos) and MFA.
   3.11 Certificate management shall be automated with expiry monitoring.
   3.12 All network services shall be monitored for anomalies and security incidents.
   3.13 Changes to network services shall follow the change management process.

4. ROLES AND RESPONSIBILITIES
   4.1 CISO: Owns the policy, ensures compliance, reports to management.
   4.2 Network Administrator: Configures and maintains network services securely.
   4.3 Security Engineer: Implements security controls for network services.
   4.4 System Administrator: Manages service availability, patching, and backups.
   4.5 Security Operations: Monitors service security events and responds to incidents.

5. ENFORCEMENT
   Violations of this policy may result in disciplinary action. Security incidents
   caused by policy violations may result in legal action.

6. REVIEW
   This policy shall be reviewed annually or after any significant security incident
   or service architecture change.

Risk Assessment

Risk Scenarios

Audit Checklist

Internal Audit Questions (20 Questions)

1. Is there a documented network services security policy? (A.8.21)
2. Is there an inventory of all network services? (A.8.21)
3. Are security requirements defined for each network service? (A.8.21)
4. Are service level agreements in place for critical services? (A.8.21)
5. Is DNSSEC deployed for all domains? (A.8.21)
6. Are DNS queries encrypted (DoH/DoT) where appropriate? (A.8.21)
7. Is SPF, DKIM, and DMARC implemented for all domains? (A.8.21)
8. Is the DMARC policy set to reject? (A.8.21)
9. Is an email gateway deployed for spam and malware filtering? (A.8.21)
10. Are SMTP relays secured and not open? (A.8.21)
11. Is HTTPS enforced for all web services with HSTS? (A.8.21)
12. Are security headers (CSP, X-Frame-Options, etc.) implemented? (A.8.21)
13. Is a WAF deployed for public-facing web applications? (A.8.21)
14. Are APIs authenticated and rate-limited? (A.8.21)
15. Are file shares secured with least privilege access? (A.8.21)
16. Is cloud storage monitored for misconfigurations? (A.8.21)
17. Is remote access protected with MFA and encryption? (A.8.21)
18. Are legacy protocols (Telnet, FTP, SNMPv1) disabled? (A.8.21)
19. Are certificates managed and monitored for expiry? (A.8.21)
20. Are network services monitored for anomalies and security incidents? (A.8.21)

Evidence to Review

• Network services security policy (documented, approved, dated)
• Network services inventory (current, complete, risk-ranked)
• Service agreements and SLAs (for internal and external services)
• DNS configuration (DNSSEC, rate limiting, query logs)
• Email authentication records (SPF, DKIM, DMARC, ARC)
• Email gateway configuration and logs
• SMTP relay configuration and access logs
• Web server configuration (HTTPS, HSTS, security headers)
• WAF configuration and alert logs
• API gateway configuration (authentication, rate limiting, throttling)
• File share access control lists and permission reviews
• Cloud storage configuration (bucket policies, IAM, public access)
• CSPM scan reports (misconfigurations, compliance)
• Remote access configuration (VPN, MFA, encryption, session logs)
• Directory service configuration (LDAP/Kerberos/RADIUS, encryption)
• Certificate inventory and expiry monitoring records
• Service monitoring logs (SIEM, service-specific logs)
• Change management records for service modifications
• Penetration test reports for web services and APIs
• Vulnerability scan reports for service software

Metrics and KPIs

Common Pitfalls and How to Avoid Them

Pitfall 1: "SPF is Enough for Email Security"

Mistake: Implementing only SPF and thinking email is secure. Reality: SPF can be bypassed, doesn't verify the "From" header, and doesn't prevent domain spoofing. DKIM and DMARC are essential. Solution: Implement SPF, DKIM, and DMARC together. Set DMARC policy to p=reject after a monitoring phase. Review DMARC reports weekly.

Pitfall 2: "HTTPS is Only for Login Pages"

Mistake: Using HTTPS only for login pages and authentication, not for the entire site. Reality: Mixed content (HTTP and HTTPS) is vulnerable to man-in-the-middle attacks. Session cookies can be stolen over HTTP. Solution: Enforce HTTPS for the entire site. Implement HSTS with includeSubDomains and preload. Redirect all HTTP to HTTPS.

Pitfall 3: "Our Cloud Storage is Secure by Default"

Mistake: Assuming cloud storage is secure out of the box. Reality: Cloud storage defaults often allow public access, permissive policies, and weak encryption. Misconfigurations are the #1 cloud security issue. Solution: Implement CSPM tools. Regularly audit bucket policies and IAM. Use least privilege access. Enable encryption and logging.

Pitfall 4: "APIs Are Internal, So They Don't Need Security"

Mistake: Assuming internal APIs are safe because they're not publicly exposed. Reality: Internal APIs are often targeted by attackers who have gained initial access. They may have weak authentication because they were "internal only." Solution: Implement authentication and authorization for all APIs, internal and external. Use API gateways for centralized security. Monitor API traffic for anomalies.

Pitfall 5: "Let's Encrypt is Not Enterprise-Grade"

Mistake: Avoiding Let's Encrypt because it's free. Reality: Let's Encrypt certificates are trusted by all major browsers and operating systems. The ACME protocol enables automated renewal, which is actually more secure than manual renewal. Solution: Use Let's Encrypt for public-facing services. Use an internal CA (AD CS, Smallstep) for internal services. Automate certificate management with monitoring.

Pitfall 6: "We Can Skip Certificate Monitoring"

Mistake: Not monitoring certificate expiry. Reality: Certificate expiry causes service outages, man-in-the-middle vulnerabilities, and loss of trust. Even large organizations have experienced outages from expired certificates. Solution: Implement automated certificate expiry monitoring. Alert at 30, 14, 7, and 1 days before expiry. Use ACME for automated renewal where possible.

Pitfall 7: "Guest Wi-Fi Doesn't Need Security"

Mistake: Leaving guest Wi-Fi open or with a simple password. Reality: Guest Wi-Fi can be used to attack the corporate network if not properly isolated. It can also be used for illegal activities that are traced to the organization. Solution: Use WPA2-Enterprise or WPA3-Enterprise for guest Wi-Fi with captive portals. Isolate guest traffic on a separate VLAN with no access to corporate resources. Implement bandwidth limits and terms of service.

Pitfall 8: "We Don't Need to Monitor Internal Services"

Mistake: Only monitoring external-facing services. Reality: Internal services are often the target of lateral movement, insider threats, and advanced persistent threats. Monitoring internal services is essential for detecting breaches. Solution: Integrate all service logs (DNS, email, web, file sharing, remote access) into the SIEM. Configure alerts for anomalies, unauthorized access, and misuse. Monitor east-west traffic.

Pitfall 9: "Split Tunneling Saves Bandwidth"

Mistake: Using VPN split tunneling to reduce bandwidth overhead. Reality: Split tunneling allows malware on the home network to access the corporate VPN. It bypasses corporate security controls for internet traffic. Solution: Use full tunneling for all VPN connections. If split tunneling is required, implement strict endpoint security and DNS security.

Pitfall 10: "We Can Use the Same Password for All Service Accounts"

Mistake: Reusing passwords across multiple service accounts. Reality: A breach of one service can lead to compromise of all services that share the same credentials. Service accounts are often targeted because they have elevated privileges. Solution: Use unique, complex passwords for each service account. Implement PAM (Privileged Access Management) for service account management. Rotate service account passwords regularly. Use managed service accounts where possible.

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1: Indian NBFC, "From Email Chaos to Email Fortress"

Organization: A 250-employee NBFC in Mumbai providing vehicle loans and microfinance. ISO 27001 certified but with weak email security.

Challenge: The NBFC had no email authentication (SPF, DKIM, DMARC). Their email server had an open SMTP relay that allowed anyone to send email through their domain. An attacker discovered the open relay and sent phishing emails to 30,000 customers impersonating the NBFC. The emails directed customers to a fake loan portal that harvested credentials and banking information. The attacker used the stolen credentials to access the NBFC's customer portal and modify loan repayment accounts, diverting INR 50 lakh in customer payments to the attacker's accounts. RBI imposed a penalty of INR 1.5 crore and required the NBFC to implement email security controls within 30 days. The NBFC's domain was also blacklisted by major email providers, causing legitimate emails to be marked as spam.

Solution: The NBFC engaged Singahi to implement email security controls:

1. Week 1: Closed the open SMTP relay. Implemented authenticated SMTP with username/password required for all outbound email. Deployed an email gateway (Fortinet FortiMail) for inbound and outbound filtering.
2. Week 2: Implemented SPF with -all (hard fail) for all domains. Implemented DKIM signing for all outgoing email. Implemented DMARC with p=quarantine (monitoring phase) and reviewed reports daily.
3. Week 3: Implemented DMARC with p=reject after confirming legitimate senders. Implemented email DLP to prevent sensitive customer data from leaving via email. Implemented email encryption for sensitive communications.
4. Week 4: Trained all staff on email security, phishing awareness, and incident reporting. Implemented email archiving for compliance. Monitored DMARC reports and email gateway logs continuously.

Results:

• Email authentication: None → SPF, DKIM, DMARC reject for all 5 domains
• Open SMTP relay: Open → Closed with authenticated relay only
• Phishing emails blocked: 0 → 500+ per month
• Customer complaints about spam: 200+ → 0
• Domain blacklisting: Blacklisted on 12 RBLs → Cleared from all RBLs
• RBI compliance: Penalty and 30-day requirement → Zero non-conformities
• overhead: INR 2,50,000 for email gateway and consulting. ROI: The fraud overhead INR 50 lakh + RBI penalty of INR 1.5 crore = INR 2 crore. The email security investment paid for itself 8x in the first year.

Quote from the CTO: "We thought email was 'just email' and didn't need special security. The incident proved that email is the most critical security control in our organization. Singahi helped us implement enterprise email security in 4 weeks, and we haven't had a single email-related incident since."

Illustrative Scenario 2: Indian SaaS Company, "Securing the Cloud-Native Stack"

Organization: A 150-employee SaaS company in Bangalore providing HR management software to 500+ Indian enterprises. Cloud-native architecture on AWS.

Challenge: The company had grown rapidly without formal security controls. Their AWS environment had 47 S3 buckets, 12 of which were publicly accessible. Their APIs had no authentication for some legacy endpoints. Their web application had no WAF. Their DNS was managed through a basic registrar without DNSSEC. An attacker used automated scanning tools to discover the public S3 buckets, which contained customer HR data (salaries, PAN numbers, bank account details) for 200,000 employees across 50 companies. The attacker exfiltrated the data and demanded INR 1 crore ransom. The company had no CSPM, no WAF, no API security, and no cloud monitoring. The incident was reported to CERT-In and caused the company to lose 30% of its customers.

Solution: The company engaged Singahi to secure their cloud-native stack:

1. Phase 1 (Cloud Storage): Implemented AWS Macie for data classification and Prowler for security scanning. Secured all 47 S3 buckets with private access, bucket policies, and IAM least privilege. Removed 12 public buckets and implemented versioning and logging.
2. Phase 2 (API Security): Implemented AWS API Gateway for all APIs with authentication (OAuth 2.0), rate limiting, and input validation. Removed legacy unauthenticated endpoints. Implemented AWS WAF for API protection.
3. Phase 3 (Web Security): Deployed AWS WAF with OWASP CRS for the web application. Implemented HTTPS enforcement, HSTS, CSP, and security headers. Implemented CloudFront CDN with DDoS protection.
4. Phase 4 (DNS Security): Migrated DNS to AWS Route 53 with DNSSEC. Implemented DNS filtering with AWS Shield for DDoS protection. Implemented DoH for internal DNS queries.
5. Phase 5 (Monitoring): Implemented AWS GuardDuty for threat detection. Integrated CloudTrail, VPC Flow Logs, and WAF logs into AWS Security Lake. Configured alerts for anomalies, unauthorized access, and data exfiltration.
6. Phase 6 (Compliance): Implemented automated compliance checks with AWS Config rules. Generated compliance reports for SOC 2 and ISO 27001. Conducted quarterly penetration testing of APIs and web applications.

Results:

• Public S3 buckets: 12 → 0
• APIs without authentication: 8 → 0
• WAF deployment: None → AWS WAF on all public endpoints
• DNSSEC: None → Deployed on all domains
• Cloud security incidents: 3 per quarter → 0 (ongoing)
• Customer retention: 70% → 95% (recovered customers after security improvements)
• SOC 2 Type II: None → Achieved in 6 months
• overhead: INR 4,50,000 for cloud security tools and consulting. ROI: The data breach overhead INR 1 crore (ransom) + INR 2 crore (lost customers, legal, remediation) = INR 3 crore. The cloud security investment paid for itself 7x in the first year.

Quote from the CEO: "We were a 'move fast and break things' startup. We learned that in B2B SaaS, security is not a feature, it's a prerequisite. Singahi helped us transform our cloud security posture from 'default open' to 'default secure' without slowing down our product development."

Multi-Framework Mapping

Regulatory and Industry Context

Indian Regulatory Requirements

Industry-Specific Context

Banking (RBI):

• SWIFT messaging requires secure email and file transfer with encryption and authentication
• Payment gateways (UPI, NPCI) require secure APIs with rate limiting and input validation
• Customer portals require HTTPS, WAF, and session security
• RBI mandates email authentication (SPF, DKIM, DMARC) for all banking domains

Healthcare (NABH):

• Patient portals require secure web services with HTTPS, MFA, and WAF
• PACS web services require DICOM-specific security controls and access logging
• Telemedicine platforms require secure video conferencing with encryption and access controls
• Medical device APIs require authentication and data integrity protection

Manufacturing (Make in India / Industry 4.0):

• IoT MQTT services require authentication, encryption, and topic-level access control
• SCADA web services require industrial WAF and protocol-specific security
• Vendor file exchange requires secure file transfer (SFTP, MFT) with encryption
• OT remote access requires vendor-specific secure access with session recording

Telecom (TRAI):

• 5G core services require secure APIs with mTLS and service mesh security
• Signaling services (SS7, Diameter, GTP) require signaling firewalls and intrusion detection
• BSS/OSS APIs require authentication, rate limiting, and fraud detection
• Customer portals require WAF, DDoS protection, and API security

RACI Matrix

A = Accountable, R = Responsible, C = Consulted, I = Informed

Documentation and Evidence Requirements

Documents Required

1. Network Services Security Policy, Approved by management
2. Network Services Inventory, Complete list of all services with owners, users, and security requirements
3. Service Agreements/SLAs, For internal and external services
4. DNS Configuration Documentation, DNSSEC, zone files, resolver configuration
5. Email Authentication Records, SPF, DKIM, DMARC records and reports
6. Email Gateway Configuration, Filtering rules, DLP policies, encryption settings
7. Web Server Configuration, HTTPS, HSTS, security headers, WAF rules
8. API Gateway Configuration, Authentication, rate limiting, throttling policies
9. File Share Access Control Documentation, Permissions, access reviews, DLP policies
10. Cloud Storage Configuration, Bucket policies, IAM, encryption, logging
11. Remote Access Configuration, VPN settings, MFA, session policies
12. Directory Service Configuration, LDAP/Kerberos/RADIUS settings, encryption
13. Certificate Inventory, All certificates with expiry dates, owners, and renewal procedures
14. Service Monitoring Configuration, SIEM integration, alert rules, dashboards
15. Service Change Records, All changes with approval and testing
16. Service Penetration Test Reports, Annual or bi-annual testing
17. Service Vulnerability Scan Reports, Quarterly scanning
18. Incident Records, Security incidents related to network services
19. Training Records, Staff training on service security policies
20. Vendor Security Assessments, For outsourced network services

Evidence Retention

• Policies and procedures: Retain current version + all previous versions for 7 years
• Service inventory: Update monthly; retain historical snapshots for 3 years
• Service agreements: Retain for 7 years after termination
• Email logs: Retain for 1 year (or as per regulatory requirements)
• DNS logs: Retain for 1 year
• Web access logs: Retain for 1 year
• API logs: Retain for 1 year
• File access logs: Retain for 3 years
• Remote access logs: Retain for 3 years
• Certificate records: Retain for the lifetime of the certificate + 3 years
• Incident records: Retain for 7 years
• Training records: Retain for 3 years after employee departure
• Audit reports: Retain for 7 years

Continuous Improvement

Maturity Model for A.8.21

Improvement Roadmap

• From Level 1 to 2: Create basic service inventory. Implement SPF. Enable HTTPS on main sites. Implement basic access controls. Enable logging.
• From Level 2 to 3: Implement complete SPF/DKIM/DMARC. Deploy WAF. Implement MFA for all remote access. Remove legacy protocols. Document policies and SLAs.
• From Level 3 to 4: Implement CASB/CSPM. Deploy API security gateway. Implement DLP for email and file sharing. Automate certificate management. Conduct regular pen testing.
• From Level 4 to 5: Implement AI-powered email security and anomaly detection. Deploy SASE architecture. Implement full zero-trust for all services. Use predictive analytics for threat prevention. Implement self-healing service recovery.

FAQ

Q1: Does A.8.21 require DMARC with p=reject? A: While the standard doesn't explicitly mandate p=reject, it requires email security mechanisms that prevent spoofing. DMARC with p=reject is the industry best practice and is required by many regulators (RBI, SEBI). Start with p=none to monitor, then move to p=quarantine, and finally p=reject.

Q2: How do we secure legacy APIs that don't support modern authentication? A: Implement an API gateway in front of legacy APIs to add authentication, rate limiting, and logging. Use the API gateway as a security proxy. Plan to modernize the APIs over time. Consider network segmentation to limit legacy API exposure.

Q3: Is DNSSEC really necessary? A: Yes, DNSSEC prevents DNS spoofing and cache poisoning, which are common attack vectors. It is mandatory for banking domains under RBI guidelines. It is also increasingly required for government domains under MeitY guidelines. Implementation is straightforward with modern DNS providers.

Q4: What is the minimum email security for a small organization? A: At minimum: SPF with -all, DKIM signing, DMARC with p=reject, an email gateway for spam/malware filtering, and TLS for all email transmission. For cloud email (Microsoft 365, Google Workspace), enable all built-in security features ( Defender for Office 365, Google Workspace security).

Q5: How do we monitor cloud storage misconfigurations? A: Use CSPM tools (Prisma Cloud, Orca, Prowler, ScoutSuite) to continuously scan cloud storage for public access, weak policies, and encryption gaps. Implement automated alerts for misconfigurations. Conduct manual audits quarterly.

Q6: Can we use Let's Encrypt for internal services? A: No, Let's Encrypt issues public certificates for public domains only. For internal services, use an internal CA (AD CS, Smallstep, Easy-RSA) or a commercial CA with private trust. Some organizations use public certificates for internal services with public DNS records (split-horizon DNS).

Q7: What is the difference between CASB and CSPM? A: CASB (Cloud Access Security Broker) monitors and controls user access to cloud services (SaaS). CSPM (Cloud Security Posture Management) monitors and secures cloud infrastructure (IaaS, PaaS) configurations. Both are needed for complete cloud security.

Q8: How do we handle third-party APIs that don't support strong authentication? A: Use an API gateway or integration platform to add authentication and logging. Use IP whitelisting and mutual TLS where possible. Document the risk and implement compensating controls (monitoring, rate limiting, data validation). Consider alternative vendors if the risk is unacceptable.

Q9: Is MTA-STS necessary if we already have TLS? A: Yes, MTA-STS enforces TLS for email delivery and prevents downgrade attacks. It complements TLS by ensuring that TLS is always used, even if the connecting server attempts to use plaintext. It is recommended by NIST and is becoming a standard requirement.

Q10: How do we measure the effectiveness of our network service security? A: Key metrics: DMARC pass rate, phishing simulation click rate, WAF block rate, API abuse attempts, cloud storage misconfigurations, certificate expiry incidents, unauthorized service access attempts, and service-related security incidents.

The following toolkit assets are available for this control:

References

1. ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection, Information Security Management Systems, Requirements
2. ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection, Information security controls
3. NIST Cybersecurity Framework 2.0, Identify, Protect, Detect, Respond, Recover, Govern
4. CIS Controls v8, Control 9: Email and Web Browser Protections
5. PCI DSS v4.0, Requirements 1.x, 2.x, 4.x, 8.x
6. RBI Cyber Security Framework, Email and DNS security requirements for banking
7. CERT-In Guidelines, Network service security for critical infrastructure
8. NIST SP 800-177, Trustworthy Email
9. NIST SP 800-52 Rev 2, Guidelines for TLS Implementation
10. OWASP API Security Top 10, API security risks and mitigations
11. M3AAWG, Messaging, Malware and Mobile Anti-Abuse Working Group best practices
12. CISA Cloud Security Guidance, Cloud storage and service security
13. Internet Society DNSSEC Deployment Guide, DNSSEC implementation guidance

This guide is part of the Singahi ISO 27001:2022 Annex A Control Guide Series.

Contact: security@singahi.com | singahi.com """

path = 'guide.md'
with open(path, 'w') as f:
    f.write(content)
return {"path": path, "bytes": len(content), "lines": content.count(chr(10))}