fix for pr acrolinx issues

Author: ceperezb

learn-pr/wwl-sci/design-solutions-network-security/includes/1a-evaluate-network-designs-best-practices.md

@@ -18,15 +18,15 @@ The [Microsoft cloud security benchmark (MCSB) v2](/security/benchmark/azure/ove
 
 | Control | Evaluation focus |
 |---|---|
-| **NS-1**: Establish network segmentation boundaries | VNet segmentation, NSGs, ASGs, subnet isolation |
-| **NS-2**: Secure cloud native services with network controls | Private endpoints, disabled public access, VNet integration, Network Security Perimeter |
+| **NS-1**: Establish network segmentation boundaries | virtual network segmentation, NSGs, ASGs, subnet isolation |
+| **NS-2**: Secure cloud native services with network controls | Private endpoints, disabled public access, virtual network integration, Network Security Perimeter |
 | **NS-3**: Deploy firewall at the edge of enterprise network | Azure Firewall, edge filtering, user-defined routes |
 | **NS-4**: Deploy intrusion detection/intrusion prevention systems (IDS/IPS) | Azure Firewall Premium IDPS, host-based EDR |
-| **NS-5**: Deploy DDoS protection | Azure DDoS Protection tiers on internet-facing VNets |
+| **NS-5**: Deploy DDoS protection | Azure DDoS Protection tiers on internet-facing virtual networks |
 | **NS-6**: Deploy web application firewall | Azure WAF on Application Gateway or Front Door |
 | **NS-7**: Manage network security centrally and effectively | Azure Virtual Network Manager Security Admin Rules, Firewall Manager, flow logs v2, Traffic Analytics |
 | **NS-8**: Detect and disable insecure services and protocols | Microsoft Sentinel insecure protocol detection |
-| **NS-9**: Connect on-premises or cloud network privately | ExpressRoute, VPN, VNet peering |
+| **NS-9**: Connect on-premises or cloud network privately | ExpressRoute, VPN, virtual network peering |
 | **NS-10**: Ensure Domain Name System (DNS) security | Azure Private DNS, Defender for DNS (included in Defender for Servers Plan) |
 
 Each MCSB v2 control also maps to industry frameworks such as CIS Controls v8.1, NIST SP 800-53 r5, PCI-DSS v4, NIST CSF v2.0, ISO 27001:2022, and SOC 2, helping you align your evaluation to regulatory and compliance requirements. When you evaluate a network design, use these controls as a checklist to identify gaps and prioritize remediation.
@@ -35,7 +35,7 @@ Each MCSB v2 control also maps to industry frameworks such as CIS Controls v8.1,
 
 Effective network segmentation aligns to MCSB v2 control NS-1. When evaluating a network design, determine whether it isolates workloads appropriately and controls traffic flow between segments. Key evaluation questions include:
 
-- Does the design use **subscriptions, VNets, and subnets** to create layered isolation boundaries between environments and workloads?
+- Does the design use **subscriptions, virtual networks, and subnets** to create layered isolation boundaries between environments and workloads?
 - Are **network security groups (NSGs)** applied to subnets with least-privilege rules, and are **application security groups (ASGs)** used to simplify rule management?
 - Does the network use a **hub-and-spoke topology** (or Azure Virtual WAN) with centralized security services in the hub and deny-by-default routing between spokes?
 - Are **Security Admin Rules** in Azure Virtual Network Manager enforcing organizational guardrails that workload teams can't override?
@@ -48,7 +48,7 @@ A strong network design applies defense-in-depth by layering multiple security c
 
 - **[Azure Firewall](/azure/firewall/overview)** as the central egress and east-west filtering point, with Premium features (TLS inspection and IDPS) for environments that require deep packet inspection.
 - **[Azure Web Application Firewall (WAF)](/azure/web-application-firewall/overview)** on Application Gateway or Azure Front Door for Layer 7 protection against OWASP top threats on web-facing applications.
-- **[Azure DDoS Protection](/azure/ddos-protection/ddos-protection-overview)** on perimeter VNets with internet-facing endpoints. Choose DDoS IP Protection for targeted deployments or DDoS Network Protection for enterprise-wide coverage.
+- **[Azure DDoS Protection](/azure/ddos-protection/ddos-protection-overview)** on perimeter virtual networks with internet-facing endpoints. Choose DDoS IP Protection for targeted deployments or DDoS Network Protection for enterprise-wide coverage.
 - **[Azure Private Link](/azure/private-link/private-link-overview)** to access PaaS services through private endpoints, removing public internet exposure and keeping traffic on the Azure backbone.
 - **[Azure Bastion](/azure/bastion/bastion-overview)** for secure RDP/SSH access without exposing management ports, combined with just-in-time (JIT) VM access to limit when ports are open.
 - **Azure ExpressRoute** for hybrid connectivity that keeps sensitive traffic off the public internet.
@@ -72,7 +72,7 @@ Later units in this module cover Internet Access and Private Access evaluation i
 A network design is incomplete without continuous visibility. MCSB v2 controls NS-7 and NS-8 emphasize centralized network security management and detecting insecure protocols. Evaluate whether the design includes:
 
 - **Microsoft Defender for Cloud** networking recommendations, attack path analysis, and adaptive network hardening for continuous posture assessment.
-- **VNet flow logs** and **Traffic Analytics** for traffic pattern analysis across the environment.
+- **Virtual network flow logs** and **Traffic Analytics** for traffic pattern analysis across the environment.
 - **Azure Firewall structured logs** with IDPS and threat intelligence logging enabled.
 - **Centralized SIEM integration** that sends network logs to Microsoft Sentinel for cross-source correlation and incident detection.
 

learn-pr/wwl-sci/design-solutions-network-security/includes/2-design-solutions-network-segmentation.md

@@ -20,9 +20,9 @@ Subscriptions provide the broadest isolation boundary. Resources in different su
 
 ### Virtual networks and subnets
 
-[Virtual networks (VNets)](/azure/virtual-network/virtual-networks-overview) provide network-level containment within a subscription. No traffic flows between VNets by default—you must explicitly enable communication through peering, VPN, or routing. This default isolation is a security advantage.
+[Azure Virtual Networks](/azure/virtual-network/virtual-networks-overview) provide network-level containment within a subscription. No traffic flows between virtual networks by default—you must explicitly enable communication through peering, VPN, or routing. This default isolation is a security advantage.
 
-Within each VNet, subnets create internal boundaries. Use [network security groups (NSGs)](/azure/virtual-network/network-security-groups-overview) on subnets to filter traffic by port, protocol, and source or destination IP address. Design NSG rules following deny-by-default principles—allow only the traffic each workload requires and deny everything else.
+Within each virtual network, subnets create internal boundaries. Use [network security groups (NSGs)](/azure/virtual-network/network-security-groups-overview) on subnets to filter traffic by port, protocol, and source or destination IP address. Design NSG rules following deny-by-default principles—allow only the traffic each workload requires and deny everything else.
 
 [Application security groups (ASGs)](/azure/virtual-network/application-security-groups) simplify NSG rules by grouping virtual machines by application role. Instead of managing rules based on individual IP addresses, you reference ASGs in your NSG rules. This approach reduces rule complexity and the risk of misconfiguration as your environment scales.
 
@@ -34,25 +34,25 @@ For PaaS services, [Azure Network Security Perimeter](/azure/private-link/networ
 
 Your topology determines how segments connect and how traffic flows between them. Choose a pattern based on the number of workloads, regions, and the level of centralized control you need.
 
-### Single VNet with subnet segmentation
+### Single virtual network with subnet segmentation
 
-All workload components reside in one VNet, with subnets defining segment boundaries. NSGs and ASGs control traffic between subnets. This pattern suits single-region deployments with a small number of workloads.
+All workload components reside in one virtual network, with subnets defining segment boundaries. NSGs and ASGs control traffic between subnets. This pattern suits single-region deployments with a small number of workloads.
 
 ![Diagram showing a segmentation pattern with a single virtual network.](../media/single-azure-region.png)
 
 This design is straightforward but provides limited centralized control. If an NSG rule is misconfigured, a public endpoint could be accidentally exposed.
 
-### Multiple VNets with peering
+### Multiple virtual networks with peering
 
-Workloads are deployed across separate VNets that connect through [virtual network peering](/azure/virtual-network/virtual-network-peering-overview). Because peering isn't transitive, each VNet pair requires explicit configuration. This pattern provides stronger isolation between workloads and supports multiregion deployments.
+Workloads are deployed across separate virtual networks that connect through [virtual network peering](/azure/virtual-network/virtual-network-peering-overview). Because peering isn't transitive, each virtual network pair requires explicit configuration. This pattern provides stronger isolation between workloads and supports multiregion deployments.
 
 ![Diagram showing a segmentation pattern with multiple virtual networks.](../media/multiple-virtual-networks.png)
 
-Use this pattern when workloads have different owners or compliance requirements that warrant VNet-level separation. You can still apply NSGs within each VNet for granular subnet-level filtering.
+Use this pattern when workloads have different owners or compliance requirements that warrant virtual network-level separation. You can still apply NSGs within each virtual network for granular subnet-level filtering.
 
 ### Hub-and-spoke topology
 
-A central hub VNet hosts shared security services, and spoke VNets contain workloads. Spokes connect to the hub through peering, and all inter-spoke and internet-bound traffic routes through the hub. This pattern provides the strongest centralized control and scales well as you add workloads.
+A central hub virtual network hosts shared security services, and spoke virtual networks contain workloads. Spokes connect to the hub through peering, and all inter-spoke and internet-bound traffic routes through the hub. This pattern provides the strongest centralized control and scales well as you add workloads.
 
 ![Diagram showing a segmentation pattern with a hub and spoke topology.](../media/hub-and-spoke.png)
 
@@ -66,25 +66,25 @@ For organizations that need global transit connectivity and integrated security
 
 ## Enforce segmentation at scale with Azure Virtual Network Manager
 
-As your network grows, manually managing NSG rules and peering across dozens of VNets becomes error-prone. [Azure Virtual Network Manager](/azure/virtual-network-manager/overview) centralizes network management and enables you to enforce segmentation policies at scale.
+As your network grows, manually managing NSG rules and peering across dozens of virtual networks becomes error-prone. [Azure Virtual Network Manager](/azure/virtual-network-manager/overview) centralizes network management and enables you to enforce segmentation policies at scale.
 
 ### Security Admin Rules
 
 Security Admin Rules are a key capability of Azure Virtual Network Manager for segmentation design. These rules are evaluated **before** NSG rules, so they act as organizational guardrails that individual teams can't override. Design your Security Admin Rules to:
 
-- **Block high-risk ports globally.** Deny inbound traffic on ports like RDP (3389), SSH (22), and SMB (445) from the internet across all managed VNets. Teams that need exceptions can use Azure Bastion or just-in-time VM access.
-- **Enforce network segmentation.** Block traffic between VNets or subnets that shouldn't communicate, regardless of individual NSG configurations.
-- **Allow platform services.** Use *Always Allow* rules to ensure traffic from hub infrastructure services (such as Azure Firewall or Azure Bastion) can always reach spoke VNets, preventing NSG misconfigurations from breaking critical services.
+- **Block high-risk ports globally.** Deny inbound traffic on ports like RDP (3389), SSH (22), and SMB (445) from the internet across all managed virtual networks. Teams that need exceptions can use Azure Bastion or just-in-time VM access.
+- **Enforce network segmentation.** Block traffic between virtual networks or subnets that shouldn't communicate, regardless of individual NSG configurations.
+- **Allow platform services.** Use *Always Allow* rules to ensure traffic from hub infrastructure services (such as Azure Firewall or Azure Bastion) can always reach spoke virtual networks, preventing NSG misconfigurations from breaking critical services.
 
 Security Admin Rules support three actions: *Allow* (evaluated first, then NSG rules apply), *Deny* (traffic is dropped, NSG rules don't apply), and *Always Allow* (traffic is permitted, NSG rules are bypassed). This hierarchy lets your central security team set guardrails while application teams manage workload-specific NSG rules within those boundaries.
 
 ### Network groups and connectivity configurations
 
-Group virtual networks into [network groups](/azure/virtual-network-manager/concept-network-groups) based on environment, region, or workload type. Use dynamic membership with Azure Policy to automatically add new VNets to the appropriate group. Then apply connectivity configurations to define whether VNets in a group use mesh or hub-and-spoke connectivity, and deploy security admin configurations to enforce segmentation rules across the group.
+Group virtual networks into [network groups](/azure/virtual-network-manager/concept-network-groups) based on environment, region, or workload type. Use dynamic membership with Azure Policy to automatically add new virtual networks to the appropriate group. Then apply connectivity configurations to define whether virtual networks in a group use mesh or hub-and-spoke connectivity, and deploy security admin configurations to enforce segmentation rules across the group.
 
 ## Control east-west traffic with Azure Firewall
 
-Segmentation boundaries are only effective when you inspect and filter the traffic crossing them. Deploy Azure Firewall as the central east-west and north-south inspection point in your hub VNet. Design your firewall rules using the principle of least privilege:
+Segmentation boundaries are only effective when you inspect and filter the traffic crossing them. Deploy Azure Firewall as the central east-west and north-south inspection point in your hub virtual network. Design your firewall rules using the principle of least privilege:
 
 - **Network rules** filter by IP address, port, and protocol for layer 3 and layer 4 traffic between segments.
 - **Application rules** filter by fully qualified domain name (FQDN) for HTTP/HTTPS and Azure SQL traffic, controlling which external destinations workloads can reach.
@@ -94,8 +94,8 @@ Use [Azure Firewall Manager](/azure/firewall-manager/overview) to manage policie
 
 ## Design microsegmentation within workloads
 
-Beyond VNet and subnet boundaries, design microsegmentation within individual workloads to limit lateral movement even inside a segment. Key approaches include:
+Beyond virtual network and subnet boundaries, design microsegmentation within individual workloads to limit lateral movement even inside a segment. Key approaches include:
 
 - **NSG rules between application tiers.** For a three-tier application, allow only the web tier to communicate with the application tier, and only the application tier to communicate with the database tier. Deny all other inter-tier traffic.
-- **Private endpoints.** Use [Azure Private Link](/azure/private-link/private-link-overview) to access PaaS services through private endpoints within the VNet, eliminating public internet exposure and mapping each endpoint to a specific resource instance to prevent data exfiltration to other accounts.
+- **Private endpoints.** Use [Azure Private Link](/azure/private-link/private-link-overview) to access PaaS services through private endpoints within the virtual network, eliminating public internet exposure and mapping each endpoint to a specific resource instance to prevent data exfiltration to other accounts.
 - **Azure Bastion.** Replace direct RDP/SSH access with [Azure Bastion](/azure/bastion/bastion-overview), which provides secure remote access over TLS through the Azure portal without exposing management ports.

learn-pr/wwl-sci/design-solutions-network-security/includes/3-design-solutions-traffic-filtering-network-security-groups.md

@@ -27,15 +27,15 @@ Azure automatically creates default rules in every NSG that you can't remove but
 
 | Priority | Name | Action |
 |---|---|---|
-| 65000 | AllowVNetInBound | Allow traffic within the VNet |
+| 65000 | AllowVNetInBound | Allow traffic within the virtual network |
 | 65001 | AllowAzureLoadBalancerInBound | Allow health probes from Azure Load Balancer |
 | 65500 | DenyAllInBound | Deny all other inbound traffic |
 
 **Outbound defaults:**
 
 | Priority | Name | Action |
 |---|---|---|
-| 65000 | AllowVnetOutBound | Allow traffic within the VNet |
+| 65000 | AllowVnetOutBound | Allow traffic within the virtual network |
 | 65001 | AllowInternetOutBound | Allow outbound traffic to the internet |
 | 65500 | DenyAllOutBound | Deny all other outbound traffic |