[sclug] Locking down
Neil Haughton
haughtonomous at googlemail.com
Tue Jun 21 07:42:54 UTC 2011
I agree (I said in the beginning I wasn't expecting one) that there is no
guaranteed technical solution, (and thanks to those who pointed this out to
me over and over :-) ) but as when making your home secure, you can't stop a
determined intruder but you can build rings of defence that increasingly
reduce the chances of it happening. That is what I was seeking guidance on,
and my thanks to those who saw this and helped out with some potentially
useful suggestions. Squid and vlans etc are currently being looked at.
As to to the arguments about this being an HR problem and the solution being
to hand pick trustworthy employees and thereafter trust them to be
trustworthy, that's a bit like shutting your eyes and putting your faith in
your God when walking through a minefield. You might be okay, but one
mistake and you don't get a second chance. The rogue employee who privately
decides that he could get a good price in Nigeria or Argentina or China,
say, is hardly going to announce his intentions. We don't take on people
who we don't believe are trustworthy, but we simply cannot really tell until
that is proved in time, can we? And is it ever proved? Julius, after all,
trusted Brutus until it was too late. If he hadn't turned his back.....
A pollicy (we have one anyway) and logging is going to be no use in the
scenario my seniors are trying to hedge against: that is, the willful and
secretive absconding with the source code. For example, our policy clearly
prohibits 'inappropriate' website access, yet a long serving and very
trusted member of staff was sacked a year or so ago for downloading some
pretty salacious stuff in his lunchbreaks. Okay, there was no harm to the
business in that (part from the nasty virus he inadvertently introduced to
the intranet) but it shows the paradox that you can't be certain that the
people you trust are trustworthy.
>>Any technical means that you use to lock down internet access and be
overly restrictive on filtering will just be seen as frustrating developers
in their role.
I disagree. The business needs come first, and you don't need unfettered
internet access to develop software, whatever some developers may
claim. Certainly not from your personal machine. One place I worked
developers had a few machines with internet access (in the 'internet room')
that were isolated from the local network, which they used when they needed,
for research ot whatever. No other machines had outside access. Never saw or
heard any dissatisfaction with that arrangement. Developers who claim that
they "can't do their job" without unfettered internet access from their
desktop are usually really saying they can't do their job. Provided you
ensure that alternative arrangements are in place it's nice to have, that's
all.
Neil.
>
> Subject: Re: [sclug] Personalised web content filtering
> Neil
>
> A technical solution to this is not possible if you also want to allow
> your people to have access to the source code for development.
>
> But what you should do on a technical level is ensure that you are
> logging events from your source repository, web proxies, Firewalls,
> emails etc. That this logging is robust and everyone is aware that
> these events are being logged. The rest of the problem is to make sure
> that all the developers are aware of their responsibilities, a written
> down code of conduct, internet use policy is essential.
>
> Any technical means that you use to lock down internet access and be
> overly restrictive on filtering will just be seen as frustrating
> developers in their role.
>
> Stuart
>
>
> -- Stuart Ward M +44 7782325143
>
>
>
> ---------- Forwarded message ----------
> From: John Stumbles <sclug at yaph.org.uk>
> To: sclug at sclug.org.uk
> Date: Mon, 20 Jun 2011 09:39:41 +0100
> Subject: Re: [sclug] Survey
> On 20/06/11 09:02, Dickon Hood wrote:
>
> The answer to that will doubtless depend on the presence of the letter
>> 'K'; it's difficult to fsck things without it.
>>
>
> Yes but at least it would prevent you fuc*ing it up ;-)
>
> --
> John Stumbles http://yaph.org.uk
> :-:-:-:-:-:-:-:-:-:-:-:-:-:-:-**:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-**
> :-:-:-:-:-:
>
>
> _______________________________________________
> sclug mailing list
> sclug at sclug.org.uk
> http://sclug.org.uk/mailman/listinfo/sclug
>
More information about the Sclug
mailing list