Topic: About Mt. Gox flaw from a security expert (Read 34165 times)

My $0.02.  

I only just read over this and someone correct me if I'm wrong but this appears to be using Xen to isolate (groups of) applications in their own VM on a single host.

My short answer:

This is at best a one trick pony and it's possibly the wrong approach.

Why (or my long answer):

I'm going to talk about some  "classes" of defense here (and these are terms I just made up so feel free to take some shots at them):

i) A defense which foils an attack (or some significant percentage of attacks) forcing attackers to use a completely different approach (ALSR - I'm sure everyones sick of me mentioning this)
ii) A defense which introduces a measurable and significant increase in difficulty to exploiting an existing flaw. (Password complexity rules, firewalls)
iii) A defense that removes one attack vector with known problems and replaces it with another which is less known. (Switching from IIS to Apache in an IIS shop)

I submit that i) is intrinsically superior to ii) and both are superior to iii)

VM isolation is at best a "Type II" defense, as it introduces the problem of detecting and compromising the hypervisor before compromising the machine and at worst it could be considered a Type III defense.  My assumption here is that a successful attack on the hypervisor means complete ownership of the machine.  Ergo,  we have reduced the problem for attackers from attacking application X from a very large selection of applications.   To attacking Hypervisor X for which the list is much smaller.    The upside is that - hopefully this also reduces the attack surface for the defenders.   This would normally be a good thing but it's only true if you assume the hypervisior is more secure than your other applications.

e.g. If I had a machine that had to run a webserver and Tomcat to provide a very simple web service to a very targeted application.  Removing that and replacing it with a few lines of well audited code could be considered reducing the attack surface of that machine.   However the hypervisor isn't a small piece of software and it's attack surface isn't well known.

It might be safer if I couldn't already do half the job: Detect running in a VM.   For lots of people who haven't installed the vmware tools on their host a simple check of the time with an external source will tell you that you're running on a VM.   Depending on the guest OS I've read about at least fifty different markers for VM detection.

Also it's worth noting that the point of Qubes seems to be the antithesis of what I understand to be best practice with regard to VM's these days.  Some of us think that depending on VM isolation is a bad idea.  It violates the principle of DiD.  So, like in my shop we consider it a bad idea to mix VMs with differing security privileges on the same host.  In other words we don't run the payment gateway software on a VM on the same machine we are running the Drupal VM.  Yet this seems to be the whole point of Qubes.  

This is a good presentation. http://handlers.sans.org/tliston/ThwartingVMDetection_Liston_Skoudis.pdf

More info on the VMChat teaser at the end: http://www.foolmoon.net/cgi-bin/blog/index.cgi?category=Security%20News

well gentlemen, that was one hell of a conversation.

thank you all kindly.  as a lowly network designer, i learned a lot.  didn't cost anything, either.

whattaya youse guys think of Qubes, and their 'security by isolation' approach?

i've got no dog in the fight - but i'd really like to know what your opinions are.

well gentlemen, that was one hell of a conversation.

thank you all kindly.  as a lowly network designer, i learned a lot.  didn't cost anything, either.

whattaya youse guys think of Qubes, and their 'security by isolation' approach?

i've got no dog in the fight - but i'd really like to know what your opinions are.

1.  All statistical modelers are statisticians.

2.  Not all statisticians are statistical modelers

Name something from statistics which is not a model of something or a modeling tool.    If you read your own article you'd see that both the so-called Pure statistician and Applied statistician are modeling something.   The only difference is the kind of validation they are willing to consider.  So the "pure" statistical model is considered valid (in this case) when it conforms to some dogma about colinearity and the "applied" model is valid when (among other things) it succeeds in predicting something.

Anyway you're cute when you just shovel barely applicable google cites and pretend that somehow makes your point.

But in the interests of you actually contributing something....I'll try to keep in mind that when you say "statistical modeler" you mean "Applied statistician".  Not that you show much understanding of what the second term means anyway.

I'm glad you finally accepted that the tension between your overly strict denotation of "statistical modeler" and the common, widespread informal connotation of "applied statistician"

My approach is superior because it preserves linguistic information, while your misinterpretation destroys the sometimes subtle distinction between a working statistician (ie statistical modeler) and the purely theoretical academic egghead (ie capitol-S Statistician).

That's why I showed you the differences with the copypasta illustrating and demonstrating their existence at length, and in excruciating detail.

Name something from statistics which is not a model of something or a modeling tool.    If you read your own article you'd see that both the so-called Pure statistician and Applied statistician are modeling something.   The only difference is the kind of validation they are willing to consider.  So the "pure" statistical model is considered valid (in this case) when it conforms to some dogma about colinearity and the "applied" model is valid when (among other things) it succeeds in predicting something.

Anyway you're cute when you just shovel barely applicable google cites and pretend that somehow makes your point.

But in the interests of you actually contributing something....I'll try to keep in mind that when you say "statistical modeler" you mean "Applied statistician".  Not that you show much understanding of what the second term means anyway.

So, again, what are the professionals using and why?  And how?

I'd like to see the 3 Stooges who insulted, attacked, and ran you off try to browbeat MtGox into switching to Linux, using similar thug tactics of ganging up and gainsaying everything said to them.

I wonder why they, who know compsec ever-so-much-better than MtGox, Muad-dib, and myself, simply don't start up their own clearinghouse and compete with MtGox.

Adorable?  Thanks.  I guess you have a thing for articulate nerds with a deep understanding of both math and language.

1.  All statistical modelers are statisticians.

2.  Not all statisticians are statistical modelers

your use of "statistical modeler" instead of simply "statistician" is adorable!

There are many controversial topics actively discussed among business analysts who follow divergent schools of thought.  The most common schools of thought can be categorized into two groups:  the first group being the theoretical statisticians, and the second being represented by those individuals who embrace “applied” statistics.  Generally, the theoretical statisticians apply what they’ve learned in an academic setting, and follow the “laws” set forth by their institutions.  On the other end of the spectrum, the applied statisticians rely heavily on market testing and key performance indicators (e.g., financial impact) to determine their own set of experientially-based statistical methods and axioms.

Neither school is inherently good or bad.  All seasoned analytic managers have met new analysts who come straight out of school with misconceptions of the value and place for various mathematical procedures and rules.  We’ve all also faced analysts with significant career experience who have carried their academic theoretical statistical knowledge with them as an unchanging edict, despite the limited (or detrimental) applicability of some of these doctrines in the marketplace.  Similarly, we’ve all also encountered business-focused “applied statisticians” whose lack of adherence to theory has resulted in unstable strategic analytic products that look great on paper, but fail in practice.

Of all the points of conflict between theoretical and applied statisticians, one of the most heated relates to the utility of the measurement of colinearity in predictive modeling.  In predictive modeling, colinearity is the amount to which two independent variables correspond to the same dependent variable.  It can also refer to the amount a single independent variable corresponds to a dependent variable.

The theoretical statistician will argue that intensively managing colinearity is of great importance in building predictive models.  A few of the arguments they will cite to support this position include that if colinearity isn’t removed:

    We cannot clearly explain the value of each independent variable in the model’s predictive algorithm
    We are endorsing a final product that may not conform with standard mathematical partiality towards a solution that is parsimonious in nature
    Parameter estimates might be unstable from sample to sample (or from validation to marketplace execution)

The applied statistician will argue that colinearity is not relevant as:

    We are seeking lift , not explanation.  If the new model makes more money in the marketplace, the ability to explain “why” becomes academic
    Parameter estimate stability can be enhanced through various exercises during the model build phase

The reality is that both sides may be correct, at specific application points, and in specific situations.  We just need to moderate academic rigor with real-world findings in order to uncover when to implement a rule, when to bend it, and when to discard it.  To address each of the five points (above):

    Explaining an individual variable’s contribution to a multivariate prediction may or may not have relevance.
        If you are in a market research company, this is a key concern.  You will need to let your clients know not only “what will be,” but “why.”
        If you are in a direct marketing company, explanation may not be relevant.  As an example, if you work for a catalog company, maximum incremental financial lift is far more important than explaining the “percent of predictive value” driven by individual model components.

    Ideally, we want a parsimonious solution as they tend to be more stable.  But, what if you find that your less parsimonious option (having been tested on multiple out-of-time validation samples) is almost identical in stability?  What if, during those same tests you find that it produces a far more robust prediction?  In short:
        Generally, you will want to favor a more parsimonious solution
        But, if you have a model that is relatively less parsimonious, but already proven stable and robust, there may not be any additional value in reworking the solution for the sake of a mathematical preference

    If you are conducting a model building strategy that does not manage colinearity, but is laser-focused on lift, and you find that your parameter estimates are not stable, a likely cause is inadequate sample size in the build data set.  As a result:
        You can increase your sample size substantially (which will typically eliminate this issue)

    For most predictive model applications in industry, lift is the goal.  But you need to be apprised of the perspective of senior management and clients.  Until they are comfortable with your track record, they may require you to explain the nature, source and quantified relevance of each individual variable in your model…and you’ll need to provide this explanation in business terms they can understand

    Managing parameter estimate instability can’t always be achieved:
        The most common way to reduce model instability (caused by collinear variables) is to increase the build and validation sample sizes.  But, for many organizations, there simply isn’t enough data to do this effectively (especially for smaller organizations that are not engaged in direct marketing).
        Another potential parameter estimate instability cure is to examine each variable and appropriately bin them relative to the dependent variable in question.  Keep in mind, though, that the more you bin, the more you will also be reducing variable information value…and this may end up reducing the overall predictive power of the model.

Overall, the positions held by the “pure” theoretical statistician and the “pure” applied statistician both have strengths and weaknesses that can be demonstrated in actual market testing.  To improve effectiveness, each group needs to move beyond a mastery of one philosophy, and become a pragmatist of both.

Mt. Gox Uses FreeBSD.

You, BB, and Tux may huff, puff, insult, gainsay, and dissemble until blue in the face, but that won't change anything in reality.

Bickering and playing word games don't cut it, especially when a statistical modeling expert (specialized in computer security) is schooling you on the facts and logic of the issue at hand.

I repeat: Referring to a commonly known fact, such as the security of BSD vs Linux, is not an argument.

im finding it interesting that you are quoting answers.com are you serious?

OpenBSD has an extremely stringent security auditing policy; only two remote attack vulnerabilities have been found in the last ten years. This is because OpenBSD doesn't create a large attack surface by running a large number of networked apps.

- BSD has proactive security, Linux security is reactive

- BSD is designed from the ground for security, Linux instead has a more chaotic architecture

Is Linux the most secure OS?

Linux-based systems get a lot of press in IT trade publications. A lot of that press relates to its security characteristics. In fact, some claim “Linux is the most secure operating system (OS) of them all.” Such statements are, of course, unsupportable hyperbole; while many Linux distributions may outshine both MS Windows and Apple MacOS X by a significant margin, there’s evidence to suggest that most Linux distributions are not up to the standards of FreeBSD, for instance — let alone OpenBSD, with possibly the best security record of any general-purpose operating system.

If it were a fact, then you would be able to point to some clear and objective evidence of that right?  (Keep in mind that because you are referring to 'security' as some kind of blanket term you'd be responsible for providing that kind of evidence for the majority of aspects of the term and of course how exactly you know that your set of aspects is the majority).

Nice labeling there mac.  This isn't gainsaying.  I, simply as a IT security professional and the holder of a degree in computer science, have seen no set of well-defined, broadly scoped evidence that BSD is superior in "security" to Linux.  Nor in my conversation with other security professionals or members of the CS community (like my alumni, Usenix attendees)  see any clear consensus as to the superiority of BSD.  I have, certainly met people who make that claim but they always seem to fall down when trying to come up with a general definition of security or if they do they fall down in substantiating it with regard to their favored OS/Platform/Giant Spider.  Ergo it seems reasonable to me to call such a term "complex" furthermore given that even the most secure systems from a theoretical point of view can be entirely undone in implementation (such as EMF side-channel attacks on QKDS) it seems again reasonable to me to call such a system "nuanced".  Given these two facts (using the term correctly here).  I think it is entirely justified to be mistrustful of any and all who consider "security' as an open and shut case for product (or platform or giant spider) X over product (you get the idea) Y.

What do you want from me here guy? The two sentences above tell me to look at your use of the term "well-known" as: your opinion of the opinions of two very large groups of which your sample size is probably so small and poorly randomized it's useless.  Not to mention that even if the majority of those two groups held the opinion you claim it still isn't necessarily meaningful   Computer Science and EECS people do not always have a background in computer security.   Making their opinion anywhere from questionable to useless.   Given the size of the groups and the variance in the population's skill set you could easily be getting the opinion of the least qualified people. I mean would you really rank the opinion of someone's who's focus was in Combinatorics or AI or Queuing Theory as equal or greater than Bruce Schneier or (going old school) D. J. Bernstien when it comes to an application or operating systems "security".  If you don't then how many Combinatoricists, AI researchers or Queuing Theorists make one Bruce or Dan?  

Not to mention it's not hard to find high-profile people in computer security who disagree on "well-known" concepts.