Why Perimeter Security in Cloud is not as simple as it Sounds
Exploring the ways of doing Perimeter Security in Cloud
The phrase Perimeter Security sounds like a domain by itself right? Well you can think of it as a separate domain altogether depending on what elements you are dealing with in Perimeter Security. What is Perimeter by the way and why do we need to Secure it?
Why Perimeter Security?
Perimeter in terms of a Network is just this — Entry Points and Exit Points of a Network, and Securing these points is Perimeter Security, so simple, right? Yes, it sounds really simple in theory. Perimeter Security looks really simple and straightforward as long as the the number of Entry/Exit Points into/out of a Network is a small number. Consider an On-Prem Network where you have a couple of Internet connections and your entry points are these Routers then you have your ASA connecting your DMZ and Internal Networks. In this case your entry/exit points are the Routers, this looks simple from a Security Standpoint as the number of elements which sit at the Perimeter are low in number. But when it comes to cloud, its very different.
How is Perimeter Security different in the Cloud?
The number of elements which can go Public is not something which can be easily determined in case of Cloud and the number of Entry/Exit points is not straight like On-Prem.
It becomes like a Maze Game to identify the number of Entry/Exit points in Cloud. For example let us consider AWS as an example — consider you have 10 AWS accounts and you are actively using 5 regions, 4 VPCs per region and 4 public subnets per VPC, so the count is —
10 x 5 regions = 50
4VPC x 50 regions = 200 VPCs
4Pub Subnets x 200VPCs = 800 Subnets
So let us consider 1 Main Entry Point into a VPC, which is Internet Gateway which is not directly in our control, next comes implicit router which can be controlled by us to an extent — that is adding routes, then comes our NACLs which work at Subnet Level, NACL is something which we can really control in terms of what can be accepted and what can be rejected as such and at last comes the Security Groups which are at the Instance Level. Security Group sometimes comes under Perimeter and sometimes not, consider an ELB which sits at Perimeter, here, our SG also falls under Perimeter.
The point to be noted here is just this, the Perimeter of a Cloud environment is not straight forward and cannot be treated as a list of Static Points of Entry/Exit, they keep changing all the time. We just spoke about Services which live inside a VPC, for which Internet Gateway acts as an Entry/Exit point, but consider an S3 Bucket or an API Gateway which is completely managed by AWS.
Consider an S3 bucket is Public with PUT permission, and this S3 is being actively being used by an application, this is public and becomes one more entry point.
Consider an API Gateway without any Resource Policy and Auth which calls Lambda and that Lambda in turn gets/puts data into DynamoDB. This API GW is public and again becomes an entry point into the network.
I just specified some examples here, there are so many services which are like this and can always act like a Pivot point into the network. This is to simply explain how the Entry and Exit elements are not straight in nature, in a Cloud Environment.
Okay now all this is fine, what do we do now to Secure Perimeter in Cloud? Well its not a straight answer like, spin these firewalls up or write some ACLs and relax. It goes way beyond, just like any other domain in Security — this is also a Process which never ends, innovation and improvisation keeps happening here also. All we can do is get the ways of Security into the DNA of People and Process so at some point Building and Security happens at the same point, not Security after Build. So let us discuss what are some steps which we could use to mature Perimeter Security in Cloud.
How Perimeter Security?
These are the five steps which I can think of when I am asked to do Perimeter Security at Scale.
- Inventorize
- Categorize
- Blast Radius Analysis
- Implementation
- Monitoring
Inventorise — Build an Inventory: Get all the elements which directly or indirectly fall into Perimeter of an environment into a single Place, so that what we have in our environment is clearly understood. When I meant directly fall into perimeter — these are the elements which are directly public and indirect elements are these, for which direct elements act as a Proxy without any restrictions in place. API Gateway invoking a Lambda function which is behind without any checks in-between could be an example for Direct and Indirect elements.
Categorize — Just building an inventory is not enough, we need to group elements in such a way that each group of elements can be identified with a unique property of theirs compared to others, this makes it easier at later stages when we are Securing/Hardening these assets. Again this Grouping cannot be straight, that I will combine all ELBs into a single group and make my job easier.. service based grouping is already there, but what we need to focus on is — a group of elements which are different by their service but allow or serve traffic from/to an application, so this group of elements, if compromised — this so and so application gets compromised, this takes me to the next Line Item which is Analysis(Blast Radius). Grouping is again subject to how elements in your environment are designed, this activity changes from env to env, not a straight process, this is just an example.
Blast Radius Analysis —
Honestly, this is the Key aspect of this whole exercise and one of my favorites. I would say, this is the place where most of your focused time has to be invested. Blast Radius is self explanatory — if something is compromised, how far can an attacker go and affect things in the environment. This becomes really tricky as the number of elements which are directly or indirectly connected to your Perimeter is high in number, or keeps growing frequently.
- Blast Radius analysis can start right at your Perimeter, go to an identified group of Perimeter elements and start drawing the flow and go deep into the internal network/elements and check how far can you reach, consider all ifs and buts and don’t take any element which is acting as a proxy for granted.
- Visualize wherever and whenever needed. Visualizing your perimeter is a powerful thing which helps you answer a lot of hidden questions which cannot even be seen in a simple Excel Sheet. Do not rely completely on some tool for this, use your own GraphDB if needed and keep the flow super clear.
- Conduct Pre-Mortem drills. Take some important group of Perimeter elements and pretend these elements got compromised. What is the Response Plan? How do you contain these attacks in Real-Time? Based on this analysis, build your Risk Engine.
Implement — Based on the above analysis, implement the solutions which you feel are right for the environment, this should also balance the graph of Risks Accepted and Security of the elements. Accepting too many Risks and being fine with it directly affects your Attack Surface and at the same time, too much Hardening defeats the Purpose of your Business.
Monitor — Now we have completed so many steps already, feels like its time to sit back and relax right? Sadly your friend from QA Team has whitelisted 0.0.0.0/0 in a security group and QAs VPC is peered with one of your Critical VPCs, and you have allowed a lot of Instances from QA to talk to this VPC. This is why this Monitor Step becomes really important.
Here, monitor doesn’t mean deploy some agents, collect all your logs and dump into your SIEM. This is more of making sure all the State changes to your Perimeter Resources are strictly noticed and approved by the Security Team so that you are always updated about What can get into your Network and How can it get in.
Monitoring should make sure you don’t repeat the whole exercise every quarter and make it look like some recurring Pen Test. Cleanup only Once, then implement controls at Source — monitor your terraform commits, cloud formation changes and stop it at source if something is going public unnecessarily. First time Perimeter security activity could be a clean up, then implementing controls, but from the second time, monitoring for changes of an existing environment becomes the key.
To conclude it here I would like to bring up a Quote which can be very much related to Security.
If you know the enemy and know yourself, you need not fear the result of a hundred battles.
Here the most important part in this quote which applies to Security is
Know Yourself. This is more than enough for us to not fear the result of a hundred battles. If we are absolutely clear about what is running in my Network and Who can enter my Network and How can they enter it, all that is needed is YOU to stop a battle before it starts. In this case, you need not even know your enemy if you know yourself enough.
Conclusion
I know I made it look like a Gyaan Session in the end, please Spare me! Doing Perimeter Security like this is subject to Scale of the Environment and again its a Personal Choice, there could be a lot of ways in which this Process can be made more efficient, this is just my take on Perimeter Security, feel free to let me know in the comments and add your articles for me to learn how you do it.
Please feel free to point out mistakes if there are any. Thank you for reading. You can connect with me on Linkedin . Happy to answer your queries.
