Because system security is the aggregate of individual component security, "system boundaries" must encompass all individual users and their workstations. But because personal computers are just that (personal), staff behavior can't always be dictated without potentially hampering worker productivity. Recall that security policy becomes ineffective when it is so restrictive that legitimate user access is threatened. Thus, a key to successful security implementation is finding a reasonable balance between system protection and user autonomy and expediency.
Effective system security depends on creating a workplace environment and organizational structure where management understands and fully supports security efforts, and users are encouraged to exercise caution. The security manager leads this effort.
The security manager ensures that administration and staff are aware of their security roles, support security efforts, and are willing to tolerate the minor inconveniences that are inevitably a part of system change and improvement. After all, if personnel circumvent security procedures (e.g., write down passwords, share accounts, and disable virus-checking software), they put the entire system at risk.
A security manager must:
- Communicate to staff that protecting the system is not only in the best interest of the organization, but also in the best interest of users.
- Increase staff awareness of security issues.
- Provide for appropriate staff security training.
- Monitor user activity to assess security compliance.
Nurturing Support within the Organization
Even when an organization is committed to improving security, security managers often find themselves having to work harder than should be necessary to remind staff of the importance of each step in the security process. Fielding questions about the necessity of sometimes burdensome procedures or the expense of technical and training initiatives is an inevitable but important part of the security manager's job. Make no mistake about it, the security manager must not only administer security policy but also champion it.
Garnering Administrator Support
Support for security at the managerial level is essential because security planning must be aligned within the context of greater organizational goals. Management must make sure that the organization's broader plans are adequately considered and that security policy conforms to existing rules, regulations, and laws to which the organization is subject-not to mention that adequate funding is budgeted. After all, every dollar that is invested in security, as necessary as it surely is, takes a dollar away from some other activity.
Management can encourage an atmosphere of security, or it can undermine it?which will help to determine whether staff who are meticulous about security are considered to be the oddballs,
or the norm.
While technical support staff may have the best understanding of the ramifications of given technology initiatives, only users have the opportunity to implement policies and management the power to enforce them-and policies that are neither implemented nor enforced are worthless. Real security requires strong, visible support from senior management as a group, as well as personal accountability and exemplary behavior from individual managers. If management ignores or circumvents security procedures, others will do likewise.
Planning for the Unexpected
A good policy whenever security is threatened, whether it be a disk crash, an external intruder attack, or natural disaster, is to have planned for potential adverse events in advance. The only way to be sure that you have planned in advance for such troubles is to plan now-because you can never predict exactly when a security breach will happen. Such forethought contributes to tracking down the source of the incident, collecting evidence to be used in prosecution efforts, protecting the valuable information contained on the system, or preparing for system recovery. Planning for emergencies beforehand goes beyond "good policy." There is no substitute for security breach response planning and other more overarching contingency planning!
Security Breach Response Planning
There are three common responses to an attack on an information system: "protect and proceed," "pursue and prosecute," and "panic and pray." Either of the first two strategies, while opposite in intent, can be appropriate depending on the nature of the security breach and the philosophy of the organization. The third approach, "panic and pray," while unfortunately more common than the first two, is never an effective response. In fact, the entire rationale for contingency planning is to minimize the need for panic and prayer in the event of a security incident:
- Protect and Proceed. If management fears that a site is particularly vulnerable to attack, it may choose a "protect and proceed" strategy. Upon detection of an attack, attempts are made to actively interfere with the intruder's penetration, prevent further encroachment, and begin immediate damage assessment and recovery. This process may involve shutting down facilities, closing off access to the network, or other drastic measures. The drawback is that unless the intruder is identified directly, he, she, or it may come back into the site via a different path, or may attack another site.
- Pursue and Prosecute. Here, the primary goal is to allow intruders to continue to access the system until they can be identified and have evidence of their unauthorized activities documented. While this approach is endorsed by law enforcement agencies and prosecutors because of the evidence it can provide, the major drawback is that the system and its information remain open to potential damage while the organization is trying to identify the source and collect its evidence.
Careful consideration must be given to both of these security breach response philosophies by site management. It is imperative that forethought and planning take place before a problem occurs or else staff may not know how to respond in the event of a real emergency: Will they protect and proceed, or will they pursue and prosecute? In fact, the strategy eventually adopted might even be one of "it depends upon the circumstances." For example, an education organization might be willing to accept the additional risks of allowing an intruder to access financial records (that have been properly backed up) while he or she is incriminating him- or herself. On the other hand, the organization might decide that threats that access confidential student records must be thwarted immediately because the potential costs of disclosure are not worth the benefits of capturing the intruder. Regardless of the approach selected, the pros and cons must be examined thoroughly by policy-makers, and users must be made aware of their responsibilities.
Prosecution is not the only possible outcome when an intruder is identified. If the culprit is an employee or a student, the organization may choose to take internal disciplinary action.
Another decision that management must make concerns any distinctions it chooses to make about different types of unauthorized users. Sites may find it helpful to define who it considers to be "insiders" and "outsiders" by referring to administrative, legal, or political boundaries. These boundaries imply what type of action should be taken to reprimand an offending party-from written censure to legal charges. Security plans need to spell out these options and how an appropriate response will be determined if someone is caught behaving in an unauthorized manner.
Contingency planning can be complex and detailed; after all, it amounts to a blueprint for jump-starting the most important aspects of the organization from scratch and, perhaps, even at another site-all during or, at best, immediately after a catastrophe has struck. The following outline includes recommended steps and considerations for effectively and completely preparing a contingency plan. As with all other guidelines provided in this resource, each organization (and its security manager and policy-makers) will need to consider these recommendations and customize them to meet their unique needs.
Make no mistake about the term contingency planning?events that could happen will happen! It's just a matter of when.
- Be inclusive when building the contingency planning team by including:
- key policy-makers
- the security manager
- building management
- technical support
- other representative staff
- local authorities
- key outside contacts (e.g., contractors and suppliers)
(adapted from Network Security Secrets)
For those in the world who are not invincible (read ?everyone?), being prepared to overcome the unpredictable is both wise and necessary.
- Obtain and/or approximate:
- an exhaustive list of critical activities performed within the organization (as identified in your risk assessment)
- an accurate estimate of the minimum space and equipment necessary for restoring essential operations
- a time frame for starting initial operations after a security incident
- a list of key personnel and their responsibilities
(adapted from Census Handbook for Information Technology Security)
Security plans should also include procedures for interaction with outside organizations, including law enforcement agencies and other security support sites. The procedures should state who is authorized to make such contact and how it should be handled.
- Establish the following resources as part of a contingency plan:
- inventory of all assets, including information (data), software, hardware, peripheral equipment, documentation and supplies-include item by item, the manufacturer's name, model, serial number, and other supporting evidence (also consider a videotape inventory of assets, including close-ups)
- reciprocal agreements with comparable organizations to share each other's equipment in the event of an emergency at one site (e.g., school district to school district, school district to state department, school district to school, school to local nonprofit)-the key is that you have compatible equipment requirements (e.g., MAC to MAC or Windows to Windows)
- arrangements to procure hardware, software, and other equipment as necessary to ensure that mission-critical activities are resumed with minimal delay-keep in mind that old equipment that you have replaced but might suffice in a pinch if it still meets your minimum requirements
- contractual agreements with "hot" and "cold" backup sites as appropriate
- alternative meeting and start-up locations to be used in case regular facilities are damaged or destroyed
- directions to all off-site locations (if moving off-site is actually required)
- procedures for obtaining off-site backup records (i.e., who, what, where, how, and under whose direction)
- contact information and procedures for communicating with key personnel, suppliers, and other important contacts
- arrangements with manufacturers to provide priority delivery of emergency orders
- Locations of support resources that might be needed (e.g., equipment repair, trucking, and cleaning companies)
- emergency agreements with data recovery specialists
- Uninterrupted site security with local police and fire departments
(some bullets adapted from Network Security Secrets and The Underground Guide to Computer Security)
A ?hot? site is an off-site facility that includes everything necessary for resuming operations (e.g., computers, backed up data, etc.)
A ?cold? site is an off-site facility that includes everything necessary for resuming operations with the exception of actual computers (if some delay is acceptable, then the expense can be incurred when necessary)
- Specify the following within the plan:
- individual roles and responsibilities-by name, job title and contact information so that everyone knows exactly what needs to be done
- actions to be taken in advance of an occurrence or undesirable event
- actions to be taken at the onset of an undesirable event to limit damage, loss, and compromise
- actions to be taken to restore critical functions
- actions to be taken to reestablish normal operations
(some bullets adapted from Network Security Secrets)
Contingency planning should be as specific as possible:
If threat A occurs, the organization will respond by doing B; if C happens, it will do D.
- Test the plan:
- test the plan frequently and completely
- analyze test results to determine further needs (e.g., more training and better backup storage)
Periodically try to restore files that have been backed up. Make the process identical to a real emergency, but be sure to make secondary backups so that you are not risking your only backup copy of the data.
- Deal with damage appropriately:
- if a disaster occurs, document all costs (even interim assessment costs) and videotape the damage (to serve as proof of loss)
- don't do anything about water damage to computing equipment-contact professional recovery technicians immediately
- be prepared to overcome downtime-insurance settlements can take time to be resolved. once settled, rebuilding, repurchasing, and reinstalling can take even more time, so don't expect that anything short of being completely prepared will get your office rolling again in a reasonable amount of time
- Give consideration to other significant issues:
- don't make the plan unnecessarily complicated
- make one individual responsible for maintaining the plan, but have it structured so that others are authorized and prepared to implement it if needed
- keep the plan in a secure but convenient location so that it can be accessed as needed
- update the plan regularly and whenever changes are made to your system
- recognize that people always come first (before equipment, information, or mission)
Testing and Review
Most organizations undergo some sort of annual financial auditing as a regular part of their fiscal life. So, too, are security audits an important part of running any computing environment. A complete security audit should include an examination of any policies that affect or are affected by system security, as well as a thorough test of each mechanism that is in place to enforce said policies. After all, a plan isn't much good if it can't be implemented—and the only way to really be sure that security policies and mechanisms are being implemented properly is through extensive testing (or during a real emergency, at which point it is too late to correct shortcomings).
A plan isn't much good if it can't be implemented—and the only way to be sure that security policies and mechanisms are being implemented properly is through extensive testing .
If your risk assessment identifies a particular type of natural disaster as a primary threat to your organization, then a drill based on that scenario could be constructed (e.g., a test to verify your backup and recovery mechanisms after an earthquake). On the other hand, if your greatest threat is from external intruders attempting to penetrate your system, a drill might be conducted that simulates a hacker attack in order to observe access countermeasures in action.
When a threat or disaster is actually happening is not the time to discover the meaning
of the phrase ?a false sense of security.?
If full-fledged security drills prove to be too time-consuming and disruptive to normal operations, consider testing individual facets of the security system one at a time. Backup procedures can be examined to make sure that data can be recovered from storage tapes. Log files can be checked to make sure that information that is supposed to be maintained has been done so accurately. These are merely examples and other features of the system can be evaluated and analyzed as well. When a security drill is performed, great care should be given to devising the test. It is important to clearly identify what is being tested, how the test will be conducted, and what results are to be expected. All aspects of this process should be documented and included in, or as an adjunct to, the security policy.
Who performs security audits and drills?
- The organization's security professional(s).
- Employee teams (peer reviewers from within the organization).
- External reviewer teams (from cooperatives, consortia, or other partner organizations).
- Hired external expert security consultants.
Implementation and Day-to-Day Maintenance
Some of the main activities security managers engage in on a day-to-day basis include administering backup and virus protection mechanisms, staying abreast of software updates, managing user accounts, and monitoring system activity.
It is impossible to over-emphasize the need for a good backup strategy. System backups not only protect the organization in the event of hardware failure or accidental deletions, but they also protect staff against unauthorized or accidental changes made to file contents. When an error is made, the option of accessing an unaltered backup can be very appealing. But reaching into those archives is a viable strategy only when backup files have been made properly-as in they do not contain the errors or problems now existent on your master file. In general, there are three types of backup strategies:
Which type of backup strategy makes sense for your organization? That depends on the types and number of files in the system, the level of technical expertise within the organization, and the organization's commitment to security-information that can be found in the results of a well-executed risk assessment. Even after needs unique to the organization have been identified, however, there are several more overarching issues to consider before establishing backup plans:
- A complete backup: backing up your entire hard drive. The advantage of this strategy is its totality; you will get a snapshot of all your hard disk's contents.
- A partial backup: only backing up selected directories. This is useful and efficient if your work is concentrated in a specific area of your hard disk.
- An incremental backup: only backing up those files that have been changed since the last backup. It means using backup software to scan the files to see if they have been changed since the last backup cycle. If so, the file is saved; if not, the previous backup is maintained.
To further evaluate the type of backup strategy that will best meet your organization's needs, also weigh the following factors:
- What amount of exposure to data loss can your organization comfortably tolerate?
- How old is your equipment? How reliable is it?
- What is the nature of your workplace? Do you process new data everyday?
- The time and effort required to make changes to the files: If changes to the file take only a little time, backing up those changes may not be imperative. If the changes require a great deal of work (e.g., entering data collected from a long form), don't risk that effort and instead back it up frequently.
- The time and effort required to back up the files: If the actual backing up process requires little effort, why put it off? If it is time consuming, be more aware of proper timing.
- The value of the data: If the data are particularly valuable, back them up more often. If not, frequent backup may be less necessary.
- The rate of file change: If a document changes rapidly (e.g., because of the operator's speed in data entry), more frequent backup is probably needed.
(adapted from the NCSA Guide to PC and LAN Security)
Use the information available in order to devise a backup plan that is most likely to be implemented. Be creative enough to develop the strategy that is most likely to ensure that your data gets backed up.
Above all, devise a backup strategy that is realistic for your organization.
Set a backup schedule that fits your agency's needs and work style and stick with it. The following are examples of commonly used backup routines in education organizations:
- twice daily: partial at noon, full at end of day
- once daily: full backup at end of day
- three times weekly: full backup at end of every other day
- twice weekly: full backup Tuesday, partial on Thursday
- once a week: full backup
- monthly: full backup
Like all security decisions, selecting a location for off-site storage facilities should be based on risk assessment findings. If, for example, risk assessment shows that an earthquake is the threat of chief concern, locating an off-site storage facility 100 miles away but along the same fault line makes little sense. Similarly, if risk assessment identifies flood as a paramount threat, the location of off-site storage should be outside the same flood plain.
The choice of backup location depends on the agency's needs, resources, and ability to secure its physical structure. Any single option, or mixture of options, can be chosen as long as they meet the site's needs and have a realistic chance of being implemented. Backup storage options include:
- Option A: In the same room-great for easily recovering files after data loss, but bad if a threat gets "in" the room (e.g., a single fire could destroy your primary and backup files).
- Option B: In the same building-less convenient for correcting mistakes, but physical separation increases security as a single event is less likely to damage everything.
- Option C: In a secure, off-site location-not convenient for quick data recovery, but excellent for protection if maintained in a secure facility.
Software programs are sets of instructions written in various programming languages. These instructions are compiled or translated into binary numbers that enable a computer's central processing unit to interpret and implement actions. Computer viruses are specific types of programs designed to cause damage to a computer system's operations or data.
Any machine that is connected to a network or that interacts with others via diskettes or a modem is vulnerable to rogue programs, including computer viruses, worms, Trojan horses, and the like. It is the security manager's duty to develop and monitor procedures for preventing viruses and other rogue programs from infiltrating the system. As a rule of thumb, no portable data storage device from outside the system (including brand name, shrink-wrapped software) should ever be used on a system machine without first having been scanned by an up-to-date antivirus program. Moreover, all incoming data from the Internet (e.g., e-mail attachments) must also be scanned by antivirus programs.
Virus programs work in different ways and enter the computer via different methods. For example, a virus can be sent as an e-mail attachment, a macro (or mini-program) within a document, an executable program on a portable storage device, or by other means.
Since virus protection software is not foolproof, ultimately the most effective protection
against a virus is having a clean, up-to-date backup file.
Virus protection software is a necessary system component that minimizes the possibility of data corruption due to a malicious virus by detecting and removing virus programs. Virus protection software can be purchased for individual computers, but it is most cost effective in large organizations to purchase a multi-user site license (an enterprise license). Once installed, virus protection software must be updated frequently because new and more destructive viruses are being created and released all the time. It is vitally important to download and install the latest updates as soon as they are available to ensure adequate protection of computer data. IT staff can assure that all computers in a network are protected by current virus definitions by daily updates to a single "enterprise" edition of virus protection software that resides on a central network server.
It goes without saying that computer systems have bugs. Even operating systems, upon which we depend for so much of the protection of our information, have bugs. Because of this, software publishers release updates on a frequent basis. Often these updates are plugs for holes in the software's security that have been discovered. It is important that whenever these bugs are identified, the system manager takes all action possible to remedy them as soon as possible in order to minimize exposure.
Bug \'bəg\ - Any of a near countless number of species of creepy, crawly insects, or, more commonly, unexpected programming errors in computer software.
A corollary to the "bug problem" deals with the source for obtaining upgrades to software. Many computer systems and software packages come with support from the manufacturer or supplier. Remedies that come directly from such a source tend to be trustworthy and can usually be implemented fairly quickly after receipt (and proper testing no matter the source). Other sources, such as software posted on Internet sites, must be scrutinized more closely.
User Account Management
In order for the security manager to effectively supervise the system, he or she needs to have access to all system components and files-access that is commonly referred to as "system administrator privileges." It is generally considered to be good practice to share system administrator access privileges with someone other than the system administrator, if for no other reason than to have emergency system access should the administrator become unavailable. Having said this, such total access also requires total accountability, and should be limited to the fewest number of staff members as is necessary to keep the system secure. After all, each person with total system access has the ability to override any and all security features.
Users other than the system manager (and an accountable replacement in case of emergency) should be given access to the system based solely on their job needs. Restricting user access minimizes the opportunities for accidents and other possibly inappropriate actions. Through the use of user accounts, each authorized user is identified before accessing the system, and any action that is made by that user is classified as such.
System Use Monitoring
Monitoring a system involves looking at all aspects of the system, identifying patterns of regular use, and searching for anything unusual. System monitoring can be done by either the security manager or software designed specifically for that purpose. Most operating systems store information about system use in special files referred to as log files. Examination of these log files on a regular basis is often the first line of defense in detecting unauthorized use of the system. System managers should:
- Compare lists of currently logged-in users and past login histories. Most users typically log in and out at roughly the same time each day. An account logged in outside the "normal" time for the account may be a sign of unauthorized activity and require investigation and explanation.
- Check system logs for unusual error messages. For example, a large number of failed login attempts in a short period of time may indicate that someone is trying to guess passwords.
The task of system monitoring is not as daunting as it may seem. Security managers can execute many monitoring tasks periodically throughout the day during even the briefest of free moments (e.g., while waiting on hold on the telephone). By executing the commands frequently, the manager will rapidly become familiar with "normal" activities and become better able to spot things that are out of the ordinary.
To recognize deviations from normal system use, the manager must understand how
the system behaves when it is running properly.
The single most important thing about monitoring system use is that it be done regularly. Picking one day out of the month to monitor the system is not a solid security strategy, since a breach can take place in a matter of hours or even minutes. Only by maintaining a constant vigil can you expect to detect security violations in time to react to them-hence one appeal of monitoring software that, unlike even the most dedicated of administrators, is able to work 24 hours and seven days a week.