Thursday, January 27, 2011

Question: Why Is Leakinator Implemented In VBscript?

So Leakinator is intentionally implemented in a somewhat simplistic, and possibly archaic, scripting language because of its use case, which seems to be more prevalent now that we are in the aftermath of the great economic implosion;

requirement : detect and monitor removable drive(s) in support of an investigation, with little or no preparation, within the constraint that you have no method of doing this, because;

- no monitoring tools are available
- no budget exists for any monitoring tools
- the need is immediate, there is insufficient time to gather or install a monitoring program or a non-native script interpreter
- even if you had a program or tool, security policy and/or insufficient privileges prevent you from quickly installing software on either the client or target system
- either system system may be a running a very basic Windows 2000/XP image lacking amenities such as a JVM, .net or powershell (and it is not immediately possible to install any of these).

Another reason WMI interaction is commonly done in vbscript is that it is very easy to customize vbscript to suit the situational needs of the moment, for example as in the next blog posting.

Here's a more interesting question: if this can be easily and remotely done in a few minutes of vbscript, why can't we have this functionality in DLP products, and reduce the associated burden of installing and maintaining tens of thousands of agents? Tamper resistance is one reason given; this seems debatable as neither WMI nor the most hardened agents are entirely tamper-proof on a general-purpose OS..and those capable of tampering are probably a minority. How many line and/or knowledge workers are capable of tampering with either WMI or a DLP agent? For those who are not, and have a stationary desktop, why can't we have agent-less DLP?

No comments: