Abstraction for Multi-Cloud Security

Multicloud.8 How the principle of abstraction applies to multi-cloud security

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

⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: Multi-Cloud Security | AWS Security

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

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

In the last post I wrote about Programmatic Governance in an AWS environment.

Now I’ve covered how you can create policies written in code in AWS, Azure, GCP. The question is — how can we make this easier?

Abstraction in cybersecurity

I’ve written a number of posts on how you can leverage the principle of abstraction in cybersecurity.

The following post explains that abstraction in software does not relate to virtualizing hardware, it relates to abstracting out the things that are common in support of the DRY principle and reducing lines of code and potential errors.

Abstraction for consistently governed cloud deployments

How can we use those principles to reduce the complexity of what we have reviewed so far? It’s challenging, right? Although we are talking about the same concepts in each cloud environment, the implementation is completely different. The code you need to write to implement programmatic policies varies in each case.

In Azure you have to understand which license applies as well. Even across a single platform in Azure and GCP you can’t deploy all the resources we need in a consistent, templatized manner as they don’t have support for all components yet.

Abstraction for AWS Deployments with CloudFormation

Compare that to AWS. In AWS, I wrote a single function to deploy a CloudFormation template in my POC code in the related series I’ve been working on here:

Every resource I deploy with a CloudFormation template gets deployed by this function. It doesn’t matter what type of resource I’m trying to deploy. As long as that resource can be deployed with a CloudFormation template, I can use this function:

Using a single function has some benefits:

• It facilitates a consistent naming convention for CloudFormation stacks.
• The naming conventions help ensure roles only update their own stacks.
• If a stack is in a failed state it will delete the stack so you can redeploy it (AWS may have just fixed that).
• The function automatically finds and shows you the appropriate error from events instead of telling you to query CloudFormation (something else I think may have improved since I wrote this ~ still testing.)
• It validates the parameters have been set with a common parameter validation function. We could add additional type checking for parameters if needed in a single spot.
• It prints out the CLI command so if there is a problem with the template deployment you can see the command that was used to deploy the function and determine what was wrong with it.
• Most importantly, it provides a single point at which you can evaluate, allow, or deny the deployment based on whatever criteria you would like to define.

I’m not through with this code and it’s not all checked in yet but will be soon. But you get the idea. We can use a single function to deploy any type of resource that we can deploy with a CloudFormation template.

Abstraction for governance in multi-cloud deployments

What if we want to use this concept to deploy our governance resources with Azure and GCP? Well, if we have an Azure resource deployed with an ARM template and a GCP configuration file, we could do something like this:

#PSEUDOCODE

#csp = cloud service provider (AWS, Azure, GCP)
function deploy_stack()
  csp="$1"
  profile="$2"
  resourcename="$3"
  resourcetype="$4"
  template="$5"
  parameters="$6"

  if [ csp=="AWS" ]; then
     deploy_aws_stack $profile $resourcename $resourcetype $template $parameters
     return
  fi

 if [ csp=="Azure" ]; then
     deploy_azure_stack $profile $resourcename $resourcetype $template $parameters
     return
  fi

  if [ csp=="GCP" ]; then
     deploy_gcp_stack $profile $resourcename $resourcetype $template $parameters
     return
  fi
  
  echo 'Cloud Provider: '$csp' not supported'
}

deploy_aws_stack{
    #code above
}

deploy_azure_stack{
  #azure specific code
}

deploy_gcp_stack{
  #gcp specific code
}

Now what’s the problem with the above solution? Well, when I showed you how we could create the core components for governance on AWS, Azure, and GCP, AWS was the only one that had a consistent way to use templates for all types of resources, except for the organization itself, which is really only ever deployed once.

That means you’ll need some more “if” logic on Azure something like this:

#pseudocode showing complexity in Azure deployments
deloy_azure_stack{
  if template != "":
    code to deploy resource via a template
    return
  fi
  
  if resourcetype="tenant":
    deploy tenant code
  fi

  if resourcetype="subscription":
    query the license type
    if $licensetype="mca" 
       deploy subscription for mca license
       return
    fi
    if $licensetype="ea"
      deploy subscription for ea license      
      return
    fi 
    if $licensetype="mpa"
      deploy subscription for mpa license
      return
    if
     
    echo "You cannot deploy a subscription without an ea, mpa, or mca."
 fi
}

Similarly you’ll need some additional if logic on GCP due to the variations described in this blog post:

So when you’re looking to standardize and simplify how you implement governance across all three cloud providers — it’s not that simple.

For each and every resource you want to deploy in a cloud environment you need to see if it is possible to deploy that resource in a standard way, if you want to use standard code. Otherwise you have to have lots of different branches and make sure that your policy enforcement for each branch is consistent. Obviously that is more complex.

If you can deploy things in a consistent way, you can create policies and rules such as naming conventions and checking environments and which IP addresses are performing the deployments, for example.

And as I have written before, every line of code is a potential bug. You need to test your infrastructure code and policies as well as any other code. Maybe more.

Multi-cloud security vendors — a potentially risky layer

The vendors selling you products may try to make it look and sound simple to handle your multi-cloud security for you. However, if you buy a tool that promises to make your cloud security, they are essentially doing the above for you. They are writing code to interface with each cloud provider and giving you the infamous “single pane of glass” that everyone seeks, not only for governance, but for deployments, IAM, monitoring, logs, and compliance. I’m just starting with governance to keep the discussion manageable.

If you buy a tool to give you a layer over the top of your cloud deployment options shown in the last few posts, then you are placing a lot of trust in that vendor. Either they are creating a tool which, if it has a vulnerability, could completely undermine your governance and security by allowing an attacker to change your policies and rules.

Alternatively, you are actually giving that tool permission to make those changes to your security controls within your cloud environment directly. In that case, an insider threat or compromised credentials at the third party organization could affect your security. Of course, you also have to worry about that at the cloud provider itself. Adding tools can help with security but it also has the potential to undermine security. Evaluate these tools with care.

Capital One used a vendor trying to provide cloud governance in the early days that did have an issue that deployed some malformed configurations and caused production outages. The product also had a three minute window for rolling back misconfigurations. Once people figured out they had three minutes to do whatever it is they wanted to do, they took advantage of that fact. It was also so cumbersome to use the tool it was simply left off for most of the day and turned on at night.

Consider how much the tool helps verses the additional risk introduced, the effectiveness of the tool, and whether it might make more sense to simply manage policies on the cloud platform itself to prevent unwanted configurations.

Assessing third-party multi-cloud security tools

The more tools you add, the more avenues for attack you create in an already complex cloud environment. You have to provide these tools permissions to do what I am doing in the code above. Make sure you assess the vendors you use in this case as carefully as you assess the cloud provider.

Make sure you understand who is at fault and what the incident response process is should one of your third-party security tools become compromised. Change the title of this post to “Before you purchase the third party security tool…” and apply these same principles to any security vendor tools you choose to acquire:

The benefit of using a tool may be that you don’t have the resources to deal with all of the above code yourself. Tools can be helpful in that case. You will need to perform a threat assessment on the risk introduced with each tool similar to how I’m going about assessing Okta in the series below.

I would do more if I had access to resources within Okta to ask questions and I haven’t performed any technical aspects of the assessment. I’m mainly reading the documentation and evaluating the available tools and trying out the product at this point. There’s a lot more that can be done through internal interviews and technical approaches to assessing the security of the product.

Why I’m not going to implement the code for all of the above

When I started out this multi-cloud blog series, I thought maybe I’ll just implement the code similar to what I have on AWS in Azure and GCP for the basic organizational structure and a couple of policies. Honestly, after diving deeper, I’m just not that interested.

• I don’t want to get an expensive license for Azure which I only use for teaching classes and occasional tests and assessments and this blog series.
• The code for that license would only be applicable to the low end type of agreement and not an EA license. It wouldn’t be usable by every type of reader of this blog post most likely.
• I’d have to write a lot of different code to handle the different variations and use at least three different template languages to cover all of this for all three clouds.
• I have other things I want to do that interest me more.

The only thing constant in the cloud is change

And…things are always changing. Since I wrote my first governance blog post in this series (literally like a week ago), Azure came out with some new multi-tenant features. Keep an eye on this new feature. By the time I finish the code things would probably change again. Add that to the list of why I’m not going through with that exercise.

This constant churn, change, and renaming in cloud environments — most often in Azure and GCP — is why I don’t write books on multi-cloud security or try to cover all three clouds in a single class.

A tool that tries to do the above for you in the next post

I’m going to show you a tool in the next post that tries to handle some of this multi-cloud deployment for you similar to the above if that is what you are seeking. We’ll see if it can handle governance across platforms for you. But remember — under the hood, it has to implement all of the above and you’re giving it a lot of power in your cloud environment, which increases risk if you are increasing your attack vector. The security benefits have to be balanced against the additional exposure, if any.

Even with that solution I’m not going to write all the code because I’ve used it before. Essentially you’re still managing three separate sets of code for each cloud provider, though at least you are using a single language. But I’ll show you how it may help with governance and the caveats.

Want multi-cloud to be simpler? Reduce the number of clouds

The more I get into it the more I just want to stick with AWS for most of my penetration testing projects and deployments.

If you can stick with one cloud (I know most people can’t in large companies) you can really optimize your use of that cloud. If you love Azure, use it, and figure out the best way to secure it. If you love GCP, use that and become an expert in all the security features before you move to the next cloud.

Honestly, GCP might be a second choice for simplicity and cost, but I’ve seen some issues in overall governance and security on GCP. Also GCPs documentation used to be great and it looks like they took a step backwards in some ways. Maybe I’ll write about documentation later.

GCP is not quite up to the level of the other two cloud providers yet for enterprise security. But it’s very developer-friendly and they have made some interesting security acquisitions lately that are worth exploring. I love the bug bounty. ❤️

If you do use multiple clouds, try to focus on writing policies that limit the most egregious actions that lead to data breaches. I’ll talk about some key IAM strategies to segregate duties in an upcomig post. Make sure your networking controls are in place to limit the risk when (not if) credentials get exploited. The policies for each of those settings will take some time to pin down. Limit the number of services and only add new services after you have defined policies to prevent the most critical mistakes if possible.

I haven’t even touched on SAAS yet. Consider all the if-then statements for your SAAS Providers to support the above governance, if the SAAS vendor even supports automated governance at all. Perhaps that should be one of the requirements of your security assessments for any SAAS vendor that will contain PII, health care, or financial data for your organization.

Hopefully that gives you an idea how all these vendors selling you cloud security products work so you can better assess their coverage, capabilities, and how much access they have to make changes in your cloud environment to do what they need to do.

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