Welcome to the second part of our Security Command Center (SCC) blog series!
Now that you have a foundational understanding of key SCC terms and concepts, we’re excited to walk you through the setup process and show you how to trigger a simple test alarm.
For the purposes of this tutorial, the SCC tier you choose is not critical. The free Standard tier is a great place to start, offering hands-on experience with SCC’s core features. However, if you plan to run your Security Operations Center (SOC) primarily through SCC, the Standard tier may fall short in areas like advanced threat detection, policy management, and incident response. For those needs, we recommend exploring one of the paid tiers. That said, we’ll be using the Standard tier for the sake of this tutorial.
Setting Up the Security Command Center (SCC)
The setup process is fairly straightforward. Start by navigating to the Security tab in the sidebar. Here, you’ll find all security-related tools, including SCC. When you open the SCC for the first time, the initial interface looks like this:
You can choose to activate SCC at either the organization level or the project level. A quick heads-up: some features are only available when SCC is enabled at organization level. To make your selection, use the dropdown in the top-left corner to choose your organization or project. In our case, we created a test project and activated SCC at the project level.
To begin the setup, click the Set Up button. You’ll be guided through the process – just confirm your desired pricing tier, enable the necessary APIs, and select the modules you want to use. You might be wondering why we’re not showing each step in detail: That’s because SCC is already activated at the organization level in our environment, and the same might be true for your setup. To check, go to the SETTINGS tab and verify that the required modules are enabled. You can also upgrade your pricing tier from this tab if needed.
And that’s it! As mentioned earlier, the setup process is pretty straightforward, isn’t it?
Testing the Security Health Analytics
To confirm that the Security Health Analytics module is functioning correctly, we’ll manually trigger a finding of type PUBLIC_BUCKET_ACL. This specific finding flags storage buckets that are publicly accessible. While public buckets might be intentional in certain use cases, they often pose significant security and compliance risks.
Let’s start by creating a bucket, which we’ll intentionally expose to simulate a vulnerability:
Navigate to the Cloud Storage section:
Click “Create Bucket” and complete the form:
– Name the bucket: test-bucket-acl-trigger
– Region: us-east1
– No multi-region required.
– Leave other options at default.
– Click “Create”.
If prompted with a ‘public access is prevented’ message, confirm it.
Now you’ve successfully created a bucket. To trigger the PUBLIC_BUCKET_ACL finding we will expose it to the public.
Open the details page for the newly created bucket:
Remove Public Access Prevention by clicking the corresponding button and confirming.
Afterwards, go to the Permissions tab and click Grant Access. Assign the following users to the Storage Object Viewer role:
– allAuthenticatedUsers
– allUsers
That’s it! The bucket is now publicly accessible – anyone on the internet can view its contents. So be cautious and leave it empty. Never perform this action on an existing production bucket, as it can expose sensitive data.
To check whether an alert has been triggered, go to the Security Command Center dashboard. You should see a new finding related to a public bucket:
Go to the Findings tab and click the Public bucket ACL finding to view more details:
If you’re aware of the finding but don’t want to fix it, click Take Action and choose Mute.
In this case, we want to resolve the issue.
– Click on the resource display name to open the bucket details.
– Go to the Permissions tab.
– Remove both allAuthenticatedUsers and allUsers.
To confirm that you’ve resolved the issue, go back to the Security dashboard — the finding should now be gone!
That wasn’t that difficult, was it?
We have now gone through the optimal lifecycle of an alert together: when it appears, we take a closer look at it, find the cause (in our case, the public bucket) and solve the problem. Finally, we confirm that the alert has actually been resolved!
Now that we know that everything is working as it should, make sure to delete the bucket.
Conclusion:
In this second part of our SCC blog series, we successfully walked through the initial setup of Security Command Center and demonstrated how to trigger and resolve a test finding using the Security Health Analytics module. By exposing and securing a test bucket, you experienced firsthand how SCC detects risks and helps guide remediation efforts. This hands-on example not only confirmed that the setup works as expected but also illustrated the practical value of SCC in maintaining a secure cloud environment.
