Arun ShankarIn the cybersecurity arena, there are essentially two entry points – the endpoint and the servers and they are fundamentally different from each other. An application hosted on a server can be accessed both by good guys and bad guys, points out Satya Gupta, Cofounder and Chief Technology Officer, Virsec.
Moreover, end points are protected by solutions called Endpoint Detection and Response, EDR that have been built on two fundamental assumptions that no longer hold true.
EDR solutions have been built on the premise that all the signatures of attacks can be catalogued and that threat attackers will at some point of time or the other, use one of those signatures for their attacks. Another assumption built into EDR solutions is that the average time span of any threat attack is an extended duration, during which time the EDR solution can detect, respond and alert the end user into some action if necessary.
“These EDR technologies are not really suited to protecting servers anymore,” stresses Gupta. “The world is very different today. Attackers are coming in unannounced, and within seconds, they will have completely wiped your machine. They are not shy about employing the best skills, because people pay $15 million ransom these days, right?” he adds.
Expectations that threat actors are obliged or to use predefined techniques and signatures that can be added to a library and catalogued by EDR solutions for the benefits of customers, can now be labelled as old school stuff, feels Gupta. “It is like trying to count every drop of water in the ocean, that many techniques exist out there,” he adds.
Today’s reality check is that attackers can take advantage of vulnerabilities in code, and within seconds can infiltrate a network, launch a ransomware and convert servers and industrial machines into bricks.
The Virsec approach
In order to meet the new realities of today and tackle modern day threat attacks, Virsec is adopting a new and completely different approach towards offering cyber security solutions. “What we do is instead of focusing on the attacker, we focus on the application. All other security controls focus on the attacker, we focus on the developer,” says Gupta.
Attacker techniques by default and for logical reasons have to keep changing, to avoid detection and to remain commercially successful. However, developers write code and use code to build applications. The code inside applications produces the same results irrespective of time, place or date. “In other words, code behaves remarkably the same way, and it does the same thing over and over again,” points out Gupta. This allows application code when executed to be used as a running timeline of application integrity.
When threat actors override application code by running their own code at the same time, this is detected against the baseline of application code. “When the code starts doing things that are not part of the infrastructure, not part of the design, it is easy to spot that. That is the fundamental difference between our technology and everybody else’s technology. We are tracking code, they are tracking data,” says Gupta.
Inside the CPU
If an application always runs the code delivered by the developer, it will not serve the purpose of the attacker, since they will not get access and control, into the organisation’s infrastructure. For that to happen, and for the attacker to inflict some damage, the attacker must be able to run their own code while the application code is being executed.
The approach adopted by Virsec is to focus on that point in time when attackers are able to gain the privilege of executing their code along with the application workload.
“Our technology is focused on detecting that moment of truth, when the attacker is gaining privileges of executing code on your system. Because after that happens, anything that they do is completely out of your control,” explains Gupta. “Whether they do ransomware, whether they do exfiltration, or both, and something else is an after effect of that step.”
The Virsec Security Platform provides tools that read Windows, such as MSIs and Linux, such as RPMs, DEB, TAR software packages and extracts executable and library information from the package to build out the enterprise’s file integrity database information. Virsec tools read the executable files and the libraries of code and build a database of these files. This database is now carrying all the information about executable files that will be present in-memory when the enterprise’s application workloads are running.
Checklist
When the applications are running, Virsec’s kernel module checks the integrity of the executable files being loaded into memory with those saved in its database. A logical question to ask at this stage would be, can malwares from threat actors also change the executable file database maintained by Virsec?
“We check integrity in the kernel module. That is essentially out of bounds of malware,” explains Gupta.
Another logical question to ask, would be whether the database look up and compare process by the Virsec tools actually hampers the performance of the application workload?
“We have very thin instrumentation and see very little performance impact,” says Gupta.
Another way to view the decision-making process of the Virsec instrumentation, is assessing whether the transition from function one to function two of the application codes was legal, based on the disassembly that was created by the Virsec instrumentation in the beginning of the run-time.
“What matters is where did the instruction that is executing in the CPU come from. That is the domain in which we play,” continues Gupta.
Inside the application space
According to Gupta, there are essentially two kinds of applications. An application that has been written in a compiled language, or those that have been written for web in an interpreted language. While the attack mechanisms are different in the two types of applications, the foundational principle that the attacker wants to be able to run code on a machine still remains the same.
Web languages include Java, .NET, .NET Core, PHP, Ruby and Node.js while developers also use web frameworks like Tomcat, WebLogic, WebSphere, Ruby on Rails.
Virsec works with those languages and other standard frameworks since people use them all the time again and again. “Our technology grows by the number of frameworks and the number of languages that we protect. We protect 90% of the web languages today, but we are always adding some more exotic ones that come up,” explains Gupta.
Another market trend around the Virsec solution portfolio, has been early adoption by selective market segments like government, defence, national and critical infrastructure, amongst other. And there is a reason for that.
“More and more people are beginning to realise, this notion of detecting and responding is not, what you would like to do. If you can have proactive protection, it is a whole lot better than detecting and responding,” points out Gupta. And the customers that are the earliest to realise this are the ones typically in the most critical market segments.
For Virsec, the early adopters and the early innovators, are those enterprises who cannot afford the risk of any type of attacks. And are definitely those market segments that cannot afford to perpetuate the outdated detect and respond approach. This is typically the frontline and the most critical market segments of any nation.
“So, we are very ubiquitous in the sense that we can protect any workload. In fact, the mission of our company, our longer-term mission is to make cybersecurity irrelevant. It is a very profound statement,” sums up Gupta.
