HackDig : Dig high-quality web security articles for hackers

«No Previous
No Next

When All Else Fails in Cybersecurity, Application Isolation Does Not

2017-07-26 12:05
  • We hear about cybersecurity fails all the time. We’re happy to tell you it doesn’t have to be that way.
  • Application isolation and containment based on virtualization is delivering results.
  • The NSA has called out this strategy as the way forward for stopping advanced threats.

To many technology folks, Application Isolation may be a new term when it comes to cybersecurity and endpoint protection. This term has been made popular by the National Security Agency (NSA). They detailed how Application Isolation is the way forward for finally stopping advanced, zero-day, and nation-state malware.

Watch: How ransomware is isolated in a micro-VM.

Fundamentally, stopping malware by using detection is flawed. This will always be a matter of catch up as the writers of malicious code tend to be one step ahead. The general rule is that a person that writes malware only needs to get it right once, while a person that writes software to stop malware needs to get it right every time. This was made publicly evident with recent malware exploits WannaCry and Petya. Most major detection vendors were vulnerable to this exploit as it was something that had never been seen before. While they were quick to develop a method to stop it, what if you were the unlucky person to get this on Day Zero?

The real problem is detection as a method to stop malware. Fred Cohen is a well respected computer scientist and the inventor of the words “computer virus”. He believed that detection was inferior as “there is no algorithm that can perfectly detect all possible viruses”.

It has often been said, “the only way to stop malware is to not stop malware”.

That is exactly what Application Isolation is all about. With Application Isolation, as users perform untrusted tasks that could be ingress points for malware, an isolated environment is created to perform that task seamlessly to the user. In the event that malware is part of that task, it can completely play out in the isolated environment with no access to the protected host operating system. This is the classic “honey pot” scenario that malware believes it is fully running and executing, yet only damaging a disposable environment.

Bromium is exactly that. Using Bromium isolation each untrusted user task is executed in a hardware isolated virtual machine transparent to the user. This means each time a user opens a tab in a browser, an untrusted Office or PDF document, or runs an untrusted executable, Bromium isolation creates a seamless hardware isolated virtual machine that performs the task for the user. In the event that malware is part of that task, it only resides in that virtual machine thus keeping the protected host operating system safe.

We take the approach of protect before you detect. While the hardware isolated virtual machine is performing the untrusted task on behalf of the user, Bromium isolation is using introspection from the outside to look into the virtual machine. This means that we are monitoring the virtual machine and looking for any “abnormal” activity. All this threat intelligence including the entire malware payload is then collected and sent back to the Bromium controller for SOC team analysis. While the forensic detail is important for the SOC team to analyze, comfort can be taken knowing that the attack never touched the users host computer.

In the walk-through below, I am going to take you through how Bromium uses Application Isolation to protect the users from untrusted documents. Also, I will show how we use introspection to monitor from the outside looking in the hardware isolated virtual machine. Finally, I will use VirusTotal as a method to show why detection is fails and the only real answer is Application Isolation.

First, I will launch a Microsoft Word document that has malware hidden inside of it. Using a utility, Bromium Live View, you can see all the running hardware isolated virtual machines on my endpoint. The Microsoft Word Document with the malware is running inside “Micro-VM 0123”. However, you will see that the Word document appears to be running no different than any other Word document from the user perspective.

Once the document is opened in a hardware isolated virtual machine, the malware will start executing its payload. The introspection of Bromium detects that abnormal events are happening, an alert is sent to the user and the SOC team that the document contains malware. However, as stated before, the malware can only execute in the hardware isolated virtual machine. At no point can the malware escape from the virtual machine.

While introspection is running on the virtual machine, all the forensic detail is being sent back to the Bromium Controller server. At this point the SOC team can examine the entire kill chain of what the malware did. Because we allow the malware to fully execute, the introspection is in a unique position to see the entire payload and step by step of what the malware did. As with most malware, the first step is a “drop and execute”. By examining the SHA256 hash of the malware, we can search a public site such as VirusTotal.com to determine what the industry knows about this particular malware.

Plugging the SHA256 into the search engine of VirusTotal.com shows the details of this particular malware. The first thing to notice is that as of the date of this blog, the malware payload is over a year old. The more interesting thing to note is that as of the date of this blog, only 31 of the 57 vendors that report to VirusTotal.com show this file as being malicious. If you are not familiar with how VirusTotal.com reports on this, all the vendors with a “result” in red show the file as malicious.

However, scrolling down, the vendors with a “result” of a green check mark do not recognize this file as malicious. I am not going to list the vendors, but I will allow you to read for yourself. This means that if your organization uses any of the vendors with the green check mark, your organization is not protected from this particular, year old, malware.

While most of the vendors on the VirusTotal.com list rely on detection, it should be pretty obvious why detection is flawed. It is only as good as the vendor that is updated their signature files. Even “Next-Gen” AV that is not necessarily based on signatures has its drawbacks. Carefully crafted malware will always be one step ahead of any type of detection, even “Next-Gen”.

It may be time to trust the advice of our friends at the NSA and take a serious look at Application Isolation.

The post When All Else Fails in Cybersecurity, Application Isolation Does Not appeared first on Bromium.

Source: /skrow-noitalosi-noitacilppa-sliaf-ytirucesrebyc/moc.muimorb.sgolb

Read:4850 | Comments:0 | Tags:Threats application isolation control demo government Isolat

“When All Else Fails in Cybersecurity, Application Isolation Does Not”0 Comments

Submit A Comment



Blog :

Verification Code:


Tag Cloud