Hello,

I am try to write up a company security policy that I can submit to my boss in hope of 
having it actually become policy. We are a very small co and up till now, security has 
been whatever I have time and get permission to do. I don't think that's a very good 
idea.

Anyway, I have never so much as seen the likes of a security policy, so I may not know 
what I'm doing, but I want it to address every issue and cover every base, if 
possible. 

I'm greatly concerned that I'm going to leave something out, and so I'd like to 
request help setting it up. Please don't worry to much about it's style, right now I'm 
trying to make sure I don't miss anything - I'll worry about making it sound official 
when I'm done. At the moment it has notes to myself and my boss mixed into the text 
which make it look funny :-) I do however want it to be correct, and as professional 
as reasonably possible. Please don't hesitate to expound upon  or lengthen anything 
:-). I guess you can even diss it if you really want to ;-)


I am mostly concerned with our *nix systems, but I suppose it wouldn't hurt to include 
things relevant to M$ OSes too.

First version bound below. Changes will be posted of course.

P.S. If anyone thinks this is not appropriate for this list please say so.

Thanks a bunch. Main body of text follows.
_____________________________________________________________

                        CCS Network and System Security Policy
                            Copyright 2001, Central Texas IT
                                    Version 1.0


        The purpose of this file is to document decisions that have been reached 
concerning security and issues that still need to be resolved.

We need a clear, detailed official policy that can be followed. An prospective outline 
follows:

1. Patches and Bug fixes
   All vendor patches should be applied unless it is a patch for mission critical 
software, in which case it should be carefully reviewed to insure backwards 
compatibility before applying. I need to spend a little more time monitoring the 
vendor patch announcements, I think it was 2 days before I got around to telnetd, and 
that worm was set loose before I finished checking up. That is not a desirable 
situation.

2. Passwords.
   We already have a system in place that requires secure passwords, and checks for 
weak ones. One thing we are not doing is changing them often enough. We should change 
passwords at a set rate. Rate needs to be determined.

3. Ports
   We should port scan out servers once a month. A list should be kept for each host 
of what ports should be opened, and each scan should be compared to the last. Changes 
should be investigated. No ports should be open that are not necessary.

4. Services and Daemons.
   Running services should be examined once a month. A list should be kept for each 
host of what services should be running. Changes should be investigated.

5. Detecting Compromises
   5.a Root Detecting
       Need to learn how to run a root kit detector. Depending on what's involved, we 
should possibly run this periodically.
   5.b File System monitors
            There are several packages that monitor changes in the file system. 
Tripwire is one of them. We should implement it.
   5.c Binary Checksums
              It's a great relief to have a checksum catalog of all important binaries 
and config files when a compromise is suspected. I wish we had one right now, since 
telnetd was open while that worm was running around.
   5.d Host and Network IDS
            There are more complete IDS systems that monitor changes in running 
services, unusual login behavior, loading of new kernel modules and so on, in addition 
to tampering with binaries, config files and the FS in general. Tripwire only monitors 
the file system.

6. Monitoring and Logs
   Need to investigate ways to monitor logs. All the professionals strongly advocate 
monitoring logs. This is a good way of catching system errors and failures before they 
get critical, as signs often start showing up in the logs before they get bad.

7. Firewalls
   Need to look into firewalls and packet filters, though I fail to have any 
confidence in them.


----------------------------------------------------
Jonathan Wilson
System Administrator

Cedar Creek Software     http://www.cedarcreeksoftware.com
Central Texas IT     http://www.centraltexasit.com

_______________________________________________
http://linux.nf -- [EMAIL PROTECTED]
Archives, Subscribe, Unsubscribe, Digest, Etc 
->http://linux.nf/mailman/listinfo/linux-users

Reply via email to