Skip to main content

🛡️ Google Project has a legacy network🟢

Logic​

Similar Policies​

Description​

Open File

Description​

In order to prevent use of legacy networks, a project should not have a legacy network configured. As of now, Legacy Networks are gradually being phased out, and you can no longer create projects with them. This recommendation is to check older projects to ensure that they are not using Legacy Networks.

Rationale​

Legacy networks have a single network IPv4 prefix range and a single gateway IP address for the whole network. The network is global in scope and spans all cloud regions. Subnetworks cannot be created in a legacy network and are unable to switch from legacy to auto or custom subnet networks. Legacy networks can have an impact for high network traffic projects and are subject to a single point of contention or failure.

Audit​

From Google Cloud CLI​

For each Google Cloud Platform project,

  1. Set the project name in the Google Cloud Shell:

         gcloud config set project <Project-ID>

  2. List the networks configured in that project:

         gcloud compute networks list

None of the listed networks should be in the legacy mode.

... see more

Remediation​

Open File

Remediation​

From Google Cloud CLI​

For each Google Cloud Platform project,

  1. Follow the documentation and create a non-legacy network suitable for the organization's requirements.
  2. Follow the documentation and delete the networks in the legacy mode.

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
💼 CIS GCP v1.2.0 → 💼 3.2 Ensure legacy networks do not exist for a project - Level 1 (Automated)1no data
💼 CIS GCP v1.3.0 → 💼 3.2 Ensure Legacy Networks Do Not Exist for Older Projects - Level 1 (Automated)1no data
💼 CIS GCP v2.0.0 → 💼 3.2 Ensure Legacy Networks Do Not Exist for Older Projects - Level 1 (Automated)1no data
💼 CIS GCP v3.0.0 → 💼 3.2 Ensure Legacy Networks Do Not Exist for Older Projects - Level 1 (Automated)1no data
💼 Cloudaware Framework → 💼 Infrastructure Modernization16no data
💼 FedRAMP High Security Controls → 💼 AC-18 Wireless Access (L)(M)(H)45no data
💼 FedRAMP High Security Controls → 💼 CM-2 Baseline Configuration (L)(M)(H)3130no data
💼 FedRAMP High Security Controls → 💼 CM-6 Configuration Settings (L)(M)(H)212no data
💼 FedRAMP High Security Controls → 💼 CM-7 Least Functionality (L)(M)(H)31833no data
💼 FedRAMP High Security Controls → 💼 CM-9 Configuration Management Plan (M)(H)8no data
💼 FedRAMP Low Security Controls → 💼 AC-18 Wireless Access (L)(M)(H)5no data
💼 FedRAMP Low Security Controls → 💼 CM-2 Baseline Configuration (L)(M)(H)29no data
💼 FedRAMP Low Security Controls → 💼 CM-6 Configuration Settings (L)(M)(H)11no data
💼 FedRAMP Low Security Controls → 💼 CM-7 Least Functionality (L)(M)(H)29no data
💼 FedRAMP Moderate Security Controls → 💼 AC-18 Wireless Access (L)(M)(H)25no data
💼 FedRAMP Moderate Security Controls → 💼 CM-2 Baseline Configuration (L)(M)(H)330no data
💼 FedRAMP Moderate Security Controls → 💼 CM-6 Configuration Settings (L)(M)(H)112no data
💼 FedRAMP Moderate Security Controls → 💼 CM-7 Least Functionality (L)(M)(H)333no data
💼 FedRAMP Moderate Security Controls → 💼 CM-9 Configuration Management Plan (M)(H)8no data
💼 ISO/IEC 27001:2022 → 💼 8.9 Configuration management12no data
💼 NIST CSF v1.1 → 💼 PR.IP-1: A baseline configuration of information technology/industrial control systems is created and maintained incorporating security principles (e.g. concept of least functionality)426no data
💼 NIST CSF v2.0 → 💼 DE.CM-09: Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events142no data
💼 NIST CSF v2.0 → 💼 ID.AM-08: Systems, hardware, software, services, and data are managed throughout their life cycles25no data
💼 NIST CSF v2.0 → 💼 PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties116no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-18 Wireless Access55no data
💼 NIST SP 800-53 Revision 5 → 💼 CM-2 Baseline Configuration729no data
💼 NIST SP 800-53 Revision 5 → 💼 CM-6 Configuration Settings412no data
💼 NIST SP 800-53 Revision 5 → 💼 CM-7 Least Functionality923no data
💼 NIST SP 800-53 Revision 5 → 💼 CM-9 Configuration Management Plan18no data
💼 PCI DSS v3.2.1 → 💼 1.1 Establish and implement firewall and router configuration standards7139no data
💼 PCI DSS v3.2.1 → 💼 1.1.6 Documentation of business justification and approval for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure.127no data
💼 PCI DSS v3.2.1 → 💼 1.1.7 Requirement to review firewall and router rule sets at least every six months.9no data
💼 PCI DSS v3.2.1 → 💼 1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.620no data
💼 PCI DSS v3.2.1 → 💼 1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ.20no data
💼 PCI DSS v3.2.1 → 💼 1.3.5 Permit only “established” connections into the network.20no data
💼 PCI DSS v3.2.1 → 💼 1.4 Install personal firewall software or equivalent functionality on any portable computing devices that connect to the Internet when outside the network, and which are also used to access the CDE.8no data
💼 PCI DSS v3.2.1 → 💼 1.5 Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties.8no data
💼 PCI DSS v3.2.1 → 💼 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.5332no data
💼 PCI DSS v3.2.1 → 💼 2.5 Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties.8no data
💼 PCI DSS v4.0.1 → 💼 1.1.1 All security policies and operational procedures identified in Requirement 1 are documented, kept up to date, in use, and known to all affected parties.8no data
💼 PCI DSS v4.0.1 → 💼 1.2.1 Configuration standards for NSC rulesets are defined, implemented, maintained.34no data
💼 PCI DSS v4.0.1 → 💼 1.2.5 All services, protocols, and ports allowed are identified, approved, and have a defined business need.27no data
💼 PCI DSS v4.0.1 → 💼 1.2.6 Security features are defined and implemented for all services, protocols, and ports that are in use and considered to be insecure, such that the risk is mitigated.27no data
💼 PCI DSS v4.0.1 → 💼 1.2.7 Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective.9no data
💼 PCI DSS v4.0.1 → 💼 1.4.2 Inbound traffic from untrusted networks to trusted networks is restricted.20no data
💼 PCI DSS v4.0.1 → 💼 1.5.1 Security controls are implemented on any computing devices, including company- and employee-owned devices, that connect to both untrusted networks and the CDE.8no data
💼 PCI DSS v4.0.1 → 💼 2.1.1 All security policies and operational procedures identified in Requirement 2 are documented, kept up to date, in use, and known to all affected parties.8no data
💼 PCI DSS v4.0.1 → 💼 2.2.1 Configuration standards are developed, implemented, and maintained.13no data
💼 PCI DSS v4.0 → 💼 1.1.1 All security policies and operational procedures identified in Requirement 1 are documented, kept up to date, in use, and known to all affected parties.8no data
💼 PCI DSS v4.0 → 💼 1.2.1 Configuration standards for NSC rulesets are defined, implemented, maintained.2434no data
💼 PCI DSS v4.0 → 💼 1.2.5 All services, protocols, and ports allowed are identified, approved, and have a defined business need.1527no data
💼 PCI DSS v4.0 → 💼 1.2.6 Security features are defined and implemented for all services, protocols, and ports that are in use and considered to be insecure, such that the risk is mitigated.627no data
💼 PCI DSS v4.0 → 💼 1.2.7 Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective.9no data
💼 PCI DSS v4.0 → 💼 1.4.2 Inbound traffic from untrusted networks to trusted networks is restricted.720no data
💼 PCI DSS v4.0 → 💼 1.5.1 Security controls are implemented on any computing devices, including company- and employee-owned devices, that connect to both untrusted networks and the CDE.8no data
💼 PCI DSS v4.0 → 💼 2.1.1 All security policies and operational procedures identified in Requirement 2 are documented, kept up to date, in use, and known to all affected parties.8no data
💼 PCI DSS v4.0 → 💼 2.2.1 Configuration standards are developed, implemented, and maintained.13no data
💼 SOC 2 → 💼 CC5.2-2 Establishes Relevant Technology Infrastructure Control Activities7no data