HomeOperationsSecurityTorq Taken an Outside-in Approach to Cloud-native Security

Torq Taken an Outside-in Approach to Cloud-native Security

Over the last decade, there has been a paradigm shift when it comes to the IT world. As the world becomes more and more digital, attacking infrastructure becomes more lucrative and potentially bearing financial benefits. Attacks on infrastructure security will never stop and only ever intensify. And nobody wants to know how insecure they are, everybody wants to know that they are secure. In this article, we look at the key issues related to Kubernetes security today, and how Torq takes a unique approach to solving these challenges.

The important aspect of any modern security today is that there is a gap. Security professionals are responsible for defining security policies and detecting various security events but they don’t possess the ability to autonomously resolve issues. They need to get back to the DevOps owners, site reliability engineers, and the ilk and collaborate with them in order to resolve any open issues. So the most significant need today is for easy, streamlined, scalable, and observable collaboration at this juncture. We are at an inflection point where there are a lot of technologies that can identify the issues but won’t go any further. Security engineers end up being in charge of fixing the issues. 

Anti-patterns seen with K8s security

The most common one is starting with detection because remediation is difficult. This is an anti-pattern because it provides people with a false sense of security. They think just because they are overseeing the infrastructure, they can detect if and when anything goes wrong. This works to a certain extent but ultimately becomes a race against time to analyze and remediate the detected issue. The super focus on detection and a complete deficiency in creating a roadmap post-detection is the biggest issue today. We need to be able to reduce the time between awareness and remediation. When it comes to security, there’s no time to freestyle.

Securing each path in a Kubernetes stack from code to production

Let’s start out by splitting a Kubernetes stack into three parts. The Kubernetes environment itself runs on some sort of infrastructure, this could be a private cloud infrastructure or public cloud infrastructure. So the first thing to do is to secure that layer of infrastructure. Then we need to focus on and secure the Kubernetes environment itself. Finally, we need to look at the innermost component – workloads – and try to secure it in the pipeline so that no vulnerable code gets to production. So, there’s underlying infrastructure, Kubernetes virtualized infrastructure, including the overlaying network and the workloads themselves that need to be secured. 

It’s not enough to just secure your pipeline though. This is because vulnerabilities are constantly getting discovered and if they get published they will exist in a code that runs somewhere in production. A workload that has passed secure pipeline checks previously doesn’t mean that the new information could not have come to light today which makes it insecure and exploitable. That’s why there needs to be a combination of in-pipeline security and runtime security for the above mentioned components. 

Torq’s approach to security

When it comes to organizational security processes, Torq’s focus is on orchestrating and automating the resolution of security; detection is not the main aspect. The shift left approach has democratized a lot of responsibilities that were previously on the IT team back to developers. No matter where, in the pipeline or the runtime, when you find an issue, remediating becomes a very orchestrated process. Torq believes that you need to build a clear follow-up and orchestration pipeline for every finding. This requires you to pre-build mitigation, remediation, and containment modules that will be used as part of the pipeline. 

Ultimately, Torq is applying the same principles – preparation, enrichment and identification, containment, analysis, remediation, and returning back to production – to Kubernetes and cloud-native security as the National Institute of Standards has defined in its standard for incident handling. These principles can be applied to any environment but the problem with cloud-native environments is their velocity, the speed at which things are rolling into production, incremental updates, continuous deployments, etc. This speed should be matched by the speed with which you continuously analyze and resolve problems. It is almost as if you extend the continuous development, integration, deployment, analysis cycle to identifying security issues, assigning, orchestrating, deploying, and remediating. It becomes the extension of your development cycle. Torq’s approach to security is a democratized, continuous, orchestrated incident management for cloud-native environments. 

The fundamental thesis Torq had in order to build a solution that allows organizations to orchestrate security events is to be a hundred percent open to any monitoring tool, in-house scripts, open-source tools, commercial products, etc. When you compare Torq as an automation and orchestration platform to previous generation products aimed to solve similar problems, Torq stands out as it comes with integration templates that can be reused and connected to homegrown tools or innovative solutions without being blocked even for a single second. So, Torq is an open platform that can connect anywhere and can quickly consume any data structure that describes the event-finding alerts at the core. 

How different teams can use Torq

There is a big difference between how a pure security specialist, and say, a developer or someone from the SecOps/Ops team uses Torq. Even though the experience is different, they care about a common communication pathway and have common building blocks.

So, the focus is on providing maximum ease of expression to teams that are not solely centered around security. Enabling development, efficiency, increasing velocity, and providing a framework that is streamlined becomes the focus of Torq when it comes to teams that aren’t necessarily involved with the security aspect. Torq has the ability to integrate with any programming language. The same platform with the same capabilities solves different problems for different groups of people.

Conclusion

With cyber criminals running rampant in the last couple of years, cloud-native security has become a huge topic of concern. The current digital world is engulfed in complex ecosystems like Kubernetes. Complex and massive infrastructures are difficult to secure in a single way. Therefore, pipeline and runtime security are equally important and need equal attention. 

In comes Torq with its unique approach to security by shining the spotlight on remediation rather than detection. The platform acts as a continuous, orchestrated incident management tool for cloud-native environments. With the amount of promise this platform has, it will be exciting to see how it carves its name in the world of cloud-native security.

For in-depth knowledge about Torq and everything it does, do check out this interview:

If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.

NEWSLETTER

Receive our top stories directly in your inbox!

Sign up for our Newsletters

spot_img
spot_img

LET'S CONNECT