Regular backups are a fundamental activity that should be performed regularly to ensure that hard drive failure, or malicious destruction of data, does not render the system useless and empty.
There should be some way of obtaining backups, at any time, for any system on the network. Obtaining a full backup is one of the first steps in security incident response, but very often there are no backups done, nor any way to do a backup on a system.
For Unix workstations, usually a SCSI bus is available (if not, PCs can and should be purchased with SCSI cards in place and configured for use). A single 4mm (DAT) or 8mm (Beta) tape drive can be moved between, and shared among, several workstations.
This policy should also include a statement about, and means for, users to make backups of their own data at more frequent intervals than the standard policy, e.g., by copying files to floppy disk or to another system. To avoid unintentional exposure of this data, also inform your users of how to secure their data files in transit on the network, or in storage on another system, if the data is sensitive enough to warrant this. Recent problems on Department of Defense computers with classified nuclear weapons data were due to this classified data being backup up on unclassified systems by non-US nationals entrusted to access to nuclear weapons data.
Also of particular interest to University of Washington administrators, your users should be informed that backed up data are (by Washington state law) considered public records and may be subject to public records requests.
Acceptable use polices can be hard to produce if you don't know what they should contain, so start with those that C&C uses for centrally administered systems.
Other examples can be found in such places as:
For some items, such as acceptable use policies (UAPs), this is entirely appropriate and reduces redundant effort. Be aware, however, that a central Information Services organization will not address many policies and procedures that are critical to a local area network environment, such as local desktop file backups/restoration, use of email features that allow executing code in email attachments, virus scanning downloaded programs/documents and email, etc.
Very often, incidents warrant immediate disconnection of a system from the network to respond to an ongoing incident. If there is no way to contact the owner of a system, or to get administrative rights on that system, response is hampered, the incident can escalate or continue, and in some cases the intruders can destroy the entire system to cover their tracks.
Every system should have some full or part time administrative support staff available, at least in an on-call basis, to deal with emergency situations. It is not enough to buy a system and set it up, it must have someone to monitor its use, keep patches up to date, provide regular maintenance and backups, etc.
In some cases, a policy of maintaining a list of all the system administrator passwords, kept with other secure records in the possession of the department chair (e.g. a locked cabinet or safe), can provide access to the system in an emergency. Passwords should not normally be kept on "post-it notes" on or near workstations.
This can take the form of a technical support contract, access to vendor published books on network, site, or system administration (often called "Site Administration Guide", "System Administrator Guide", etc.), or (at the very minimum) books on system administration that cover all major areas of administrative responsibility.
The moment that a crisis hits is not the time to try to run for help with the basics from someone else. The administrator should have an available knowledge base to turn to for vendor-specific commands, techniques, and procedures, and rely on outside help for the higher-level, more general, procedural matters of incident response (and even then, the basics should still be mastered prior to a crisis).
Training and central support are also available. The R870: Unix System Administration - A Survival Course is taught quarterly, and administrators can always send questions to firstname.lastname@example.org.
There are many occasions, such as security incidents involving "network sniffers" that compromise the passwords of every user of a network, where access to some or all computers on the network must be taken away to prevent continued access by unauthorized intruders.
The point of a crisis is not the time to try to determine who and how to notify about an incident, as this only slows down response and compounds the problems faced by those responding. At a bare minimum, all computer users should know to whom, and where, to go to report or learn about network related problems.
Knowing how to react properly in an emergency is critical to making the right decisions to restore operations smoothly, quickly, completely, and while still preserving evidence necessary to determine what happened (and perhaps even to prosecute those who damaged the system). E.g., see Incident Response Cycle in a Nutshell for highlights of such procedures.
[Prev] | [Top]