Infrastructure Security: a Personal Perspective
My ways of Fortifying Modern Infrastructure — a high level overview
Note: This article talks about How to define infrastructure security in layers. This will not dive deep into the “what” part much — what can be done in each layer can be covered in a separate blog and is very subjective. This is a very high level overview and not a deep tech talk.
Infrastructure does not have a clear-cut definition of its boundaries or a comprehensive list of components falling under its category. Quantifying and determining what constitutes infrastructure is not an easy task. The challenge lies in the context, how one contextualizes infrastructure defines the scope of items that should be secured as part of Infrastructure Security. This is a field where the scope of breadth is little more important than the depth, most of the attacks on infrastructure I have seen are not because of lack of defense in depth, but the lack of defense in breadth.
Defense in depth is important, but breadth should not be overlooked at. Breadth ensures the lights are on no matter what. I feel breadth first & depth next is a really good strategy, of course depends on whats critical for you and whats not and moving accordingly.
The way I see it — 7Cs of Infra Security:
This is an attempt to define different categories of Modern Infrastructure so it will become easier to think of Security for Infrastructure and see whats important at which point of time. I call it the 7Cs of Infrastructure which go like —
CDN
Cloud
Cluster
Compute
Container
Code
Compliance
CDN Layer
This will become the entry point into my infrastructure, apart from caching and distribution, this serves a critical role in becoming the first line of defense for the fortress. My origin should always be free of any spikes and shocks, so CDN will become my shock absorber, be it a genuine spike in traffic due to a business use case or a malicious DDOS on the system, my CDN(s) should be indomitable here. Apart from DDOS, I can offload WAF & few other checks on to CDN to ensure minimal to no junk is processed by origin.
Since the role played by CDN is not just limited to caching and distribution, it becomes a critical component in the Infrastructure. One bad misconfig here can bring you down to your knees in no time. So CDN should always be considered part of your infrastructure, the mindset of - CDN is my vendor would work for certain things, but would not be appropriate when it comes to Security.
Cloud Layer
A place where all the core workloads reside. This layer could be Public Cloud, Private Cloud, even On Prem workloads, this layer signifies the organization’s core infrastructure.. Depending on the type of cloud — it depends what kind of security controls someone has to look at, mostly a shared responsibility model, few aspects covered by the provider and few aspects to be covered by the customers.
This layer mostly involves security of default services provided by cloud service providers and is specific to the platform, ex — s3 security, eks security, azure AD security etc.. Workload security should not be mixed here since this layer is very specific to Cloud and not about all the workloads deployed, that can be covered in the layers discussed further.
Cluster Layer
Once we start taking a closer look and start quantifying more, the next layer we get to see would be Clusters, which are of different kind and solving various purposes. Clusters could be Kubernetes, Kafka, Airflow, ES and so many more.
Clusters can be part of a single layer, but the security controls of each cluster are entirely different. Hence this layer qualifies to be looked at with certain amount of dedication and time.
Compute Layer
Quantifying further — here comes our compute layer, this could be both Server and Serverless. Core workload protection controls can be applied here, mostly dealing with Host level security.
Though the hardware level security is taken care by the providers, security of what gets installed on the compute layer is entirely on the customer.
Container Layer
This is the atomic layer of compute which you can run in the infrastructure. It is cgroups and namespaces all the way down. Container Security landscape is very different and requires dedicated effort to ensure security controls are up to the mark in this space.
Some of the host level controls intersect with container controls as well in many ways. Container networking is no different from traditional networking in anyway but requires a very different approach than traditional network security.
In any modern infrastructure where core workload is running in a container, it becomes super important to have a security strategy at this layer. If someone gets into your network, its not the perimeter, its your container all the way down, so this is indirectly your direct perimeter :D.
Code Layer
There are two things we can talk about in this layer
- Code which defines my Infrastructure & any configs around that.
- Core Application code which runs inside the container.
When it comes to 1 — it is part of Infra scope, since that is the source of truth for entire infrastructure. For 2 — it is more of an intersection between Prod Sec and Infra Sec.
Security controls around who can define what and how becomes extremely important when you are working on Shift Left culture, this is a layer which you should be most worried about.
Compliance
A silent underlying layer which is quite important and decides a lot of things in each layer. This defines how, many things in every layer has to be compliant to various frameworks in the compliance space. It involves adhering to industry standards, legal requirements, data privacy regulations, and internal policies.
It becomes easier to believe in certs more than substance in this world. Hence this layer becomes important xD.
Conclusion
All these layers help in defining what infrastructure is and how to categorize various aspects of it to ensure planning and strategy around it can be actionable enough, this also helps in not getting overwhelmed by looking at vast number of tools/components in the infrastructure, any tool can be put under one of these generic categories and have controls around it.
What security controls can be implemented in each layer is subjective and depends on the context. All kinds of security domains will be applicable in all the layers, ex — pentest, detection engg, threat intel etc.. this article is more focused on how to define infrastructure and not on what can be done. Whats and Whys can be covered in other articles.
Please feel free to point out mistakes if there are any. Thank you for reading. You can connect with me on Linkedin / Twitter. Happy to answer your queries.
