<br>From Previous Post:<br>
<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Your points are valid and we've been thinking about them all. What I<br>
am considering is a firewalled network for code development that only<br>allows connections from specific thin clients (I should be able to<br>allow only specific mac addresses to connect just like a wireless<br>node, no?). We are also considering a separate desktop for the users
<br>to check email, internet access, etc. but what prevents them from<br>just taking the time to copy the data from the isolated network to<br>the other network. At some point you have to trust that your source<br>code is safe with your new employees, but I think that might be too
<br>cautious of an approach.<br><br>We'd like to limit the access to the code and try like heck to keep it<br>from getting out....which is a huge task and probably not possible.<br><br>Brian.<br><br>
</blockquote></div><br>
[ warning : long post ]<br>
<br>
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. <br>
<br>
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.<br>
<br>
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.<br>
<br>
One way to do this is:<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.)<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Regarding the "<a href="http://thinpathsystems.com">thinpathsystems.com</a>" 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.<br>
<br>
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.<br>
<br>
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.<br>
VMware Player can even limit which shared folders are available.<br>
<br>
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.<br>
<br>
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.<br>
<br>
The VMware ACE route has a higher price tag, but is a single bundled package.<br>
The Linux+VmwarePlayer+VMwareWorkstation route is cheaper, but requires a little more admin experience/knowledge.<br>
<br>
But both options will mitigate the risk of developers walking off with
information on their laptops, portable media, etc... when properly
configured.<br>
<br>
How much protection you need depends on what the requirements are for the project.<br>
<br>
Wing.<br>
<br>-- <br>Wing Wong<br><a href="mailto:wingedpower@gmail.com">wingedpower@gmail.com</a>