Visibility at the Enterprise Level in a Multi-Cloud Environment

MultiCloud.2 Are you seeing everything in, to, and from your clouds?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Part of my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: Multicloud Security | Data Breaches

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

My last explained a bit about this series I’m writing on multi-cloud security.

In this first post, I want to explain a bit about one of the concerns you need to have when dealing with any cloud environment, from SAAS, to PAAS, to IAAS. Are you seeing everything? I explained some of the things you might be missing in the presentation I wrote for IANS last year. This time around I want to take a look at specifically how one might go about obtaining visibility in a cloud environment.

Connecting to Clouds — different levels of support

The first thing you need to know is that each cloud will provide this visibility in a different way. They are structured different as I covered in that last presentation. So there’s no single magic tool that can connect to every single cloud the same way.

There are some tools that have been connecting to clouds for a long time, like Okta. I wrote about Okta and how you can and cannot use it to connect to certain cloud environments. I want to add a few more posts the series on connecting to other clouds.

If you dive into the details in those stories you’ll see that there are different mechanisms for connecting to clouds depending on what the vendor supports.

Visibility into accounts and resources

As for visibility in any cloud, you need to understand what “root” or “admin” or “super user” really means. When does it mean you actually have control of, or visibility into everything and when doesn’t it? Sometimes the administrative user or the root user that created the account can’t actually see all the data. Sometime they can’t even see all the environments.

I just wrote a post about how “root” in an AWS KMS key policy might not mean what you think it means.

You need to make sure you understand the nuances of what the root user can and cannot see and who has root or administrative access in different scenarios and how each cloud defines boundaries when defining permissions. It is possible to set up resources in AWS that a root user cannot manage or see. In an organization, that may be desirable to an extent where you don’t want admins to be able to decrypt sensitive data, but someone needs total visibility in the event of a data breach or to detect malicious activity and data exfiltration.

On AWS you create an organization with accounts, but what happens when someone creates an account for AWS outside of your organization? For this and every other cloud, you need to have a process for authorizing new vendors. Your legal team reviews and approves the contracts. The finance team reviews and approves the bills. Those two entities within any organization are your friend. Get to know them and have them help you monitor for unapproved accounts and cloud resources.

In Azure, there’s a special checkbox to give the global admin user that created the account more visibility. You would think by default the global admin can just see anything or do anything in the account. But no.

If you want to create a security role that can see everything in an Azure account with multiple tenants, the last time I did that, you had to go in and specifically grant access to each and every tenant in the account. I’m going to review the latest guidance and capabilities in Azure to see if anything has changed since then.

In GCP, a customer asked me to perform a penetration test and the person who gave me access provided me with a role that had access to one single project. I was pretty sure that customer had more than one project. I asked the person if they had an organization set up (which you should — more on that later.) He said yes. I provided him a script that would loop through and give me access to every project. I mentioned before that GCP didn’t have something like a Security Audit role in AWS and how I requested one. That was a while back. Time to revisit GCP roles and see if things have changed.

Visibility into all the connections and data flowing over them

Certain cloud products allow users to make connections to external systems. If those products are connecting to external systems from the cloud platform itself, and people within your company can upload data to the cloud platform, does security have visibility into any possible data exfiltration? What about malware being downloaded from those environments into your own?

I’ve written before that I think if you have a known vulnerability you should likely fix that first and foremost because a breach may be imminent. But when it comes to architecting your cloud infrastructure and connections, visibility is still key. An inventory of all the places your clouds connect should be part of that inventory you create according to the Center for Internet Security best practices.

But how do you do that? I wrote about that in my book and answer questions like that for IANS Research clients.

Visibility into permissions and access

You’ll want to understand what permissions different people have in your cloud environment and what people are doing with it. There are certain types of access that is more risky than others. The ability to create permissions is a risky permission because someone might try to create permissions for themselves they don’t already have. An attacker might try to create a backdoor for themselves and then delete your permission and demand a ransom.

How can you deal with those type of problems in a multi-cloud environment? You could try to use a tool like Okta, but does that actually solve the problem? Okta grants access to your cloud in a somewhat consistent way, though if you read my posts above you will see that you still need to understand exactly how each cloud provider connects. Beyond that, each cloud provider has different mechanisms to create policies and grant permission to a user that has logged in via Okta. At the end of the day, you need to understand how the unique policies work in each cloud environment. That can get complex fast.

How do we make that easier if nothing is the same? I’ve already written about that for AWS but I’ll explore similar ideas on Azure and GCP. It all revolves around the idea of abstraction and how you archiect your cloud environment.

Visibility into compliance and vulnerabilities

There are lots of tools to help you with generic compliance. There’s a list of best practices and I explained some of those and some of the pitfalls related to using those lists in my prior IANS presentation on multi-cloud security. However, a lot of tools can help you determine if you are following those best practices. They give you a score or a grade on security.

On that note, I have a half-finished post on why an F grade on a website scan might not mean that much. If anyone ran a scanner over a website and told you — look — it gets an F — without looking at the underlying technologies and potential use of said vulnerabilities — then you should regard that person’s expertise as suspect. A lot of penetration testing companies or people new to security will just run scans without understanding what they mean and what the impact of those scans is in reality. I have so many topics to cover — that one is on the list.

When you run a scan in a web environment it tells you, oh my goodness look at all these bad things. But do those “bad” things matter for your particular use of that cloud environment? That is something I work to understand and revise as I work with customers year after year. I tune their reports to align with what matter to their use cases and cloud environment. I have a second talk at the IANS Forum in October on that topic.

There is so much information I could share with you on multi-cloud security. In fact, my last presentation was actually a bit too long to fit into the allotted time. I’ll try to do better this year! But there is something specific I want to get across. And that is how policies and automation can help make security jobs easier.

I want to get into specifics and also provide some code. How far I can go on this is a bit dependent on time but at least I can get you started. I always think security problems come down to the following at the end of the day:

• Permissions
• Network access
• Encryption
• Application Security

There’s more to it but those are the key factors. How can we make it eaiser to manage and monitor those things? If we can leverage some abstraction in the way we approach security in a cloud environment — and I’m talking about abstracting out commonalities not the abstraction for hardware to virtual — two different things — then we can potentially make our lives easier.

What I want to show in some upcoming posts are some specific examples of how you can get a handle on what’s going on in your AWS, Azure, and GCP cloud accounts by thinking through your organizational architecture, understanding a few pitfalls, and leveraging some cloud native tools and features that help you monitor things globally.

Yes, some CSPM tools will help you do that, but you probably don’t want to blindly trust a tool without understanding what it’s doing under the hood, right? Let’s look at how visibility in each cloud platform across an organization really works and how we can manage global policies to prevent egregious misconfigurations. Let’s look at how the design of our IAM policies can exacerbate a breach or help limit the blast radius. The first step is to understand the organizational structure in the cloud environment.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab