Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Computer Security > Disk Encryption for remote XP machines.

Reply
Thread Tools

Disk Encryption for remote XP machines.

 
 
nemo_outis
Guest
Posts: n/a
 
      01-29-2010
Regis <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

....
>> Securing a platform remotely against those who will have direct
>> unsupervised physical control of it is a "hard" problem - there are
>> no cheap easy solutions (well, none that work).
>>
>> Not for nothing were HSMs and cryptographic coprocessors such as the
>> IBM 4764 invented. Not for nothing do they cost thousands of dollars.




> No doubt, but... you have to admit that encrypting it with something
> key'd to the specific hardware is a hell of a lot better than nothing
> at all (which one can assume is where it's at right now). This
> particularly true against the "misplaced hard drives" threat that's on
> the OP's mind.


Yes and no.

If I have to restrain a tiger, two layers of tissue paper ARE, at least in
principle, better than a single layer of tissue paper. The only minor flaw is
that neither is a remotely adequate solution to the problem

Sure, some easily readable/spoofable property of the computing platform (e.g., a
motherboard serial number) could be used to "authenticate" that platform, but such
a "lame" approach is worth exactly SFA - trusting it to supposedly provide some
level of incremental security (beyond the utterly trivial and minuscule) is living
in a fool's paradise.


> You whittle down the means of reading those drives to a much smaller
> audience.


The "threat source" is already known - it is comprised overwhelmingly of
(putatively) unfaithful maintenance men (and whichever accomplices they can
recruit). There is no significant whittling to be done.


> And your maintenance guys with physical access are perenially the weak
> spot. But at least the people riffling through the maintenance guys
> trash or folks servicing his truck won't be able to trivially read the
> drives, which does have some value.


You thwarted those riffling through the trash of unfaithful maintenance men? -
well, there's a 0.00001% improvement in security right there. No, unfocussed and
misplaced effort on ridiculously remote and improbable threats is just energy
wasted.


> Just because a security measure isn't fool-proof doesn't mean it's
> worthless. Otherwise, we're all just jerking off because no security
> measures are fool proof.


It is not a question of some set of security measures being foolproof but rather
of them rising to at least somewhere near "fit for purpose."

Security is not something that it is added on, like icing on a cake, but rather
something that is built in - right from the start. All the more so if what we're
we're talking about, as Mike seems to state, is a major ATM/POS-like system with
9000 sites! This major system was deployed without considering the possibility of
unfaithful maintenance men?

Nobody did threat scenarios? Nobody did risk and consequence analysis? Nobody
analyzed the system for vulnerabilities? Nobody designed security in from the
start? Astounding!

And now Mike want to cobble together a quick "security fix" with little or no
budget and no willingess to make any serious effort if it means really changing
anything? He's going to MacGyver some quick fix using Truecrypt and motherboard
serial numbers or the like? And we here on alt.computer.security are the
consultative resource he's leaning on regarding how to go about it?

Well, sorry mate, in that case Mike is royally fooked - he'd better just hope
instead all his maintenance men are honest. Hope real hard!

Regards,
 
Reply With Quote
 
 
 
 
Mike
Guest
Posts: n/a
 
      01-29-2010
On Jan 29, 1:49*am, "nemo_outis" <(E-Mail Removed)> wrote:
> Regis <(E-Mail Removed)> wrote innews:(E-Mail Removed):
>
> ...
>
> >> Securing a platform remotely against those who will have direct
> >> unsupervised physical control of it is a "hard" problem - there are
> >> no cheap easy solutions (well, none that work).

>
> >> Not for nothing were HSMs and cryptographic coprocessors such as the
> >> IBM 4764 invented. Not for nothing do they cost thousands of dollars.

> > No doubt, but... you have to admit that encrypting it with something
> > key'd to the specific hardware is a hell of a lot better than nothing
> > at all (which one can assume is where it's at right now). *This
> > particularly true against the "misplaced hard drives" threat that's on
> > the OP's mind. *

>
> Yes and no.
>
> If I have to restrain a tiger, two layers of tissue paper ARE, at least in
> principle, better than a single layer of tissue paper. *The only minor flaw is
> that neither is a remotely adequate solution to the problem
>
> Sure, some easily readable/spoofable property of the computing platform (e.g., a
> motherboard serial number) could be used to "authenticate" that platform, but such
> a "lame" approach is worth exactly SFA - trusting it to supposedly provide some
> level of incremental security (beyond the utterly trivial and minuscule) is living
> in a fool's paradise.
>
> > You whittle down the means of reading those drives to a much smaller
> > audience.

>
> The "threat source" is already known - *it is comprised overwhelmingly of
> (putatively) unfaithful maintenance men (and whichever accomplices they can
> recruit). *There is no significant whittling to be done.
>
> > And your maintenance guys with physical access are perenially the weak
> > spot. *But at least the people riffling through the maintenance guys
> > trash or folks servicing his truck won't be able to trivially read the
> > drives, which does have some value.

>
> You thwarted those riffling through the trash of unfaithful maintenance men? -
> well, there's a 0.00001% improvement in security right there. *No, unfocussed and
> misplaced effort on ridiculously remote and improbable threats is just energy
> wasted.
>
> > Just because a security measure isn't fool-proof doesn't mean it's
> > worthless. Otherwise, we're all just jerking off because no security
> > measures are fool proof.

>
> It is not a question of some set of security measures being foolproof but rather
> of them rising to at least somewhere near "fit for purpose."
>
> Security is not something that it is added on, like icing on a cake, but rather
> something that is built in - right from the start. *All the more so if what we're
> we're talking about, as Mike seems to state, is a major ATM/POS-like system with
> 9000 sites! *This major system was deployed without considering the possibility of
> unfaithful maintenance men?
>
> Nobody did threat scenarios? *Nobody did risk and consequence analysis? * *Nobody
> analyzed the system for vulnerabilities? *Nobody designed security in from the
> start? *Astounding!
>
> And now Mike want to cobble together a quick "security fix" with little or no
> budget and no willingess to make any serious effort if it means really changing
> anything? *He's going to MacGyver some quick fix using Truecrypt and motherboard
> serial numbers or the like? *And we here on alt.computer.security are the
> consultative resource he's leaning on regarding how to go about it?
>
> Well, sorry mate, in that case Mike is royally fooked - he'd better just hope
> instead all his maintenance men are honest. *Hope real hard!


LOL. Talk about overstating the case. Unless you have a particularly
high opinion of yourself and think that i'm leaning too hard? This
estate has been active for 20 years or so and has grown to a
particular size due to integration following takovers, migration of O/
Ss etc. I'm not trying to cobble anything together I'm looking for a
remote distribution of some disk encryption software which will link
the hard disk to the device WITHOUT any extra hardware. Yes, risk and
threat analyses have been made and the single risk/hole call it what
you will is the disk itself. Not that it has any sensetive data, not
that it will allow access to anything compromising but merely for the
reputational risk should the disk end up on ebay and it has BANK OF
XXXXX all over it. My approach is certainly fit for purpose it's just
that I intend on purchasing a Mini to get me from a to b rather than a
Bugatti Veyron.
God I love usnet.
 
Reply With Quote
 
 
 
 
nemo_outis
Guest
Posts: n/a
 
      01-29-2010
Mike <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

....
> LOL. Talk about overstating the case. Unless you have a particularly
> high opinion of yourself and think that i'm leaning too hard? This
> estate has been active for 20 years or so and has grown to a
> particular size due to integration following takovers, migration of O/
> Ss etc. I'm not trying to cobble anything together I'm looking for a
> remote distribution of some disk encryption software which will link
> the hard disk to the device WITHOUT any extra hardware. Yes, risk and
> threat analyses have been made and the single risk/hole call it what
> you will is the disk itself. Not that it has any sensetive data, not
> that it will allow access to anything compromising but merely for the
> reputational risk should the disk end up on ebay and it has BANK OF
> XXXXX all over it. My approach is certainly fit for purpose it's just
> that I intend on purchasing a Mini to get me from a to b rather than a
> Bugatti Veyron.
> God I love usnet.



A bit difficult to reconcile with your previous statement: "Mmm don't really want
to go the extra hardware route as there a 9000 of these beasts and that will
require actual man in a van visit (aside from the cost)"

9000 of them, eh? and like Topsy, they just growed, eh? Well, OK

Risk and threat amalyses have been made, you say? And yet it is only now, 20
years on, that the risk of a HD going astray or malfeasance by maintenance men is
noticed and ways to address the matter are being considered. Hardly an exotic
risk and yet somehow it has been overlooked/ignored until now. Let's just say I'm
not overwhelmed by either the timeliness or thoroughness of that risk and security
analysis. But better late than never, I guess (So much for timeliness - as for
thoroughness?)

And now all you say you need is disk encryption. The matter of possible
malfeasance by maintenance men has largely disappeared. You only need to protect
data at rest and not data in use? Well, good, because the maintenance man problem
is non-trivial and there are no quick fixes.

Your explanations have now cleared things up. Your goals are very modest and
limited and can be reduced to one core objective: don't let HDs (or, more
specifically, the data on them) go astray.

So here're my revised quick fixes to your problem:

1) Since malfeasance by maintenance men has now been discarded as an issue, put
out a memo to all your maintenance men establishing the policy that any "loose"
HDs are to be returned to headquarters and not disposed of otherwise. While
you're at it, establish protocols and procedure for HD disposal at headquaters
(not as simple as it seems if we're talking many disks over a long period of
time).

or, if you can "push" software installations to each site:

2) Install any modern full-HD encrypton system. Truecrypt is one of the better
ones and it's free, so, sure, use it.
(And note that it won't be a trivial matter to manage the logistics of that
"push" to ensure nothing is missed, no old hardware hangs, and no equipment does
"strange" things. Or to establsh a backup procedure for data recovery, etc. But
then again there's no need for me to go into all this - after all, you've already
done a risk and threat analysis, right?)

And that's it. A cheap, easy and quick fix. Just don't kid yourself that you've
"solved" the problem of data security.

However, if you wish to do more than put a band-aid on the problem, let me suggest
that a budget of $10-100 per machine for retrofitting real security would hardly
be extravagant or lavish - it would, in fact, be a "bargain basement" approach.
IOW, a real security review and refurbishment applied to a 9000-unit hodge-podge
system developed incrementally over 20 years could well cost hundreds of thousands
of dollars. And I suggest that a goodly chunk of that cost be expended on a
qualified security consultant. While you're at it, some input from a specialist
in business processes and procedures would also not be amiss.

Regards,

PS Implementing security on a dispersed 9000-unit system is very different from
encrypting one or two drives on a home system. The scale introduces a
*qualitative,* not just a quantitative, change in the nature of the problem.

Hell, it takes a lot of coordination and effort to push out a lousy Windows patch
to thousands of machines at a single company site - companies must put
considerable effort into making sure there are no foul-ups on gaps. And your
problem, even in its most reduced form as you've now restated it, is considerably
more difficult. I suggest you ponder this well before you rely on your cheap and
easy encryption quickfix.











 
Reply With Quote
 
Mike
Guest
Posts: n/a
 
      01-29-2010
On Jan 29, 4:53*pm, "nemo_outis" <(E-Mail Removed)> wrote:
> Mike <(E-Mail Removed)> wrote innews:(E-Mail Removed):
>
> ...
>
> > LOL. Talk about overstating the case. Unless you have a particularly
> > high opinion of yourself and think that i'm leaning too hard? This
> > estate has been active for 20 years or so and has grown to a
> > particular size due to integration following takovers, migration of O/
> > Ss *etc. I'm not trying to cobble anything together I'm looking for a
> > remote distribution of some disk encryption software which will link
> > the hard disk to the device WITHOUT any extra hardware. Yes, risk and
> > threat analyses have been made and the single risk/hole call it what
> > you will is the disk itself. Not that it has any sensetive data, not
> > that it will allow access to anything compromising but merely for the
> > reputational risk should the disk end up on ebay and it has BANK OF
> > XXXXX all over it. My approach is certainly fit for purpose it's just
> > that I intend on purchasing a Mini to get me from a to b rather than a
> > Bugatti Veyron.
> > God I love usnet.

>
> A bit difficult to reconcile with your previous statement: "Mmm don't really want
> to go the extra hardware route as there a 9000 of these beasts and that will
> require actual man in a van visit (aside from the cost)"
>
> 9000 of them, eh? *and like Topsy, they just growed, eh? *Well, OK
>
> Risk and threat amalyses have been made, you say? *And yet it is only now, 20
> years on, that the risk of a HD going astray or malfeasance by maintenance men is
> noticed and ways to address the matter are being considered. *Hardly an exotic
> risk and yet somehow it has been overlooked/ignored until now. *Let's just say I'm
> not overwhelmed by either the timeliness or thoroughness of that risk and security
> analysis. But better late than never, I guess (So much for timeliness - as for
> thoroughness?)
>
> And now all you say you need is disk encryption. The matter of possible
> malfeasance by maintenance men has largely disappeared. *You only need to protect
> data at rest and not data in use? *Well, good, because the maintenance man problem
> is non-trivial and there are no quick fixes. *
>
> Your explanations have now cleared things up. *Your goals are very modest and
> limited and can be reduced to one core objective: don't let HDs (or, more
> specifically, the data on them) go astray. *
>
> So here're my revised quick fixes to your problem:
>
> 1) Since malfeasance by maintenance men has now been discarded as an issue, put
> out a memo to all your maintenance men establishing the policy that any "loose"
> HDs are to be returned to headquarters and not disposed of otherwise. *While
> you're at it, establish protocols and procedure for HD disposal at headquaters
> (not as simple as it seems if we're talking many disks over a long period of
> time).
>
> or, if you can "push" software installations to each site:
>
> 2) *Install any modern full-HD encrypton system. *Truecrypt is one of the better
> ones and it's free, so, sure, use it. *
> (And note that it won't be a trivial matter to manage the logistics of that
> "push" to ensure nothing is missed, no old hardware hangs, and no equipment does
> "strange" things. *Or to establsh a backup procedure for data recovery, etc. But
> then again there's no need for me to go into all this - after all, you've already
> done a risk and threat analysis, right?)
>
> And that's it. *A cheap, easy and quick fix. Just don't kid yourself that you've
> "solved" the problem of data security.
>
> However, if you wish to do more than put a band-aid on the problem, let me suggest
> that a budget of $10-100 per machine for retrofitting real security would hardly
> be extravagant or lavish - it would, in fact, be a "bargain basement" approach. *
> IOW, a real security review and refurbishment applied to a 9000-unit hodge-podge
> system developed incrementally over 20 years could well cost hundreds of thousands
> of dollars. *And I suggest that a goodly chunk of that cost be expended on a
> qualified security consultant. *While you're at it, some input from a specialist
> in business processes and procedures would also not be amiss.
>
> Regards,
>
> PS *Implementing security on a dispersed 9000-unit system is very different from
> encrypting one or two drives on a home system. *The scale introduces a
> *qualitative,* not just a quantitative, change in the nature of the problem. *
>
> Hell, it takes a lot of coordination and effort to push out a lousy Windows patch
> to *thousands of machines at a single company site - companies must put
> considerable effort into making sure there are no foul-ups on gaps. *And your
> problem, even in its most reduced form as you've now restated it, is considerably
> more difficult. *I suggest you ponder this well before you rely on your cheap and
> easy encryption quickfix.


Thanks for your suggestions.
No thanks for your boorish attitude and presumption that I'm a
complete arse.
I came here looking for suggestions for a solution based on my
requirements, not a lecture on the why's and wherefore's of how to
distribute software on 9k remote machines (something we do ALL the
time) , or the hint that no other security exists. Extrapolation based
on what I asked was unnecessary but thanks for the reply.
 
Reply With Quote
 
nemo_outis
Guest
Posts: n/a
 
      01-29-2010
Mike <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

....
> Thanks for your suggestions.
> No thanks for your boorish attitude and presumption that I'm a
> complete arse.
> I came here looking for suggestions for a solution based on my
> requirements, not a lecture on the why's and wherefore's of how to
> distribute software on 9k remote machines (something we do ALL the
> time) , or the hint that no other security exists. Extrapolation based
> on what I asked was unnecessary but thanks for the reply.



Presumption that you're a complete arse? No, Mike, it's not a presumption - you've
amply demonstrated it to be fact.

We now know that not only is this particular bank too cheap and stupid to do proper
security analysis and implementation, but that it has also skimped by putting an
ignorant and incompetent person in charge of it - you, Mike!

No, Mike, even though your ego is too fragile to handle it, everything I've said has
been spot on.

Best of luck - you'll need it.

Regards,


 
Reply With Quote
 
Mike
Guest
Posts: n/a
 
      01-29-2010
On Jan 29, 8:08*pm, "nemo_outis" <(E-Mail Removed)> wrote:
> Mike <(E-Mail Removed)> wrote innews:(E-Mail Removed):
>
> ...
>
> > Thanks for your suggestions.
> > No thanks for your boorish attitude and presumption that I'm a
> > complete arse.
> > I came here looking for suggestions for a solution based on my
> > requirements, not a lecture on the why's and wherefore's of how to
> > distribute software on 9k remote machines (something we do ALL the
> > time) , or the hint that no other security exists. Extrapolation based
> > on what I asked was unnecessary but thanks for the reply.

>
> Presumption that you're a complete arse? *No, Mike, it's not a presumption - you've
> amply demonstrated it to be fact.
>
> We now know that not only is this particular bank too cheap and stupid to do proper
> security analysis and implementation, but that it has also skimped by putting an
> ignorant and incompetent person in charge of it - you, Mike!
>
> No, Mike, even though your ego is too fragile to handle it, everything I've said has
> been spot on.
>
> Best of luck - you'll need it.
>
> Regards,


LOL.
 
Reply With Quote
 
nemo_outis
Guest
Posts: n/a
 
      01-29-2010
Mike <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

....
> LOL.



I see both Mike and I are amused by his truculence and stupidity.

So, moving on, I will instead provide some additional comments for those less
impervious to common sense than Mike.

I spoke in previous posts of possibly using Truecrypt for Mike's 9000 endpoints.
While conceivable, this would likely be a bad idea.

Not because of any inherent weakness in Truecrypt's encryption, but rather because
Truecrypt is primarily designed for use on a onesy-twosy basis. Large-scale
corporate deployments (let alone wide-scale *dispersed* corporate deployments)
*require* administrative and management functions - these are provided by the
"enterprise" (or similarly named) versions of major HD-encryption vendors.

What is needed are key-management methods (including generation, tracking,
revocation, replacement, etc.), audit trails and compliance reporting, policy
management, role management, and similar features as found in products from those
such as Winmagic and Utimaco. Truecrypt has none of this.

Imagine that old Bill, the maintainer of the Northwest district has just retired,
quit, or been fired. Ordinary prudence and due diligence (no aspersions on old
Bill's honesty) require that you change the keys on all machines (say 261 of them)
to which he had access. But which 261? Or is it 273? (You don't want to forget
the 12 units he was temporarily responsible for when old Jack was sick last week)
And are you going to do the 261 key changes manually? And who exactly is going
to make this change to the system. And how are you going to be sure you didn't
accidentally miss something and that all the changes were done right? And which
lower-level managers need to have access to those same keys (or a higher level
"pass" key)? And is there a vendor to provide support for this system, including
managing periodic patches and upgrades? And on and on...

No, it would be lunacy of the first order (lunacy no imaginary "cost savings"
could justify) to try to do all this manually with something like Truecrypt. A
management system is needed. And it would generally be inefficient, unsafe, and
costly for the bank to try to develop such a crypto management system on its own
(especially without qualified crypto staff).

So what is needed is an "enterprise" crypto system. And that costs money. Say,
arguendo, $50 a unit - total cost for 9000 of them pushing half a million dollars!

So before you go this route you might (Mike wouldn't, but *you* might) want to
drop, say, $50,000 on a real security study by real professionals (not just by
Mike as supported by alt.computer.security) to see if this is the right way to
proceed or if you should be doing something different or additional.

Regards,

PS There are also a number of other issues along these lines, but one example
should be sufficient illustration of the principle for all but the terminally
thick - like Mike.







 
Reply With Quote
 
♥Ari ♥
Guest
Posts: n/a
 
      01-30-2010
On Fri, 29 Jan 2010 11:47:40 -0800 (PST), Mike wrote:

> On Jan 29, 4:53*pm, "nemo_outis" <(E-Mail Removed)> wrote:
>> Mike <(E-Mail Removed)> wrote innews:(E-Mail Removed):
>>
>> ...
>>
>>> LOL. Talk about overstating the case. Unless you have a particularly
>>> high opinion of yourself and think that i'm leaning too hard? This
>>> estate has been active for 20 years or so and has grown to a
>>> particular size due to integration following takovers, migration of O/
>>> Ss *etc. I'm not trying to cobble anything together I'm looking for a
>>> remote distribution of some disk encryption software which will link
>>> the hard disk to the device WITHOUT any extra hardware. Yes, risk and
>>> threat analyses have been made and the single risk/hole call it what
>>> you will is the disk itself. Not that it has any sensetive data, not
>>> that it will allow access to anything compromising but merely for the
>>> reputational risk should the disk end up on ebay and it has BANK OF
>>> XXXXX all over it. My approach is certainly fit for purpose it's just
>>> that I intend on purchasing a Mini to get me from a to b rather than a
>>> Bugatti Veyron.
>>> God I love usnet.

>>
>> A bit difficult to reconcile with your previous statement: "Mmm don't really want
>> to go the extra hardware route as there a 9000 of these beasts and that will
>> require actual man in a van visit (aside from the cost)"
>>
>> 9000 of them, eh? *and like Topsy, they just growed, eh? *Well, OK
>>
>> Risk and threat amalyses have been made, you say? *And yet it is only now, 20
>> years on, that the risk of a HD going astray or malfeasance by maintenance men is
>> noticed and ways to address the matter are being considered. *Hardly an exotic
>> risk and yet somehow it has been overlooked/ignored until now. *Let's just say I'm
>> not overwhelmed by either the timeliness or thoroughness of that risk and security
>> analysis. But better late than never, I guess (So much for timeliness - as for
>> thoroughness?)
>>
>> And now all you say you need is disk encryption. The matter of possible
>> malfeasance by maintenance men has largely disappeared. *You only need to protect
>> data at rest and not data in use? *Well, good, because the maintenance man problem
>> is non-trivial and there are no quick fixes. *
>>
>> Your explanations have now cleared things up. *Your goals are very modest and
>> limited and can be reduced to one core objective: don't let HDs (or, more
>> specifically, the data on them) go astray. *
>>
>> So here're my revised quick fixes to your problem:
>>
>> 1) Since malfeasance by maintenance men has now been discarded as an issue, put
>> out a memo to all your maintenance men establishing the policy that any "loose"
>> HDs are to be returned to headquarters and not disposed of otherwise. *While
>> you're at it, establish protocols and procedure for HD disposal at headquaters
>> (not as simple as it seems if we're talking many disks over a long period of
>> time).
>>
>> or, if you can "push" software installations to each site:
>>
>> 2) *Install any modern full-HD encrypton system. *Truecrypt is one of the better
>> ones and it's free, so, sure, use it. *
>> (And note that it won't be a trivial matter to manage the logistics of that
>> "push" to ensure nothing is missed, no old hardware hangs, and no equipment does
>> "strange" things. *Or to establsh a backup procedure for data recovery, etc. But
>> then again there's no need for me to go into all this - after all, you've already
>> done a risk and threat analysis, right?)
>>
>> And that's it. *A cheap, easy and quick fix. Just don't kid yourself that you've
>> "solved" the problem of data security.
>>
>> However, if you wish to do more than put a band-aid on the problem, let me suggest
>> that a budget of $10-100 per machine for retrofitting real security would hardly
>> be extravagant or lavish - it would, in fact, be a "bargain basement" approach. *
>> IOW, a real security review and refurbishment applied to a 9000-unit hodge-podge
>> system developed incrementally over 20 years could well cost hundreds of thousands
>> of dollars. *And I suggest that a goodly chunk of that cost be expended on a
>> qualified security consultant. *While you're at it, some input from a specialist
>> in business processes and procedures would also not be amiss.
>>
>> Regards,
>>
>> PS *Implementing security on a dispersed 9000-unit system is very different from
>> encrypting one or two drives on a home system. *The scale introduces a
>> *qualitative,* not just a quantitative, change in the nature of the problem. *
>>
>> Hell, it takes a lot of coordination and effort to push out a lousy Windows patch
>> to *thousands of machines at a single company site - companies must put
>> considerable effort into making sure there are no foul-ups on gaps. *And your
>> problem, even in its most reduced form as you've now restated it, is considerably
>> more difficult. *I suggest you ponder this well before you rely on your cheap and
>> easy encryption quickfix.

>
> Thanks for your suggestions.
> No thanks for your boorish attitude and presumption that I'm a
> complete arse.


Mike, nemo is a very bright guy but any argument you will have with him
will, ultimately, without any chance of deviance, end up with him going
ballistic, his becoming personal and insulting. Expect the "troll"
moniker to come out before the month is over.

As he has aged, he has more and more trouble keeping up with thread
flow.

If you need to swat him, do as I do. Drop hints about his wife, Nepal,
macaroni and sit tight while he goes into orbit.

It's fun to watch but anyway, carry on...
--
A fireside chat not with Ari!
http://tr.im/holj
Motto: Live To Spooge It!
 
Reply With Quote
 
Mike
Guest
Posts: n/a
 
      02-01-2010
On Jan 30, 8:20*pm, ♥Ari ♥ <(E-Mail Removed)> wrote:
> On Fri, 29 Jan 2010 11:47:40 -0800 (PST), Mike wrote:
> > On Jan 29, 4:53*pm, "nemo_outis" <(E-Mail Removed)> wrote:
> >> Mike <(E-Mail Removed)> wrote innews:(E-Mail Removed):

>
> >> ...

>
> >>> LOL. Talk about overstating the case. Unless you have a particularly
> >>> high opinion of yourself and think that i'm leaning too hard? This
> >>> estate has been active for 20 years or so and has grown to a
> >>> particular size due to integration following takovers, migration of O/
> >>> Ss *etc. I'm not trying to cobble anything together I'm looking for a
> >>> remote distribution of some disk encryption software which will link
> >>> the hard disk to the device WITHOUT any extra hardware. Yes, risk and
> >>> threat analyses have been made and the single risk/hole call it what
> >>> you will is the disk itself. Not that it has any sensetive data, not
> >>> that it will allow access to anything compromising but merely for the
> >>> reputational risk should the disk end up on ebay and it has BANK OF
> >>> XXXXX all over it. My approach is certainly fit for purpose it's just
> >>> that I intend on purchasing a Mini to get me from a to b rather than a
> >>> Bugatti Veyron.
> >>> God I love usnet.

>
> >> A bit difficult to reconcile with your previous statement: "Mmm don't really want
> >> to go the extra hardware route as there a 9000 of these beasts and that will
> >> require actual man in a van visit (aside from the cost)"

>
> >> 9000 of them, eh? *and like Topsy, they just growed, eh? *Well, OK

>
> >> Risk and threat amalyses have been made, you say? *And yet it is only now, 20
> >> years on, that the risk of a HD going astray or malfeasance by maintenance men is
> >> noticed and ways to address the matter are being considered. *Hardly an exotic
> >> risk and yet somehow it has been overlooked/ignored until now. *Let's just say I'm
> >> not overwhelmed by either the timeliness or thoroughness of that risk and security
> >> analysis. But better late than never, I guess (So much for timeliness - as for
> >> thoroughness?)

>
> >> And now all you say you need is disk encryption. The matter of possible
> >> malfeasance by maintenance men has largely disappeared. *You only need to protect
> >> data at rest and not data in use? *Well, good, because the maintenance man problem
> >> is non-trivial and there are no quick fixes. *

>
> >> Your explanations have now cleared things up. *Your goals are very modest and
> >> limited and can be reduced to one core objective: don't let HDs (or, more
> >> specifically, the data on them) go astray. *

>
> >> So here're my revised quick fixes to your problem:

>
> >> 1) Since malfeasance by maintenance men has now been discarded as an issue, put
> >> out a memo to all your maintenance men establishing the policy that any "loose"
> >> HDs are to be returned to headquarters and not disposed of otherwise. *While
> >> you're at it, establish protocols and procedure for HD disposal at headquaters
> >> (not as simple as it seems if we're talking many disks over a long period of
> >> time).

>
> >> or, if you can "push" software installations to each site:

>
> >> 2) *Install any modern full-HD encrypton system. *Truecrypt is one of the better
> >> ones and it's free, so, sure, use it. *
> >> (And note that it won't be a trivial matter to manage the logistics of that
> >> "push" to ensure nothing is missed, no old hardware hangs, and no equipment does
> >> "strange" things. *Or to establsh a backup procedure for data recovery, etc. But
> >> then again there's no need for me to go into all this - after all, you've already
> >> done a risk and threat analysis, right?)

>
> >> And that's it. *A cheap, easy and quick fix. Just don't kid yourself that you've
> >> "solved" the problem of data security.

>
> >> However, if you wish to do more than put a band-aid on the problem, let me suggest
> >> that a budget of $10-100 per machine for retrofitting real security would hardly
> >> be extravagant or lavish - it would, in fact, be a "bargain basement" approach. *
> >> IOW, a real security review and refurbishment applied to a 9000-unit hodge-podge
> >> system developed incrementally over 20 years could well cost hundreds of thousands
> >> of dollars. *And I suggest that a goodly chunk of that cost be expended on a
> >> qualified security consultant. *While you're at it, some input from a specialist
> >> in business processes and procedures would also not be amiss.

>
> >> Regards,

>
> >> PS *Implementing security on a dispersed 9000-unit system is very different from
> >> encrypting one or two drives on a home system. *The scale introduces a
> >> *qualitative,* not just a quantitative, change in the nature of the problem. *

>
> >> Hell, it takes a lot of coordination and effort to push out a lousy Windows patch
> >> to *thousands of machines at a single company site - companies must put
> >> considerable effort into making sure there are no foul-ups on gaps. *And your
> >> problem, even in its most reduced form as you've now restated it, is considerably
> >> more difficult. *I suggest you ponder this well before you rely on your cheap and
> >> easy encryption quickfix.

>
> > Thanks for your suggestions.
> > No thanks for your boorish attitude and presumption that I'm a
> > complete arse.

>
> Mike, nemo is a very bright guy but any argument you will have with him
> will, ultimately, without any chance of deviance, end up with him going
> ballistic, his becoming personal and insulting. Expect the "troll"
> moniker to come out before the month is over.
>
> As he has aged, he has more and more trouble keeping up with thread
> flow.
>
> If you need to swat him, do as I do. Drop hints about his wife, Nepal,
> macaroni and sit tight while he goes into orbit.
>
> It's fun to watch but anyway, carry on...



 
Reply With Quote
 
Mike
Guest
Posts: n/a
 
      02-01-2010
On Jan 29, 9:32*pm, "nemo_outis" <(E-Mail Removed)> wrote:
> Mike <(E-Mail Removed)> wrote innews:(E-Mail Removed):
>
> ...
>
> > LOL.

>
> I see both Mike and I are amused by his truculence and stupidity.
>
> So, moving on, I will instead provide some additional comments for those less
> impervious to common sense than Mike.


Who are you lecturing to? Where is your audience?

> I spoke in previous posts of possibly using Truecrypt for Mike's 9000 endpoints. *
> While conceivable, this would likely be a bad idea.


Who said I wanted to use Truecrypt?

> Not because of any inherent weakness in Truecrypt's encryption, but rather because
> Truecrypt is primarily designed for use on a onesy-twosy basis. *Large-scale
> corporate deployments (let alone wide-scale *dispersed* corporate deployments)
> *require* administrative and management functions - these are provided by the
> "enterprise" (or similarly named) versions of major HD-encryption vendors..


Who said I wasn't talking to enterprise vendors?

> What is needed are key-management methods (including generation, tracking,
> revocation, replacement, etc.), audit trails and compliance reporting, policy
> management, role management, and similar features as found in products from those
> such as Winmagic and Utimaco. *Truecrypt has none of this.


Agreed. Who said I wanted Truecrypt?

> Imagine that old Bill, the maintainer of the Northwest district has just retired,
> quit, or been fired. *Ordinary prudence and due diligence (no aspersions on old
> Bill's honesty) require that you change the keys on all machines (say 261 of them)
> to which he had access. *But which 261? *Or is it 273? *(You don't want to forget
> the 12 units he was temporarily responsible for when old Jack was sick last week)
> And are you going to do the 261 key changes manually? * And who exactly is going
> to make this change to the system. *And how are you going to be sure you didn't
> accidentally miss something and that all the changes were done right? And which
> lower-level managers need to have access to those same keys (or a higher level
> "pass" key)? *And is there a vendor to provide support for this system, including
> managing periodic patches and upgrades? *And on and on...


Your ability to surmise is exceptional.

> No, it would be lunacy of the first order (lunacy no imaginary "cost savings"
> could justify) to try to do all this manually with something like Truecrypt. *A
> management system is needed. *And it would generally be inefficient, unsafe, and
> costly for the bank to try to develop such a crypto management system on its own
> (especially without qualified crypto staff). *


Again, who said I wanted Truecrypt?
We have crypto systems of our own, fully developed and fully staffed.
Who said we didn't?

> So what is needed is an "enterprise" crypto system. *And that costs money. *Say,
> arguendo, $50 a unit - total cost for 9000 of them pushing half a million dollars!
>
> So before you go this route you might (Mike wouldn't, but *you* might) want to
> drop, say, $50,000 on a real security study by real professionals (not just by
> Mike as supported by alt.computer.security) to see if this is the right way to
> proceed or if you should be doing something different or additional.
>
> Regards,
>
> PS *There are also a number of other issues along these lines, but one example
> should be sufficient illustration of the principle for all but the terminally
> thick - like Mike.


Well done sir. You've decision on my behalf, told me what I want, told
me what package I've selected, told me I've forgotten all sorts of
basic, elemental considerations for a large scale distribution of
security protocols. Based on what? You're own high opinion of yourself
and the opinion that I'm an imbecile. I have the distinct impression
that should anyone else read any of this thread that one persons
shortcomings will be brought into sharp relief.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Which hard drive encryption program has the strongest tested encryption & security? =?iso-8859-1?Q?-=3D|__=28=BAL=BA=29__|=3D-____o=3D=5B:::::::::::::::=BB?= Computer Security 6 02-20-2008 01:35 PM
Remote Assistance fails to connect, remote remote host name could not be resolved Peter Sale Wireless Networking 1 12-11-2004 09:09 PM
REQ INFORMATION: Disk Encryption, free, small (see body) fluk Computer Security 1 10-06-2003 04:10 PM
CompuSec Disk Encryption fluk Computer Security 0 09-28-2003 05:02 AM
Whole disk encryption advice needed ayosha Computer Security 1 09-02-2003 11:56 AM



Advertisments