[geeks] Gmail's attraction

[Mike Hebel]

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

> Yes, but then another layer has to manage it.  If Bob wants to
> send a file to Sue, why should he need to involve another department
> to do it?  Now someone has to set up an ftp account, give Bob the
> password, and then he has to put the file out there and tell
> Sue to go look for it.

So.  That to me goes under the realm of educating users on how to use 
their systems.
As for another layer - there's probably a way to take the username list 
from a Windows network and map it onto the ftp users.  Heck if you're 
using Active Duh-rectory and IIS the name is already there as part of 
the domain structure.

>> As for FTP servers signed on/off by security auditors - that's a
>> "security management issue" not a technical one.
>
> Security management is just as valid a concern as technical ones.

Yes but we're talking technical here.  And having another group manage 
your security instead of you is a "management"/sphere of 
influence/department pissing ground 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.
>
> How can you know that without knowing the company's needs?  If they're
> using one of those horrid email systems like Notes or Exchange, they
> handle file transfers within the company just fine.  Even for [more]
> standardized email systems, file transfer is RFC supported.

The answer is to not be using one of "those horrid email systems".
And if your user is too untrained to save or copy a file onto a network 
share then they need more education or less responsibility.

>> 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.
>
> Don't you get tired of LARTing them?

I'm proud to say that once proper education is put upon said users they 
have to be LARTed very little.  Some of them even make me proud 
sometimes.  "So and so wanted me to send these huge drawings by e-mail 
but since he's in $division and not outside the company I just walked 
him through mapping a drive to the public share and put them there."

>> 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.
>
> I admire your goal, and it used to be my goal, but I'm not as
> idealistic as I used to be.  Too many PHB's I guess.

PHBs matter very little to me.  They have specific, though insane, 
goals.  Once these goals are met and they see "progress" they often 
don't give a damn what else you do.
I'm serious here - I've had several PHBs in my working life and not one 
of them was unsatisfied with my work.  After a while they learned to 
leave me alone so I could work.
Even if they didn't I always had something I could show them as 
progress.

>> 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.
>
> All of our internal servers store user mail and transfer it between
> servers in an encrypted form, everything is logged, and receipts
> are never stripped.  It's been fully audited and signed off on
> as a secure method for an employee to send a confidential file
> to another employee.

That's fine for you internally but you can only guarantee one side of 
an e-mail transfer is secure outside the company.  Period.  I don't 
care if you encrypt anything.  Though encryption solves a lot of issues 
and makes it as secure as possible.  And note when I previously said 
_all e-mail_ was encrypted I was talking about both sides of the 
connection.  Impossible to guarantee.  There's _always_ a way to 
breach.  There is simply almost no way to make e-mail secure enough for 
me to accept it as a file transfer mechanism.

>> 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.
>
> Yes, it does suck, the budget is tight, and none of us really wants to
> take on another full time set of duties.  If you'd like to volunteer
> your services, great.

http:///www.geekfinder.com - You can probably find some young PFY to do 
that sort of stuff for very little money.  I don't see budget as an 
excuse.  If you need someone you need someone.  Period.  If you can't 
hire and IT guy then hire a "data entry" person.  If you can't hire a 
"data entry" person then hire a "cleaning" person.  There's always ways 
to deal with a budget issue if you're creative.  I once bought a whole 
server in parts because we didn't have the budget to buy one complete.

>> 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.
>
> We haven't lost a sysadmin yet.  Some of us shoot back.

Good for you!  Now find a different line of work.  Really.  Or at least 
a customer that doesn't require you working under such stress.  It's 
not worth it.  Life is more important than that.

>>>>> 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.
>
> Since security is part of the discussion, assuming email is virus
> scanned seems like a valid assumption.  If we don't assume that,
> why do we care at all about any level of security in file transfers?

You brought up the security of e-mail in discussion not me.  You 
claimed that it was more secure than a file transfer protocol.  It is 
not.

And as for the scanning thing - again you only have control of one side 
of the equation here.  There's no guarantee that the other server isn't 
doing something malicious.

> Just stick it out on gnutella and hope they'll pick it up.

That's not a valid IT solution to even suggest and you know it.
Stick to the argument of I slap you around with a dead trout.  ;-)

>>> 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.
>
> Email within a company can be secure and traceable.

I call bullshit here.  There are a metric assload of ways to forge 
e-mail even with secure sender lists, cross checking, etc.  The whole 
concept of e-mail is for _delivery_ and _propigation_ thus securing it 
and monitoring it goes against it's grain.  This is why there is so 
much crap being redesigned due to spammers.  You're too good not to 
know this.

>>> How many SMTP servers does it pass inside the company?
>>
>> Exactly why it's not a realistically trackable option.  Too many
>> variables.
>
> Email within a company can be secure and traceable.

See above post.

>>> 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.
>
> Here, I'll let you answer this one yourself:
> "If the sending server is logging.  If the receiving server is 
> logging."

Again, you're forgetting that outside the company you only have control 
of _ONE_ side of the equation.  Once it leaves your network you have no 
guarantees that it will even reach it's destination much less be secure 
in transit.

>> 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.
>
> With FTP, they don't need to intercept the file in transit.  They
> can just sniff for the password and then go in and get the file
> and any other files sitting in there as well.

FTP was the example that was originally given - SFTP is much better.

> But when I email a file, there's no password to sniff.  They'd
> have to sniff the entire file in transit, which might be made
> even more difficult by other email passing through at the same time.

No they don't.  They just have to hijack the receiving domain then the 
mail goes to them.  Either that or compromise something close upstream 
and re-route your packets to them instead of anywhere else for a minute 
or two.  You think a minute of "Internet down time" is going to be 
missed?  You think that's air you're breathing?

> This becomes even more difficult if the company is using an
> internal email system where the entire path from a user's client
> to the server to the other user's client can be encrypted.

Fair enough but once it leaves the company you have 0, zero, nada, zip, 
zilch control over where it goes or who it ends up with.

>> Again, training users is not a bad thing.
>
> It's not a bad thing, but it may not be feasible all the time.
> You can't smack users around when they're in another city.  I've
> tried.

*sigh*  Sit on hell desk for a few years and then call me.  It's as 
simple as pie to walk a problem user through a solution on the phone as 
long as you have patience and a little imagination.  BOFH is a fantasy 
not a reality.  In the decade and a half I've been doing IT work there 
has only been two users that I could not handle.  The first one was 
early on and was handicapped so bad that I could not understand him.  
The second one was a user who was mis-trained into thinking he knew 
more than he did and would reverse any changes I had him make to get 
his notebook running.  After a couple times of this I got his ass fired 
for misusing the equipment.  (Frankly he was going to get fired anyway 
but I gave them the excuse.)

>> 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.
>
> I know.  It's very sad.  Wait, were we talking about using computers
> or cars?

Both.  The situation is the same.  You're supposed to have 1000 hours 
in a car in the state of Illinois but most people only get 100.  And 
never by a professional teacher.  Computers you don't even often get 
any instruction.

>>> 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.
>
> That depends on the company.

It depends on you.  The situation above is a static.  It will always 
cost you more in lost time to _not_ educate your users.  Period.

>> It is my job as an IT person to make sure people can and do function
>> efficiently on their systems.  That means training.
>
> On what scale?  Do you really want to train 20,000 people in several
> countries to use a new tool that isn't installed yet when they
> already know how to use a system that is in place and does the job
> quite well?

If they wish to continue being able to send files yes.  Educate that 
group and remove the ability to e-mail files and you cut down on a 
great many virii, worms, spyware, etc.

>>> 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.
>
> Nice if the company is nearby.

FedEx delivers overnight.  I've never had to have a "same day" resume 
request.  I never take a job based on one day of decision.  It's just 
too risky a thing to do with the future of my family and myself.

>> 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 choice.  Some of us like to eat.

I've worked suit infested waters too and I can tell you that _any_ job 
would have been better.  I still have current suit problems but I made 
sure that the division of $company I work for knows how valuable I am.  
$General_Manger of $division keeps suits out of my hair so I can work.

>> 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.
>
> Both are true in some companies, and in those situations email
> is the defacto tool for the job.

No.  Those companies are BROKEN and need to be REPAIRED.  If you don't 
do it then somebody else has to or they will crumble to the ground 
under their own ineptitude.  Perhaps that's what needs to be allowed to 
happen...

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