In this version, the CIRDB has been updated to import XML data from the National Vulnerability Database, and a few bug fixes were made (a library file was missing in the previous distribution to support RSS feeds of the status of each domain over SSL).

  I am pleased to announce the availability of the first beta of my_cassandra.php, which can be downloaded from my home page
(change the extension from phps to php after you download it).

Because you get the source code and the custody of your profiles, this version of Cassandra should not generate the privacy concerns that the online version did.  As it is under your control you can also run it at the intervals you choose.  It is made available under an open source license so you can modify it.  It runs under PHP so it should run on almost any platform by changing the path to PHP (from “#!/usr/bin/php -q” for MacOS X).
Enjoy!

P.S.: I already received a patch from Benjamin Lewis from Purdue ITSP, improving robustness while reading a profile.  Thanks Ben!

It is very risky to enable all client-side scripting technologies when browsing the web (plugins/ActiveX/ JavaScript/Flash etc…).  I installed the “NoScript” extension for Firefox, which allows JavaScript to run only on some whitelisted sites. It is a wonderful idea, except that it comes with a list of pre-enabled sites with some that you can’t delete (the arrogance of dictating unerasable sites!), and the defaults are to not block Flash and other plugins. Moreover, it’s only as secure as DNS, unless you require the “full addresses” option through which I presume you could require an https (SSL) url. Unfortunately there is no way to enable “base 2nd level domains” *and* require SSL, to say for example that I want to trust all *.purdue.edu sites that I contact through SSL and that have valid SSL certificates. It is better than nothing, but needs SSL support to be really useful.  Most people don’t understand the limitations and vulnerabilities of DNS, and the need for SSL, and will therefore have an unwarranted feeling of security while using this plugin.

King and Chen (2005) write about their BackTracker software.  The idea is interesting:  let’s log everything needed to relate a sequence of events leading to an intrusion.  Everything in this case is processes, files, and filenames.  It can generate dependency graphs, once an anomalous process or event has been identified.  That is, something else must raise an alert, and then BackTracker helps find the cause.  It’s an interesting representation of an attack.

Taken one step further than they do, perhaps these dependency graphs could be used for intrusion detection?

Suh et al. (2004) propose a wonderful method for tracking taintedness, and denying dangerous operations.  It’s elegant, easy to understand, cheap in terms of performance hit, and effective.  The only problem is…  it would require re-designing the hardware (CPUs) to support it. 

I wish it would happen, but I’m not holding my breath.  Perhaps virtual machines could help until it happens, and even make it happen?

Kiriansky et al. (2002) wrote an interesting paper on what they call “program sheperding”.  The basic idea is to control how the program counter changes and where it points to.  The PC should not point to data areas (this is somewhat similar in concept to non-executable stacks or memory pages).  The PC should enter library code through approved entry points only.  It would be capable in principle to enforce that the return target of a function should be the instruction located right after the call.

Their solution keeps track of “code origins”, which resembles a multi-level taint tracking.  The authors argue that this is better than execute flags on memory pages, because those could be “inadvertently or maliciously changed” (and they have three states instead of only two).  I thought those flags were managed by the kernel and could not be changed in user space?  If the kernel is compromised, then program sheperding will be compromised too.  The mechanism tracking code origins heavily uses write-protected memory pages, so the question that comes to mind is why couldn’t those also be “inadvertently or maliciously changed” if we have to worry about that for execute flags?  I must be missing something.

The potential versatility of this technology is impressive.  The authors test only one policy.  Policies have to be written, tested and approved;  it is not clear to me why that policy was chosen and the compromises it implies.

The crux of the whole system is code interpretation, which, despite the use of advanced optimizations, slows the execution.  It would be interesting to see how it would fare inside the framework of a virtual machine (e.g., VMWare).  Enterprises are already embracing VMWare and virtual machine solutions for its easier management of hardware, software, and disaster recovery.  With a price already paid for sandboxing, using this new sandboxing technology may not be so expensive after all.  Whereas it may not be as appealing as some solutions requiring hardware support, it may be easier to deploy.

No, not our esteemed director of research.  It turned off my ELISA project, Enterprise-Level Information Security Assurance, due to lack of interest from the public at large.  The idea for this web application was to keep track of patches and basically support NIST’s recommendation on managing patches to use such a system.  I believe this indicates that the process was too heavy;  people don’t like to spend so much effort and money managing patches.