"more secure" 3rd-party file sharing?

[Ben Scott]

On 8/23/06, Bill McGonigle <bill at bfccomputing.com> wrote:
>>  I know that fixing wetware makes the Microsoft patch process look
>> easy, but ultimately, it is what is needed.  No matter what you do,
>> you can't have a secure system with insecure people.  This is
>> inescapable fact.
>
> you also can't have fool-proof people.  I wonder how the TLA's handle
> this.

  Are you referring to classified information security?

  If you really want to know, much of it is documented in the NISPOM
(National Industrial Security Program Operations Manual, available
from http://www.dss.mil/isec/nispom.htm).  Along with the venerable
NSA rainbow books (http://en.wikipedia.org/wiki/Rainbow_Series).  Most
of it is really rather dull.

  On the IT side of things, it is conceptually simple.  Direct
connections to untrusted systems are not allowed.  An air gap is the
usual method.  If some kind of connectivity is a needed, a "Controlled
Interface" must be used.  The CI must be able to identify classified
information and prevent disclosure.  In other words, don't hook it up
to the Internet.

  I doubt any of that is much use to you.  :)

  The procedural side of things might be more useful to you.  Again,
not in the details, but in the concepts.  Regular briefings and
training.  Lots of logs and audit trails and accountability.  To get a
Security Clearance, you have to sign an NDA, take an oath, submit to a
background investigation.  Security Is A Big Deal.  It is treated as
an essential element, rather then a hassle.  Not the rubber stamp that
corporate security usually is, but "You will go to Federal Pound Me In
the Ass Prison if you screw off".

  If you get that kind of commitment, the human factors become
manageable.  If you lack it, you'll probably never win.  Most
organizations lack the commitment.  They reap what they sow.

>>> ... forcing all users to use PGP or S/MIME ...
>> [forcing users to use web page thingy]
>>> ... blocking outbound 25, 465, 587 at the firewall and
>>> stripping attachments at the MTA ...
>>
>>  You think you can get away with the later when you couldn't get away
>> with the former?
>
> Yeah, I can't control the recipients who would also need to run PGP or
> S/MIME in that model.

  Ah.  So you're mainly solving the problem of getting "everybody
else" to use email crypto.  I see your point.

  spaf's commentary on Internet crypto should probably come into play here.

>>  Your mail server cannot keep logs?
>
> yeah but not of who read the message where and when.

  And the SSL HTTP file transfer gets you what, exactly?  You don't
know who, or where.  You know when the file was downloaded, but not
that it was read or opened or anything.  It might have gone into the
bit bucket, for that matter.

[web file transfer thingy]
>>> ... links can be expired ...
>>
>>  True, but so what?
>
> you can limit the exposure to a single download, for instance.

  I usually only get a given email message once.  :)

[web file transfer thingy]
> reduces unintentional spread (compromised machines, nosy mail admins, etc.)

  A compromised machine is, well, compromised.  We assume the attacker
can access the files on the machine.  Does it matter if the file got
there via HTTP instead of SMTP?

  Likewise the nosy admin problem.  A nosy admin (or PHB with the root
password (or janitor with a keystroke logger dongle)) can spy on what
people do, be it email or the web.

  You're not really solving the problem, just moving it around.

> How I wish everybody had S/MIME certs stored on smartcards. :)

  ... which we assume they will hand over to the first stranger who asks, right?

-- Ben