ACM.134 Preventing a user from leveraging another user with permissions they don’t have
This is a continuation of my series on Automating Cybersecurity Metrics and is also applicable to my series on Secure Code By Design.
In the last post, I wrote about privilege escalation in a cloud account (AWS specifically, but it applies to any cloud environment.)
Backdoors and Privilege Escalation Via Cloud Account Users
Now we want to try to write the policies using the approaches I mentioned in those blog posts. Before we do that I want to clarify something I wrote about previously as it is applicable to writing IAM policies with as few lines of code as possible and still achieve a correct result.
I’ve referenced the term abstraction in multiple blog posts. I talk about abstraction in terms of taking your policies and reducing them down to the things that are common into a higher level policy.
I recently saw the word abstraction used in a different manner, and applied to cybersecurity. I suppose that definition works but it is not what I mean when I talk about abstraction, so it prompted me to write this blog post.
Where did I get this concept of abstraction? From the same place I came up with the concept of immutable infrastructure — years of Java programming. Concepts used to reduce code and write reusable components in Java and other object oriented programming languages can be used to write better cybersecurity policies.
Abstract Class
In Java you can create an abstract class. You cannot instantiate an abstract class. Instead you use an abstract class as the basis for creating other classes with common properties but different implementations. For example, a shape has some common properties, regardless of whether it is a circle, a square or a triangle. For the sake of time and not to reinvent the wheel I will reference this class diagram from geeksforgeeks.com (and I could draw up my own image if needed using cars, fruit, animals, or whatever.)
Abstraction in Java - GeeksforGeeks
In the example above, a shape always has certain properties. In this example, all shapes have a color, an area, and a “toString()” function which could return whatever string a developer wants to return for that particular shape.
The common properties have been extracted or in other words the details are abstracted to create higher level class with all the common properties for a particular type of objects.
The classes that extend that abstract class are of the same type as the abstract class but will fill in their particular implementation. In other words, the implementation of calculating the area for a circle will differ from that of a rectangle or a triangle.
Abstraction in cloud code and cloud security policies
When you create a CloudFormation template you can remove the details that vary and extract the common properties into parameters. Those parameters that get populated when the template gets executed.
Each particular execution of the template may have a different implementation resulting in a different resource by passing in different parameter values. However, all the stacks can use a single template for their underlying definition.
That’s what I am referring to when I talk about abstraction.
When I look up the terms abstraction and Java abstraction I find many varying definitions. The reason I used the term “abstraction” is because an abstract class is a concept in Java similar to the concept I am trying to explain. The abstract class contains the properties and methods that are common to all the classes that extend that abstract class.
Other classes can extend and build on the class as shown in the following example, but they must include and implement the properties and methods in the abstract class.
In this example below, curtesy of Oracle, the Circle extends a Graphic Object and fills in the specific implementation of the placeholder methods provided by the abstract class.
In the example above, the class that extends the abstract class has to implement the methods defined by the abstract class but it can also add its own functionality.
DRY — Do not repeat yourself
I mentioned the DRY concept in my series on software security. The less code you write, the less potential bugs or typos will exist in your application.
The abstract class itself, unlike an interface in Java, can include implementation, or in other words functionality. You can implement some code and each class that extends that abstract class will include that code.
If every “GraphicObject” in our example above (or Shape in the prior example) is going to repeat the same code over and over because each one implements the same functionality, it makes more sense to move that common functionality into the abstract class. That way each class that extends the abstract class will not be repeating the same code over and over. It will get that code when it extends the abstract class.
The idea here can be used when creating IAM policies. You abstract out the smallest possible policy that is common across a number of resources and use that, let’s say, for all users. Then you create more specific policies on top of that only where required instead of repeating the same code over and over.
The same concept applies in networking. You don’t want to create a single security group for every single application if you can abstract out a number of common rules that every application will need into a single, reusable group. Then you can apply that reusable group wherever possible, and add the unique rules in a separate group if you need them.
In a CloudFormation policy, you can “abstract” or “extract” the values that change from template to template and pass them in as parameters. Then you can reuse all the code in that template that is the same across all the same types of resources. That’s what I did when I created a single template to create all the KMS keys in your organization from a single template.
Automating Cybersecurity Metrics (ACM)
That’s what I did when creating security groups in the above framework for batch jobs, which has turned into a full-on AWS architecture from start to finish. I started down the rabbit-hole of secure automation and now I am digging my way out.
While searching for definitions of abstraction many variations presented themselves but I think this definition is the closest to the concept I am trying to convent when I use the word abstraction:
Abstraction (from the Latin abs, meaning away from and trahere , meaning to draw) is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics.
What is Abstraction? - Definition from WhatIs.com
Yes, there are other definitions, but the point I am trying to make to simplify management of your security resources is in line with that definition. If you want to use another definition for some other purpose, feel free, but that is not what I mean when I’m talking about using the principal of abstraction to simply your security management.
We want to reduce and extract all the common properties into the highest-level, simplest policy, and then extend that policy as needed, only adding complexity and addition words and code where they are absolutely required. We’ll try to do that in the upcoming policies to prevent the types of privilege escalation I wrote about on AWS in the last few posts.
Less words are better — or to paraphrase Mark Twain — if I had more time, I would write a shorter blog post.
Follow for updates.
Teri Radichel
If you liked this story ~ clap, follow, tip, buy me a coffee, or hire me :)
Medium: Teri Radichel
Email List: Teri Radichel
Twitter: @teriradichel
Twitter (company): @2ndSightLab
Mastodon: @teriradichel@infosec.exchange
Post: @teriradichel
Facebook: 2nd Sight Lab
Slideshare: Presentations by Teri Radichel
Speakerdeck: Presentations by Teri Radichel
Books: Teri Radichel on Amazon
Recognition: SANS Difference Makers Award, AWS Hero, IANS Faculty
Certifications: SANS
Education: BA Business, Master of Sofware Engineering, Master of Infosec
How I got into security: Woman in tech
Buy me a coffee: Teri Radichel
Company (Penetration Tests, Assessments, Training): 2nd Sight Lab
Request services via LinkedIn: Teri Radichel or IANS Research
© 2nd Sight Lab 2023
All the posts in this series:
____________________________________________
Author:
Cybersecurity for Executives in the Age of Cloud on Amazon
Need Cloud Security Training? 2nd Sight Lab Cloud Security Training
Is your cloud secure? Hire 2nd Sight Lab for a penetration test or security assessment.
Have a Cybersecurity or Cloud Security Question? Ask Teri Radichel by scheduling a call with IANS Research.
Cybersecurity & Cloud Security Resources by Teri Radichel: Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts
Abstraction in Cybersecurity was originally published in Cloud Security on Medium, where people are continuing the conversation by highlighting and responding to this story.
0 Comments