Since we published the PAID paper in 2004, people have asked whether the same approach could be extended to the Windows® platform where only application binaries are available. Originally, we thought it was just a matter of applying a state-of-the-art disassembler such as IDA Pro to a Windows binary to obtain its intermediate form, and then using the original PAID compiler to derive its sandboxing policy. Well, Windows binaries are much more challenging than we thought because the coverage and accuracy of commercial disassemblers is less than 100%. Since PAID transforms programs, it needs 100% disassembly coverage and accuracy. We then spent the next 12 months building a general Windows binary analysis and transformation infrastructure called BIRD, and used it to develop a binary version of PAID called BPAID, which is the first known system that can automatically derive a sandboxing policy for Windows binaries such as IIS that is guaranteed to produce zero false positives and negatives. This talk will walk you through the details of this adventure.  

As probably most of you know, almost any type of algorithm has been applied, sooner or later, to the topic of anomaly detection. Their mileage varies; sometimes the idea is good, sometimes it is plainly crazy. Host-based anomaly detection through the analysis of system calls sequences has been done in almost any way you can think of, but something no one (almost no one) has tinkered with until now is how to deal with system call arguments.

Even informally, you can understand that the argument of a system call is much more indicative of anomalous activity than the call itself. For instance, an "open" may not be suspicious per se, but a "read-write"open of the "/etc/passwd" file by a process which usually does not add users to the system may very well look suspicious.

We have developed a tool which analyzes each argument of the system call, models the contents of each, and then compares it against a "normal" model of previous calls. It is able to cluster system calls and thus detect "different uses" of the same syscall at different points of different programs. It then builds a Markovian model of the sequence, which is then used to trace and flag anomalies.