DARPA wants to make soldier more easily targetable

A very long time ago - nearly another life ago - I helped a military contractor who had a security breach try to see what the scope of the breach was. In the process I learned quite a bit about battlefield communications. So, you can imagine my surprise to read this article in The Register about outfitting every soldier with a long distance readable RFID tag (not the type in the picture on the right, by the way). Readable from 150 km, no less! Considering all the pains the contractor I worked with went through to prevent any form of RF to be emitted, I find this technology rather bizarre. 

I could imagine the tag being useful for training and maneuvers. I could also imagine it being useful as a last resort for a soldier to be located when lost or wounded in theater and to be fair, in the referenced presentation it mentions (once) that the tag is 'inert', which may mean that it needs to be activated before it sends a beacon. That might be an acceptable application.

What worries me is that UAVs are now so cheap and accessible that I could easily imagine even small states being able to afford a small fleet of UAVs that swarm over enemy troops in theater and home in on these tags. Or other forms of identifiable RF radiation, such as from a FCW Land Terminals. 

I hope they know what they are doing, but I have my doubts.

Insider hacks own system

ABC reports that a San Francisco employee created "virtually exclusive access to most of the city's municipal data." And I thought those days were long gone when that would be possible. 

However, it doesn't sound like something that a good computer forensics expert couldn't solve.

I really like this idea from Symantec: paper-based malware. Somehow this way of raising awareness of the problems of bots appeals to me.

I can't be sure that ideas like that really work, but one can hope. Anyway, better to have a bot next to one's PC than in it!

But what's with that Norton Today site? No RSS feed? Come on! 

Semantic Web Meetup June 1, 2008

What would you do on a day of perfect weather in New York City? Attend an all-day code camp on Semantic Web programming in Brooklyn of course! OK, I guess I would have preferred it to be a rainy day if I had to be inside, but it still was worth it. I learned a lot about Semantic Web programming and more importantly, realized that the technology is closer to being reality than before. This is a report on what I learned.
The event was organized by Marco Neumann and hosted by Breck Baldwin of Alias-i. After bagles, that Marco had brought along, and introductions, a brief run-down of some of the concepts and technologies was given. This was followed by quick descriptions of the projects we were to tackle at the meetup. After a rather late lunch we chose our projects and had a few hours to complete them. In theory, we were supposed to use the Extreme Programming paradigm, but that devolved a bit into group programming interspersed with discussion. 

I don't really want to go into the projects in detail. I was interested in two of them, the Natural Language Processing project headed by Breck, our host, and a spatial reasoning projected headed by Marco. The actual projects were not that important really, though, instead the programming aspects were. I was at a disadvantage as it turned out that Java is king when it comes to semantic web programming and I've been doing my programming in Ruby and Erlang for over a year. Semantic Web support for Ruby is not great and not really existent on Erlang. 

In Java, the way to go was to use the Jena library. Jena started at HP, but in the intermediate time had become a sourceforge project. It now offers support for RDF, RDFS, OWL and SPARQL. It also supports reading and writing the RDF in RDF-XML, N3, N-Triple and I believe also Turtle. There was some discussion of the strengths and weaknesses of these formats. The rough consensus was that N3 and N-Triple are more human readable, but RDF-XML is more expressive, at least from a syntactical standpoint. It wasn't clear to me if there was any semantic difference. In the NLP project, Jena was used to emit RDF, initially in N3 format, though that was quickly changed to RDF-XML. Once that was done for a subset of the data, a SPARQL query was hacked together (again using Jena) that used that file. All in all, it required not that much real code, though given that it was Java there was all sorts of fluff surrounding it. 

On a side note, one of the participants showed us some of his Groovy code, and I must say that Groovy might get me back in Java again. It's like a less wordy version of Java, or perhaps a Java that has been put on a diet by the Ruby camp. When Groovy is mentioned, I guess you have to mention Scala as well. Both seem to be taking Java beyond the confines of the actual language, Java, by leveraging Java, the virtual machine and all the libraries that are available as Jars. 

Apart from the programming, there were a few other things I picked up. In the past I had been using Protegé. However, apparently this is no longer the way to go. A company called TopBraid Composer, which is based on the Eclipse platform and Jena has usurped Protegé from its throne. Apparently it is free for non-commercial use, though that is unclear from the website as it does say that you need to purchase a license after 30 days. 

One of the other projects was looking at transforming a relational database into an RDF database using D2RQ. There was a paper at W3 that describes this idea. From what I gather, this is nearly equal to trying to derive semantics from database schemata - not something that can really be mechanized. There are also all sorts of performance issues that will have to be addressed if a production database were to be stored as an RDF database, but perhaps this is too early to discuss those issues as we first need to understand why we need them this at all. If it means that we can elevate the data in a database to the level of information, this might be worth it, though. Since there seem to be all sorts of expressivity issues when comparing traditional databases to RDF stores, perhaps the right thing would be to develop new application based on RDF first and only then try to transform existing databases. 

Another subject that came up was the difference between ABox and TBox reasoning. ABox reasoning is based on assertions on individuals (ie, the rows of data, to use a database table analogy) whereas TBox reasoning is based on concepts (ie, the schema of a database table).

So, what does all this have to do with security? There are two aspects of this. 

1. The security of the Semantic Web metadata
2. Using Semantic Web technology to secure our data

The first aspect is certainly not a trivial one. Metadata has already caused embarrassment to many people including Tony Blair when people don't realize that there is more data in a typical document than (literally) meets the eye. In computer forensics, this is what we live for. However, as more webpages get semantic data attached to them, more data may be transmitted than gets shown to the user and now it can be read automatically. Privacy advocates will be all over this problem, but corporations will have to pay attention, too. 

However, what I am more interested in is the use of this metadata and the technologies of the semantic web to define and enforce security. At IBM, this is called Data-Centric Security and as far as I can tell, they are working on database security using taxonomies for classification. What the NLP projected showed me is that to some degree, we could also create a content based security system at some point in time. Alias-i and OpenCalais might be the key.

What the code camp showed me is that the technology has reached the point that it is usable. While security is nearly never a business case in itself, there will be other, more motivating, reasons to use semantic metadata in corporations and that will enable such ideas as DCS.

I just read about a canadian bank handing out ASUS EEE PCs. Now, a while ago when dealing with a Bank phishing case, I suggested that hypothetically, a bank could offer a simple laptop to their customers solely to do banking with. Of course, that is a problematic proposition that one single bank may not actually want to venture into on its own. We went over perhaps more practical solutions like booting from a Knoppix-like CD that could only be used for bank transactions as well as using a VMWare image. None were adapted, of course.

Now RBC is offering a free ASUS EEE PC as an incentive, but I keep on thinking that having a dedicated cheap laptop would be a good idea for the general population. The EEE is a small and basic Linux system, but supports one important thing: a browser useful for e-banking, Firefox. While I'm not a fan of remote attestation on practicality grounds, I could see it working in this case of a dedicated e-banking machine.

Would banks want to get into this business? I don't think so. However, an enterprising company might be able to convince enough banks to offer such a device to their customers and offer the security maintenance of such systems as a service.

Swedish interview

Hey cool. Me and Simone got quoted by Computer Sweden about Apple Macs and the malware problem.

Virus calendar

Gosh, what a blast from the past. Way, way back in the annals of time it was actually possible to analyze malware (OK, viruses mainly) well enough to know all trigger dates of their payloads. So, I thought I'd create a virus calendar. I think the first was created for the year 1990 or 1991 for the Virus Test Center so that we'd have something fun to show at expos like CeBIT. Then I got a commission to create one (and later another one) for perComp Verlag which they dug up recently and posted on their site for the years 1992 and 1993. While the 1992 version was mainly my work, I think I only contributed data and ideas to the 1993 version. Apparently some people in Germany still show excerpts of these calendars in presentations, though I shudder to think why. I think S&S International Ltd, UK also created a few calendars based on their own data and graphics, but after 1995 it became impossible to analyze all known viruses and even if it was possible, it would have been one crowded calendar!

This is one rare moment, where I was able to do something graphical in the context of computer security.

I think when I get back home, I'll dig out the original and scan that in, too!