RE: Worms, Air Gaps and Responsibility

["Victor Williams" <vbwilliams () essvote net>]

I don't understand this point of view:

"Ah. Let me step through this ;>

You've got [for the sake of arguement] a home computer, connected to the
Internet via a cable modem.

The user starts up a thin client, which connects to their employer.

At this point in time, you've got a connection to the Internet, and a
connection to the employer.  There is no separation of priveledge here. You
have what is supposed to be a "secure" connection feeding data from the
employer co-existing with an "insecure" connection - the Internet.

This is, by definition, not a good thing."


A true thin-client, the definition I've come to accept/understand, gets its
data/configuration/whatever from the server serving it...ala X-terminals.
Regardless of what happens, if the server/thin-client architecture is
deployed correctly (which is a very EASY thing to do nowadays if you can
read), the client cannot do anything to the server.  The client is seeing
what is happening on the server and interacting that way.  Nothing that goes
on on the client-end (what the client is seeing) is happening locally.  I
don't understand why anyone would have an issue with that architecture.  If
money's not an object, that's my optimum deployment strategy...but that's
the problem from my point of view...money.  In the Windows world--which is
what all dumb users understand--you've got a LOT of costs to deploy that
architecture.  I would LOVE for a large chunk of my enterprise that I manage
to be deployed this way.  It gives me absolute control over the environment.
But I think the financials are the barrier there...not the
practicality/security of the architecture.

I remember about 8 years back I was the administrator for a gov't network
with a lot of engineers who used GIS software served by HPUX to HP X
terminals.  It was the absolute easiest thing to administer from every
aspect.  There was no floppy drive access.  The data came from a direct
download from another *trusted* gov't agency.  Internet access wasn't an
issue then as bandwidth was rather expensive and all data that anyone needed
to work with was already on the system.  I think that's the goal of the
thin-client architecture.  Everything you need is already there.  There is
no reason to have to inject your own *stuff* into the system.  This is how
accounting and mission-critical business programs are handled in the company
I'm currently at.  Funny thing, those are the only systems that have never
been negatively affected by any worms, bugs, etc in the 3+ years I've been
there.  The thin-client is delivered to the PC over the network...but the PC
can't modify it in any way...works well in my opinion.


 
Victor Williams 


-----Original Message-----
From: firewall-wizards-admin () honor icsalabs com
[mailto:firewall-wizards-admin () honor icsalabs com] On Behalf Of Gwendolynn
ferch Elydyr
Sent: Monday, May 10, 2004 3:52 PM
To: Mike McNutt
Cc: Mason Schmitt; firewall-wizards () honor icsalabs com
Subject: RE: [fw-wiz] Worms, Air Gaps and Responsibility


On Mon, 10 May 2004, Mike McNutt wrote:
> > > A recent SANS webcast talked about using true thin client
> > hardware or
> > > terminal server clients (and equivalents such as citrix, X, etc) 
> > > for providing remote users or risky users access to document 
> > > stores, and other LAN resources.  I think that using a thin client 
> > > as a security tool is a great idea.
> >
> > Heh. What do they say? "Everything old is new again"?
> >
> > For the terminal server hardware, I've got a bit less to say [but 
> > are you -sure- where that image came from?] - but in the case of the
>
> Are you suggesting that someone/something can hijack a thin-client 
> connection and provide [accurate-in-terms-of-user-interaction] *false* 
> images of the remote system?  Wow.  Never actually thought of that, 
> myself.  At first glimpse, the effort seems daunting (but I guess 
> anything is possible).

Wow, no!  What I was talking about was thin client hardware. Most of it gets
an OS image from somewhere - and depending on where and how it obtains that
image, there's the standard problem of "how do I trust that what this
machine has been loaded with is appropriate".

> > software thin clients, you're -still- running on a platform with 
> > unknown security, and reaching into the enterprise.
>
> Care to expand on: "running on a platform with unknown security"?   Are
> you talking about the thin-client "client application" itself?

If you have a user running a thin client on their home desktop, you have a
platform whose security is unknown to you.

> > Thin clients also
> > don't address the question of having a box with a live connection to 
> > the Internet and your enterprise - it just moves it around.
>
> What exactly is the "question" related to having a box on the Internet 
> that you are referring to?  It sounds like you are poo-pooing remote 
> users' use of the Internet for connectivity to the office because the 
> office has to maintain a connection to the Internet...  Is that bad?  
> Or is it *potentially* bad?

Ah. Let me step through this ;>

You've got [for the sake of arguement] a home computer, connected to the
Internet via a cable modem.

The user starts up a thin client, which connects to their employer.

At this point in time, you've got a connection to the Internet, and a
connection to the employer.  There is no separation of priveledge here. You
have what is supposed to be a "secure" connection feeding data from the
employer co-existing with an "insecure" connection - the Internet.

This is, by definition, not a good thing.

> ... Which puts the resolution back in the hands of the administrator, 
> so he/she at least has a chance of addressing/rectifying the problem.  
> I'll take that headache any day over the headche of 
> reviewing/patching/protecting my systems from the infected ones.  Not 
> like there is actually a choice, though.

It just swings back and forth *shrug* There are arguements to be made for
thin and thick clients [but not thick users ;>] - but I think you'd find
that it's all about shifting problems around, not solving them.

> I don't understand what point you are trying to make here; thin 
> clients like Citrix or TS (I can't speak to X) certainly have a 
> productive role for remote users and currently offer some real 
> advantages over security concerns of other approaches.  It's the 
> functionality vs. security arguement; you must assess the risk before 
> making your choice, and thin-clients provide an awful lot of 
> functionality for the security risk.

The point that I'm trying to make really boils down to "policy, not
technology".  The niftiest piece of tech in the world doesn't make a bit of
difference if it's set up poorly - or the local policy says "allow
everything".

Further, although there are uses for thin clients, they're not a panacea for
all woes.  I would be interested in seeing your particular arguements in
favour of thin clients, though ;>

cheers!
==========================================================================
"A cat spends her life conflicted between a deep, passionate and profound
desire for fish and an equally deep, passionate and profound desire to avoid
getting wet.  This is the defining metaphor of my life right now."

_______________________________________________
firewall-wizards mailing list firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards