Thin Client solutions

Tue Oct 25 12:15:20 PDT 2005

Regarding "At some point you have to trust that your source code is safe
with your new employees...", I would say that that won't hold water with
your employers if something goes wrong and code leaks. It is better to say,
"This failed and can be fixed to prevent future breeches" than to say, "We
thought we could trust them with the code."

They could all be your friends. They could be people you don't know. They
could be employees of some years. But what matters is that the system needs
to be secure. Maybe it isn't going to be any of the people who work with the
company now. It might be an intern. It might be that new hire your company
pulled from a competitor. It could be the janitor.

In a similar situation, I would say that it is a matter of ensuring that if
someone should want to steal your company's intellectual property, you are
going to make it as near impossible as is feasible, rather than saying you
don't trust current and future employees.

Wing.

On 10/25/05, Wing Wong <wingedpower at gmail.com> wrote:
>
>
> From Previous Post:
>
> >
> > Your points are valid and we've been thinking about them all. What I
> > am considering is a firewalled network for code development that only
> > allows connections from specific thin clients (I should be able to
> > allow only specific mac addresses to connect just like a wireless
> > node, no?). We are also considering a separate desktop for the users
> > to check email, internet access, etc. but what prevents them from
> > just taking the time to copy the data from the isolated network to
> > the other network. At some point you have to trust that your source
> > code is safe with your new employees, but I think that might be too
> > cautious of an approach.
> >
> > We'd like to limit the access to the code and try like heck to keep it
> > from getting out....which is a huge task and probably not possible.
> >
> > Brian.
> >
> >
> [ warning : long post ]
>
> Mac addresses can be cloned, so mac address filtering is pretty pointless.
> Google the internet for articles about getting into wifi access points and
> you will see notes about Mac address cloning.
>
> Your best bet would be to have a VPN setup on your network. The coders are
> on one VPN and the public access terminals for email/etc are on a seperate
> VPN. That way, the only way anyone is able to do anything on your network is
> if they are authenticated against one of the VPNs. Just plugging a
> computer/laptop into your network won't get them anywhere. This will prevent
> code from walking.
>
> Note: The developer VPN should have its own email server for internal only
> emails. That way, the developers can email one another code and notes, but
> the email has no chance of ever entering the public networks/internet. Same
> for word processing, printing, etc.
>
> One way to do this is:
>
> Setup your various VPN networks so that developers are isolated from the
> rest of the world, since theft of IP seems to be a concern. Have a VMware
> ACE setup to create limited access images of Windows for developers to use.
> Have development data on a central server, not on the images. All changes to
> the thinclient images are undone when the system is rebooted or the user
> logs out. USB, PCMCIA, FW, CDROM, SOUND, etc are disabled on the thinclient
> machine image. The Image contains the VPN software to authenticate against
> the Developer network, but requires a developer to login.
>
> Instead of ACE, you can also use a stripped down and hardened PXE-booted
> Linux to run VMware player. Use that to run restricted VMware images served
> by your central server. The Linux image can have the USB, CDROM, PCMCIA, etc
> modules unloaded or not compile in so that the developer/user won't have
> access to it from Linux or VMware/Windows.
>
> Ultimately, if your developers are looking to steal your info, they can
> always bring in a digicam to photograph snippets of code/etc. They could
> bridge the private and public networks to copy data. They could work with
> someone who manages to the networks to bridge the networks physically. They
> could steal a backup tape. Depending on the code they are developing, they
> could even embed the source code into the compiled application for redumping
> later.
>
> They could even bridge the desktop and the thin client with a serial cable
> or parallel port cable to do a system-to-system copy. I mean... they are
> developers, it isn't hard to write a simple utility or download a public one
> to do a serial/parallel cable transfer. With a custom LED/photo-diode
> device, you could, in theory, use the monitor to export data serially or
> parallel. (Might be a nice hobby project, actually.)
>
>
> If the thinclient needs to be secure, then it should store NO information
> and have no means to input/output other than the screen and the
> keyboard/mouse. The system should stop working if it is unplugged from the
> network and require re-authentication to prevent cached data from being
> copied to another computer(thinclient+ramdrive => laptop via cross-over
> cable). Ie, if the thinclient's OS detects it isn't in contact with the
> central server, it should wipe it's local ramdisk and shutdown.
>
> The desktop/workstation should similarly be restricted and limited, but
> via a different network and different central server. "Maybe" have USB/CDROM
> access since it is for normal office work, but it should definitely not have
> any means to connect with the thin client in any way.
>
> Assume that the BIOS can be compromised. Passwords can be reset. So a
> normal machine plugged into your network will get nothing except the
> PXE-boot/dhcp information to load a highly restricted image which will not
> access the hard drive, cdrom, usb, flash, pcmcia, serial, parallel,
> infrared, bluetooth, wifi, or sound ports.
>
> Regarding the "thinpathsystems.com <http://thinpathsystems.com>" X
> terminal product, it makes use of the local hard disk. So once you have
> installed it once, there is very little to prevent it from being compromised
> to allow copying data to another machine from hooking up to it and copying
> data from it.
>
> Seriously, virtualize the OS. This allows you to lock down the hardware at
> 2 levels: the host OS(Linux) can disable drivers to the various hardware
> ports, so that even if the system HAD a hard drive in it, it won't be used,
> and the GUEST OS ala VMware Player(Windows), where it has no access to the
> HOST OS's devices, which aren't available, and the VMware instance is
> further disabled.
>
> If they manage to hack the Windows Guest OS, the Linux underlying OS won't
> let them write to anything or transmit anywhere. If they manage to hack the
> underlying Linux OS, there is nowhere to write programs to since the system
> isn't compiled with support for local storage or local buses.
> VMware Player can even limit which shared folders are available.
>
> If they disconnect the network, you can encode the Linux distro to
> basically wipe the ram drive on the thinclient via a heartbeat with a
> central server. No return beats in say 5 seconds and the ethernet link is
> down? We've been disconnected, wipe it and shutdown. Mitigated risk to
> cached data theft. Since the saved data is stored on a NFS/CIFS/CVS central
> server, no data loss. Since the OS is booting from a remote image, no OS
> corruption.
>
> It might be a bit more involved than a straightforward
> firewall/VPN/segmented network approach or an X11 thinclient approach, but
> you get alot more control while being able to provide a "full" OS to the
> developers to work on. You can also maintain different revisions of
> workstation images,should someone need to work on a particular OS revision
> or a different set of development tools.
>
> The VMware ACE route has a higher price tag, but is a single bundled
> package.
> The Linux+VmwarePlayer+VMwareWorkstation route is cheaper, but requires a
> little more admin experience/knowledge.
>
> But both options will mitigate the risk of developers walking off with
> information on their laptops, portable media, etc... when properly
> configured.
>
> How much protection you need depends on what the requirements are for the
> project.
>
> Wing.
>
> --
> Wing Wong
> wingedpower at gmail.com
>

--
Wing Wong
wingedpower at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.baylisa.org/pipermail/baylisa/attachments/20051025/f3130689/attachment-0006.html>