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.

Blogger: Dan Blum

With the crisis in financial markets still unfolding, it is important to draw what lessons we can from the experience. Since the roots of the crisis lie in a monumental failure of risk management, it’s important to understand more about what happened, and then draw some parallels to our business risk management and  IT risk management situations.

The risk management failure in the housing market and on Wall Street had multiple interdependent dimensions:

• Mortgage lenders abandoned long standing prudent loan practices. They made too many loans that buyers might not be able to repay. Exotic instruments like ARMs, option ARMs, and interest only loans proliferated. In many cases, all pretense of lending standards were abandoned, so-called “liar loans” approved.
• Capital was grossly over-leveraged. Mortgage lenders and other financial services packaged loans into securities, which they sold to raise capital to support more lending. Real capital reserve requirements to back loans were reduced. Of course, if borrowers could not repay loans, all or parts of the derivative securities would become worthless.
• Risk was aggregated at Fannie Mae, Freddie Mac, and mortgage loan insurance companies. These companies bought or insured some mortgage loans, providing something of a backstop should loans fail. Government sponsored enterprises (GSEs) Fannie and Freddie in turn became over-leveraged and securities that they sold were in turn repackaged in the murky brew of mortgage-backed securities called collateralized debt obligations (CDOs) and other exotic instruments returning generous yields.
• Non-Caveat Emptor. Institutional wealth funds and financial services firms who should have known better bought securities that had been deliberately structured to obfuscate risk. They bought securities they didn’t understand with buried tranches of toxic subprime loans..

It was a great Ponzi scheme – one that kept working as long as housing prices were going up; the recipients of subprime loans could always flip that house to the next buyer. Everyone made money. As Chuck Prince of Citigroup famously put it during a July, 2007 interview: “So long as the music is playing, you’ve got to keep dancing. We’re still dancing.” But one month later, the music stopped. Since then, Citigroup and other financial institutions have taken massive writeoffs with more to come. Wall Street titans like Bear Sterns, Lehman Brothers, Merrill Lynch, and AIG have fallen or been bought out.

What can we learn from this risk management debacle?

As business risk managers and investors, we should ask questions like these:

• Does the executive incentive structure of the company encourage managers to dance around risk? Many Wall Street firms paid senior managers 5 times their salary in bonuses tied to annual growth alone.
• Is the company over-leveraged? Is it borrowing too much money and betting it on ventures with uncertain outcomes?
• Are financial models used for risk management realistic? Earlier, I described the mortgage market of the past few years as a Ponzi scheme, where risk management models must have assumed prices would keep rising. Unlike the dotcom boom whose demise many predicted, very few in the industry foresaw the sharp declines to come in housing prices and sales volumes. Historically, the U.S. housing market has been a steadily rising one, but on the other hand the 2000s saw unprecedented rates of price increases. In reality, what goes up must come down.
• Has your company’s risk council ever performed worst case scenario analysis and built adequate reserves? In the days before economics emerged as a would-be “hard” deterministic science, business leaders may have been more cautious, more aware of and more accepting of uncertainty. Events like the Great Tulip Bubble came once in decades or centuries – not every few years. Note that legendary investor George Soros has proposed a Theory of Reflexivity that, if true, helps explain the recent extremes of boom and bust cycles. This theory holds that market participants model market behaviors based on self-interest, and for a time, their manipulations change the reality of the market – until gravitational forces bring it back to earth. Has the music of ephemeral success played to the backbeat of deterministic-sounding economic models gone to your heads and infected your risk management models?
• Are cost cutting efforts pursued blindly? Outsourcing and other forays into treacherous global waters may be giving away the crown jewels. Smart companies cut costs, but they do it in smart ways. Smart companies think like intelligence agencies as they parcel out work to different partners with varying levels of dependability, and they check on those partners.

Risk management failures can also occur at the more technical level of IT security. As IT risk managers, we might ask questions like these:

• Are the accounting and financial systems your IT department supports under adequate control? As Fred Cohen wrote in one of our documents: “Many companies use computers to manage financial systems, and despite the Sarbanes-Oxley Act (SOX) claims about accounts being properly kept, there are many attacks on financial systems that remain. For example, most of the largest financial systems in the world running on common financial databases do not use double-entry bookkeeping and are thus susceptible to all manner of frauds by insiders.” We find it troubling that a prudent control dating back to the 12th century is going out of style in the name of convenience and cost cutting. Kind of like credit checking became anachronistic during the housing bubble, eh?
• Is the “separation” in your “separation of duty” (SoD) for real? Sure the SOX auditors are looking for SoD, and maybe you have different administrators with different accounts maintaining different systems or functions. But when they say Western civilization may be but one weak password from collapse they’re not lying. Look what happened to Sarah Palin’s email account! Weak and straggly SoD is a problem across all critical IT systems where deperimiterization and server consolidation may be bringing down protective barriers, identity management is weak, and strong process controls (e.g., where two people must sign on, one perform a critical operation such as backbone router reconfiguration, and the second observe) abandoned in the name of expediency.
• Are risks being aggregated to unacceptable levels in centralized control systems? There are many ways that risks aggregate within enterprise IT infrastructures as we pursue automation and cost cutting. Network risks aggregate when centralized domain name system control is implemented. Application risks aggregate when common infrastructure is shared among applications. And enterprises aggregate platform risks when they use low-assurance endpoints, authentication, and directory systems with single sign-on to access large numbers of resources and don’t separate high consequence systems.
• Non-caveat emptor: Has IT security really done the worst case consequence analysis, attack graphs, and vulnerability analysis to know when putting more eggs in a supposedly stronger basket aggregates risks to an unacceptable level? Or are you depending only on vendor claims about some black box appliance equivalent of a risk-obfuscated CDO security? Caveat emptor (buyer beware) again! (The good news is we’ll keep talking about promoting vendor and product rating systems so you don’t have to do all the detailed product analysis yourself, but that’s another post.)

There are many parallels between the monumental risk management failure in the financial markets, and the probable weaknesses in our day to day business risk management and IT risk management. Abandonment of prudent practices for profit; excessive leverage and centralization; ill-constructed risk analysis models; risk obfuscation; and a failure of caveat emptor seem to be common problems. Please take this as a wakeup call to sharpen up the risk management thinking, process, and execution.

At the moment, event correlation and event analysis is Gartner’s closest magic quadrant (MQ)  that relates directly to complex event processing (and event processing in general).    

A number of our friends and colleagues would like to position CEP as BRE, BRMS, BPM, SOA, algo trading and just about every other technology under the sun, except event correlation!

In a nutshell, the state-of-the-state of CEP/EP is that a number of firms in the software industry have found some “uncharted magic quadrant waters” and are positioning themselves to be “chart worthy”. Instead of competing head on with the experienced players (event correlation and analysis) that have been in the event processing field for many years.   

As I have mentioned a few times here on The CEP Blog, if the current generation self-described CEP engines were leading the industry in event correlation and analysis (CEP’s core technology domain) they would be either be on Gartner’s Magic Quadrant for IT Event Correlation and Analysis, or possibly acquired by a one of these large giants in event processing to solve complex event processing and event correlation problems that remain, for the most part, still unsolved!

When I discussed this openly with Waters in Muddy Waters comments they kindly replied that “customers are loath to be a reference client for a vendor,”  like this fact somehow justifies having 600 people, most who have never actually used the software in practice, vote on how great it is.  

Follow the Yellow Brick Road.

Or, as Mark Adler pointed out in his well written blog post The First Annual Fluffies for CEP , a secretive “panel of renowned judge” is going to tell us, via Jolt, who has the better solution?  Holy Cow Batman!   Let me buy a nice layout in your magazine  or web site,  please, so “my software company” will be on the short list for the “the awards”.  

Follow the Yellow Brick Road.

All this smoke-and-mirrors. share-the-love, marketing reminds me of The Matrix a bit, where the world as we observe it, is a complete artificial construction, where most people in the Matrix believe they are “real” because they do not know that they really just a computer generated program designed to keep humans happy as they sleep in some cold goop with electrodes stuck up their you-know-what, really just bio-batteries insuring the light bill is paid.

Follow the Yellow Brick Road.

Or better yet, these fluffies are similar to most of the Webinars we see where there are questions from “the audience” but we know that most of these questions did not come from the “audience” - yet we all seem to continue ”the  audience” myth just like Santa Claus and the Easter Bunny! 

Follow the Yellow Brick Road.

The Easter Bunny, Santa Claus, the Tooth Fairy and the Fluffy Awards are real, if you want them to be real.  Just close your eyes and click your heels three times….

Follow the Yellow Brick Road. Follow the Yellow Brick Road.
Follow, follow, follow, follow,
Follow the Yellow Brick Road.
Follow the Yellow Brick, Follow the Yellow Brick,
Follow the Yellow Brick Road.

We’re off to see the Wizard, The Wonderful Wizard of Oz.
You’ll find he is a whiz of a Wiz! If ever a Wiz! there was.
If ever oh ever a Wiz! there was The Wizard of Oz is one because,
Because, because, because, because, because.
Because of the wonderful things he does.
We’re off to see the Wizard. The Wonderful Wizard of Oz

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

The two CEP/ESP related Water’s categories were, Best Streaming Data Management Solution and Best Complex Event Processing Solution.    Water’s awards Best Streaming Data Management Solution to data/event stream processing company StreamBase; and then awards Best Complex Event Processing Solution to Oracle’s BEA product, which is built on top of another data/event stream processing engine.  Confused?   

Alexander Alves,  currently employed by Oracle, previously having worked for BEA Systems, in Best Complex Event Processing Solution, observes:

“Regardless, I find it intriguing that Waters not only does not state the differences between the categories, but also uses the term CEP several times in the SDMS category.

I guess the verdict is that there is still confusion amongst the experts regarding event and stream processing… And that both products must be very good.”

Of course, Alex must be politically correct, and rightly so, since he works for Oracle/BEA and Water’s gave them an award.  But on what tangible, objective basis for Best Complex Event Processing Solution?

According to our 2007 survey, CEP/EP Reference Customers 2005-2007, BEA was in last place based on public CEP/EP reference clients.  

Waters’ award  for Best Streaming Data Management Solution to StreamBase is a much more credible.   Congratulations StreamBase.   Most would agree that StreamBase is a streaming data management solution (SDMS), but so are Apama and Coral8 (and BEA etc etc).   

Waters simply muddies the water, unfortunately.  

Last week in response to Richard Stiennon's glowing write up, I questioned what it is exactly that Rohati does. Well someone from Rohati must have seen it and I was contacted by the Rohati team and offered a peek and a deep explanation of exactly what Rohati does.  So today I had a chance to speak with Shane Buckley, CEO, Prashant Ghandi VP of product management and strategy and Steven Wastie, VP of marketing.  I was impressed that such a triumvirate of power players from the Rohati team took the time to speak to me.  But I guess after I wrote what I did, it was followed up by JJ writing her article on it and than Rothman piling on with his own two cents. 

Give the Rohati team credit for recognizing the power of blogs to influence the influencer and reaching out to stem the tide.  It just goes to show you how far blogging has come. But enough about the power of blogs, lets talk about Rohati.

The best way for me to describe Rohati is that it is layer 7 ACLs to control access to applications.  Where we already have security at the perimeter and at the edge, Rohati is about controlling access at the server/application.  The diagram on the left (click on it to get a bigger version), is a good illustration of how Rohati works. By integrating with LDAPs Rohati can assign you an access policy to any application.  Based upon that Rohati gives a very fine grain level of access control at the application layer.  It acts as a proxy to the app server for both regular and encrypted traffic.  Because the ACLs are on the Rohati box itself, there really is not any integration with switches per say and so no integration worries.

The only problem is that the Rohati box has to be able to handle the traffic flow.  Hence the box is a big honker.  The cheap one is about 20k list I believe and the industrial size version is 80k. This product is aimed squarely at the data center space and is sold through channels.

Will Rohati succeed.  Yes, I think it will.  I think they have taken a unique approach to a security issue that will continue to grow in years to come.  Application access is an area that I think is still up and coming.  In a period of nothing is ever new in security, the Rohati team seems to have found something that has not been done before in a packaged dedicated way like this.  If nothing else, with all of the ex-Cisco folks there, Cisco will eat its young and buy the technology back in.

We will watch Rohati's progress in the months to come.  At the very least, it seems they are blog savvy enough to navigate the waters of social media.  Maybe they will start their own blog soon.

Last week in response to Richard Stiennon's glowing write up, I questioned what it is exactly that Rohati does. Well someone from Rohati must have seen it and I was contacted by the Rohati team and offered a peek and a deep explanation of exactly what Rohati does.  So today I had a chance to speak with Shane Buckley, CEO, Prashant Ghandi VP of product management and strategy and Steven Wastie, VP of marketing.  I was impressed that such a triumvirate of power players from the Rohati team took the time to speak to me.  But I guess after I wrote what I did, it was followed up by JJ writing her article on it and than Rothman piling on with his own two cents. 

Give the Rohati team credit for recognizing the power of blogs to influence the influencer and reaching out to stem the tide.  It just goes to show you how far blogging has come. But enough about the power of blogs, lets talk about Rohati.

The best way for me to describe Rohati is that it is layer 7 ACLs to control access to applications.  Where we already have security at the perimeter and at the edge, Rohati is about controlling access at the server/application.  The diagram on the left (click on it to get a bigger version), is a good illustration of how Rohati works. By integrating with LDAPs Rohati can assign you an access policy to any application.  Based upon that Rohati gives a very fine grain level of access control at the application layer.  It acts as a proxy to the app server for both regular and encrypted traffic.  Because the ACLs are on the Rohati box itself, there really is not any integration with switches per say and so no integration worries.

The only problem is that the Rohati box has to be able to handle the traffic flow.  Hence the box is a big honker.  The cheap one is about 20k list I believe and the industrial size version is 80k. This product is aimed squarely at the data center space and is sold through channels.

Will Rohati succeed.  Yes, I think it will.  I think they have taken a unique approach to a security issue that will continue to grow in years to come.  Application access is an area that I think is still up and coming.  In a period of nothing is ever new in security, the Rohati team seems to have found something that has not been done before in a packaged dedicated way like this.  If nothing else, with all of the ex-Cisco folks there, if nothing else Cisco will eat its young and buy the technology back in.

We will watch Rohati's progress in the months to come.  At the very least, it seems they are blog savvy enough to navigate the waters of social media.  Maybe they will start their own blog soon.

1. people need to actually review the code


2. developers/reviewers need to know how to write secure code
   


3. once found, security problems need to be fixed quickly, and their fixes distributed quickly

1. people need to actually review the code


2. developers/reviewers need to know how to write secure code
   


3. once found, security problems need to be fixed quickly, and their fixes distributed quickly