download issue 24 here - Help Net Security
download issue 24 here - Help Net Security
download issue 24 here - Help Net Security
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
A specific case is when processing an online<br />
form to become a registered user of a web<br />
site, often the siteʼs server creates a cookie<br />
that is placed onto the userʼs computer.<br />
Under precision emulation, the virtualization<br />
engine should follow a very simple, firewalllike<br />
rule. All user-solicited <strong>download</strong>s from the<br />
Internet write to the computer just like normal.<br />
But unsolicited <strong>download</strong>s such as drive-bys<br />
write to the emulation layer, never touching<br />
the computer.<br />
The result is that users can browse to any<br />
web site and click on any link without worry<br />
because all unknown or unwanted changes<br />
(from browser exploits and drive-by <strong>download</strong>s,<br />
spyware, and viruses) are made to a<br />
virtualized file system. So only the items the<br />
user purposely <strong>download</strong>s are placed on the<br />
endpoint PC.<br />
A closer look at precision emulation<br />
Precision emulation works by intercepting Microsoft<br />
Windows interfaces to directly access<br />
files and registry keys. In doing so, the process<br />
creates two major components:<br />
• A virtualization engine to creates a duplicate<br />
Windows file and registry system<br />
• A hooking engine to selectively redirect NT<br />
kernel calls to the virtualization engine.<br />
The purpose of the hooking engine is to intercept<br />
indiscriminate NT kernel calls. At this<br />
point, it decides if a kernel call was solicited<br />
by the user or was automatic, as in a drive-by<br />
<strong>download</strong>. The engine determines this based<br />
upon whether or not expected UI calls were<br />
made (user initiated) or not (automated,<br />
drive-by).<br />
User-solicited calls are made to the native<br />
system component as always, so as not to<br />
interrupt the userʼs normal workflow. Unsolicited<br />
calls, however, get applied to the virtualization<br />
engine and virtual file and registry system,<br />
and t<strong>here</strong>fore never reach the actual<br />
computer. At the end of each browsing ses-<br />
sion, the virtual layer can be reset and<br />
scrubbed to a clean state.<br />
Without this approach, user accounts often<br />
run with administrative privileges, giving applications<br />
freedom to read and write to the<br />
operating system and kernel. This allows malicious<br />
code to directly access and harm the<br />
operating system.<br />
Web shield benefits<br />
Caroline Ikomi is the Technical Director at Check Point (www.checkpoint.com).<br />
To conclude, placing a virtual shield around<br />
the browser has three core security benefits.<br />
1. It is signature independent: itʼs a zero-hour<br />
system that employs a simple firewall-like<br />
rule: reject all changes to the userʼs PC<br />
unless the user specifically solicits them.<br />
2. It protects the userʼs PC from the moment<br />
of connection: as web-based attacks can occur<br />
the moment the user encounters a web<br />
site, the shield approach does not passively<br />
wait for malware to transfer from the Internet<br />
to the PC. The virtualization layer shields the<br />
user immediately and through the whole<br />
session.<br />
3. Itʼs unobtrusive: no special setup or maintenance<br />
on the part of the enterprise administrator<br />
is needed, and all virtualization activity<br />
is invisible to the user and requires zero maintenance.<br />
The latest generation of web-based attacks<br />
need a solution that supplements and goes<br />
beyond the best of traditional endpoint defenses,<br />
including signature-based security,<br />
updates to virus and spyware eradication<br />
mechanisms, and firewalls. It needs to shield<br />
the browser – the userʼs point of contact with<br />
the Internet – from the endpointʼs operating<br />
system and file system, to stop unauthorized<br />
changes.<br />
After all, if youʼre going to put armor on your<br />
endpoints, why not do what our medieval<br />
ancestors did, and use a shield as well?<br />
www.insecuremag.com 19