Partial Disclosure - The Good

The responsible disclosure process tends to break down in rare occasions where the vendor doesn’t want to fix the issue. When this occurs, the researcher is put into a difficult position whereby full disclosure could put users’ systems at high risk of compromise. The other case where partial disclosure becomes an alternative is when the researcher has discovered a design flaw in a protocol or underlying multiple vendor component. Examples of this case include the DNS flaws published this past summer by Dan Kaminsky and the TCP denial of service condition discovered by Robert E. Lee and Jack Louis that is currently in the disclosure process. When the flaw affects a very large number of vendors and the actual problem is located within the underlying protocols that support the communications of the Internet as a whole, one possible solution is to follow a partial disclosure model where phasing the details to the general public can be used to encourage adoption and creation of patches throughout the enormous target audience.

Partial Disclosure - The Bad

What is driving the fear surrounding partial disclosure is the potential for abuse. When a major flaw is partially disclosed, a number of potential issues may occur. First and foremost, the further along the partial disclosure path we are, the more details will be released to the public, and the higher the probability that someone (either good or bad intentioned) will figure out the exploit and disclose the details. Second, when partially disclosing, the vendor’s hand is being forced into a situation that could speed up fixes, reduce testing, and cause ripple problems elsewhere within the infrastructure. It is difficult enough to dance the fine time line when doing responsible disclosure, but if we are escalated to the point of partial disclosure, additional fuel is added to the fire.

The Ugly

The real ugly part of partial disclosure is when we add to the equation the ability to spread fear, uncertainty, and doubt into the normal user community. It is generally well accepted that FUD can be used to drive additional revenue. If it is possible to increase the perceived magnitude of the “problem” that your product or service solves, it is possible to directly impact the demand for that product or service. That is the major fear imposed by the growing trend of partial disclosure. By releasing just enough information to trigger wide scale speculation into the flaw, it is possible to create buzz and garner media attention resulting in a lot of speculation and very little hard facts around the issue. The potential for abuse by the security industry at large is enormous.

The Fix

Some have suggested a group of security researchers be convened to vet the requirement of partial disclosure and to allow for independent peer review of any security research that requires the partial disclosure process. This suggestion leaves questions regarding who would stand on this group and who would be impartial enough to ensure that the right thing was always done regardless of profit potential. It also leaves open the opportunity for member researchers to utilize the information gathered during the vetting process to position themselves to profit from the data upon release. It might be wiser to rely on a higher level authority or government entity to manage this process and use the services of security researchers as required for subject matter expertise. While a group of this type wouldn’t ensure that all partial disclosure is appropriate, it would hopefully limit the potential for abuse and the ever present chance that people try to profit from the FUD that surrounds the current partial disclosure process.

These “take-down” companies are generally specialist offshoots of more general “brand protection” companies, and are hired by banks to handle removal of fake phishing websites.

When we examined our data more carefully we found that we were receiving “feeds” of phishing website URLs from several different sources — and the “take-down” companies that were passing the data to us were not passing the data to each other.

So it often occurs that take-down company A knows about a phishing website targeting a particular bank, but take-down company B is ignorant of its existence. If it is company B that has the contract for removing sites for that bank then, since they don’t know the website exists, they take no action and the site stays up.

Since we were receiving data feeds from both company A and company B, we knew the site existed and we measured its lifetime — which is much extended. In fact, it’s somewhat of a mystery why it is removed at all! Our best guess is that reports made directly to ISPs trigger removal.

The paper contains all the details, and gives all the figures to show that website lifetimes are extended by about 5 days when the take-down company is completely unaware of the site. On other occasions the company learns about the site some time after it is first detected by someone else; and this extends the lifetimes by an average of 2 days.

Since extended lifetimes equate to more unsuspecting visitors handing over their credentials and having their bank accounts cleaned out, these delays can also be expressed in monetary terms. Using the rough and ready model we developed last year, we estimate that an extra $326 million per annum is currently being put at risk by the lack of data sharing. This figure is from our analysis of just two companies’ feeds, and there are several more such companies in this business.

Not surprisingly, our paper suggests that the take-down companies should be sharing their data, so that when they learn about websites attacking banks they don’t have contracts with, they pass the details on to another company who can start to get the site removed.

We analyse the incentives to make this change (and the incentives the companies have not to do so) and contrast the current arrangements with the anti-virus/malware industry — where sample suspect code has been shared since the early 1990s.

In particular, we note that it is the banks who would benefit most from data sharing — and since they are paying the bills, we think that they may well be in a position to force through changes in policy. To best protect the public, we must hope that this happens soon.

Well here’s a story where the tradeoff for speed and efficiency caused a massive stock dump erroneously.

Apparently, many traders use automation software that trolls the Web for news stories and then, depending on what it finds, executes stock trades automatically. It was United Airline’s bad luck that an old article about its 2002 bankruptcy-court filing showed up on Google’s news service and somehow made it to the list of most popular stories. In one of a series of mistakes here, the story had no date on it – which means Google’s algorithm for assessing popularity didn’t have a way to exclude it as an “old” story – OR (because there are conflicting accounts) the South Florida Sun-Sentinel actually put “today’s” date on the page that the story appeared on. This got picked up by the Income Security Advisors newsletter and sent over to Bloomberg News as a one-line brief. Plus there’s the inevitable conspiracy theory that people manipulated the web traffic for this story to adversely affect UAL. Regardless, on Monday afternoon, the stock plunged 76% in less than a day.

But the real problem here is the growing use of automated programs to trigger stock trades without any human interaction – instead based on news headlines and earnings data. According to the Wall Street Journal, these automated programs were responsible for a very surprising 25% of NYSE trades in the last week of August.

I’m sure we’ll hear more as the lawyers are now involved trying to figure out who should get the blame.

A few folks have tried to tie “maturity” to “if the code is robust” or “if the product has certain product features.” The way we have addressed this emerging controversy over at The CEP blog is to center the discussion around the Gartner Hype Cycle, which is a pretty good model for representing the maturity, adoption and business application of specific technologies.

On CEP Maturity and the Gartner Hype Cycle

Since many folks work very closely with Gartner, I expect they are keenly aware of Gartner’s view on technology adoption maturity models and their definitions. Just for our readers who might not be as familar, I quote Gartner’s definitions below to be complete from here:

A hype cycle is a graphic representation of the maturity, adoption and business application of specific technologies. The term was coined by Gartner[citation needed], an analyst/research house, based in the United States, that provides opinions, advice and data on the global information technology industry.

Since 1995, Gartner has used hype cycles to characterize the over-enthusiasm or “hype” and subsequent disappointment that typically happens with the introduction of new technologies. Hype cycles also show how and when technologies move beyond the hype, offer practical benefits and become widely accepted. According to Gartner, hype cycles aim to separate the hype from the reality, and enable CIOs and CEOs to decide whether or not a particular technology is ready for adoption. A longer-term historical perspective on such cycles can be found in the research of the economist Carlota Perez.

A hype cycle in Gartner’s interpretation comprises 5 steps:

“Technology Trigger” — The first phase of a hype cycle is the “technology trigger” or breakthrough, product launch or other event that generates significant press and interest.

“Peak of Inflated Expectations” — In the next phase, a frenzy of publicity typically generates over-enthusiasm and unrealistic expectations. There may be some successful applications of a technology, but there are typically more failures.

“Trough of Disillusionment” — Technologies enter the “trough of disillusionment” because they fail to meet expectations and quickly become unfashionable. Consequently, the press usually abandons the topic and the technology.

“Slope of Enlightenment” — Although the press may have stopped covering the technology, some businesses continue through the “slope of enlightenment” and experiment to understand the benefits and practical application of the technology.

“Plateau of Productivity” — A technology reaches the “plateau of productivity” as the benefits of it become widely demonstrated and accepted. The technology becomes increasingly stable and evolves in second and third generations. The final height of the plateau varies according to whether the technology is broadly applicable or benefits only a niche market.

The term is now used more broadly in the marketing of new technologies.

We used the Gartner Hype Cycle in Two-Thirds of Our Readers Say CEP is Still Immature as a basis for having interested readers vote, and in a unscientific straw poll, the readers indicated that, in their view, CEP is still immature.

At the CEP Blog we ground our discussions and terminology on maturity in Gartner’s models on maturity, and we ground our discussions on event processing in the art-and-science of a long standing domain in event processing - multisensor data fusion (MSDF).

Only 6% of the those who responded to the poll, conducted from July 3 thru July 12th, voted that CEP was mature.   If you include those who consider CEP getting close to maturity, 18% of our readers who voted said that CEP was in the final stages of maturity.

How is it possible that 31% of the folks who responded believe that CEP is in the Gartner-defined Technology Trigger stage of maturity, while 6% believe CEP is at the other end of spectrum, in the Plateau of Maturity Phase?

During the poll I received a question from a colleague who asked me if I “still loved CEP?” and “why are you trashing the entire industry that you love?”   

Frankly speaking, I have enjoyed a passion about event processing since my early days at Sprint, circa 1993, during the NSFNET transition to the commercial Internet.   Then, as today, we hoped for the same goals and objectives that network and security management people seek to achieve; high confidence in actionable alerts with a very low false alarm rate, all based on processing myriad distributed networking events, sometimes referred to today as sense-and-respond networking.

Today, we are good at “sensing”.  Events are created, perhaps trillions upon trillions a second globally.   No one knows the exact number of events the world’s networks generate in a single second, much less in a day or a year.      Yet, we are quite good at producing events.

What we do know is that we do not yet have the technology to listen to myriad events and determine complex events and situations with high confidence.   At best, we can detect, sense-and-respond, to simple events and primitive situations.  

On the other end of the maturity curve, there have been some advances.  Some of the notable progress has been in the event stream processing (ESP) space.    ESP is an importart part of the equation but it is nowhere close to the entire solution because rule-based stream processing is at a very low level in most sense-and-respond decision-making models.  Higher level inference requires more sophistication.

Two-thirds of our readers believe that CEP is still in the very early stages.  The majority of our readers envision CEP as a technology, or set of technologies, to solve myriad complex event processing problems and they know we have a long way to go.     On the other hand and with just as much passion, about one-in-six readers think that the technology is mature, and we are at the end of the CEP maturity cycle.

My crystal ball is just as foggy as yours on the future of CEP - but here on The Complex Event Processing Blog, we continue to work hard to “keep it real” for our readers.  

From Secunia:

Description:
Some vulnerabilities and a security issue have been reported in Apple Safari, which can be exploited by malicious people to disclose sensitive information or to compromise a user’s system.

1) A boundary error within the handling of BMP and GIF images can be exploited to trigger an out-of-bounds read and disclose content in memory.

2) A security issue exists due to Safari automatically launching downloaded executable files from sites in a Internet Explorer 7 zone with the “Launching applications and unsafe files” option set to “Enable”, or sites in the Internet Explorer 6 “Local intranet” or “Trusted sites” zone.

3) An unspecified error in the handling of Javascript arrays can be exploited to cause a memory corruption when a user visits a specially crafted web page.

Successful exploitation of this vulnerability may allow execution of arbitrary code.

The vulnerabilities are reported in Safari for Windows prior to version 3.1.2.

If you’re running it patch ‘er up. Or conversely you could just bite the bullet and get a Mac. (right, and use Firefox with NoScript. thx folks)

Article Link