Applying AV signature strategies to sandboxing

Enumerating badness is not scalable. Enumerating goodness is often impractical. But how about enumerating sandboxes?

i.e. maintaining a database of rules for known good applications, and distributing it along with the usual AV signature updates. The hypothetical AV would include a sandboxing driver, which would block program behaviors based on those rules. Unknown programs would just run unconfined (assuming the traditional part of the AV didn't consider them malware and block their execution).

"Wait," you might say, "What happens when a program is updated?"

Well, what I'm hoping is that the same strategies used by AV companies to create more generic malware detection rules could also be applied to legitimate programs. The sandboxing AV would recognize an updated version of e.g. Firefox as being similar to the old version, and attempt apply the old set of rules to it. If that caused problems, the company could issue a signature update to fix the rules.

What's the point of this? Convenience. Not everyone has the time or the knowledge to lock down their computer, and just looking for malware (even with heuristics) is not scalable. Paying someone to maintain a database of working access control rules strikes me as a reasonable compromise for most users.

 

The goal of moving beyond the default-allow model used by AVs, without involving the user in decisions about what behaviours to allow or deny, is currently achievable with policy restriction programs such as AppGuard and DefenseWall.

Policy restriction programs fill the gap left by blacklisting. Unknown programs that have not been intentionally installed on the system by the user, together with known good programs that have been designated as untrusted (e.g. browsers), are not allowed to run unconfined.

Unlike signature-based strategies, the policy restriction approach doesn't need signature updates to remain effective.

 

Agree with what pegr said.

If you take the AV part out of your post, you would realize that this is what Sandboxie and Defensewall does. The developers create the rules for their respective implementations of sandboxes (Defensewall uses kernel patching while Sandboxie v4 uses IL, access control and redirection). Both make policy-based sandboxes more usable for the end-user. Users simply have to "sandbox" or "untrust" a program. In the case of Defensewall, it comes with preset list of "untrusted" programs. You can see the changelogs: whenever a new version of let's say a browser is released which conflicts with the sandboxing program, the dev releases a new version to fix the conflict.

Then, there's also implementations like Comodo's sandbox where instead of restricting the threatgates, "unknown" programs (using predefined Trusted Publishers as identification) can be auto-sandboxed (there's 4 restrict-type settings and 1 "fully virtualized" setting; you have to choose 1)

AppGuard combines both approaches by using a system-vs-user space differentiation model. System space generally trusted except for common threatgates (you can also manually add untrusted programs). Userspace executions are either "guarded" (sandboxed without redirection) or denied (userspace AE similar to LUA+SRP combo) depending on which mode you set it to.

Tzuk, Ilya and Blue Ridge never claim their products as replacement for AV (generally recommend pairing their products with AV although most Wilders users choose not to). Comodo comes with its own local and cloud AV.

AVs themselves also now incorporate some form of sandboxing. Avast for e.g. Some AVs choose to use sandboxing in a different way. Instead of restricting threatgates or unknown programs, they use it as a mean to isolate unknown code while analyzing the code to identify it as clean or malicious.

Microsoft uses AppContainer as their sandbox for Modern (aka Metro) apps.

All-in-all, sandboxing as a concept is gaining momentum and wider usage. Just in different forms and implementations.