Network Security covers controls to secure and protect networks, including securing virtual networks, establishing private connections, preventing, and mitigating external attacks, and securing DNS.
NS-1: Establish network segmentation boundaries
CIS Controls v8 ID(s)
NIST SP 800-53 r4 ID(s)
PCI-DSS ID(s) v3.2.1
3.12, 13.4, 4.4
AC-4, SC-2, SC-7
1.1, 1.2, 1.3
Security principle: Ensure that your virtual network deployment aligns to your enterprise segmentation strategy defined in the GS-2 security control. Any workload that could incur higher risk for the organization should be in isolated virtual networks.
Examples of high-risk workload include:
An application storing or processing highly sensitive data.
An external network-facing application accessible by the public or users outside of your organization.
An application using insecure architecture or containing vulnerabilities that cannot be easily remediated.
To enhance your enterprise segmentation strategy, restrict or monitor traffic between internal resources using network controls. For specific, well-defined applications (such as a 3-tier app), this can be a highly secure "deny by default, permit by exception" approach by restricting the ports, protocols, source, and destination IPs of the network traffic. If you have many applications and endpoints interacting with each other, blocking traffic may not scale well, and you may only be able to monitor traffic.
Azure guidance: Create a virtual network (VNet) as a fundamental segmentation approach in your Azure network, so resources such as VMs can be deployed into the VNet within a network boundary. To further segment the network, you can create subnets inside VNet for smaller sub-networks.
Use network security groups (NSG) as a network layer control to restrict or monitor traffic by port, protocol, source IP address, or destination IP address. Refer to NS-7: Simplify network security configuration to use Adaptive Network Hardening to recommend NSG hardening rules based on threat intelligence and traffic analysis result.
You can also use application security groups (ASGs) to simplify complex configuration. Instead of defining policy based on explicit IP addresses in network security groups, ASGs enable you to configure network security as a natural extension of an application's structure, allowing you to group virtual machines and define network security policies based on those groups.
AWS guidance: Create a Virtual Private Cloud (VPC) as a fundamental segmentation approach in your AWS network, so resources such as EC2 instances can be deployed into the VPC within a network boundary. To further segment the network, you can create subnets inside VPC for smaller sub-networks.
For EC2 instances, use Security Groups as a stateful firewall to restrict traffic by port, protocol, source IP address, or destination IP address. At the VPC subnet level, use Network Access Control List (NACL) as a stateless firewall to have explicit rules for ingress and egress traffic to the subnet.
Note: To control VPC traffic, Internet and NAT Gateway should be configured to ensure the traffic from/to the internet are restricted.
GCP guidance: Create a virtual private cloud (VPC) network as a fundamental segmentation approach in your GCP network, so resources such as compute engine virtual machine instances (VMs) can be deployed into the VPC network within a network boundary. To further segment the network, you can create subnets inside the VPC for smaller sub-networks.
Use VPC firewall rules as a distributed network layer control to allow or deny connections to or from your targeted instances in the VPC network, which include VMs, Google Kubernetes Engine (GKE) clusters, and App Engine flexible environment instances.
You can also configure VPC firewall rules to target all instances in the VPC network, instances with a matching network tag, or instances that use a specific service account, allowing you to group instances and define network security policies based on those groups.
NS-2: Secure cloud native services with network controls
CIS Controls v8 ID(s)
NIST SP 800-53 r4 ID(s)
PCI-DSS ID(s) v3.2.1
3.12, 4.4
AC-4, SC-2, SC-7
1.1, 1.2, 1.3
Security principle: Secure cloud services by establishing a private access point for resources. You should also disable or restrict access from public networks when possible.
Azure guidance: Deploy private endpoints for all Azure resources that support the Private Link feature to establish a private access point for the resources. Using Private Link will keep the private connection from routing through the public network.
Note: Certain Azure services may also allow private communication through the service endpoint feature, though it is recommended to use Azure Private Link for secure and private access to services hosted on Azure platform.
For certain services, you can choose to deploy VNet integration for the service where you can restrict the VNET to establish a private access point for the service.
You also have the option to configure the service native network ACL rules or simply disable public network access to block access from public networks.
For Azure VMs, unless there is a strong use case, you should avoid assigning public IPs/subnet directly to the VM interface and instead use gateway or load balancer services as the front-end for access by the public network.
AWS guidance: Deploy VPC PrivateLink for all AWS resources that support the PrivateLink feature, to allow private connection to the supported AWS services or services hosted by other AWS accounts (VPC endpoint services). Using PrivateLink will keep the private connection from routing through the public network.
For certain services, you can choose to deploy the service instance into your own VPC to isolate the traffic.
You also have the option to configure the service native ACL rules to block access from the public network. For example, Amazon S3 allows you to block public access at the bucket or account level.
When assigning IPs to your service resources in your VPC, unless there is a strong use case, you should avoid assigning public IPs/subnet directly to your resources and instead use private IPs/subnet.
GCP guidance: Deploy VPC Private Google Access implementations for all GCP resources that support it to establish a private access point for the resources. These private access options will keep the private connection from routing through the public network. Private Google Access has VM instances that only have internal IP addresses (no external IP adresses)
For certain services, you can choose to deploy the service instance into your own VPC to isolate the traffic. You also have the option to configure the service native ACL rules to block access from the public network. For example, the App Engine firewall allows you to control which network traffic is allowed or rejected when communicating with the App Engine resource. Cloud Storage is another resource where you can enforce public access prevention on individual buckets or at the organization level.
For GCP Compute Engine VMs, unless there is a strong use case, you should avoid assigning public IPs/subnets directly to the VM interface and instead use gateway or load balancer services as the front-end for access by the public network.
NS-3: Deploy firewall at the edge of enterprise network
CIS Controls v8 ID(s)
NIST SP 800-53 r4 ID(s)
PCI-DSS ID(s) v3.2.1
4.4, 4.8, 13.10
AC-4, SC-7, CM-7
1.1, 1.2, 1.3
Security principle: Deploy a firewall to perform advanced filtering on network traffic to and from external networks. You can also use firewalls between internal segments to support a segmentation strategy. If required, use custom routes for your subnet to override the system route when you need to force the network traffic to go through a network appliance for security control purposes.
At a minimum, block known bad IP addresses and high-risk protocols, such as remote management (for example, RDP and SSH) and intranet protocols (for example, SMB and Kerberos).
Azure guidance: Use Azure Firewall to provide fully stateful application layer traffic restriction (such as URL filtering) and/or central management over a large number of enterprise segments or spokes (in a hub/spoke topology).
If you have a complex network topology, such as a hub/spoke setup, you may need to create user-defined routes (UDR) to ensure the traffic goes through the desired route. For example, you have the option to use an UDR to redirect egress internet traffic through a specific Azure Firewall or a network virtual appliance.
AWS guidance: Use AWS Network Firewall to provide fully stateful application layer traffic restriction (such as URL filtering) and/or central management over a large number of enterprise segments or spokes (in a hub/spoke topology).
If you have a complex network topology, such as a hub/spoke setup, you may need to create custom VPC route tables to ensure the traffic goes through the desired route. For example, you have the option to use a custom route to redirect egress internet traffic through a specific AWS Firewall or a network virtual appliance.
GCP guidance: Use Google Cloud Armor security policies to provide Layer 7 filtering and protection of common web attacks. Additionally, use VPC firewall rules to provide distributed, fully stateful network layer traffic restriction, and firewall policies for central management over a large number of enterprise segments or spokes (in a hub/spoke topology).
If you have a complex network topology, such as a hub/spoke setup, create firewall policies that group firewall rules and to be hierarchical so that they may be applied to multiple VPC networks.
NS-4: Deploy intrusion detection/intrusion prevention systems (IDS/IPS)
CIS Controls v8 ID(s)
NIST SP 800-53 r4 ID(s)
PCI-DSS ID(s) v3.2.1
13.2, 13.3, 13.7, 13.8
SC-7, SI-4
11.4
Security principle: Use network intrusion detection and intrusion prevention systems (IDS/IPS) to inspect the network and payload traffic to or from your workload. Ensure that IDS/IPS is always tuned to provide high-quality alerts to your SIEM solution.
For more in-depth host level detection and prevention capability, use host-based IDS/IPS or a host-based endpoint detection and response (EDR) solution in conjunction with the network IDS/IPS.
Azure guidance: Use Azure Firewall’s IDPS capabilities to protect your virtual network to alert on and/or block traffic to and from known malicious IP addresses and domains.
For more in-depth host level detection and prevention capability, deploy host-based IDS/IPS or a host-based endpoint detection and response (EDR) solution, such as Microsoft Defender for Endpoint, at the VM level in conjunction with the network IDS/IPS.
AWS guidance: Use AWS Network Firewall’s IPS capability to protect your VPC to alert on and/or block traffic to and from known malicious IP addresses and domains.
For more in-depth host level detection and prevention capabilities, deploy host-based IDS/IPS or a host-based endpoint detection and response (EDR) solution, such as third-party solution for host-based IDS/IPS, at the VM level in conjunction with the network IDS/IPS.
Note: If using a third-party IDS/IPS from marketplace, use Transit Gateway and Gateway Balancer to direct the traffic for in-line inspection.
GCP guidance: Use Google Cloud IDS capabilities to provides threat detection for intrusions, malware, spyware, and command-and-control attacks on your network. Cloud IDS works by creating a Google-managed peered network with mirrored virtual machine (VM) instances. Traffic in the peered network is mirrored and then inspected by embedded Palo Alto Networks threat protection technologies to provide advanced threat detection. You can mirror all ingress and egress traffic based on protocol, or IP address range.
For more in-depth host level-detection and prevention capabilities, deploy an IDS endpoint as a zonal resource that can inspect traffic from any zone in its region. Each IDS endpoint receives mirrored traffic and performs threat detection analysis.
Security principle: Deploy distributed denial of service (DDoS) protection to protect your network and applications from attacks.
Azure guidance: DDoS Protection Basic is automatically enabled to protect the Azure underlying platform infrastructure (e.g. Azure DNS) and requires no configuration from the users.
For higher levels of protection of your application layer (Layer 7) attacks such as HTTP floods and DNS floods, enable the DDoS standard protection plan on your VNet to protect resources that are exposed to the public networks.
AWS guidance: AWS Shield Standard is automatically enabled with standard mitigations to protect your workload from common network and transport layer (Layer 3 and 4) DDoS attacks
For higher levels of protection of your applications against application layer (Layer 7) attack such as HTTPS floods and DNS floods, enable AWS Shield Advanced protection on Amazon EC2, Elastic Load Balancing (ELB), Amazon CloudFront, AWS Global Accelerator, and Amazon Route 53.
GCP guidance: Google Cloud Armor offers the following options to help protect systems against DDoS attacks:
Standard network DDoS protection: basic always-on protection for network load balancers, protocol forwarding, or VM’s with public IP addresses.
Advanced network DDoS protection: additional protections for Managed Protection Plus subscribers who use network load balancers, protocol forwarding, or VM’s with public IP addresses.
Standard network DDoS protection is always enabled. You configure advanced network DDoS protection on a per-region basis.
Security principle: Deploy a web application firewall (WAF) and configure the appropriate rules to protect your web applications and APIs from application-specific attacks.
Azure guidance: Use web application firewall (WAF) capabilities in Azure Application Gateway, Azure Front Door, and Azure Content Delivery Network (CDN) to protect your applications, services and APIs against application layer attacks at the edge of your network.
Set your WAF in "detection" or "prevention mode", depending on your needs and threat landscape.
Choose a built-in ruleset, such as OWASP Top 10 vulnerabilities, and tune it to your application needs.
AWS guidance: Use AWS Web Application Firewall (WAF) in Amazon CloudFront distribution, Amazon API Gateway, Application Load Balancer, or AWS AppSync to protect your applications, services and APIs against application layer attacks at the edge of your network.
Use AWS Managed Rules for WAF to deploy built-in baseline groups and customize it to your application needsfor the user-case rule groups.
To simplify the WAF rules deployment, you can also use the AWS WAF Security Automations solution to automatically deploy pre-defined AWS WAF rules that filters web-based attacks on your web ACL.
GCP guidance: Use Google Cloud Armor to help protect your applications and websites against denial of service and web attacks.
Use Google Cloud Armor out-of-the box rules based on industry standards to mitigate common web-application vulnerabilities and help provide protection from OWASP Top 10.
Setup your preconfigured WAF rules, each consisting of multiple signatures sourced from ModSecurity Core Rules (CRS). Each signature corresponds to an attack detection rule in the ruleset.
Cloud Armor works in conjunction with external load balancers and protects from distributed denial-of-service (DDoS) and other web-based attacks, whether the applications are deployed on Google Cloud, in a hybrid deployment, or in a multi-cloud architecture. Security policies can be configured manually, with configurable match conditions, and actions in a security policy. Cloud Armor also features preconfigured security policies, which cover a variety of use cases.
Adaptive Protection in Cloud Armor helps you prevent, detect and protect your application and services from L7 distributed attacks by analyzing patterns of traffic to your backend services, detecting and alerting suspected attacks, and generating suggested WAF rules to mitigate such attacks. These rules can be fine-tuned to meet your needs.
Security principle: When managing a complex network environment, use tools to simplify, centralize and enhance network security management.
Azure guidance: Use the following features to simplify the implementation and management of the virtual network, NSG rules, and Azure Firewall rules:
Use Azure Virtual Network Manager to group, configure, deploy, and manage virtual networks and NSG rules across regions and subscriptions.
Use Microsoft Defender for Cloud Adaptive Network Hardening to recommend NSG hardening rules that further limit ports, protocols and source IPs based on threat intelligence and traffic analysis result.
Use Azure Firewall Manager to centralize the firewall policy and route management of the virtual network. To simplify the firewall rules and network security groups implementation, you can also use the Azure Firewall Manager Azure Resource Manager(ARM) template.
AWS guidance: Use AWS Firewall Manager to centralize the network protection policy management across the following services:
AWS WAF policies
AWS Shield Advanced policies
VPC security group policies
Network Firewall policies
AWS Firewall Manager can automatically analyze your firewall-related policies and create findings for non-compliant resources and for detected attacks and send them to AWS Security Hub for investigations.
GCP guidance: Use the following features to simplify the implementation and management of the virtual private cloud (VPC) network, firewall rules, and WAF rules:
Use VPC Networks to manage and configure individual VPC networks and VPC firewall rules.
Use Hierarchical Firewall policies to group firewall rules and apply the policy rules hierarchically at a global or regional scale.
Use Google Cloud Armor to apply custom security policies, pre-configured WAF rules, and DDoS protection.
You can also the Network Intelligence Center to analyze your network and gain insights into your virtual network topology, firewall rules and network connectivity status to improve management efficiency.
NS-8: Detect and disable insecure services and protocols
CIS Controls v8 ID(s)
NIST SP 800-53 r4 ID(s)
PCI-DSS ID(s) v3.2.1
4.4, 4.8
CM-2, CM-6, CM-7
4.1, A2.1, A2.2, A2.3
Security principle: Detect and disable insecure services and protocols at the OS, application, or software package layer. Deploy compensating controls if disabling insecure services and protocols are not possible.
Azure guidance: Use Microsoft Sentinel’s built-in Insecure Protocol Workbook to discover the use of insecure services and protocols such as SSL/TLSv1, SSHv1, SMBv1, LM/NTLMv1, wDigest, weak ciphers in Kerberos, and Unsigned LDAP Binds. Disable insecure services and protocols that do not meet the appropriate security standard.
Note: If disabling insecure services or protocols is not possible, use compensating controls such as blocking access to the resources through network security group, Azure Firewall, or Azure Web Application Firewall to reduce the attack surface.
AWS guidance: Enable VPC Flow Logs and use GuardDuty to analyze the VPC Flow Logs to identify the possible insecure services and protocols that do not meet the appropriate security standard.
If the logs in the AWS environment can be forwarded to Microsoft Sentinel, you can also use Microsoft Sentinel's built-in Insecure Protocol Workbook to discover the use of insecure services and protocols
Note: If disabling insecure services or protocols is not possible, use compensating controls such as blocking access to the resources through security groups, AWS Network Firewall, AWS Web Application Firewall to reduce the attack surface.
GCP guidance: Enable VPC Flow Logs and use BigQuery or Security Command Center to analyze the VPC Flow Logs to identify the possible insecure services and protocols that do not meet the appropriate security standard.
If the logs in the GCP environment can be forwarded to Microsoft Sentinel, you can also use the Microsoft Sentinel’s built-in Insecure Protocol Workbook to discover the use of insecure services and protocols. Additional you can forward logs to Google Cloud Chronicle SIEM and SOAR and build custom rules for the same purpose.
Note: If disabling insecure services or protocols is not possible, use compensating controls such as blocking access to the resources through VPC Firewall rules and policies, or Cloud Armor to reduce the attack surface.
NS-9: Connect on-premises or cloud network privately
CIS Controls v8 ID(s)
NIST SP 800-53 r4 ID(s)
PCI-DSS ID(s) v3.2.1
12.7
CA-3, AC-17, AC-4
N/A
Security principle: Use private connections for secure communication between different networks, such as cloud service provider datacenters and on-premises infrastructure in a colocation environment.
Azure guidance: For lightweight site-to-site or point-to-site connectivity, use Azure virtual private network (VPN) to create a secure connection between your on-premises site or end-user device and the Azure virtual network.
For enterprise-level high performance connections, use Azure ExpressRoute (or Virtual WAN) to connect Azure datacenters and on-premises infrastructure in a co-location environment.
When connecting two or more Azure virtual networks together, use virtual network peering. Network traffic between peered virtual networks is private and is kept on the Azure backbone network.
AWS guidance: For site-to-site or point-to-site connectivity, use AWS VPN to create a secure connection (when IPsec overhead is not a concern) between your on-premises site or end-user device to the AWS network.
For enterprise-level high performance connections, use AWS Direct Connect to connect AWS VPCs and resources with your on-premises infrastructure in a co-location environment.
You have the option to use VPC Peering or Transit Gateway to establish connectivity between two or more VPCs within or across regions. Network traffic between peered VPC is private and is kept on the AWS backbone network. When you need to join multiple VPCs to create a large flat subnet, you also have the option to use VPC Sharing.
GCP guidance: For lightweight site-to-site or point-to-site connectivity use Google Cloud VPN.
For enterprise-level high performance connections, use Google Cloud Interconnect or Partner Interconnect, to connect to Google Cloud VPCs and resources with your on-premises infrastructure in a colocation environment.
You have the option to use VPC Network Peering or Network Connectivity Center to establish connectivity between two or more VPCs within or across regions. Network traffic between peered VPCs is private and is kept on the GCP backbone network. When you need to join multiple VPCs to create a large flat subnet, you also have the option to use Shared VPC
Security principle: Ensure that Domain Name System (DNS) security configuration protects against known risks:
Use trusted authoritative and recursive DNS services across your cloud environment to ensure the client (such as operating systems and applications) receives the correct resolution result.
Separate the public and private DNS resolution so the DNS resolution process for the private network can be isolated from the public network.
Ensure your DNS security strategy also includes mitigations against common attacks, such as dangling DNS, DNS amplifications attacks, DNS poisoning and spoofing, and so on.
Azure guidance: Use Azure recursive DNS (usually assigned to your VM through DHCP or preconfigured in the service) or a trusted external DNS server in your workload recursive DNS setup, such as in the VM's operating system or in the application.
Use Azure Private DNS for a private DNS zone setup where the DNS resolution process does not leave the virtual network. Use a custom DNS to restrict the DNS resolution to only allow trusted resolution to your client.
Use Microsoft Defender for DNS for advanced protection against the following security threats to your workload or your DNS service:
Data exfiltration from your Azure resources using DNS tunneling
Malware communicating with a command-and-control server
Communication with malicious domains, such as phishing and crypto mining
DNS attacks in communication with malicious DNS resolvers
You can also use Microsoft Defender for App Service to detect dangling DNS records if you decommission an App Service website without removing its custom domain from your DNS registrar.
AWS guidance: Use the Amazon DNS Server (in other words, Amazon Route 53 Resolver server which is usually assigned to you through DHCP or preconfigured in the service) or a centralized trusted DNS resolver server in your workload recursive DNS setup, such as in the VM's operating system or in the application.
Use Amazon Route 53 to create a private hosted zone setup where the DNS resolution process does not leave the designated VPCs. Use Amazon Route 53 firewall to regulate and filter the outbound DNS/UDP traffic in your VPC for the following use cases:
Prevent attacks such as DNS exfiltration in your VPC
Set up allow or deny list for the domains that your applications can query
Configure Domain Name System Security Extensions (DNSSEC) feature in Amazon Route 53 to secure DNS traffic to protect your domain from DNS spoofing or a man-in-the-middle attack.
Amazon Route 53 also provides a DNS registration service where Route 53 can be used as authoritative name servers for your domains. The following best practices should be followed to ensure the security of your domain names:
Domain names should be automatically renewed by the Amazon Route 53 service.
Domain names should have the Transfer Lock feature enabled in order to keep them secure.
The Sender Policy Framework (SPF) should be used to stop spammers from spoofing your domain.
GCP guidance: Use GCP DNS server (i.e. metadata server which is usually assigned to your VM through DHCP or preconfigured in the service) or a centralized trusted DNS resolver server (such as Google Public DNS) in your workload recursive DNS setup, such as in the VM's operating system or in the application.
Use GCP Cloud DNS to create a private DNS zone where the DNS resolution process does not leave the desginated VPCs. Regulate and filter the outbound DNS/UDP traffic in your VPC the use cases:
Prevent attacks such as DNS exfiltration in your VPC
Set up allow or deny lists for the domains that your applications query
Configure Domain Name System Security Extensions (DNSSEC) feature in Cloud DNS to secure DNS traffic to protect your domain from DNS spoofing or a man-in-the-middle attack.
Google Cloud Domains provides domain registration services. GCP Cloud DNS can be used as authoritative name servers for your domains. The following best practices should be followed to ensure the security of your domain names:
Domain names should be automatically renewed by Google Cloud Domains.
Domain names should have the Transfer Lock feature enabled in order to keep them secure
The Sender Policy Framework (SPF) should be used to stop spammers from spoofing your domain.