What Would Make Multi-Cloud Security Easier?

Multicloud.12 A proposed standard for cloud deployments and drift detection

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

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

🔒 Related Stories: Multi-Cloud Security | AWS Security | Azure Security | GCP & Google Security.

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

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

In the last post I wrote about one of the most challenging aspects of multi-cloud or any cloud security — IAM.

In this post I’m going to write about what I think would make cloud deployments easier.

I’m going to leverage the principle of abstraction again I wrote about in this post to propose an idea to make cloud deployment and policy management easier in cloud environments across the board — including SAAS cloud environments.

If cloud providers could agree on some kind of template language like Terraform’s templates (preferably in YAML, though it is easy to convert JSON to YAML) and provide a standard mechanism to deploy a template for any resource — including and starting with organizational and IAM policies— wouldn’t that be nice?

I’ve seen so many things converge and standardize over the years and this is just one more area with room for improvement. In fact there’s already a push for standardization of the events from cloud providers.

And schemas:

What if you could write a single template and actually deploy that template to create a similar resource like a policy, a role, or a VM on any cloud? That would be nice right? Not this overlay of the interface but an actual template that deploys to any cloud.

Some cloud environments might have extra features for deployments not available in other clouds. There could be a base set of properties and then cloud-specific extensions. Upon deploying the template the cloud provider would deploy the resource using the base properties, plus the appropriate extension properties section for any cloud-specific details.

This is XML because I think it’s easier to read than JSON or YAML but I would prefer YAML.

<resources>
  <vm>
    <size></size>
    <region></region>
    <os></os>

     <extensions>
       <aws>
         <userata>...</userdata>
       </aws>
     </extensions>
  </vm>
</resources>

Would it really be that hard for cloud providers to map to such a standard so deployments could be transferable and so could your skills as you move from platform to platform? No, but of course by making people learn proprietary languages they can lock you in, so there’s that.

It would be amazing if all cloud providers would let you deploy policies to your cloud environment that map to their specific actions with a common template format. What am I talking about? Though every cloud environment has different actions you can take, they all have a list of actions.

AWS

This list gives you all available AWS actions.

For example if you click on accounts:

Azure

Unfortunately with Azure you can use a predefined set of roles, unless you pay extra for a license that allows you to create custom roles. This should be a recurring theme by now.

Custom roles have actions that they can take:

Here’s where you can find a list of available actions:

For example Microsoft compute:

GCP

Here’s the GCP IAM Permissions reference:

A common role deployment template can easily be conceived from the above to look something like this:

<Resources>
  <Role>
    <Name>Role</Name>

      <AWS>
        <actions>
          <action>action1</action>
          <action>action1</action>
          <action>action1</action>
        </actions>      
      </AWS>
      
      <GCP>
        <actions>
          <action>action1</action>
          <action>action1</action>
          <action>action1</action>
        </actions>
      </GCP>

   </Role>
</Resources>

The beautiful thing would be if all your SAAS cloud providers start adopting this standard. Then you could define a role that has access to a set of resources across platforms like this:

<Resources>
  <Role>
    <Name>Developer</Name>
       
    <AWS>
      <actions>
        <action>action1</action>
        <action>action1</action>
        <action>action1</action>
      </actions> 
    </AWS>
      
     <GCP>
       <actions>
         <action>action1</action>
         <action>action1</action>
         <action>action1</action>
       </action>
    </GCP>

     <Hashicorp>
       <actions>
          <action>action1</action>
          <action>action1</action>
          <action>action1</action>
        </actions> 
     </Hashicorp>

     <GitHub>
       <actions>
         <action>action1</action>
         <action>action1</action>
         <action>action1</action>
      </actions> 
    </GitHub>
    
    <DockerHub>
      <actions>    
        <action>action1</action>
        <action>action1</action>
        <action>action1</action>
      </actions>
    </DockerHub>

   </Role>
</Resources>

I was thinking about another approach like the following which borrows an idea from the Java namespace mechanism of prefacing a class name with the domain name of the owner but reversed. This would reduce some additional lines of code.

<Resources>
  <Role>
    <Name>IAM_Administrator</Name>
    <Actions>
      <Action>com.amazonaws.iam.createuser</Action>
      <Action>com.azure.iam.createuser</Action>
      <Action>cloud.google.iam.createuser</Action>
    </Actions>
  </Role>
</Resources>

Either way, you could use that same template to create a role with a common name across all cloud platforms and use that template to detect drift. Each cloud provider should offer a real-time mechanism for drift detection on their platform. If you don’t want to send all the above information to a particular provider for drift detection, perhaps there’s a tool that transforms the above into only what is required before sending it. But a standardized template would make it easier to leverage a standard deployment and configuration checking mechanism across cloud providers.

This includes SAAS providers. One of the primary things you configure on SAAS platforms is IAM. If SAAS platforms would adhere to a standard for deploying permissions they could easily be added to the list above and it would be so much easier to check for drift detection across all of them.

Over provisioned permissions leveraged when credentials get stolen or abused and misconfigurations are two of the top threats — still — in any cloud environment. A standard like the above might move us towards a realistic mechanism for managing and auditing the complexity that comes with multiple clouds.

Wouldn’t it be nice….A song is running through my head. 😊

Care to discuss? Come join me at the IANS Security event in Atlanta in October 2023. I can’t promise you a standard will come out of it but it would be interesting to get your thoughts on this idea. 💡 Vendors are not allowed in my session but you can contact IANS for ways to present or sponsor.

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