Getting Started with Security Command Center

Getting Started with Security Command Center

Security Command Center (SCC) is a security monitoring platform that helps users:

• Discover security-related misconfigurations of Google Cloud resources.
• Report on active threats in Google Cloud environments.

• Fix vulnerabilities across Google Cloud assets.

• Explore SCC interface elements.
• Configure SCC settings at the project level.
• Analyze and fix SCC vulnerability findings.

Open the navigation menu and select Security > Security Command Center > Risk Overview.

• Threats notify Google Cloud users about current suspicious activities happening in their Google Cloud environments, such as a service account investigating its own permissions.
• Vulnerabilities provide information on misconfigurations or vulnerabilities of resources, such as an open TCP port or an outdated library running on a Virtual Machine.

Threats and vulnerabilities are two different types of finding classes, which SCC uses to categorize and report security issues in your environment.

A finding is a record generated by SCC, which provides details on vulnerability or threat data in the Security Command Center dashboard.

In the “New threats over time” card, select the FINDINGS BY RESOURCE TYPE tab.

This card enumerates currently active threats that have happened in your project during the period of time determined by the “Time range” drop down on the right side of this information panel.

By default, the time range drop down shows all threats that appeared during the last 7 days, but you can view all threats that happened during the last 180 days.

Scroll down to the Vulnerabilities per resource type card.

A majority of these findings are generated because we are using the default VPC network, which is insecure by design. For example, it contains firewall rules that allow SSH and RDP access from any IP address.

Now scroll down to the Active vulnerabilities card below.

Select the FINDINGS BY CATEGORY tab.

This will show your environment’s vulnerabilities organized by different categories of vulnerabilities and their severity. This is a property of the finding that helps to estimate the risk that the issue poses to the Google Cloud environment.

The level of severity cannot be changed—each type of finding has a severity level that is predetermined by SCC. Below is a list of the different types of severities and common examples:

• Critical - for example, a Reverse Shell session launched from inside of a GKE Pod.
• High - for example, an SSH port opened to the entire Internet (0.0.0.0/0);
• Medium - for example, one of primitive IAM roles (Owner/Editor/Viewer) has been granted to a user or a service account;
• Low - for example, no VPC Flow logs are collected
• Unspecified - can appear in SCC, but are not common.

Now select the FINDINGS BY RESOURCE TYPE tab. This will show vulnerabilities categorized by the different types of Google Cloud resources available

Finally, select the FINDINGS BY PROJECT tab. This tab is more informative when you use SCC on the level of a folder or organization root node.

In the left-hand menu, under the Security Command Center header, open each of the following tabs and read their description below:

Threats: gives you a quick overview of findings that are classified as threats in SCC. Some examples could be:

• Successful attempt of an SSH BruteForce attack (link).
• Cryptomining software running on compute resources (link).
• Reverse shell session was launched from inside a GKE container (link).

Vulnerabilities: this tab gives you a quick overview of all misconfigurations or flaws in software which might exist in the current scope (whether that be inside your project, folder, or organization). This gives you more fine-grained access to the vulnerabilities, allowing you to drill down into each one. Some examples of vulnerabilities are:

• MySQL port open to the whole Internet (link).
• An Owner/Editor/Viewer role has been assigned to a user or a Service Account (link).
• A web-page or a web-application vulnerable to XSS-attacks (link).

Compliance: shows information about compatibility of your Project with the most important compliance standards such as CIS, PCI DSS, NIST 800-53 and others.

Findings: this tab allows you to explore all findings available in the SCC database. We will investigate findings and how to work with them in task 3.

Sources: the software modules that analyze configuration of Google Cloud resources and monitor current activities by reading log files and checking currently running processes. We can say that Sources are the actual “detectors” of SCC, which analyze configuration of resources and publish information to SCC.

Configure SCC settings at project level

In this task, you will learn how to configure SCC settings at the project level.

Click SETTINGS from the top right corner of the overview page.

Ensure you are on the SERVICES tab.

This tab will allow you to set up parameters of SCC’s integrated services, which are also called sources (“the brains of SCC”, as we learned about in the previous task). In this lab the terms services and sources are interchangeable.

Services detect threats and vulnerabilities and provide information to SCC. Most of them are available only in the Premium edition of SCC, which is what you have in this lab.

The following are built-in services that you can configure:

• Security Health Analytics (SHA): finds and reports misconfigurations of resources (disabled logs, extra IAM permissions, publicly exposed services). This is what we have currently enabled in our project and what detected the 76 vulnerabilities in our project.
• Web Security Scanner (WSS): scans publicly available web applications exposed via external IP addresses and checks for OWASP top 10 vulnerabilities. You will have a chance to work with this in a later lab.
• Container Threat Detection (CTD): can detect the most common container runtime attacks in a Container Optimized OS (will also be shown in a later lab).
• Event Threat Detection (ETD): log-based threat analysis that continuously monitors Google Cloud and Google Workspace logs to scan for potential threats.
• Virtual Machine Threat Detection: analyzes memory of VM instances on the level of a Hypervisor and can detect suspicious activities happening in VM memory. Examples are unexpected kernel modules or running crypto-mining software.
• Rapid Vulnerability Detection (RVD): a zero-configuration network and web application scanner that actively scans public endpoints to detect vulnerabilities that have a high likelihood of being exploited.

Click on the link MANAGE SETTINGS for Security Health Analytics.

Click on the tab MODULES.

Modules are pre-defined, or custom units of detection logic. As you can see, SCC offers many different types of modules that can help you detect different misconfigurations of resources. SCC makes it easy to enable and disable different types of modules to support your security posture and the resources you are interested in monitoring.

In the filter, type in VPC_FLOW_LOGS_SETTINGS_NOT_RECOMMENDED.

Select Enable from the Status dropdown.

Security Health Analytics will now check whether the enableFlowLogs property of VPC subnetworks is missing or set to false.

Now that you are familiar with Security Command Center’s different services and how to configure them, you will identify and fix a vulnerability with SCC.

Analyze and fix SCC vulnerability findings

In this task, you will learn how to manage and mitigate vulnerability findings.

Open the navigation menu and select Security > Security Command Center > Risk Overview.

From the left-hand menu, select the FINDINGS tab.

Set the time range selector in the top-right corner to All time.

By default in the FINDINGS tab you can see unmuted findings with the state ACTIVE.

The two properties state and mute of every finding define visibility of findings in many filters used for SCC.

• The Mute value can be set on findings by the security analyst or it can be set automatically if the analyst does not want to see irrelevant and noisy findings in the SCC interface.
• The State property indicates whether a finding requires attention and has not been addressed yet, or if it’s been fixed or otherwise addressed and is no longer active.

A recommended way to manage the lifecycle of findings and hide them is to use the “mute” property. Changing the “state” property is typically handled by software sources.

In the “Quick filters” card select the category Default network.

Note that the query string in the “Query preview” has changed (it now has AND category="DEFAULT_NETWORK" attached to it.)

Select the checkbox next to “Default network” and select CHANGE ACTIVE STATE.

Set the state to Inactive state for this finding.

Now the finding has been deactivated and hidden from the screen because by default you can see only active and not muted findings.

Reset the FINDINGS tab view by clicking Risk Overview, then Findings under the SCC header.

Findings can be activated and deactivated manually, but they never can be deleted by a user. They are deleted automatically only when a finding has not been refreshed by scanners during 13 months.

When a security scanner checks the same finding and does not detect the misconfiguration which kicked off the finding, it marks it as “INACTIVE”. If the vulnerability still presents in the system, the finding will stay in the same “ACTIVE” state.

Our default VPC network was created with --subnet-mode=auto parameter, so none of its subnets have Private Google Access enabled and all subnets do not write VPC Flow logs.

Imagine that we are working in a test environment, so we do not want to see SCC findings about Private Google Access in this network.

In the “Quick filter” window select the category Private google access disabled.

Now click on the Category checkbox so all “Private google access disabled” findings are selected:

Now that the “Private google access disabled” findings are muted, you will no longer see any of them in the Console. As you can see, muting is a powerful way to filter Security Command Center’s results, and provides you the fine-grained control over your resources and findings you are interested in.

Another misconfiguration of the default network is that VPC Flow Logs are also disabled in the subnets of this network. Since we are working in a test environment, we won’t need VPC Flow Logs enabled, so we are going to mute all existing and all future findings related to this category.

Click the button MUTE OPTIONS > Create mute rule.

In the new window enter a new Mute rule ID: muting-pga-findings.

For the mute rule description, enter Mute rule for VPC Flow Logs.

In the “finding query” enter the following filter category="FLOW_LOGS_DISABLED"

Now press the SAVE button.

You should see a notification in the bottom part of the Console that a mute rule was created.

Now refresh the main SCC Dashboard by selecting Findings from the left-hand menu.

Ensure that you no longer see any “Private google access disabled” or “Flow logs disabled” findings.

Now we will create one more network with automatically configured subnets.

Open a new Cloud Shell session () and run the following command to create this network: gcloud compute networks create scc-lab-net --subnet-mode=auto

Close the Cloud Shell window after you have verified the above message.

Refresh the SCC findings window and note that you can see newly created “Private google access disabled” finding, but there are no findings about VPC Flow Logs (this is because of the mute rule we created earlier).

Although we created mute rules for VPC Flow Logs, SCC still allows you to view them by using the query editor.

Check the findings query results table and note that in the column “Resource display name” you can see both networks: “defaults” and “SCC-lab-net”.

In the “Query preview” window, click Edit Query.

Now copy and paste the the following query: state="ACTIVE" AND NOT mute="MUTED"

When you finish editing, press the APPLY button.

Now we will investigate and fix two findings with high severity.

In the Quick Filters section, select High from the list of severity options.

You should see two findings: “Open RDP port” and “Open SSH port”. They have been initiated because the “default” network contains two firewall rules enabling SSH and RDP traffic to all instances in this network from the whole Internet.

Click on the Open RDP port finding.

A new window will appear. In this window you will find a detailed description of the issue itself, list of affected resources and “Next steps”, which help you remediate it.

Click on the link to go to the firewall rules page, which will open a new tab.

Click default-allow-rdp firewall rule.

Click EDIT.

Delete the source IP range 0.0.0.0/0.

Add the following source IP range 35.235.240.0/20 and press Enter.

Do not change any other parameters!

Click SAVE.

Once saved, close the browser tab where you edited the firewall rule.

Refresh the SCC finding browser tab.

You should now see only one finding with “High” severity - “Open SSH Port”.

Click on the Open SSH port finding.

Click on the link to go to the firewall rules page, which will open in a new tab.

Click default-allow-ssh firewall rule.

Click EDIT.

Delete the source IP range 0.0.0.0/0.

Add the following source IP range 35.235.240.0/20 and press Enter.

Do not change any other parameters!

Click SAVE.

Once saved, close the browser tab where you edited the firewall rule.

Now close the window with an open finding description and refresh the browser window.

You should now see no findings with High severity.

You have now successfully used Security Command Center to identify and remediate critical security vulnerabilities in your Google Cloud environment. Throughout this lab, you learned how to explore SCC interface elements, configure SCC settings at the project level, and analyze and fix SCC vulnerability.