|
Service accounts(SAs) are a special type of Google account that grants permissions to GCP resources instead of end users. Service accounts are primarily used to ensure safe, managed connections to APIs and Google Cloud services. Granting access to trusted connections and rejecting malicious ones is a must-have security feature for any Google Cloud project. In order to understand the threats to SAs companies must start with broad Org level IAM audits to gauge where these powerful IAM accounts stand in the present. Overly Permissive SAs at different levels of the GCP heirarchy are weaknesses that can cause havoc in GCP and should be reviewed regularly to maintain a consistent secure IAM posture. At the Application level, specific SAs should not have access to both GCP Folder production and non-production environments. This process of cross pollinating SA accounts should never be recommended as a best practice for domain folders such as Production and Non-Production. This practice lowers the SA account security posture as a least privilege model within a Zero Trust Architecture. The result? In a worst case scenario an SA granted full access to non-production could theoretically use those permissions in a production environment to destroy everything and anything in its way. A total nightmare for enterprises! An even bigger nightmare is if a basic role (Owner, Editor) tied to SA has been set at the GCP org level in the hierarchy. If this were to occur the potential of homeland destruction increases 10-fold. This SA, if compromised by a bad actor, can now roam freely at will throughout the entire GCP environment. So what happens when an application fails or any other emergency situation presents itself in a GCP environment? Where is the Bat-phone located? Who can reach the hammer to crack the glass enclosure? If the hammer is used, then what? These are questions to be addressed within a standard Break Glass process. IT companies have struggled to properly identify and implement a rapid reactionary method of protecting the homeland. In the GCP world a Break Glass solution can utilize “Service Account Impersonation.” This is a sophisticated approach that allows users to assume an SA permission set while abandoning their own. Access is granted ahead of time to a small trusted set of subject matter experts (SMEs) who are approved by management and security. When an agreed upon Break Glass event occurs, internal processes and workflows are kicked into high gear and the user impersonating the SA does what he/she does best, puts out fires! Angel RosarioLucidPoint Cloud Engineer 
0 Comments
Today’s Cloud IT Security experts are overwhelmed in their fast-paced departments. They are the protectors against malicious activity from persistent threats and incorrectly configured cloud resources. Most have relied on stand-alone security information event management (SIEM) systems to aggregate log data from many sources for event correlation, detection, and incident response. However, these legacy SIEM solutions are unable to scale to accommodate increasing data volumes and the growing number of cloud data sources. In turn, the process of identifying, investigating and tracking these incidents have failed to keep up with the complexities of cloud computing. Companies have been experiencing a growing visibility gap and insufficient repeatable automation that prevent IT Security from achieving their goals in threat detection, response, and vulnerability management. Enter Google’s Security Command Center (SCC), a one-stop shop for security and risk management platform for GCP with out-of-the-box detection and response capabilities for greater visibility. SCC allows you to gain centralized visibility of cloud assets, identify security configurations and detect threats using streamlined log aggregation running in GCP at scale. I must say, it is an amazing tool for stopping bad actors before attacks escalate into breaches. A comprehensive approach to solving this problem is to automate processes and workflows from (identification) SCC into Gitlab (Tracking). In between these two endpoints are automated and human workflows that speed up the linking of the processes involved. By applying filters (Critical-High-Medium-Low) for active vulnerabilities in SCC the GCP Messaging service Pub/Sub can ingest these filter events at accelerated speeds and publish them in near real-time when alerts are generated. Server-less compute services such as Cloud Functions will quickly and logically process the input from Pub/Sub topics. The Cloud Function will also communicate rapidly with the GITLabs API and perform the following processes:
At this stage the human workflow GITLab Maintainers adhere to standard SLA Policies describing timeframes for resolving vulnerabilities. These Maintainers also analyze and decide whether the vulnerability is legitimate or not. More Importantly, Vulnerability Exceptions come into play and are an integral part of the workflow as they require a written approval from IT Security. At this stage additional mitigating risk controls can be discussed to compensate for a possible rejection of the Vulnerability Exception. Through the back and forth communications between the business unit and IT Security, a time frame and compromise will be agreed upon so that vulnerability fixes will be efficiently implemented. A third and final workflow is executed via SCC Mute Rules which allows the IT Security staff to decide on either applying bulk or individual mute rules based on severity, validity and additional criteria being met. This essentially disables the noise within the SCC console on similar SCC findings. Finally, with the speedy click of a mouse button, IT Security can transform 100s or 1000s of reviewed SCC findings into resolved issues thereby responsibly enhancing the security posture of a company’s Google Cloud Platform. Angel RosarioLucidPoint Cloud Engineer |
Hybrid IT and IT infrastructure solutions that meet your business goals.
|
|
|