[geeks] Gmail's attraction

[Mike Hebel]

On Sunday, September 5, 2004, at 05:01 PM, Dan Duncan wrote:

> On Sun, 5 Sep 2004, Jonathan C. Patschke wrote:
>> You give them separate accounts.  Proftpd makes this -easy-.  I'd 
>> assume
>> there's some widget for 'doze that's equally simple.
>
> Now you have users managing individual ftp servers and
> expecting them to manage security, and a requirement to use
> two different applications to send a file to a user (since I assume
> they will also be sending an email telling them to get the file)
> and now of course we have to make sure whatever ftp server we
> choose is available and signed off on by security auditors.

Yes.  And I would do the same.  If we're talking Windows look at a 
program called WS-FTP.  It has an Explorer interface that "just works". 
  You set it for the corporate server for a particular username and they 
drag and drop files to it.  It asks for a password then transfers the 
file.

As for FTP servers signed on/off by security auditors - that's a 
"security management issue" not a technical one.  Don't confuse having 
tight "managed" security with misuse of an improper tool.  Ftp and it's 
ilk are the right tool for the right job.  E-Mail is not.

>>> Do you have that ability as a mere user, or does it require admin
>>> privs?
>>
>> If you have "Power User" access to your workstation, you can share
>> folders.  Most users have "Power User" access to placate them in that
>> they can change the date and such.
>
> When you expand user permissions, you increase the security risks.

This is why education of users is important.  With more access comes 
more responsibility.  If they can't handle that then they have to ask 
someone else to send the file.

I know I'm going to get flamed here for "educating" users but I won't 
do it any other way.  The only reason I can get things done efficiently 
at any IT position I hold is because my user base is educated to handle 
certain issues - most of them common sense.

>>> How about letting mere users share out what may be privileged data
>>> in a manner with NO AUDIT TRAIL WHATSOEVER?
>>
>> EMail does not solve this.  Does your company keep records of every
>> single attachment that flies over the wire (not just the filename, but
>> the contents, as filenames can easily be forged)?
>
> I can't answer that question, but email with files attached is no
> different than emails containing sensitive information inside, and
> presumably there is already a mechanism in place to audit it.

If the sending server is logging.  If the receiving server is logging.  
If neither server strips receipts for some reason.  As for sensitive 
data internal to the message - that should be encrypted if it's going 
by e-mail at all.  If all e-mail were being encrypted I could accept 
your argument but that's obviously not true.

>> And you -CAN- enforce
>> share-level audting as part of the domain policy.
>
> True, but it creates a flood of logs and requires someone to audit 
> them.

So.  That means you employ one more person to do log auditing.  No harm 
in having another person.  The job market for IT people still sucks if 
I recall.  Give a fellow Geek a job.

>>> Perhaps you've never had the pleasure of having security auditors
>>> crawling up your ass in a corporate environment,
>>
>> I'll one-up you.  I've been there in a -government environment-, one
>> that has to goosestep by HIPAA.
>
> Then you know how they feel about audit trails.  My last security
> audit was by the Dept of Energy in a company that operates
> nuclear power plants in a post 9/11 environment.  The data center
> is guarded by personnel with fully automatic weapons.  Wheee!

Time to change jobs.  I'm serious here.  You should never be under 
threat of life while doing a job unless the job is inherently 
life-threatening.  IT shouldn't have the same potential hazard as say 
underwater welding.

>> If the file's Large, it's horribly inefficient.  That 30% bloat 
>> doesn't
>> help anyone, and a good number of gateways will tell you to stuff
>> anything over 4MB up your backside.
>
> True.

Some are still at low as 1meg.


>>> You get a virus scan,
>>
>> Oh, that's part of RFC 2822 now?  I must've missed that part.
>
> Do you really propose a company not do virus scans on attachments?

No.  What he's saying is that it's an added thing and not done in 
nearly enough environments because it's not an inherent part of sending 
e-mail.  Though you are half right that it should now be a part by 
design.

> Why are we even bothering to discuss security?

Because you claimed that e-mail was secure and traceable.  It is not.  
At least not reliably so.

>>> a delivery receipt, and a reasonable assurance that someone who
>>> shouldn't have it didn't get it from you along with an auditable
>>> paper trail.
>>
>> All of which can be forged.  Easily.  Never mind that the file is
>> passing in the clear and can be picked up at -any- SMTP server along 
>> the
>> way.
>
> How many SMTP servers does it pass inside the company?

Exactly why it's not a realistically trackable option.  Too many 
variables.

> If you're worried about passing in the clear, why propose FTP?

Because FTP is point-to-point for the most part.  On any system I've 
ever seen each transfer is logged on both sides.  Now FTP does have 
some security issues - SFTP would work better in my opinion.  There's 
truly less chance of an interception though between a unpredicted file 
transfer versus an e-mail server that you always have traffic on.

>>>> And Windows is the standard OS.  That doesn't mean it's worth a 
>>>> crap.
>>>
>>> No, but since it IS the standard OS in a corporate environment you
>>> often have to work within that framework to make it as secure as
>>> possible.  Letting users share out directories on their own breaks
>>> that rule.
>>
>> No, it doesn't.  Sharing a folder saying that ONLY $user can get to 
>> it,
>> with auditing, lets you know who got the file, from where, when.  Plus
>> it's more efficient, kinder to the wire, and USING THE RIGHT TOOL FOR
>> THE JOB.
>
> And requires a lot more permissions and training for users to
> properly maintain and an additional audit trail to watch.

Again, training users is not a bad thing.

> I don't LIKE it that email has become a standard corporate method
> of file transfer any more than I like it that Windoze has become
> the corporate desktop platform, but in a given environment there
> are advantages to limiting the number of tools users need to
> work with.  Most users in a company have email and know how
> to use it.  They don't necessarily have experience with FTP
> or publishing web pages so if they need to send a file to
> someone then email has the smallest learning curve.

Limiting tools and not training users will only get you gumby users 
that cause you endless problems.  The dumber and less informed the user 
the dumber they will act.

> Is it ideal?  No, of course not, but it allows an existing tool
> with existing security to be used by users with existing knowledge,
> all of which saves time and money.

Time and money between dealing with gumby users and lost information 
and clogged e-mail far outweighs the cost in time/money training users 
to use the right tool.
It is my job as an IT person to make sure people can and do function 
efficiently on their systems.  That means training.

> Let me ask you this:  The last time you sent out a resume, how did you
> send it and why?

I sent it by hand delivery.  I did send one by e-mail and later found 
out that it was because the country was suit infested.  Needless to say 
I didn't want to work there.

Your arguments do have some merit but to me they show that you have 
fallen into the trap of "stupid users" and "I have no say in anything". 
  Neither is true by default.  And if the second is true it's time to 
find another position.

Mike
----
"I think we used too much!" - Chris Knight