Disk Encryption for remote XP machines.

Discussion in 'Computer Security' started by Mike, Jan 27, 2010.

  1. Mike

    Mike Guest

    Hi
    I'm trying to get around a particularly thorny issue of how to
    authenticate an encrypted disk instead of using a password or token.
    Remote machines need to be able to reboot and startup (autologon)
    without any user input or extra token hardware. I'd like to be able to
    somehow tie the authentication to the actual device (CPU id?) or
    network that the PC sits on. If the disk is removed from the device
    (and hence the network) it should remain unreadable as a boot device
    or using an external housing. The disk does not need to be recovered
    and is essentially a dispoable item.
    Any ideas? Suggestions?

    Thanks
    Mike
     
    Mike, Jan 27, 2010
    #1
    1. Advertising

  2. Mike

    Regis Guest

    Mike <> writes:
    > Hi
    > I'm trying to get around a particularly thorny issue of how to
    > authenticate an encrypted disk instead of using a password or token.
    > Remote machines need to be able to reboot and startup (autologon)
    > without any user input or extra token hardware. I'd like to be able to
    > somehow tie the authentication to the actual device (CPU id?) or
    > network that the PC sits on. If the disk is removed from the device
    > (and hence the network) it should remain unreadable as a boot device
    > or using an external housing. The disk does not need to be recovered
    > and is essentially a dispoable item.
    > Any ideas? Suggestions?


    Tis an interesting problem. I'm not aware of a solution that's out
    there. True Crypt is open source, though, so rolling your own I
    assume would be allowed. http://www.truecrypt.org/downloads2


    But I'm curious though what situation there is where this security
    model makes a lot of sense though.

    If the disk gets stolen and you want to be protected by disk
    encryption, that's all well and good, but I'm trying to envision a
    situation where a disk getting stolen is possible/likely, but the
    entire machine getting picked up and taken away is not.
     
    Regis, Jan 27, 2010
    #2
    1. Advertising

  3. Mike

    Mike Guest

    On Jan 27, 2:26 pm, Regis <> wrote:
    > Mike <> writes:
    > > Hi
    > > I'm trying to get around a particularly thorny issue of how to
    > > authenticate an encrypted disk instead of using a password or token.
    > > Remote machines need to be able to reboot and startup (autologon)
    > > without any user input or extra token hardware. I'd like to be able to
    > > somehow tie the authentication to the actual device (CPU id?) or
    > > network that the PC sits on. If the disk is removed from the device
    > > (and hence the network) it should remain unreadable as a boot device
    > > or using an external housing. The disk does not need to be recovered
    > > and is essentially a dispoable item.
    > > Any ideas? Suggestions?

    >
    > Tis an interesting problem. I'm not aware of a solution that's out
    > there.  True Crypt is open source, though, so rolling your own I
    > assume would be allowed.  http://www.truecrypt.org/downloads2


    Thanks, I'll take a look.

    > But I'm curious though what situation there is where this security
    > model makes a lot of sense though.
    >
    > If the disk gets stolen and you want to be protected by disk
    > encryption, that's all well and good, but I'm trying to envision a
    > situation where a disk getting stolen is possible/likely, but the
    > entire machine getting picked up and taken away is not.


    Without wanting to give too much away it's a PC encapsulated in a Safe
    which is bolted to the floor. Used by many 'customers' and card
    activated in order to perform certain financial transactions (can you
    guess what it is yet?).
    If an engineer visits to perform an upgrade or repair this is often
    acheived by a disk swap, and the old disk may be 'lost' by the
    engineer.
     
    Mike, Jan 27, 2010
    #3
  4. Mike

    Regis Guest

    Mike <> writes:

    > Without wanting to give too much away it's a PC encapsulated in a Safe
    > which is bolted to the floor. Used by many 'customers' and card
    > activated in order to perform certain financial transactions (can you
    > guess what it is yet?).
    > If an engineer visits to perform an upgrade or repair this is often
    > acheived by a disk swap, and the old disk may be 'lost' by the
    > engineer.


    Ah ha. In that case indeed, strong physical secrity is in place for
    the guts of the machine. Seems like a reasonable approach.

    Of course the disk would then have to change (or its encryption) for
    swap of whatever hardware is being used to auto, but that's just
    maintenance procedure.

    Another angle is that there are libraries I think that are used by
    software vendors for license validation that key a license to a high
    priced piece of software to things like the machine's MAC address, or
    the like. I wonder if those might somehow be applicable such that
    you could at least implement folder based encryption on the drive
    using a key read off a hardware.

    I just did a little searching and found there are lots of disk
    encryption bits out there. You may want to use one that's GPL or BSD
    license depending on what the lawyers say. Lots to choose from it
    seems:

    http://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software

    DiskCryptor and CrossCrypt are aimed at XP and have GPL
    licenses. DiskCryptor is the only one of the 2 being maintained
    however.

    Good luck with the project! Sounds like fun.
     
    Regis, Jan 27, 2010
    #4
  5. Mike

    nemo_outis Guest

    Mike <> wrote in news:ee529650-0f9c-45d4-8d24-ad84aead8d63
    @k41g2000yqm.googlegroups.com:

    > Any ideas? Suggestions?


    Yes, but in the unforgettable words of Deep Thought, "Though I don't think that
    you're going to like it."

    Bitlocker and a TPM which holds the keys. The TPM provides "platform
    authentication." The paranoid will ensure that the the TPM is integral with the
    motherboard (i.e., soldered on) or take steps to make it so (e.g., epoxy, etc.).
    Only a few MBs have integral TPMs or risers for separate TPMs, however.

    A Rube Goldberg version of this can be done with Truecrypt and an Aladdin eToken
    epoxied to a USB port directly on the MB (many MBs have such right-on-the-MB USB
    ports). Additional hardening can be done by the inventive/paranoid if desired.
    Truecrypt directly supports the Aladdin USB key.

    Regards,
     
    nemo_outis, Jan 27, 2010
    #5
  6. Mike

    Mike Guest

    On Jan 27, 4:34 pm, Regis <> wrote:
    > Mike <> writes:
    > > Without wanting to give too much away it's a PC encapsulated in a Safe
    > > which is bolted to the floor. Used by many 'customers' and card
    > > activated in order to perform certain financial transactions (can you
    > > guess what it is yet?).
    > > If an engineer visits to perform an upgrade or repair this is often
    > > acheived by a disk swap, and the old disk may be 'lost' by the
    > > engineer.

    >
    > Ah ha.   In that case indeed, strong physical secrity is in place for
    > the guts of the machine.  Seems like a reasonable approach.  
    >
    > Of course the disk would then have to change (or its encryption) for
    > swap of whatever hardware is being used to auto, but that's just
    > maintenance procedure.  
    >
    > Another angle is that there are libraries I think that are used by
    > software vendors for license validation that key a license to a high
    > priced piece of software to things like the machine's MAC address, or
    > the like.    I wonder if those might somehow be applicable such that
    > you could at least implement folder based encryption on the drive
    > using a key read off a hardware.
    >
    > I just did a little searching and found there are lots of disk
    > encryption bits out there.  You may want to use one that's GPL or BSD
    > license depending on what the lawyers say.  Lots to choose from it
    > seems:
    >
    > http://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software
    >
    > DiskCryptor and CrossCrypt are aimed at XP and have GPL
    > licenses. DiskCryptor is the only one of the 2 being maintained
    > however.
    >
    > Good luck with the project!  Sounds like fun.


    Thanks Regis. Appreciate your input.
     
    Mike, Jan 28, 2010
    #6
  7. Mike

    Mike Guest

    On Jan 27, 5:09 pm, "nemo_outis" <> wrote:
    > Mike <> wrote in news:ee529650-0f9c-45d4-8d24-ad84aead8d63
    > @k41g2000yqm.googlegroups.com:
    >
    > > Any ideas? Suggestions?

    >
    > Yes, but in the unforgettable words of Deep Thought, "Though I don't think that
    > you're going to like it."
    >
    > Bitlocker and a TPM which holds the keys.  The TPM provides "platform
    > authentication."  The paranoid will ensure that the the TPM is integral with the
    > motherboard (i.e., soldered on) or take steps to make it so (e.g., epoxy, etc.).  
    > Only a few MBs have integral TPMs or risers for separate TPMs, however.
    >
    > A Rube Goldberg version of this can be done with Truecrypt and an Aladdin eToken
    > epoxied to a USB port directly on the MB (many MBs have such right-on-the-MB USB
    > ports).  Additional hardening can be done by the inventive/paranoid if desired.
    > Truecrypt directly supports the Aladdin USB key.
    >
    > Regards,


    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)
    I will investigate further though. Thanks
     
    Mike, Jan 28, 2010
    #7
  8. Mike

    nemo_outis Guest

    Mike <> wrote in
    news::

    > 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)
    > I will investigate further though. Thanks


    The problem is this: using ad hoc identifiers (e.g., motherboard serial number or
    some such) is a very weak way of authenticating a platform, one which is easily
    bypassed or subverted. Hell, even the integral TPM method, while better, is still
    pretty weak. Put these in the category of "only keeping honest people honest"
    (comparable to a $5 padlock you can buy at the local hardware store).

    All the more so if your threat model is someone who is permitted to make
    unsupervised site visits (e.g., a maintenance man you fear might steal/swap/copy the
    drive/data). That someone (a someone who, for a period of time, has complete
    physical control of the computer) is in a position to any number of things to
    destroy your security (e.g., he can probe any line on the MB, etc.)

    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.

    Regards,
     
    nemo_outis, Jan 28, 2010
    #8
  9. Mike

    Regis Guest

    "nemo_outis" <> writes:

    > Mike <> wrote in
    > news::
    >
    >> 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)
    >> I will investigate further though. Thanks

    >
    > The problem is this: using ad hoc identifiers (e.g., motherboard serial number or
    > some such) is a very weak way of authenticating a platform, one which is easily
    > bypassed or subverted. Hell, even the integral TPM method, while better, is still
    > pretty weak. Put these in the category of "only keeping honest people honest"
    > (comparable to a $5 padlock you can buy at the local hardware store).
    >
    > All the more so if your threat model is someone who is permitted to make
    > unsupervised site visits (e.g., a maintenance man you fear might steal/swap/copy the
    > drive/data). That someone (a someone who, for a period of time, has complete
    > physical control of the computer) is in a position to any number of things to
    > destroy your security (e.g., he can probe any line on the MB, etc.)
    >
    > 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.

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

    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.

    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.
     
    Regis, Jan 28, 2010
    #9
  10. Mike

    Mike Guest

    On Jan 28, 3:51 pm, Regis <> wrote:
    > "nemo_outis" <> writes:
    > > Mike <> wrote in
    > >news::

    >
    > >> 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)
    > >> I will investigate further though. Thanks

    >
    > > The problem is this: using ad hoc identifiers (e.g., motherboard serial number or
    > > some such) is a very weak way of authenticating a platform, one which is easily
    > > bypassed or subverted.  Hell, even the integral TPM method, while better, is still
    > > pretty weak.  Put these in the category of "only keeping honest people honest"
    > > (comparable to a $5 padlock you can buy at the local hardware store).

    >
    > > All the more so if your threat model is someone who is permitted to make
    > > unsupervised site visits (e.g., a maintenance man you fear might steal/swap/copy the
    > > drive/data).  That someone (a someone who, for a period of time, has complete
    > > physical control of the computer) is in a position to any number of things to
    > > destroy your security (e.g., he can probe any line on the MB, etc.)

    >
    > > 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.  
    >
    > You whittle down the means of reading those drives to a much smaller
    > audience.
    >
    > 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.
    >
    > 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.


    The PCs are connecting to a network using VPNs, a 3DES key exchange
    process goes on next to tie the PIN pad of the machine to the Host
    system and the applications and ports are protected by an endpoint
    protection system which blocks access to the drive and USB ports for
    all but the allowed (whitelisted) items. Disk encryption is required
    to effectively render the disk unusable when it's not in the device it
    should be (THAT pc core in THAT machine). This is to prevent the
    maintenance guys from doing anything other than the prescribed process
    required once a disk is removed (bag it seal it and destroy it). So
    the misplaced hard drive is all i'm trying to cover off here.

    Thanks
    Mike
     
    Mike, Jan 28, 2010
    #10
  11. Mike

    nemo_outis Guest

    Regis <> wrote in
    news::

    ....
    >> 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,
     
    nemo_outis, Jan 29, 2010
    #11
  12. Mike

    Mike Guest

    On Jan 29, 1:49 am, "nemo_outis" <> wrote:
    > Regis <> wrote innews::
    >
    > ...
    >
    > >> 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.
     
    Mike, Jan 29, 2010
    #12
  13. Mike

    nemo_outis Guest

    Mike <> wrote in
    news::

    ....
    > 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.
     
    nemo_outis, Jan 29, 2010
    #13
  14. Mike

    Mike Guest

    On Jan 29, 4:53 pm, "nemo_outis" <> wrote:
    > Mike <> wrote innews::
    >
    > ...
    >
    > > 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.
     
    Mike, Jan 29, 2010
    #14
  15. Mike

    nemo_outis Guest

    Mike <> wrote in
    news::

    ....
    > 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,
     
    nemo_outis, Jan 29, 2010
    #15
  16. Mike

    Mike Guest

    On Jan 29, 8:08 pm, "nemo_outis" <> wrote:
    > Mike <> wrote innews::
    >
    > ...
    >
    > > 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.
     
    Mike, Jan 29, 2010
    #16
  17. Mike

    nemo_outis Guest

    Mike <> wrote in
    news::

    ....
    > 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.
     
    nemo_outis, Jan 29, 2010
    #17
  18. On Fri, 29 Jan 2010 11:47:40 -0800 (PST), Mike wrote:

    > On Jan 29, 4:53 pm, "nemo_outis" <> wrote:
    >> Mike <> wrote innews::
    >>
    >> ...
    >>
    >>> 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!
     
    ♥Ari ♥, Jan 30, 2010
    #18
  19. Mike

    Mike Guest

    On Jan 30, 8:20 pm, ♥Ari ♥ <> wrote:
    > On Fri, 29 Jan 2010 11:47:40 -0800 (PST), Mike wrote:
    > > On Jan 29, 4:53 pm, "nemo_outis" <> wrote:
    > >> Mike <> wrote innews::

    >
    > >> ...

    >
    > >>> 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...


    :)
     
    Mike, Feb 1, 2010
    #19
  20. Mike

    Mike Guest

    On Jan 29, 9:32 pm, "nemo_outis" <> wrote:
    > Mike <> wrote innews::
    >
    > ...
    >
    > > 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.
     
    Mike, Feb 1, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Peter Sale
    Replies:
    1
    Views:
    12,098
    Robin Walker
    Dec 11, 2004
  2. =?iso-8859-1?Q?-=3D|__=28=BAL=BA=29__|=3D-____o=3D

    Which hard drive encryption program has the strongest tested encryption & security?

    =?iso-8859-1?Q?-=3D|__=28=BAL=BA=29__|=3D-____o=3D, Sep 24, 2004, in forum: Computer Security
    Replies:
    6
    Views:
    4,004
    Kornholio
    Feb 20, 2008
  3. Tom
    Replies:
    32
    Views:
    2,442
  4. D. Spencer Hines

    Re: FTP Client With File Encryption For Remote Backup?

    D. Spencer Hines, Feb 21, 2006, in forum: Computer Security
    Replies:
    3
    Views:
    455
    Borked Pseudo Mailed
    Feb 21, 2006
  5. Giuen
    Replies:
    0
    Views:
    1,431
    Giuen
    Sep 12, 2008
Loading...

Share This Page