gCloud Genie defeats data exfiltration
Recommended: Please read the Introduction here: Tech blogs with a twist!
This feature is covered by the Pre-GA Offerings Terms of the Google Cloud Terms of Service. Pre-GA features might have limited support, and changes to pre-GA features might not be compatible with other pre-GA versions. For more information, see the launch stage descriptions.
The December chill and the festive fervor of Christmas was in the air.
But, Sam Rancher, the CISO of the Cygnos Imperial Bank, was a very worried man!
He’d just gotten off the phone with his peer, the CISO of another leading bank in the country. His peer told him of a horror story of data exfiltration by a malicious insider!
Basically an authorized employee on an official device had a massive score to settle with the management for some reason, and he extracted his revenge by logging into the bank’s cloud account and exfiltrating and uploading the data to his own personal cloud account. Needless to say, he was sacked, but the damage was done. The bank was now staring at a very public, and very expensive embarrassment, not to mention regulatory action.
Sam got a hold of the head of User and Endpoint Device Security at Cygnos Imperial Bank, Buddy Yardley, and quickly scheduled a meeting with Zach Kennedy, his Cloud Architect. He had to review his security posture and take corrective action if necessary, pronto!
They met in Zach’s office that very afternoon, the three of them.
“So Buddy, keep me honest here”, Sam began in a calm tone, but Buddy could feel the icy undertones in his voice. Sam was not a man to be messed with, especially when he was in one of his ‘moods’!
“If an authorized employee of CIB logs tries to access Google Cloud using his authorized official laptop, he’s allowed, correct?”
“That’s right Sam.”
“Good. And how do you ensure this? Can you explain the flow to me?”
“Sure sir. The user is logged into his official laptop using his AD credentials (his @cygnosimperialbank.com email address). On his official laptop, there’s an endpoint protection software running. Using the same laptop, if he accesses Google Cloud, this software proxies the session to an internet-facing gateway sitting on premises in CIB’s environment. This gateway has a static public IP Address range, registered with Google Cloud. Google cloud allows entry into CIB’s organization only if the traffic emanates from this source IP Address Range. Between the AD Authentication, and by restricting the source IP Address ranges, we can ensure that only an authorized user on an authorized device can access GCP.”
“Okay, very good. And what happens if the authorized user tries to access GCP from an unmanaged laptop?”
“Well Sam, the unmanaged laptop will not have the endpoint protection software client installed, which means the traffic will not be proxied to the Gateway. The traffic will flow over the open internet to Google Cloud. The login page itself will open since that’s a public webpage, but the moment the user tries to access CIB’s GCP assets, GCP will detect that the source IP range is not that of the Gateway on CIB’s premises, and deny access. So you see sir, there’s no way to access CIB’s GCP assets unless you’re an authorized user on an authorized device.”
“Awesome! That’s great, Buddy!”
“Buddy allowed himself to break into the slightest of smiles. Perhaps this wasn’t going to be such a bad day after all!”
“Now tell me Buddy, what happens if an authorized user on an authorized device tries to access a Non-CIB GCP Instance? I understand you have effective measures to prevent unauthorized access to the CIB GCP instance, but what measures do you have in place to prevent access to some other organizations’ or a personal instance of GCP?”
Buddy opened his mouth to answer, but then realized to his horror that he didn’t have one! His boss had accurately exposed a flaw in his security design! He remained open mouthed, making pitiful croaking noises as he fumbled for words. He felt his mouth go dry and the color drain from his face, as he saw his boss’ face getting flushed red with rage.
“My man! You better come with a plan to fix this loophole, or Christmas ain’t gonna be merry for you!” Sam Rancher practically hissed this sentence, making Buddy’s blood run cold!
“Calm down, calm down gentlemen!” Zach intervened, a jovial smile on his face.
Fortunately, he too had heard about his peer bank getting hit, and had a chat on this topic with gCloud Genie the night prior.
“No harm, no foul, gentlemen. I have a remedy for the situation.”
Sam & Buddy turned to Zach.
“Shoot!” Sam said.
“All right, here goes! Zach settled in comfortably, projected his laptop to a large monitor and began to explain”
“Do I describe your issue accurately here? The Endpoint Protection Software architecture acts as the Egress Proxy. This is the flow of the request today, and the trouble is, from an authorized user and device it can go to any org within GCP, correct?”
“Yes!” both echoed.
“Okay, how about we modify the above picture into this:
We insert a custom http header into the http request as it passes through the Egress Proxy and voila! GCP Infra has now been trained to look at the values of that custom http header and allow access to only authorized organizations! How’s that!”
“This is brilliant!” Both Buddy and Sam said in unison! “Tell us more!”
“This is a new feature that Google Cloud is coming out with, called Organization Restrictions. This is the Header Format
X-Goog-Allowed-Resources: <HEADER_VALUE>
The Header value is in JSON Format
An example in JSON is:
Where ‘1234 and 3456 are Org IDs of allow-listed Orgs.
But since http headers don’t support all the characters in JSON, it’s encoded in web safe base64 encoding.
So that’s about it gentlemen! You configure your Endpoint Protection Software or any outbound firewall en-route, a.k.a Egress Proxy to insert this header into outgoing http requests bound for specific Google ecosystem URLs, and bingo! The Google front-end will detect this header, and bar traffic going to any org not specifically allowlisted! The actual decision flow is like this:
- If the header is absent, the traffic is allowed regardless.
- If the header is present, then traffic is allowed to only those org IDs which are allow-listed in the header.
By the way, you can vary this configuration to do even more funky stuff!”
“Like what?” Sam asked.
“Well, you might have a reason for legitimate external read access. For example CIB might have to legitimately read data off a vendor’s Google Cloud Storage Bucket but not write to it (i.e upload data). In that case, you can selectively apply this header only for PUT, POST, & PATCH HTTP Methods. This will effectively ensure that you cannot upload any data outside to an untrusted organization, but you can read data from any organization. Nifty, ain’t it!”
“Outstanding man! Just outstanding! Talk about innovative solutions!” Sam gushed.
“Well, Buddy, looks like you have your work cut out for you!”
“Yes sir!” Buddy nodded in the affirmative.
“Hold on there, tiger!” Zach interjected.
This is still a preview feature, so be a little cautious. This feature is covered by the Pre-GA Offerings Terms of the Google Cloud Terms of Service. Pre-GA features might have limited support, and changes to pre-GA features might not be compatible with other pre-GA versions. For more information, see the launch stage descriptions.
Also, do go through the documentation for the product, here:
Take sensible precautions with preview products, and you should be good.”
“Thanks Zach, you’re a lifesaver!”
Both Sam and Buddy were very profuse in their appreciation and had relief writ large on their faces as they took Zach’s leave.
“All in a day’s work, gentlemen! Wish you a Merry Christmas and happy holidays!” Zach responded with a friendly wave as they stepped out of his office.
“Thanks gCloud Genie, you’re a lifesaver!” echoed Zach, the moment they were alone!
The genie beeped with pleasure.
“Merry Christmas Zach, God Bless you all, God Bless CIB!”, said gCloud Genie!
