[unisog] justification

Peter Van Epp vanepp at sfu.ca
Mon Feb 24 21:12:50 GMT 2003


	It certainly can be a short-sighted approach, but I'll argue (with 
appropriate modifications) it can be both an effective and cost-effective 
approach (although not done quite that way :-)). 
	As a number of others have commented despite what I would like we don't
have the resources nor the final say on policy to do what we would like. We are
lucky enough to have management support for security however. 
	We generally do something very like what is being suggested, i.e.
insist that a compromised machine be rebuilt and properly patched before it 
will be allowed back on the network after a compromise. In addition the machine
must pass a nessus scan and an email detailing what has been done to avoid a
compromise in future has to be submitted to the Director of the computing 
center (mostly for documentation purposes, a pattern of such compromises from
the same machine might get acted upon, however a series of compromises of the 
same machine hasn't occurred yet to find out :-)).
	We have argus recording traffic coming in/out of the Internet connection
and can and do find compromised machines which then get the above treatment.
Because of the argus logs (and other logs around the place) we can often give
at least guidance on how the user likely got hit. We can also tell if they 
got hit again (or are port scanning outwards, or using an excessive amount of
network bandwith with some idea of what it is being used for and thus whether
it should be inquired about in terms of the AUP :-)). We can (and do when 
needed because of pain :-)) provide a report of who and how many got hit lately 
and how to management. That in turn has gotten support from the academic 
community for the blocking of some ports at the border. As an example we told 
them that in a 20 day period 17 Windows machines (and one Unix machine via a 
different flaw) got compromised via the netbios ports (which got them blocked
at the border after years of trying unsuccessfully to get that approved). This 
in turn causes some work on the part of network operations staff to remove the 
machines from the network (time which wasn't being spent fixing other network 
problems and thus impacting the community which is well worth pointing out to
the community :-)) which is relatively speaking small. It causes much more work
for the owner and/or local departmental administrator where the machine was
because they had to stop work and reinstall and patch the machine. This costs
the University as a whole for the lost productivity and in the case where a 
shared departmental administrator did the work, he or she wasn't available to 
do things for other members of that department while that work got done (again
something useful to point out to the community).
	So while we usually won't do a detailed analysis of a breakin, that
isn't (at least in our view) as irresponsible as it may seem and is certainly
much less expensive than doing a full analysis. 

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada

<snip>
> 
> Sounds like an amazingly short-sighted, almost Microsoftian solution.
> 
> "Oh, your machine isn't working right?  Format, reinstall Windows, and 
> everything is all better again."
> 
> "Oh, your student information server was hacked?  Ah well, wipe, 
> reinstall, apply the patch de jour and hope it doesn't happen again."
> 
> 
> 
> ----------------------------------------------
> Mike Stanley, MCSE
> mikestanley at utk.edu
> OIT Lab Services
> 



More information about the unisog mailing list