MIS Security Check-list


Consider your entire organization

When considering security, the best way to avoid obvious breaches of security is to capture the big picture of your installation. Practically, this means that you should work from the outside in, ie. consider security of the building and area, then the actual offices, followed by the network infrastructure, and end with hosts themselves. It's a bit pointless to spend a lot of time securing hosts if anyone can walk into the server room and walk out with a host under each arm. Those things do happen. This is all the more important since most of computer crime is perpetrated by insiders, for obvious ease of action and lack of interest to hackers about the average corporate data. Because it is more exciting to most system administrators, computer books usually concentrate on securing hosts, but sound computer security doesn't deal with just individual computers. You must consider your entire organization.

Prepare for disaster

Generally speaking, check for any single point of failures in your environment, and provide backup solutions. Perform dry runs regularly to make sure everyone knows what to do in case of a breakdown. Post-incident plans must be updated whenever any change is made to your site, and as much as possible, everyone, especially MIS personnel, must be capable of performing the procedures. Plans should also include procedures to solve day-to-day MIS activities, like installing a new host, welcoming a new employee, etc. Also, whenever possible, use fail-safe tools, ie. should the device fail, they should refuse access instead of letting people in.

A firewall is not the magic bullet to securing a site. Generally speaking, try to place as many barriers as possible between valued asset and a potential adversary, without this security being too invasive to employees. Remember that an effective security policy requires that every single employee abide by it, and not just the rank-and-files. The more prepared you are to handle break-ins and disasters, the better for the image of the company and the MIS team. In addition, your company may be held responsible legally if your network was used by hackers to launch attacks on other sites. You might want to hire an outside company to test your security at random times.

Usage policy

A usage policy is an important user-oriented document, not just to cover your ass in case someone in your organization steals information that is off-limit for them, but also because it forces you to think about how your organization works from an MIS point of view.

Security policy

A security policy is more MIS-oriented than the user policy, and its goal is to offer a big picture view of security of your organization.


Keep in touch with local police authorities about robberies in your area, as thieves are likely to keep using a tactic if it proved successful in a location (eg. burglars pretending to be couriers and stealing unattended portable PCs.) Update this list accordingly, and warn users about those new risks. Also, check with authorities what the regulations are about setting up an alarm system at your site, and whether it can be set up to call up the police automatically when the alarm goes off.

Doors and windows

Locks and keys

Alarm System






Routers - Firewalls - Switches




Hard disk



Authorization deals with controlling access to resources, while authentication means checking that the user is indeed who he means he is (ie. enter a password to prove this)




 Users/MIS Personnel

Appendix A - Employee In- and Out-Processing

Employee In-Processing

  1. Create various accounts (NT user, NT computer, Unix e-mail, Lotus Notes, FTP, etc.), and communicate login/password. Tell user to change passwords immediately, and choose solid passwords per instructions in user guide
  2. Add IP address in DHCP and DNS
  3. Add phone # to online phone list
  4. Update caller ID and SPID in PBX
  5. Hand out documentation on resources available onsite (Phone-HOWTO, backup, etc.)
  6. Take picture, update mug-sheet and organization chart, provide access control card

Employee Out-Processing

  1. Disable all accounts (including RAS) immediately before employee is leaving or is told of his dismissal (disgruntled employees and the like are the most common problem of internal threats). Disabling is better than deleting, in case the employee can be expected to return in a short while.Add account to list, and remember to delete them after a given period of time in case the employee is not to return
  2. Remove user from all mailing lists and backup jobs
  3. Check with manager or co-workers whether some files should be backed up from employee's workstations, and burn CDs or save to tapes before reconditioning hosts
  4. If admin passwords were known by employee, change them
  5. E-mail: Set up automated answer for incoming mails, except corporate and known mailing lists (eg. personal or ex-customers), explaining that the employee has left and can be reached at such and such phone # or e-mail address
  6. Do NOT forward e-mails to a new address, as employee could continue receiving individual corporate e-mails after leaving the company
  7. Remove employee picture from mug-sheet, phone directory, and Caller ID
  8. Remove hosts from backup selection list
  9. Make sure security knows that this employee is no longer with the company, and, unless OKed by management, should not be allowed in in the premises without an escort

Appendix B - MIS Personnel Hiring Test












(Proficiency in VB, C/C++, Python, PearlPerl, DOS batch files, Visual Test, Office macros)



Check applicant's location, transportation means, and commute time
If possible perform assessment test: Fill a box with different hardware (NIC, video adapters, etc.), and ask applicant about their use

Appendix C - User Policy

Appendix D - Security Policy

The security policy to handle incidents should have the following sections: Goals and objectives, notification, identification of the incident, handling, post-mortem to improve security in the future.

As explained in RFC 2196, in each area, identify what you are trying to protect (files, corporate reputation, etc.), determine what you are trying to protect it from (files being accessed or deleted or replaced, unauthorized programs being run, disruption of service, using your hosts as stepping stone to launch attacks to other sites, etc.), determine how likely the threats are, implement measures which will protect your assets in a cost-effective manner, and review the process continuously and make improvements each time a weakness is found.

The basic goals of security are authentication, authorization, availability, confidentiality, and data integrity. Threats include unauthorized access to resources and/or information, and denial of service. For each service that will be provided, list who will provide and administer it, and who will be allowed to access them.

Needless to say, the cost of protecting assets should be less than the cost of their loss, whether it's the amount of work to re-create them (lost files), or the impact of the image or future of the company (break-ins, confidential information passed on to the competition.)

Also, take into account the knowledge required to use computers securely, as e-mail-based virus are all it takes to bring down an entire organisation. To make matters worse, non-technical employees are those most likely to not upgrade to the latest anti-virus and launch any application or click on any e-mail attachement. Performing such daily routine tasks is not only time-consuming, but also very boring, and hence, very likely to be neglected. Therefore, automate as many tasks as you can, and hire MIS employees with such coding skills. Perl, Python, and shell scripts are your friends.

No security, especially as technical and involved as handling day-to-day management of a computer infrastructure, can be achieved without dedicating significant resources. Pay peanuts, and you'll get monkeys.
That money can be spent on software, hardware, or the wages of your staff, but if you don't take measures to provide these necessary resources, there is no way that anybody will be able to provide you with any acceptable level of security.

Finally, keep in mind that, as the Bugtraq mailing list shows, new breaches of security are found every single day, if only because new software and upgrades often means new security flaws. Do not assume that because your whole site is secure today, that it will remain so tomorrow. Security is a state of mind, so remember to check security-related mailing lists and web sites on a daily basis.

Applications (and their corresponding bugs and breaches of security) are updated constantly. In order to keep it as universal as possible and avoid having to update it too often, this document gives a list of general hints, and does not deal with particular versions of softwares you might be running. Hence the need to keep abreast through mailing lists and web sites.

Appendix E - Choosing a backup software

Temp stuff


Tape Drive Roundup - Which Tape Drive Is Best for Your Linux System?

CastleWood ORB Int IDE $150 Int SCSI $160 Ext SCSI $180 USB $200 2.2GB tapes
Travan TR4 (4-8GB $200-500), TR5 (10-20GB, $250-600) Mgf = Seagate TapeStor
OnStream (15-30GB, 25-50GB, $150-600) DI30 (IDE) is Certified for Linux! ADR50 is Certified for Linux!
120M floppy drive

DAT 4mm (DDS)
DAT 8mm (AIT)
Exabyte Mammoth-2
Magneto optical

Drive price, tape price, models (IDE, int SCSI, ext SCSI, USB), Linux, standard recording format (can be accessed using non-proprietary software)

The Emerging Tape Backup Market

Tape technology is broken into two major categories: helical tape and linear tape. The former touts higher density and performance, while the latter promises increased reliability. The main difference between the two is that a helical-scan drive pulls the tape out of the cartridge and, using a series of tensioners, wraps the tape around a rotating drum that contains the heads. Linear scan uses stationary heads and a less complex tape-threading method. The stationary heads of the linear tape technology are what theoretically give linear-tape drives superior reliability.

The other difference is the way data is written to the tape. Linear scan writes data from front to back in a serpentine method. That is, when the head reaches the end of the tape, it drops down a row and switches direction. Helical scan writes data diagonally across the entire tape--simultaneously using multiple heads. Concerns about the tape stretching or snapping due to drum rotation speeds upward of 7,000 rpm and high tension conditions have been quelled by the success and reliability of solutions such as the Sony AIT-2 drive. Aided by DLT, linear-scan drives have been winning the race with proven market success.

Appendix F - Unix Security Checklist

(from Practical Unix & Internet Security)


Chapter 1: Introduction

Chapter 2: Policies and Guidelines

Chapter 3: Users and Passwords

Chapter 4: Users, Groups, and the Superuser

Chapter 5: The UNIX Filesystem

Chapter 6 Cryptography

Chapter 7: Backups

Chapter 8: Defending Your Accounts

Chapter 9.. Integrity Management

Chapter 10: Auditing and Logging

Chapter 11: Protecting Against Programmed Threats

Chapter 12: Physical Security

Chapter 13: Personnel Security

Chapter 14: Thlephone Security

Chapter 15. UUCP

Chapter 16. TCP/IP Networks

Chapter 17: TCP/IP Services

Chapter 18: WWW Security

Chapter 19: RPC, NIS, NIS+, and Kerberos

Chapter 20: NFS

Chapter 21: Firewalls

Chapter 22: Wrappers and Proxies

Chapter 23: Writing Secure SUID and Network Programs

Chapter 24: Discovering a Break-in

Chapter 25: Denial of Service Attacks and Solutions

Chapter 26: Computer Security and US. Law

Chapter 27: "Who Do You Trust?

Appendix B: Important Files

Appendix C: UNIX Processes

Appendix F: Organizations

Appendix G: Table of IP Services

Read the table and add your own site notes indicating the services you do and do not wish to support.

Under construction

nslookup (ls -d acme.com. > zone.txt), host -lvt any acme.net, close tcp 53 on firewall, traceroute -S -p53 x, fping gping, icmpquery & icmpush, strobe & udp-scan, identd to get infos on a running process, net view /domain: mydomain, vrfy/expn mysmtp, netcat, don't run progs as root, remove all unneeded sws, dll's, core dump, world-writable files + dir, tx alarm if nic set to promiscuous, seifried.org/lasg, modems, rogue phone plugs, spread dial-in phone #s,g

RFC 1244
Policy for handling incidents:

Temp stuff

djbDNS instead of BIND

Use tcpserver to replace inetd

netstat -an --inet

netstat -nl --inet

# netstat -ln


There's replacements for, among other things, dns, http and FTP software, and of course Qmail

One gruesome night of crawling through man pages, newsgroups, deeply hidden scripts and obscure configuration files reveals that in fact the only one not using port 6000 is the local user. On the local machine domain sockets are used. Even better, X's TCP port can be banished, if you just know how. Ditto of xdm's UDP port.

I've decided to switch to a little known print system called PDQ. It's not particularly sophisticated, but it's got the funniest web site of the lot. As before, I won't go into detail on installing it; that's what documentation is for. I will however, try to explain how it works, since it is very different from the way lpd works. http://feynman.tam.uiuc.edu/pdq

So I have my standards. Anything that does interaction with the outside world should either be very trivial, very well audited, or be sufficiently sandboxed that possible damage is limited. Preferably it should be all of them. Many classic programs cannot be set up this way and should not be exposed to the public Internet.

Suid programs can be made only accessible to those who need to use them. The usual way it to create a special group for each class of suid programs you can identify and make each user a member of the groups needed. Programs like sudo provide other ways to control who may use what program.

Of the remaining 12, 7 had a legitimate reason to be suid root (like su) while the other 5 needed to be suid root for practical reasons but there really should be a better way of doing this. Examples are ping and Xwrapper. All remaining twelve programs had one thing in common: normally they would only be started by humans. No system account needs to use them. I therefore put them all into a directory that only those accounts that correspond to real users can access. If an attacker breaks into a system account he cannot reach any suid root program. For six of the twelve I added extra requirements - a number of special group IDs controls who may access these.

Security Tools

More at http://packetstorm.securify.com/UNIX/utilities/  and http://sites.inka.de/lina/freefire-l/tools.html



Lance Spitzer's Armoring Linux is a pretty cool doc for most newer Admins/Newbie/Cluebie users. He's actually a kick ass guy on the Checkpoint side of things ;) as well. http://www.enteract.com/~lspitz BroncBuster has an ok doc written in accordance to Slackware. Even though he didn't give me an opportunity to interview him for the BroncBuster vs. Michael Jackson event, I ain't mad at him. http://www.attrition.org/hosted/bronc Vetesgirl is a good friend, and has some cool shit on her page in reference to Linux. She is also the author of VetesScan which is also a cool ass tool to have around /usr/local/bin http://www.self-evident.com Packet Storm Security is one of the biggest security sites around. Started by Ken Williams which is also one of the coolest people in the world, Packet Storm is on top of security like JP is on top of Brad's anus. Definitely a place to go and read documentation on everything from a-z. http://packetstorm.securify.com SecurityFocus is another one of the coolest sites to gain info from. This is AlephOne's bugtraq site, complete with tools, documentation, postings, etc. http://www.securityfocus.com SecuritySearch is a search engine dedicated to security and should be in your bookmark list. This is the most thorough search engine related to security I've found. Although you do have to watch those damn geoshitty sites that have sprung up there like the plague... ;) http://www.securitysearch.net XForce has some pretty cool documentation related to security. While I get tired of typing this 1/2 hour doc, I'll just throw in links and you can check em for yourself. http://xforce.iss.net NMRC (great Novell documentation) http://www.nmrc.org Rewted Labs (pestilence sector9 bell are cool as hell) http://www.rewted.org Technotronic Security http://www.technotronic.com