The technologies, generally regarded as promising but unproved, have yet to be widely accepted as evidence — except in India, where in recent years judges have begun to admit brain scans. But it was only in June, in a murder case in Pune, in Maharashtra State, that a judge explicitly cited a scan as proof that the suspect’s brain held “experiential knowledge” about the crime that only the killer could possess, sentencing her to life in prison.

[...]

This latest Indian attempt at getting past criminals’ defenses begins with an electroencephalogram, or EEG, in which electrodes are placed on the head to measure electrical waves. The suspect sits in silence, eyes shut. An investigator reads aloud details of the crime — as prosecutors see it — and the resulting brain images are processed using software built in Bangalore.

The software tries to detect whether, when the crime’s details are recited, the brain lights up in specific regions — the areas that, according to the technology’s inventors, show measurable changes when experiences are relived, their smells and sounds summoned back to consciousness. The inventors of the technology claim the system can distinguish between people’s memories of events they witnessed and between deeds they committed.

“I have quite a few other concerns the with EPTS Member Agreement.   Basically, the agreement needs to be written with an eye toward a more flexible, open and inclusive process that puts the future of the EPTS square into the hands of the event processing community, not a small group of well intended folks who represent a small part of the overall event processing community and worldview.”

Opher’s reply was to just dismiss these comments, a bit surprising since I served the CEP/EP community on the EPTS steering committee; worked quite hard as a matter of fact, for a number of years.   Opher’s appreciation for the years of work is to just off-handly dismiss my comments.

Then in On faithfull representation and other comments and On Top Down and Bottom Up Opher does the same thing, he simply dismisses my comments, defensively, adding humor, sarcasm and fallacy.

I am sorry Opher is so defensive of his narrow society; however I will not yield, because I do not need to resort to sarcasm, fallacy and ad hominums; the facts obviously support my view.  For proof that Opher has a narrow view of event processing, go no further than look at the companies he hand-picked for his EPTS Steering Committee; most startups (or with startup products) in the event processing space, working on common messages to distinguish themselves in a market with much more mature players excluded - classic “not invented here,” isn’t it?

Opher’s claims the EPTS view on event processing is quite general, but the  majority of vendors on the EPTS Steering Committee members are selling similar platforms, a very narrow segment of the CEP/EP space.    Opher claims that he agrees that other domains (like sensor fusion) are significant to CEP/EP, but he simply dismisses my advice to create a true, general EPTS, inclusive of the prior-art and science of CEP/EP (before the marketing folks took over).  He insists on having the EPTS “reinvent the wheel” and develop their own vocabulary, as if event processing did not exist prior to one book on CEP.

Opher’s fun-to-read blog counterpoints to my concerns are evolving to a mixture of ad hominums and sarcasm, sometime wrapped in a defensive tone.   I think we can do better and we must be more inclusive of the other prior-art.  I say we, because I am also a founding member of the EPTS, althought I suspect Opher will banish my name from the membership for trying to diminish the “not invented here” attitude that seems to dominate the EPTS since inception.

The truth of the matter is that the EPTS has a relatively narrow view of event processing, evident by the makeup of the steering committee and the focus of their discussions.    It is not a technical society about event processing, per se; it is a marketing society with a narrowly focused membership that discounts most of the prior-art in the event processing space, it is really, an Event Processing Marketing Society (EPMS) for a narrow group of niche players.

The event processing domain is much, much larger.   The art-and-science of event processing is deep and mature, much more mature (and inclusive) than what we see in the EPTS. 

I think Opher (and the EPTS committee) should take these comments seriously and not discount them with sarcasm and subtle ad hominum replies.

Dan Munz, project manager of the Collaboration Project commented on the unique work that the National Academy of Public Administration (NAPA) is doing to bring together government leaders. The Collaboration Project seeks to innovate across government not just down the silos and create a safe place for leaders to have discussions around innovation.

ScienceLogic: What is the National Academy of Public Administration?

Dan Munz: The Academy is an independent, non-partisan, non-profit organization dedicated to tackling government’s most complex challenges. We were founded in 1967 by James Webb, the NASA administrator who took us to the moon – he saw that he could consult the National Academy of Sciences for expert technical advice, but had no counterpart in government for expert management advice. That’s been our mission ever since.

ScienceLogic: What is the Collaboration Project? How long has it been around?

Dan Munz: The Collaboration Project is the Academy’s response to two parallel trends we see in government. The first is the government’s need to transform the way it does business. There is a strong demand for change out there driven by a number of challenges that are forcing the government to rethink its mission and structure. Challenges include a public disconnected from government; a multi-sector workforce and increasing reliance on contractors; financial instability; and new types of security threats, just to name a few. More and more, the challenges facing government reach across the traditional boundaries of agency and mission. But government isn’t configured to work that way.

The second trend is the unprecedented opportunity collaborative technology offers to drive transformational change in government. Tools like blogs, wikis, and mashups are changing the way leaders think about problems. They’re focusing not on what they can do just within their offices or agencies, but what voices they need to pull together across government, non-profits, the general citizenry, and other stakeholders to solve these problems. The Collaboration Project’s goal is to encourage this type of thinking and empower leaders committed to use collaborative technology to:

• strengthen citizen civic engagement;
• enhance government transparency;
• improve service delivery and operational efficiency; and
• facilitate coordination and innovation within and between agencies.

ScienceLogic: Why focus on Web 2.0 in the government?

Dan Munz: The question of how web 2.0 will impact federal IT departments is a critical one. Our view is that “the era of big systems” is basically over. Things like disk space, bandwidth, and computing power are basically shifting from being assets to being commodities.

There’s also a shift in expectations. People both inside and outside government – especially Gen-X and Gen-Y – are incredibly frustrated by being able to use lightning-fast apps like Flickr, YouTube, and Facebook that don’t even live on their hard drives while the government and other large organizations still operate clunky PCs, space-limited e-mail accounts, and sluggish e-mail servers.

So aside from the opportunity for transformative leadership, the idea of web 2.0 at a government level is very appealing in terms of getting the most out of the IT infrastructure we already have, rather than embarking on costly, large-scale projects in an era of diminishing budgets.

ScienceLogic: How do you build a sense of community at the Collaboration Project?

Dan Munz: Some community feel emerges naturally, from a sense that mass collaboration really is a tool for “doing government” in a whole new way.

The more formal community building mechanisms we have include our web page, where we share insights, news, case studies, and other content – The virtual space serves as an anchor for people, whether they’re experts or beginners, to learn about what we do.

Finally, we are conducting an ongoing series of in-person meetings, usually featuring a leader who has harnessed collaborative technology in what we think is a truly revolutionary new way.

ScienceLogic: How do you hear about cool new government Web 2.0 projects?

Dan Munz: That’s a key question, because part of our mission is to inspire action by finding leaders who have succeeded and highlight their accomplishments. We’ve done that with folks like Kip Hawley, TSA, Molly O’Neill, EPA, and Jim Walker, Alabama DHS.

We also feel that the Academy’s position as a “safe space” for leaders means that we’re a place people can turn to when they hear about an emerging trend or project and want some help making sense of it.

ScienceLogic: What are the most innovative uses of Web 2.0 technology you’ve seen in the government?

Dan Munz: It’s important to distinguish between agencies that are simply adjusting to the reality of web 2.0, and those that are “using” it. Getting a YouTube account for your agency, or putting some photos on Flickr, is a great first step, but we want to inspire leaders to really transform their normal ways of doing business. At the moment a few that come to mind are the EPA Puget Sound Mashup, ODNI’s Intellipedia, TSA IdeaFactory, the PTO Peer-to-Patent Project, and Virtual Alabama, to name a few.

The TSA launched the IdeaFactory in February 2008. TSA set up a collaboration platform with commenting, voting, etc. to form communities in a way to bring people to consensus and offer ways to improve the agency’s performance.

ScienceLogic: Do you see a difference between state and local versus federal adoption of Web 2.0?

Dan Munz: That’s a hard generalization to make – at all levels you see leaders who recognize the potential in this technology to bring new voices into the governance process.

ScienceLogic: What are the obstacles to Web 2.0 adoption by government agencies?

Dan Munz: The three main challenges that we see are in the areas of technology, culture, and policy/governance.

The technology issue is probably the simplest to solve – it’s important to choose a technology that fits the problem you’re trying to solve, but these technologies are usually inexpensive and almost never very complex.

The question of culture is harder, particularly given the way that baby boomers, gen-xers, and millenials are beginning to interact in the workforce. How do you gain acceptance and buy-in among groups that have very different comfort levels with collaborative tools and environments?

Finally, the most daunting challenge might be the questions of policy and governance, if only because those are the things that most commonly prevent leaders from even dipping a toe in the waters of collaboration. Most of the policies, regulations, and statutes governing the way government does business don’t anticipate things like wikis, blogs, or instant messaging. One of our most important missions is helping leaders who just want to get to action navigate these obstacles.

ScienceLogic: Is there any advice you can give to government employees getting started with Web 2.0? Or any places you would point them to for more info?

Dan Munz: It’s shameless plug time! I’d of course point them to our web page, collaborationproject.org, where, among other things, we’ve collected a case library of over 40 instances of collaborative technology being used in the government and non-profit sectors. The library is growing every day and is a sort of “database of record” for what is and isn’t working in terms of collaborative government. I think that would be a great place to start for anyone looking to get started but not really knowing the way.

In terms of advice, the best thing to say is that, once you’ve settled on a problem you want to solve and an audience you want to reach out to, just do it! We believe strongly that there are a lot of organizational and leadership issues that still need to be addressed regarding collaboration in government, but our biggest mantra is about getting leaders to action. The most successful projects we’ve seen are ones that try something daring and new, and discover the true power of what they’ve done as it catches on more and more widely.

ShareThis

Kapil Singh and Wenke Lee. On the Design of a Web Browser: Lessons learned from Operating Systems

Mike Ter Louw, Prithvi Bisht and V.N. Venkatakrishnan. Analysis of Hypertext Markup Isolation Techniques for XSS Prevention

Adrienne Felt and David Evans. Privacy Protection for Social Networking Platform

Monica Chew, Dirk Balfanz, and Ben Laurie. (Under)mining Privacy in Social Networks

D. K. Smetters. Building Secure Mashups

Tyler Close. Web-key: Mashing with Permission

Tyler's talk may have been the most entertaining of the day, if only because of his obvious frustration with what the web has become. Tyler's main claim was that we ought to be using capability URLs to handle our authentication and authorization concerns. URLs that encode both authentication and authorization data bring us back to the original intent of the web, where the link is everything.

It was nice to see someone railing against a bit of what the web has become, but it almost felt like an original internet user lamenting the end of the end-to-end internet. A decent architectural argument, and yet one that isn't likely to yield a lot of converts. I don't think I understood a few of Tyler's points about how to prevent these URLs from leaking out and/or how to revoke access should they happen to. There are a multitude of user acceptance, behavior, and expectation questions to be answered. It was a nice twist though on how to perhaps make access-controlled content more in keeping with the spirit of the web.

Mihai Christodorescu. Private Use of Untrusted Web Servers via Opportunistic Encryption

Mihai's presentation was about how to take advantage of networked services/web-applications while proividing them with only opaque data references created with cryptography. His main example was about how to use Google's Calendar product without ever sending them your real data, and sending them only client-side encrypted data instead.

While it seems like a nice idea, and while parts of his solution were technically elegant, I think again it was a solution looking for a problem. If you're so concerned about a networked service having your data that you're willing to reverse engineer the service to make it store your individual data elements encrypted, then perhaps a networked service isn't the one for you. TYhe architectural challenges in achieving what he was able to with Google's calendar are nearly impossible with a more complicated service. And, in order to make it work you have to give up many of the feature's you'd really like from a service - full text searching, etc.

I'm guessing there are a few places where's Mihai's ideas are feasible, but its hard for me to see the value prop in building what he proposed.

Some Final Thoughts:

• We haven't come close to solving the security problems in a Web-1.0 world
• We don't know what the security policies really ought to look like for the web, consequently we don't know what the architecture and implementation look like either.
• Browsers are lacking fundamental architecture and policy around security.
• Web-2.0 only makes things worse

The SQL [structured query language] inserts that came earlier were just pablum intended to lull the Army cadets into a false sense of security. But then the bad guys unleashed a stealthy kernel-level rootkit that burrowed into one workstation, started scraping data and "calling home."

It was a highly sophisticated attack, but this time the bad guys were really good guys in wolves' clothing.

For four days in late April, the National Security Agency -- the nation's most secretive repository of spooks, snoops and electronic eavesdroppers -- directed coordinated assaults on custom-built networks at seven of the nation's military academies, including West Point, the Army university 50 miles north of New York City.

It was all part of the seventh annual Cyber Defense Exercise, a training event for future military IT specialists. The exercise offered a rare window into the NSA's toolkit for infiltrating, corrupting or destroying computer networks.

The 34 Army cadets comprising the West Point IT team operated in a different kind of battlefield, but their combat skills and instincts need to be every bit as sharp. Like George Washington said: "There is nothing so likely to produce peace as to be well prepared to meet the enemy."

The SQL injections, targeting their Fedora Core 8 Web server, were a piece of cake for these IT combatants. Each injection tried to smuggle malicious code inside the seemingly harmless language used by the network’s MySQL software. The cadets handily defended with open source Apache web server modules, plus some manual tweaking of the SQL database to "avoid any surprises," in the words of Lt Col. Joe Adams, a West Point instructor who helped coach the team.

But the kernel-level rootkit was much more dangerous. This stealthy operating-system hijacker can open unseen "back doors" into even highly protected networks. When they detected the rootkit's "calls home" the cadets launched Sysinternal's security software to find the hijacker, then they manually scoured the workstation to find the unwelcome executable file.

Then they terminated it. With extreme prejudice.

"This was probably the most challenging part of the exercise, since it required them to use some advanced techniques to find the rootkit," Adams says. And rooting it out helped boost the West Point team to the top of the pile when, in the aftermath of the exercise, the referees rated all the universities' network defenses.

For the second year in a row, the Army placed first over the Navy, Air Force, Coast Guard and others, winning geek bragging rights and the privilege of holding onto a gaudy, 60-pound brass trophy festooned with bald eagles and American flags. Adams credits the team’s thorough preparation and their excellent teamwork despite the round-the-clock schedule.

At the network control room on the second floor of West Point’s 200-year-old engineering building (which once was an indoor horse corral and still smells like it in some remote corners, according to one instructor), the IT team set up cots and, just for the hell of it, camouflaged netting. They worked in shifts, with one team member always monitoring incoming and outgoing traffic. He or she would alert other cadets -- "router guys" -- to block any suspicious addresses. Meanwhile, off-shift cadets would make food and coffee runs to keep everyone fueled up and alert. Together, the team was "faster than anyone else," Adams says.

But the way the cadets designed their network was a big factor in their victory, too. The NSA dictated some terms: All networks had to be capable of e-mail, chat and other services and had to be up and running at all times despite any attacks or defensive measures. Beyond that, the teams were free to come up with their own designs.

West Point's took three weeks to build. The cadets settled on a fairly standard Linux and FreeBSD-based network with advanced routing techniques for steering incoming traffic in directions of the IT team's choosing.

The choices in software tools for responding to any attack really boiled down to "automatic" versus "custom," says Eric Dean, a civilian programmer and instructor. He adds that while automatic tools that do most of their own work are certainly easier, custom tools that allow more manual tweaking are more effective. "I expect one of the 'lessons learned' will be the use of custom tools instead of automatics."

Even with a solid network design and passable software choices, there was an element of intuitiveness required to defend against the NSA, especially once it became clear the agency was using minor, and perhaps somewhat obvious, attacks to screen for sneakier, more serious ones.

"One of the challenges was when they see a scan, deciding if this is it, or if it’s a cover," says Dean. Spotting "cover" attacks meant thinking like the NSA -- something Dean says the cadets did quite well. "I was surprised at their creativity."

Legal limitations were a surprising obstacle to a realistic exercise. Ideally, the teams would be allowed to attack other schools' networks while also defending their own. But only the NSA, with its arsenal of waivers, loopholes, special authorizations (and heaven knows what else) is allowed to take down a U.S. network.

And despite the relative sophistication of the NSA's assaults, the agency told Wired.com that it had tailored its attacks to be just "a little too hard for the strongest undergraduate team to deal with, so that we could distinguish the strongest teams from the weaker ones."

In other words, grasshopper, nice work -- but the NSA is capable of much craftier network take-downs.

My choice of words seems to raise a few eyebrows with my audience. You, like several others, may ask- “That seems like an ‘untechnical’ term, shouldn’t you say it ‘disables’ the port?” 

Well, no, we shouldn’t say that. When we talk about ‘enable’ and ‘disable’ for ports, that’s actually a port property designation within the switch. When we disable a port in the switch, we’re turning it off and preventing it from passing any traffic.

When we have an 802.1X-enabled port that’s unauthenticated, it still has to pass SOME traffic types, such as EAP (and possibly discovery protocols, such as Cisco’s CDP). Otherwise, we’d never be able to authenticate, right?

So, I, like many others in the NAC world, usually refer to an unauthenticated 1X port as being ‘shut off’ or ‘closed’ just as a means to distinguish it from ‘disabled’ which does have its own meaning.

# # #