[RndTbl] firewall/router in a VM

[Kevin McGregor]

While we're on the topic, what sort of desktop-PC motherboards are available
that support ECC memory? I've never really paid attention, so for all I
know, ECC support is common.

On Thu, Feb 18, 2010 at 9:09 PM, Daryl F <wyatt at prairieturtle.ca> wrote:

> Personally I find there is another aspect of data security that is often
> overlooked: data accuracy. As the owner of valuable data I want it
> protected from loss and private but I also want it to be correct.
>
> There are many who believe that an application always crashes when there
> is an undetected memory error but that is not always the case. One of the
> most difficult problems to track down is caused when data resides in flaky
> RAM and then is written to disk where it is faithfully recorded
> inaccurately forever.
>
> Hardly anyone writes code to see if their spreadsheet adds 2+2, comes up
> with 4, then saves it to disk as a 5 via a DMA transfer from bad RAM.
> Eventually some program blows up executing from the bad RAM and it is
> finally replaced but now we have some amount of bad data floating around
> on durable media.
>
> I'm constantly astonished by the amount of corrected ECC memory errors I
> see over time in the servers I care for. The DIMMs eventually fail but I
> feel more secure knowing corrupt data was never transferred from place to
> place.
>
> While auditors may have convinced their customers it is really important
> to have data security and data durability have you ever heard any of them
> ask their customers if they are OK with data inaccuracy?
>
> I think non-ECC memory should be illegal. Somebody's gonna lose an eye and
> it won't be funny any more.
>
> -Daryl
>
>
> On Thu, 18 Feb 2010, Sean Walberg wrote:
>
> > What you say is not untrue, but the larger issues (IMHO) are that:
> >
> > 1. Most people design such that they avoid trouble and confrontation.
> > 2. Most IT auditors have no IT experience.
> >
> > For #1, most people have lost the ability to rationally assess risk. No
> one
> > wants to be the guy to say "I saved $xxxxx by specing a lower box that
> will
> > still handle the load" or some variation of that when that's the first
> > decision that's going to be looked at if there is a problem. In most
> cases
> > the IT department has lost touch with the business value they provide. So
> we
> > get this proliferation of redundant servers and network gear that sits
> idle.
> >
> > There is an aspect of hardware to it, though. Developers tend to assume
> they
> > are writing to a machine that executes commands in zero clock cycles, has
> > infinite memory, and has a network with zero latency and infinite
> bandwidth.
> > Rather than try and correct these misunderstandings, IT will throw money
> at
> > the problem to make it run and not get blamed.
> >
> > For #2, I'm not sure what else has to be said. I have only met one
> auditor
> > who I respect and actually gets these kind of discussions. He explained
> to
> > me that he understood some of these things made no technical difference,
> but
> > the problem was to convince every other auditor. Sometimes it's easier
> just
> > to bite the bullet and do things sub-optimally rather than having to
> spend
> > several hours explaining it each time the (new) audit team comes around.
> > Back to #1, the cost of being right is high and the benefits are almost
> nil.
> >
> > With respects to your arguments you're mixing data durability and data
> loss
> > prevention. They are both aspects of security (eg, mitigating risk), but
> I'm
> > sure that most IT departments would agree that they are more worried
> about a
> > critical Excel spreadsheet getting in the hands of the media or
> competition
> > than they are having Excel crash because of a memory error. The cost
> > and likelihood of the former dwarf that of the latter.
> >
> > Sean
> >
> > On Wed, Feb 17, 2010 at 10:20 PM, Adam Thompson <athompso at athompso.net
> >wrote:
> >
> >> <soapbox>
> >> That's because we don't, collectively, think about hardware.  And we
> don't
> >> think about hardware being buggy.  And we especially don't think about
> >> "hardware" having inherent security flaws.
> >>
> >> (OK, yes, the security folks who crossed over *into* IT do.  They aren't
> >> auditors, for better or worse.)
> >>
> >> A Cisco router is "software" enough (and has had enough bugs :-) that it
> >> crosses into our conscious awareness regarding security, but their
> switches?
> >>  Nah.  Mature product, all hardware (despite running an OS), no bugs.
> >>  Either works or it doesn't.
> >>
> >> Bullshit.
> >>
> >> Show me a hardware-accelerated device and I can show you half a dozen
> ways
> >> it could fail unnoticed, (potentially) compromising security as it goes.
> >>
> >> Notice that we install local firewalls on every PC but don't use ECC
> memory
> >> to guard against random bit errors.  (I do, BTW - even on my PC.  It's
> one
> >> small part of why I don't have a laptop.)  A HERF gun is a better DoS
> tool
> >> than any virus or worm, by several objective measurements.
> >>
> >> The entire IT industry has its head stuck up... you know where, in so
> many
> >> different ways.
> >>
> >> Yet, this isn't surprising.  Humans want instant gratification, a free
> >> ride, and the illusion of control.  Those things are all way easier with
> >> software than with hardware.  (Contemplate the difference between "soft"
> and
> >> "hard", if you will, for a moment.)
> >>
> >> Do I expect this to change any time before the heat death of the
> universe?
> >>  No.  But I sure wish auditors took a wider view of the world.
> >>
> >> "Never attribute to malice that which can be adequately explained by
> >> stupidity." - Hanlon's Razor (among other attributions)
> >> </soapbox>
> >>
> >> -Adam
> >>
> >
> >
> _______________________________________________
> Roundtable mailing list
> Roundtable at muug.mb.ca
> http://www.muug.mb.ca/mailman/listinfo/roundtable
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.muug.mb.ca/pipermail/roundtable/attachments/20100219/ec9dd779/attachment-0001.html