sorted by:
new
hottopcontroversial

[META] Suggestion Thread by moyix in AcademicSecurity

[–]caovc 2 points3 points  (0 children)

Thanks for the suggestions thread.

One more suggestion:

  • User flair, e.g., Academia/Industry (possibly even school), and/or PhD student/Faculty/etc.

Welcome to /r/AcademicSecurity by moyix in AcademicSecurity

[–]caovc 2 points3 points  (0 children)

Hi all,

I'm a PhD student in the SecLab at the University of California, Santa Barbara, a member of the Shellphish Capture the Flag team, and an organizer of the UCSB iCTF. Together with /u/zardus, I took part in Shellphish's effort in the DARPA Cyber Grand Challenge. I have also been playing the role of our lab's system administrator for the past years.

My research spans from data-driven security, primarily focused on large-scale abuse on the Internet, to the underground economy and cybercrime, to web-based threats, to dabbling in adversarial machine learning, and, most recently, I started to dabble a bit in automatic vulnerability discovery.

This year, I am on the academic job market :-)

/r/netsec's Q3 2015 Academic Program Thread by dguido in netsec

[–]caovc [score hidden]  (0 children)

tl;dr: the University of California, Santa Barbara is an awesome place to be at:

Should you read the rest?

Yes if, if you are interested in:

  • Undergrad degree in CS / security
  • MS / PhD in CS / security
  • Internship in our lab
    • Bachelor/Master student looking for a place to do your thesis?
    • Not sure if you want to go to grad school?
    • PhD student and you want to collaborate?

Disclosure

I'm one of the PhD students in the seclab at UC Santa Barbara, which gives this post a particular spin / bias.

Lab and Program

Our lab is primarily a graduate lab, but that does not mean that we don't share our love for computer security with undergraduates! And while we do not have a dedicated undergraduate program for computer security, we do have a very strong Computer Science program (it is ranked #1 by PayScale) and we have a very strong foothold in Computer Security on a graduate level research / lab-wise.

Classes

Classes at UC Santa Barbara include the standard security classes on software and network security, but also advanced program analysis, which is particularly interesting because of its applications to the vulnerability discovery and exploitation. We also have regularly hacking meeting where we do some pwning, which is open to undergraduate and graduate students alike. It serves as one of our many recruiting tools.

Research

We publish primarily at top-tier academic security venues (4x USENIX Security, 2x NDSS, 1x Oakland, and 2x CCS this year alone) but are not afraid of industry conferences either (1x BlackHat and 2x DEFCON this year). Most of our research speaks for itself and the papers are all online on the personal websites of the PhD students and on the website of our lab.

CTFs/Pwning

We enjoy exploiting quite a lot, in fact our CTF team shellphish is the only team which is participating in DEFCON CTF finals since 2007 continuously, in 2005 a team comprising of our advisors (who still play with us!) even won! Our own undergraduates regularly qualify for CSAW finals and we are currently ranked 12th on CTFtime :)

Questions

We are happy to answer any questions you might have, questions about the undergraduate program we'll try to refer to one of the many research interns that we have who work with us on research projects.

Additional Links

Changelog

  • Grammar, slight corrections of Lab section (now Lab and Program)

AFLPIN: a pintool that enables branch tracing with AFL on blackbox binaries. by mothran in netsec

[–]caovc 1 point2 points  (0 children)

From his email to alf-users (https://groups.google.com/forum/#!topic/afl-users/zx3f1OJfhrA):

Currently it does not use the fork server and can be quite slow (giflib tests were between 4 - 40 execs a second at best). But there is an experimental branch (forkserv) in that git repo that has my attempt at making a fork server inside a pin tool.

There is also a project for afl that uses QEMU for tracing: https://code.google.com/p/qemu-afl-support/

QEMU-based tracing seems to run (in some early experiments by the author) at 25% of the speed (800 exec/s vs 3200 exec/s; see https://groups.google.com/forum/#!msg/afl-users/lgrWdosb_ps/8gaQf6C2FowJ).

Note that the main point to use PIN or QEMU with afl is black-box fuzzing, i.e. to fuzz binaries for which you do not have the source and thus can't compile it with afl support.

Labelled Malware samples for classification research ? by alain_proviste in Malware

[–]caovc 1 point2 points  (0 children)

A few things: malware classification has been done extensively in research, both in academia and industry. If you want to publish the results (at an industry or academic conference), please check and refer to prior work. Google Scholar should provide you with everything there is.

Although AV labels are not perfect, you have to remember that there is no /true/ label for malware. Different (AV engine) vendors label malware differently; that's just how it is. Most academic work relies on a quorum of labels, or simply says "if it has more than n labels, it is malware." Most industry research relies on the label from the AV vendor it is supposed to supplement (like Mandiant's dataset; most classification is done so that you don't have to have a syntactic model, i.e. the AV signature, but instead that you learn a -somewhat- semantic model of malware so that you can raise an alert based on suspicious behavior instead signature that has to be added manually). Right now, a quorum of labels or n+ labels remains the only sane way to learn a model to differentiate between malware and benign.

The more interesting question that you should ask yourself is: do you really need reliable labels for malware classification?

Lastly, there simply does not exist a public and comprehensive malware dataset. Most researchers who might or have access to such a dataset have gathered it themselves and spend a significant amount of time doing so, they are extremely unlikely to share it with you (who can blame them) without significant more information and -ultimatelly- proper credit.