Richard Stallman - the man that gave us GNU - doesn’t trust Cloud providers with his data and says you shouldn’t either.  Richard believes we should store our private data on our own computers using ‘free’ (as in freedom) software.  The ironic part for Richard is that a significant portion of the Cloud is powered by open source software which he indirectly created (think gcc).

Richard sees it as a question of control.  Control is important but it isn’t the only variable.  Rather, I see it as a question of control, competence and economics.

The quick rebuttal to Richards’ view is this: the average computer user is not as smart as you.  Control is not the same as competence.  Control is about exercising choice, not about requiring everyone in the world to develop sufficient skills to protect complex hardware and software systems (aka their computer) against ever increasing threats.

My view is that privacy is not ‘free’.  It comes at a cost.  Whether you run your own systems or rely on someone else to do it, there is a cost.  There is cost in designing and implementing mechanisms to support privacy.  Beyond upfront costs there are ongoing expenditures to ensure privacy is maintained e.g. maintaining access control lists, testing and applying security patches, data leakage prevention etc.  None of these things are ‘free’.

If we agree that privacy costs money then how much is your privacy worth?

Stop for a second - think of a number…  

Now did we all think of the same number?

The problem with a one size fits all approach to privacy is that we each place a different value on it.

Checking in on the EPIC site, I saw this:  

A new report from Pew Internet and American Life Project indicates that “cloud computing” applications, such as web-based email and other web apps, are raising new privacy concerns. The report Use of Cloud Computing: Applications and Services found that 69% of online Americans use webmail services, store data online, or use software programs such as word processing applications whose functionality is located on the web. At the same time, “users report high levels of concern when presented with scenarios in which companies may put their data to uses of which they may not be aware.” For example, 90% of respondents said that they “would be very concerned if the company at which their data were stored sold it to another party,” 80% say “they would be very concerned if companies used their photos or other data in marketing campaigns,” and 68% of “users of at least one of the six cloud applications say they would be very concerned if companies who provided these services analyzed their information and then displayed ads to them based on their actions.”

What does that tell us?

The average (American) Internet user finds Cloud services convenient but has concerns about how their privacy might be affected by Cloud providers actions (duh!).  The survey identifies a lack of awareness in how private data is used in some consumer based Cloud services (consistent with web advertising awareness surveys).  

Unfortunately, the results of this survey are not very actionable.  The survey doesn’t mention whether these are all ‘free’ Cloud services (we can only assume they are) or ask the respondents what their expectations of privacy are and how much they would be willing to pay for different privacy assurance levels. 

On a sidenote, respondents were not asked if they had actually read the privacy agreement for the services they signed up to.  But the providers know if they did or not…  Or at least, they have the data to figure it out.  At sign up time they can measure the time between displaying the privacy agreement and the user clicking ‘I accept’.  If its just a few seconds then its pretty obvious there was more scrolling than reading going on.  But I think we can probably guess the answer without the data ;-).

I believe we need to be able to link expectation of privacy with cost.

• How much are you willing to pay for privacy?  What level of privacy assurance do you need?
• How much is your Cloud Provider paying to protect your privacy today?  What privacy services could they reasonably offer if they had customers willing to pay?  How might this compare with how you manage your private data on your home computer today?

The cynical view is that we expect privacy but don’t want to pay for it.  Its a bit like uptime - there is a parallel universe out there, where internal IT departments allegedly meet their 99.999% uptime SLAs, but when Gmail goes down, the Sergey Brin witchcraft dolls come out.

From a provider perspective, the “cost” of privacy invariably gets bundled under that line item called ‘Information Security’.  And don’t be fooled, the cost of privacy in reality is more than the salary of the person employed to be the privacy advocate (if there is one).  If we can’t see how much our providers are spending on our privacy then how can we judge if they are spending enough?  And what is enough?  And what can I get if I’m willing to pay a little extra?

Personally, I would rather we get some transparency around privacy costs and assessment of offerings.  However, without a sufficiently sized market of customers willing to pay for privacy assurance and Cloud Providers willing to be more open, I won’t hold my breath.

What about you?  Would you be prepared to pay for privacy?  Should providers be more transparent about what they do and don’t do and how they do it?
 
 

The Cisco 7600 OSR consists of a 256 Gbps switching fabric and a 30 million packets per second (mpps) forwarding engine. Its breadth of IP services comes from Cisco IOS, which provides features such as security, enhanced QoS, and destination sensitive services. In addition, the Cisco 7600 OSR allows the migration of existing port adapters from Cisco 7500 series routers, via the Cisco FlexWAN module, giving service providers one the industry’s widest array of interface options in any single platform. This provides service providers great flexibility in deploying the Cisco 7600 OSR for a variety of applications, protects their investment in existing systems, and gives them a practical migration path to the New World Optical Internet.

A Revolutionary Platform For Evolving Networks

The Cisco 7600 OSR helps service providers break through service and bandwidth barriers today, while designing networks to scale for future growth. The Cisco 7600 OSR achieves this through “adaptive network processing,” or the ability to evolve the platform for new IP services without hardware upgrades. Unlike fixed, ASIC-based platforms, which are hardware encoded, the Cisco 7600 OSR relies on the highly flexible Parallel eXpress Forwarding (PXF) technology for scalable performance of services. PXF is a patented, Cisco-developed network processor capable of line-rate IP services delivery that can support new IP services through periodic software upgrades. Each OSM has two PXF processors capable of 12 mpps of IP services delivery per interface card.

“IP+Optical combines the dynamism of the Internet world with the foundation of the transport world, creating an infrastructure that can deliver the services that service providers need,” said Lele Nardin, vice president of the Internet Systems Business Unit at Cisco. “Cisco will continue to add innovative solutions on top of this solid foundation to make service providers better equipped to meet the constantly escalating and changing customer demands for new networking services.”

Pricing and Availability

The base Cisco 7600 OSR system is list priced at $73,000 and the entry level system, with interfaces, start at $100,000. The interfaces modules are priced between $27,000 to $180,000. The Cisco 7600 OSR is available now worldwide.

The "Oyster card" used on the London Tube was at issue in the Dutch case, and a similar fare card used on the Boston "T" was the center of the U.S. case. The Dutch court got it right, and the American court, in Boston, got it wrong from the start -- despite facing an open-and-shut case of First Amendment prior restraint.

The U.S. court has since seen the error of its ways -- but the damage is done. The MIT security researchers who were prepared to discuss their Boston findings at the DefCon security conference were prevented from giving their talk.

The ethics of full disclosure are intimately familiar to those of us in the computer-security field. Before full disclosure became the norm, researchers would quietly disclose vulnerabilities to the vendors -- who would routinely ignore them. Sometimes vendors would even threaten researchers with legal action if they disclosed the vulnerabilities.

Later on, researchers started disclosing the existence of a vulnerability but not the details. Vendors responded by denying the security holes' existence, or calling them just theoretical. It wasn't until full disclosure became the norm that vendors began consistently fixing vulnerabilities quickly. Now that vendors routinely patch vulnerabilities, researchers generally give them advance notice to allow them to patch their systems before the vulnerability is published. But even with this "responsible disclosure" protocol, it's the threat of disclosure that motivates them to patch their systems. Full disclosure is the mechanism (.pdf) by which computer security improves.

Outside of computer security, secrecy is much more the norm. Some security communities, like locksmiths, behave much like medieval guilds, divulging the secrets of their profession only to those within it. These communities hate open research, and have responded with surprising vitriol to researchers who have found serious vulnerabilities in bicycle locks, combination safes (.pdf), master-key systems and many other security devices.

Researchers have received a similar reaction from other communities more used to secrecy than openness. Researchers -- sometimes young students -- who discovered and published flaws in copyright-protection schemes, voting-machine security and now wireless access cards have all suffered recriminations and sometimes lawsuits for not keeping the vulnerabilities secret. When Christopher Soghoian created a website allowing people to print fake airline boarding passes, he got several unpleasant visits from the FBI.

This preference for secrecy comes from confusing a vulnerability with information about that vulnerability. Using secrecy as a security measure is fundamentally fragile. It assumes that the bad guys don't do their own security research. It assumes that no one else will find the same vulnerability. It assumes that information won't leak out even if the research results are suppressed. These assumptions are all incorrect.

The problem isn't the researchers; it's the products themselves. Companies will only design security as good as what their customers know to ask for. Full disclosure helps customers evaluate the security of the products they buy, and educates them in how to ask for better security. The Dutch court got it exactly right when it wrote: "Damage to NXP is not the result of the publication of the article but of the production and sale of a chip that appears to have shortcomings."

In a world of forced secrecy, vendors make inflated claims about their products, vulnerabilities don't get fixed, and customers are no wiser. Security research is stifled, and security technology doesn't improve. The only beneficiaries are the bad guys.

If you'll forgive the analogy, the ethics of full disclosure parallel the ethics of not paying kidnapping ransoms. We all know why we don't pay kidnappers: It encourages more kidnappings. Yet in every kidnapping case, there's someone -- a spouse, a parent, an employer -- with a good reason why, in this one case, we should make an exception.

The reason we want researchers to publish vulnerabilities is because that's how security improves. But in every case there's someone -- the Massachusetts Bay Transit Authority, the locksmiths, an election machine manufacturer -- who argues that, in this one case, we should make an exception.

We shouldn't. The benefits of responsibly publishing attacks greatly outweigh the potential harm. Disclosure encourages companies to build security properly rather than relying on shoddy design and secrecy, and discourages them from promising security based on their ability to threaten researchers. It's how we learn about security, and how we improve future security.

This essay previously appeared on Wired.com.

EDITED TO ADD (8/26): Matt Blaze has a good essay on the topic.

The "Oyster card" used on the London Tube was at issue in the Dutch case, and a similar fare card used on the Boston "T" was the center of the U.S. case. The Dutch court got it right, and the American court, in Boston, got it wrong from the start -- despite facing an open-and-shut case of First Amendment prior restraint.

The U.S. court has since seen the error of its ways -- but the damage is done. The MIT security researchers who were prepared to discuss their Boston findings at the DefCon security conference were prevented from giving their talk.

The ethics of full disclosure are intimately familiar to those of us in the computer-security field. Before full disclosure became the norm, researchers would quietly disclose vulnerabilities to the vendors -- who would routinely ignore them. Sometimes vendors would even threaten researchers with legal action if they disclosed the vulnerabilities.

Later on, researchers started disclosing the existence of a vulnerability but not the details. Vendors responded by denying the security holes' existence, or calling them just theoretical. It wasn't until full disclosure became the norm that vendors began consistently fixing vulnerabilities quickly. Now that vendors routinely patch vulnerabilities, researchers generally give them advance notice to allow them to patch their systems before the vulnerability is published. But even with this "responsible disclosure" protocol, it's the threat of disclosure that motivates them to patch their systems. Full disclosure is the mechanism (.pdf) by which computer security improves.

Outside of computer security, secrecy is much more the norm. Some security communities, like locksmiths, behave much like medieval guilds, divulging the secrets of their profession only to those within it. These communities hate open research, and have responded with surprising vitriol to researchers who have found serious vulnerabilities in bicycle locks, combination safes (.pdf), master-key systems and many other security devices.

Researchers have received a similar reaction from other communities more used to secrecy than openness. Researchers -- sometimes young students -- who discovered and published flaws in copyright-protection schemes, voting-machine security and now wireless access cards have all suffered recriminations and sometimes lawsuits for not keeping the vulnerabilities secret. When Christopher Soghoian created a website allowing people to print fake airline boarding passes, he got several unpleasant visits from the FBI.

This preference for secrecy comes from confusing a vulnerability with information about that vulnerability. Using secrecy as a security measure is fundamentally fragile. It assumes that the bad guys don't do their own security research. It assumes that no one else will find the same vulnerability. It assumes that information won't leak out even if the research results are suppressed. These assumptions are all incorrect.

The problem isn't the researchers; it's the products themselves. Companies will only design security as good as what their customers know to ask for. Full disclosure helps customers evaluate the security of the products they buy, and educates them in how to ask for better security. The Dutch court got it exactly right when it wrote: "Damage to NXP is not the result of the publication of the article but of the production and sale of a chip that appears to have shortcomings."

In a world of forced secrecy, vendors make inflated claims about their products, vulnerabilities don't get fixed, and customers are no wiser. Security research is stifled, and security technology doesn't improve. The only beneficiaries are the bad guys.

If you'll forgive the analogy, the ethics of full disclosure parallel the ethics of not paying kidnapping ransoms. We all know why we don't pay kidnappers: It encourages more kidnappings. Yet in every kidnapping case, there's someone -- a spouse, a parent, an employer -- with a good reason why, in this one case, we should make an exception.

The reason we want researchers to publish vulnerabilities is because that's how security improves. But in every case there's someone -- the Massachusetts Bay Transit Authority, the locksmiths, an election machine manufacturer -- who argues that, in this one case, we should make an exception.

We shouldn't. The benefits of responsibly publishing attacks greatly outweigh the potential harm. Disclosure encourages companies to build security properly rather than relying on shoddy design and secrecy, and discourages them from promising security based on their ability to threaten researchers. It's how we learn about security, and how we improve future security.

---

Bruce Schneier is Chief Security Technology Officer of BT Global Services and author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World. You can read more of his writings on his website.

In fact, it’s not just great artists like Mr. Lucas and I starting up old projects, our honourable colleagues wearing the black hats have got the same idea. We have new victims reporting in, rumours abound of an auth system compromise at Citi, the Ombudsman is backlogged with months of disputed withdrawal cases, and some like Alain Job are even going to court.

One original contributor to the phantom case histories has just been hit by a second phantom withdrawal five years on and is chalking up another case in the files. While her new phantom is a bread-and-butter skim incident (a magstripe clone used in the far east), amongst this mass, true phantoms — the real mystery cases — are on the rise too. Two new victims with whom I have been corresponding very kindly offered to fund the hosting for the revamped site.

Let’s consider one of these mysteries. The McGaughey case has been reported in the media in Northern Ireland: dozens of withdrawals taking place over four weeks, totaling almost five thousand pounds, all within a ten mile radius of the McGaughey’s home. Summarised that way it looks like a classic first party fraud (couple short on cash withdraw money, then deny it later). But no-one in the family is short on cash, the McGaugheys look after their card details carefully, and have solid alibis at the time of many of the withdrawals, and the interlocking pattern of real and disputed withdrawals is such that any third party would have a hard time taking and returning the card (whether covertly or in collusion with the McGaugheys). No-one appears to have either the means or the motive.

Unusually the bank has been very cooperative, providing logs from their authorisation system (BASE24), including all of the cryptograms, input data and transaction parameters covering the affected transactions. Everything turns on the Application Transaction Counter (ATC), an on-card counter which increments with every transaction initiated. If an EMV chip can be fully cloned (secret keys and all), then it will have to submit an ATC value when transacting, and if used in parallel with the real card, it won’t be long before the same number pops up twice in the auth system, or large gaps in the sequence appear. The McGaughey’s ATC sequence appears to interlock perfectly: clearly the original card was used?

Of course logs can be misinterpreted (Badger) or even faked, auth systems may not work as expected, and customers may lie and cheat following all sorts of agendas; just around the corner the missing piece of the jigsaw may lie, which reveals the truth behind the case. And there is the totally separate matter of who should suffer the loss in the interim, whilst the truth remains unclear. Liability for disputed withdrawals is the most hotly contested issue of all.

phantomwithdrawals.com can’t do much more for the McGaugheys, but it can bear witness. Documenting the incidence of phantoms and the experiences of customers disputing them adds much needed transparency to the process, and helps researchers and experts seek out the really interesting cases.

Maybe we can lift the lid and discover the truth behind the “phantom menace” — everyone is united in that goal at least — but let’s also hope that Episode 2: Attack of the Clones has not yet started shooting!

Mike.

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

Complex event processing (CEP) is a new technology. It can be applied to extracting and analyzing information from any kind of distributed message-based system. It is developed from the Rapide concepts of (1) causal event modeling, (2) event patterns and pattern matching, and (3) event pattern maps and constraints. Complex event processing can be applied to a wide variety of Enterprise monitoring and management problems, from low level network management to high level enterprise intelligence gathering.

Applications of Complex Event Processing:

• Instant Insight  - hierarchical event viewing applied to the Enterprise IT layer. (coming soon)
  • Analysing business processes (paper in pdf format)
• Network Level Monitoring and Management (Powerpoint presentation)
• Cyber Security: Network Intrusion Detection
• Enterprise Monitoring and Management (coming soon)
• Modeling and Simulation of Collaborative Business Processes
• Business Policy Monitoring. (coming soon)
• Analysis and Debugging of Distributed Systems (coming soon)

Presentations:

• “Complex Event Processing: An Essential Technology for Instant Insight into the Operation of Enterprise Information Systems,” lecture at the Stanford University Computer Systems Laborary EE380 Colloquium series. Video of the lecture (duration: 60 minutes).

Publications:

• Complex Event Processing in Distributed Systems. David C. Luckham and Brian Frasca, Stanford University Technical Report CSL-TR-98-754, March 1998, 28 pages.Abstract: Complex event processing is a new technology for extracting information from distributed message-based systems. This technology allows users of a system to specify the information that is of interest to them. It can be low level network processing data or high level enterprise management intelligence, depending upon the role and viewpoint of individual users. And it can be changed from moment to moment while the target system is in operation. This paper presents an overview of Complex Event Processing applied to a particular example of a distributed message-based system, a fabrication process management system. The concepts of causal event histories, event patterns, event filtering, and event aggregation are introduced and their application to the process management system is illustrated by simple examples. This paper gives the reader an overview of Complex Event Processing concepts and illustrates how they can be applied using the Rapide toolset to one specific kind of system.
   
• Event Mining with Event Processing Networks. Louis Perrochon and Walter Mann and Stephane Kasriel and David C. Luckham, The Third Pacific-Asia Conference on Knowledge Discovery and Data Mining. April 26-28, 1999. Beijing, China, 5 pages.Abstract: Event Mining discovers and delivers information and knowledge in a real-time stream of data, or events. We show that the process of delivering knowledge by searching patterns in data and subsequent abstraction of found patterns can be applied in real-time to a complex, asynchronous system. Our event processing engine consists of a network of event processing agents (EPAs) running in parallel that interact using a dedicated event processing infrastructure. The agents can be configured at run-time using a formal pattern language. The underlying infrastructure (1) provides an abstract communication mechanism and thus allows dynamic reconfiguration of the communication topology between agents at run-time and (2) provides transparent, location-independent access to all data. These features allow dynamic allocation of EPAs to different threads and processes on different machines at run time.
   
• eJava - Extending Java with Causality. Alexandre Santoro and Walter Mann and Neel Madhav and David Luckham, Proceedings of the 10th International Conference on Software Engineering and Knowledge Engineering, June 1998, 10 pages.Abstract: Programming languages like Java provide designers with a variety of classes that simplify the process of program development. Some of these classes allow one to easily build multithreaded programs. Though useful, especially in the creation of reactive systems, multithreaded programs present challenging problems such as race conditions and synchronization issues. Validating these programs against a specification is not trivial since Java does not clearly indicate thread interaction. These problems can be solved by modifying Java so that it produces computations, collections of events with both causal and temporal ordering relations defined for them. Specifically, the causal ordering is ideal for identifying thread interaction. This paper presents eJava, an extension to Java that is both event based and causally aware, and shows how it simplifies the process of understanding and debugging multithreaded programs.
   
• Event-Based Execution Architectures for Dynamic Software Systems. James Vera, Louis Perrochon, David C. Luckham.
  Proceedings of the First Working IFIP Conf. on Software Architecture. 1999. San Antonio, Texas.Abstract: Distributed systems’ runtime behavior can be difficult to understand. Concurrent, distributed activity make notions of global state difficult to grasp. We focus on the runtime structure of a system, its execution architecture, and propose representing its evolution as a partially ordered set of predefined architectural event types. This representation allows a system’s topology to be visualized, analyzed and con-strained. The use of a predefined event types allows the execution architectures of different systems to be readily compared.
   
• Using Context-Based Correlation in Network Operations and Management. Louis Perrochon (work in progress, mail author for newest version)Abstract: Network operation consists to a large degree of reaction to activities happening in the network. Better knowledge of the network at any time allows more appropriate reactions. On the example of intrusion detection, we show how context-based correlation of such activities can provide a more detailed view of the network in shorter time. We first present how we model context and then describe the architecture of the Stanford University CEP context-based correlator. Correlation is specified as event patterns in a declarative language that allows us to specify what needs to be detected, instead of specifying how it should be detected. CEP introduces the concept of causal context to intrusion detection. The correlator is able to process events on-line, as they are generated and it can be reconfigured at dynamically. We then show how it increases detection rate, reduce false alarms, and detect large-scale attack patterns at an early stage.

Hmm.

From GCN:

“This is a change we have not faced in the IT security industry before,” he added.

The closest parallel has been in the Defense Department, which anticipated OMB’s reaction in this area. DOD’s Directive 8570 on information assurance, approved in December 2005, requires all of the department’s information assurance workers to obtain an accredited commercial certification in computer security. DOD has approved 13 certifications for the directive.

The DOD requirement already has thrown what one conference attendee called a giant monkey wrench into the IT security manpower market.

“If OMB issues a similar requirement, it’s going to throw the supply and demand curve even more out of balance,” he said.

Datesman agreed, saying it probably would take years for the supply of certified workers to catch up with demand. A CISSP certification requires five years’ experience. “You don’t mint them out of college,” he said.

OK, this is where this trolley leaves the track. I have met CISSP certified folks that I would wager they’d be lucky to fight their way out of a wet paper bag. “Don’t mint them out of college” is a phrase that I’d argue. I would offer that the ISC2 should start auditing certified members. The validity of the CISSP cert is becoming diluted in the eyes of the market.

A picture is worth a thousand words.

It’s great for the mandatory HR tick box but, how many of these folks actually have the ability? Sure they can memorize some flash cards and pass a test but, are they effective? Some, not so much.

On the face of it this is a good idea.

Like all good intentions, they make great paving stones on the road to hell.

Article Link