The announcement is of course Good News — because once the PCeU is up and running next Spring, it should plug (to the limited extent that £2 million a year can plug) the “level 2″ eCrime gap that I’ve written about before. viz: that SOCA tackles “serious and organised crime” (level 3), your local police force tackles local villains (level 1), but if criminals operate outside their force’s area — and on the Internet this is more likely than not — yet they don’t meet SOCA’s threshold, then who is there to deal with them?

In particular, the PCeU is envisaged to be the unit that deals with the intelligence packages coming from the City of London Fraud Squad’s new online Fraud Reporting website (once intended to launch in November 2008, now scheduled for Summer 2009).

Of course everyone expects the website to generate more reports of eCrime than could ever be dealt with (even with much more money), so the effectiveness of the PCeU in dealing with eCriminality will depend upon their prioritisation criteria, and how carefully they select the cases they tackle.

Nevertheless, although the news this week shows that the Home Office have finally understood the need to fund more ePolicing, I don’t think that they are thinking about the problem in a sufficiently global context.

A little history lesson might be in order to explain why.

Back in 1930’s, Bonnie and Clyde and other US bank robbers were using the new-fangled automobile to flee across state lines — creating jurisdictional problems as a result. The US solution was to make bank robbery (along with auto-theft and other related offences) into federal offences rather keeping them as state-specific infractions. In particular this meant that the FBI could provide federal level policing (tracking down and killing John Dillinger for example).

We have the same jurisdictional issues dealing with cyberspace, with criminals in one country fleecing consumers in another while using systems hosted in a third. The Convention on Cybercrime addresses part of the problem by trying to ensure international consistency where eLaws are specifically needed (which of course is only the case for small parts of eCriminality, fraud is fraud whether eEnabled or not). However, there is limited inter-jurisdictional co-ordination for eCrime investigations — for example Interpol (often incorrectly perceived to be international police force) merely keeps a large database and passes faxes from one place to another.

In practice, most cross-border investigations are done as “joint operations” and the jointness is usually very limited — one force does all the legwork and a liaison officer in the other country deals with local paperwork. There’s usually a quid pro quo element to these joint operations, for budgeting reasons if no other.

What isn’t happening, or at least only in a handful of very specialised areas, is any international co-operation in setting priorities or selecting cases to pursue. Every country is doing its own thing about eCrime, and there’s a widespread impression that any criminal who can operate from “across the state line” is essentially immune from serious investigation.

We identified this problem last year when we (Ross Anderson, Rainer Böhme, Tyler Moore and myself) wrote a report on Security Economics and the Internal Market for ENISA. It’s not an easy one to fix whilst politicians (and populaces) are unwilling to see “foreign” police officers operating in their country, and the establishment of a truly international “cyber police force” seems equally unlikely.

Our policy proposal to tackle the issue harks back to WWII’s SHAEF, which has morphed into similar arrangements within NATO. In essence liaison officers from multiple forces would sit around a single table, working with a central coordinator, to set policy and decide which investigations to pursue. They would then communicate back to their own countries, who have specifically budgeted to provide appropriate assistance. So it’s very like “joint operations”, but the scheme is multi-laterial, and has a true command and control function in the centre — who will quickly learn to shy away from politically sensitive topics and make a real impact on eCriminality.

To summarise then, a welcome to the Home Office for finally finding a small amount of funding for some country-wide ePolicing; but it’s well past time to be working on world-wide initiatives.

One of the main problems in counterterrorism today is that there are so many people and vehicles, and so much data and material, moving through globalization's myriad networks that it seems virtually impossible to track it all effectively. Nowhere has this problem been more acute than on the high seas.

In 2006, Adm. Harry Ulrich, then U.S. commander of NATO Naval Forces Europe, decided to do something about it. Despite having virtually no resources, his dream was to transpose the global air-traffic control system onto sea traffic.

Worldwide, aircraft are transparent, because they're all required to carry an identification beacon that allows them to be tracked leaving and entering airports, and monitored between airports, by a global network of sensors. Act suspiciously and somebody's fighter aircraft will soon be on your tail.

No such pervasive system currently exists globally for maritime traffic. While bigger ships carry an ID beacon similar to aircraft, without a shared monitoring network, that's like tracking only selected commercial jets and giving everyone else a pass.
So Ulrich, upon taking command, asked a simple question: "If we can do that in the air, why can't we do it on the sea?" He made a point of pioneering his sea-traffic-control effort first inside the Mediterranean, where NATO's southern naval forces have historically been concentrated, but his real target was waters off Africa -- the most ungoverned maritime space in the world.

Ulrich knew the U. S. Navy couldn't do it alone, much less bring Africa's meager coast-guard-like navies up to snuff so they could do it on their own. So he quickly created a network of assets -- both public and private -- to manage that space, modeling his monitoring system on international air-traffic control.

Ulrich began stitching together a network of shore-based sensors ringing the Mediterranean. His naval command then began initial monitoring by tapping into the International Maritime Organization's existing Automated Identification System, transforming NATO's ability to track ship traffic in the Med.

Almost overnight, NATO went from tracking dozens of ships on the Mediterranean to thousands, and instead of getting the data sometimes up to 72 hours late, now the contacts were being tracked in one to five minutes -- to an accuracy within 50 feet on the earth's surface.

When the classic big-firm systems integrators told Ulrich it would be too costly to pull it off, the admiral turned to the Volpe Center in Cambridge, Massachusetts, a U.S. Department of Transportation research center. Instead of hundreds of millions of dollars, Ulrich's initial network cost $900,000. The shore-based receivers are small, roughly the size of a radar dish you might find on a pleasure craft.

The strength of the system is a function of its reach: the more countries join, the larger the shared operational picture. By the time Ulrich retired at the end of 2007, he had enlisted 32 countries throughout the Mediterranean, the North Atlantic, along the west coast of Africa, around the Black Sea, and in the Pacific. Today, the network continues to spread around the planet.

With Ulrich's system in place, local police, coast guards, and border patrols catch most bad guys, obviating American military responses. As Harry told me for an article I wrote about his work in a fall 2007 issue of Esquire, "I don't do defense; I do security. When you talk defense, you talk containment and mutually assured destruction. When you talk security, you talk collaboration and networking. This is the future."

The admiral's legacy program, the Maritime Safety and Security Information System, earned the Volpe Center a prestigious "Innovations in American Government" award this month from Harvard University's Ash Institute for Democratic Governance and Innovation.

Based in Europe, the Rock Phish group is a criminal collective that has been targeting banks and other financial institutions since 2004. According to RSA, they are responsible for half of the worldwide phishing attacks and have siphoned tens of millions of dollars from individuals' bank accounts. The group got its name from a now discontinued quirk in which the phishers used directory paths that contained the word "rock."

The first sign the group was expanding operations came in April, when it introduced a trojan known alternately as Zeus or WSNPOEM, which steals sensitive financial information in transit from a victim's machine to a bank. Shortly afterward, the gang added more crimeware, including a custom-made botnet client that was spread, among other means, using the Neosploit infection kit.

[...]

Soon, additional signs appeared pointing to a partnership between Rock Phishers and Asprox. Most notably, the command and control server for the custom Rock Phish crimeware had exactly the same directory structure of many of the Asprox servers, leading RSA researchers to believe Rock Phish and Asprox attacks were using at least one common server. (Researchers from Damballa were able to confirm this finding after observing malware samples from each of the respective botnets establish HTTP proxy server connections to a common set of destination IPs.)

The following excellent discussion is reposted from Streaming SQL approaches insist in ignoring causality by PatternStorm.

The recent paper “Towards a Streaming SQL Standard” by Oracle and Streambase unifies and generalizes two different execution models of Streaming SQL: Oracle’s and StreamBase’s.

While it’s true that the generalization succeeds in overcoming the unability of both execution models of producing correct results for astonishing simple queries (showing evidence of the actual limitations of these two Streaming SQL languages) it is also true that the generalization is closer to being overly complex than natural and intuitive.

The root cause behind the actual limitations of these two Streaming SQL languages is that their execution models “hardcode” the way events can be related to each other: in the Oracle case events are partially ordered by timestamp, in the StreamBase case events are totally ordered by time of arrival. These design decisions (natural in a stream oriented lamguage) have strong implications on what queries can be answered correctly, particularly when these queries involve joins of derived streams.

The generalization, of course, mainly consists in providing a new operator that allows the user to establish custom ordering relationships among the events (the SPREAD operator), which is good news but takes us to the fundamental issue: event processing cannot be reduced to stream processing, that is, to the processing of events that are totally or partially ordered by a pre-defined relationship (as Oracle and StreamBase actual implementations do), on the contrary, no particular ordering can be assumed because the user needs to be able to order the events in different ways in order to solve different problems. This is what event processing is about and the paper provides evidence that Streaming SQL approaches have found the need to move towards that direction and are having trouble in their way.

For instance, one of the queries used in the paper as an example of a query that StreamBase cannot solve (but Oracle can) is the following: correlate the stream that contains the total number of cars on the road for each time interval with the stream that contains the total average speed of the cars on the road for each time interval in order to detect the situation where the avergae speed is below 45 and the total number of cars is two or more. This query can be very easily and more robustly solved if you order the events by causality rather than by time, that is, if you have each position report update the average speed stream and the total number of cars stream and then you causally relate each position report to the new average speed event and the new total number of cars event that it generates; then the query is just a matter of detecting all report speeds that are causally related both to an average speed event below 45 and a total number of cars event of two or more (notice that this approach is more robust than Oracle’s time-based one because it works without requiring derived streams to be synchronized with the report speed stream)

Conclusions:

• Event Processing is a generalization of Stream Processing (as the paper shows)
• Event Processing requires providing the ability to the user of creating custom relationships among events and then define patterns/queries using those custom relationships.
• Causality is more often than not a more robust and easier criteria to order events than time or order of arrival.
• Event Processing Languages should support causality.

Regards,
PatternStorm

Parlez-vous open source? While wide-spread open source usage is still debated in many companies, the French have been advocating for all open source all the time in government and education. French President Nicolas Sarkozy set up an economic commission that recommended tax benefits to stimulate more open source development. Lesson learned from France: start ‘em early. “All students in France use open source.”

Just in time for Labor Day, John Edwards (no, not that one) comes out with an informative guide on “Who provides what in the cloud”. No doubt, this will be a rapidly expanding list, but what’s really interesting is the comment on the article. People have very strong opinions on the cloud…

Research firm Aberdeen Group reports that network costs will increase slightly more than 5 percent over 2007. Contributing factors: “need for speed”, shift from standard to mobile PCs (more end points of connectivity), and the ever-expanding network. And of course the hidden costs of multiple tools with multiple management consoles – if you’re not smart enough to choose say a comprehensive network management solution that is vendor agnostic…One tool to monitor them all…

And just because I miss the Olympics already, here’s an irreverent take on what it’s like to lose to Michael Phelps. http://www.thetechstop.net/?p=1503

Enjoy your long Labor Day Weekend!