CHAPTER 4 Security Management | |||||||||
| |||||||||
Effective security strikes a balance between protection and convenience. | Introduction to Security Management Because system security is the aggregate of individual component security, "system boundaries" must encompass individual users and their workstations. But because personal computers are just that (personal), staff behavior can't always be dictated without potentially hampering workers' overall productivity.
Recall that security policy becomes ineffective if it's 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 convenience. The person responsible for finding that balance and actively promoting organizational security is the security manager. Security management consists of nurturing a
security-conscious organizational culture, developing tangible procedures to support security, and managing the myriad of pieces that make up the system. 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. | ||||||||
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. A security manager must:
| |||||||||
Commonly Asked Questions Q. Can an organization make do without hiring a security manager? Q. Would assigning a top
educational administrator to the security manager role show commitment to system security? Q. Where does the security manager fit into the organizational hierarchy?
Even when an organization is committed to improving its information 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 must 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. | |||||||||
Security must be a joint effort between decision-makers, technical staff, and all other personnel. | 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. It Really Happens! Now Melissa was doing it too! It just drove Carl crazy. First it was Dr. Dawson who flouted security regulations-- but what more was Carl to do after his polite reminders about security policies had been ignored by the Superintendent? Then the Deputy, Dr. Cosgrove, began dismissing the policies as well. Soon both assistant superintendents had decided that they, too, need not comply with inconvenient security regulations. And now it had finally reached Melissa, the executive secretary. Carl didn't blame her-- of course she wasn't going to play by the rules when no one else in her office did. But as the security manager, Carl was worried that when word got out that Melissa no longer changed her password regularly or used a screensaver, the rest of the support staff would quit following regulations as well. And from there it was a slippery slope until staff in the schools realized that the central office wasn't following agreed-upon security policies. At this pace, Carl knew it wouldn't take long for the district's entire investment in system security to unravel. | ||||||||
| Management can encourage an atmosphere of security, or they can undermine it- their behavior in large part determines whether staff who are meticulous about security are considered to be the oddballs, or the norm. | ||||||||
Employees also have an ethical responsibility to maintain the security of confidential information entrusted to them. | Ensuring User Support Computers and networks are valuable tools to their users. Many people rely on them every day to help perform their jobs more efficiently. When computer resources are not available, fulfilling job requirements can become considerably more difficult. One important role a security manager plays is communicating to staff that protecting the system is in their best interests as well as those of the organization.
Traditional computer security frequently relies heavily upon protecting systems from attack and minimizing the likelihood of software and equipment failure, but little attention is usually paid to how to handle an attack or failure once it actually occurs. The result is that when a problem does occur, many decisions are made in haste.
Often, such decisions reflect this lack of forethought and don"t contribute 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. | ||||||||
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. It could happen in a year, a month, or this afternoon. Planning for emergencies beforehand
goes beyond "good policy." There is no substitute for security breach response planning and other more overarching contingency planning! It Really Happens! The district"s backup drive finally broke beyond repair. But Rita, the security manager, was prepared for the eventuality, and quickly produced a copy of a maintenance contract with her vendor that covered exactly this type of event. She called the sales representative and was told that she'd receive a replacement drive within 48 hours. She said that would be fine because the system wasn't due for another complete backup for three more days. Two days later the replacement part arrived as promised, but, to the sales representative's chagrin, it wasn't compatible with the district's system- the wrong part had been sent! Remarkably, Rita maintained her composure as the salesman told her that despite his unyielding efforts to correct the mistake, a new part couldn't possibly reach her rural site for another 48 hours. They'd have to postpone the backup cycle. "Not necessarily," Rita replied with determination. Ten minutes later Rita was on her way to the County Office Building. Two years earlier she had collaborated with the County Administrator before purchasing technology for the district. The two had agreed to buy compatible equipment that could be shared if an emergency ever arose. While Rita acknowledged that she wasn't quite facing a dire emergency, borrowing the county"s backup drive for an evening was a fairly simple procedure- and was exactly what she was going to do to prevent a delay in her backup routine. All of her advanced planning was finally paying off. | |||||||||
| 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 clearly opposite in design, 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 the 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. This alternative to the "protect and proceed" approach adopts the opposite philosophy
and goals. 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 gathered against them. 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.
| ||||||||
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. | 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: to protect and proceed, or 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 and being identified. 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. 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 pressing 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. | ||||||||
| 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. Contact information for security support organizations can be found in Appendix E.
| ||||||||
Contingency Planning Hard drives will crash, electrical surges will zap data, and files will be erased accidentally. General system security (Chapters 5-9) is designed and implemented to protect an organization from these disturbing events. But as valuable as locks, virus scanners, disk labels, and passwords can be, if a fire, flood, or sophisticated intruder knocks at your door uninvited, be prepared for trouble. Make no mistake about the term contingency planning- events that could happen will happen, it's just a matter of when. | |||||||||
For those in the world who are not invincible (read "everyone"), being prepared to overcome the unpredictable is wise and necessary. | Contingency planning does not protect the organization from a threat but, instead, explicitly details what is to happen if (when) there is a penetration or the system goes down. It prepares the organization for recovery from a breach in security as quickly and efficiently as possible. In fact, another term for contingency-type planning is recovery planning. Planning for recovery from loss or downtime is not pessimistic as much as it
is realistic. 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 offered
in this document, each organization (and its security manager and policy-makers) will need to consider these recommendations and customize them to meet their unique needs. | ||||||||
Be inclusive when building the contingency planning team by including:12
| |||||||||
Obtain and/or approximate:13
| |||||||||
Contingency planning should be as specific as possible: If threat "a" happens, the organization will respond by doing "b"; if "c" happens, it will do "d". | Perform and/or delegate the following duties as part of the development of a contingency plan:14
| ||||||||
Specify the following within the plan:15
| |||||||||
Test the plan:
| |||||||||
Deal with damage appropriately:
| |||||||||
Give consideration to other significant issues:
| |||||||||
This anecdote may sound far-fetched, but something remarkably similar was reported to have happened after the 1996 California earthquake. | It Really Happens! The Great Quake, as it was soon called, took everyone by surprise- including the regional education agency that had been compiling student records for the state legislature for more than two months. Don Jones was in charge of the project and found himself in quite a predicament. Luckily, or unluckily depending on the outcome of his actions, he didn't think about what he was about to do-- he just ran back into the burning building to get a copy of his backup data tapes. He returned to an astonished group of co-workers who were amazed that he would, quite literally, risk his life to protect "his" data. He made it out alive, so he might say that it was worth the risk, but wouldn't it have been easier to have just practiced off-site storage?
| ||||||||
| 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). | ||||||||
Keep in mind that there are limits to reasonable testing. The purpose of testing is to verify that security procedures are being implemented properly and meet critical policy goals, not to prove the absoluteness of every aspect of the system and policy. | Although security drills can't be scheduled every day of the week without seriously affecting office productivity (and probably morale), they should be conducted as frequently as is necessary to determine that security procedures are being implemented effectively. What kind of drills? Well, if your risk assessment (see Chapter 2) 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. It Really Happens! City Schools committed itself to top-rate system security. It assigned a staff member to serve as a full-time security manager, purchased state-of-the-art backup equipment, and refurbished an old building it owned on the edge of town to serve as off-site storage for its backup tapes. The security manager, having attended numerous technology and security conferences to keep abreast of his job responsibilities, took pride in his system and tested every step of his backup procedures right up until the tapes hit the shelves at the off-site storage facility. To the best of the manager's knowledge, security drills had proven time and again that the system could truly be trusted. One night, as the manager lay in bed thinking about how wonderful the City Schools security system was, he realized that he'd never actually reloaded backup tapes from off-site storage. He was, of course, very confident that the facility (with its fire-retardant renovations, anti-static carpeting, and full-time security guard) was secure, but acknowledged that he couldn't be sure until he actually tested it. The next morning, he went to the facility, checked in with the security guard, entered the combination to unlock the door, and signed out a sample tape. He took it to his office and tried to reload it on a stand-alone "test" computer, but, to his great surprise, found that the tape held no data. He immediately returned to the storage facility to withdraw another tape but again, upon trying to read the data, found that there were no files. Quicker than a flash, the security manager called in a team of high-tech security consultants to diagnose his problem. He showed them his records of test after test and drill after drill that verified that all pre-storage steps to backing up the data were being implemented properly. The specialists were convinced that the off-site facility was the place to begin the investigation. As they approached the building, the security manager mentioned that while he hadn't thought to budget for the high hourly charges of the expert consultants, they should take whatever time they needed to figure out the problem because he wanted that backup system running properly. To this, the lead consultant replied as he walked toward the door, "Well, in that case I think that I've got some good news and some bad news to tell you. The good news is that I've already identified your problem and will only have to charge you for one hour's work." "That is good news," the manager responded. "But what's the bad news?" "The bad news is that electrical transformer behind the storage facility. Unless you have lead walls, it's emanating enough residual electricity to erase every tape you have in the building. You're going to have to move your storage site." "But we have a very secure site here," the manager contended desperately. "It has a security guard, a state-of-the-art sprinkler system, and anti-static carpeting." "And it also has a giant, tape erasing, electrical plant in its back yard. I'm sorry, but this site will never be secure. Every backup tape that gets within 50 feet of the building is going to have all of its data erased. But look at the bright side- while you may have lost the investment in the facility, at least you found all this out before you really needed the backed up data. Take last night's tapes to another storage location and you should be okay." | ||||||||
Although security can't be tested each day, testing must be performed frequently enough to verify the effectiveness of security initiatives. | If full-fledged security drills prove to be too time-consuming and disruptive to normal operations to be implemented on a large scale, 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. 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?
Security is more than keeping hackers and other trouble-makers out of your system. It involves a host of internal practices that serve to protect information in the case of system or disk failure. 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. | ||||||||
Recommended practices concerning actual backup procedures are included in Chapter 6. | Backups It is almost 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. If an error is ever made (and we all know that they are), having 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- a backup of a file that contains the errors and/or viruses you are trying to eliminate usually isn't very helpful. Similarly, backup files need to be created at appropriate intervals and themselves must be well protected from damage and destruction. 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 (see Chapter 2). Even after needs unique to the organization have been identified, however, there are several more overarching issues that
need to be considered before establishing backup plans:
To further evaluate the type of backup strategy that will best meet your organization's needs, also weigh the following factors:16
| ||||||||
You may choose a combination of complete and partial backup routines. However, when initiating any system, a complete backup should first be done to serve as a reference point. | In general, there are three types of backup strategies:
| ||||||||
Above all, devise a backup strategy that is realistic for your organization's setting. | So how do all of these factors get synthesized into an effective strategy for meeting an organization's needs? The answer is simple: use the information available in order to devise a backup plan that is most likely to be implemented. Whatever the solution might be, be creative enough to develop the strategy that is most likely to ensure that your data gets backed up. It is imperative to establish realistic policies based on your agency's
environment. In any case, set a backup schedule that fits your agency's needs and work style and stick with it. Here are a few examples of common backup routines:
| ||||||||
Option C, "In a secure off-site location," is the best option from purely a security perspective. See Chapter 5 for recommendations on securing a location. | A last major planning issue to consider is what to do with backup files once they have been created. The choice of backup location depends on the agency's needs, resources, and ability to secure its physical structure (see Chapter 5). 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:
| ||||||||
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. | |||||||||
See Chapter 6 for more specific guidelines about combating viruses and other rogue programming. | Virus Protection Any machine that is connected to a network or that interacts with others via diskettes or a modem is vulnerable to rogue programs: 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 diskette 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.
| ||||||||
| Software Updates 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, in fact, 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. 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. As a general rule, trust manufacturer upgrades more than those that are posted on the Internet. | ||||||||
| User Account Management As stated throughout this chapter, a single person needs to have primary responsibility for an information system. For this person, the security manager or systems administrator, 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 ever become unavailable. But, having said this, such total access also requires total accountability, and should be limited to the fewest number of staff 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 (see Chapter 8). 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. Users should be given access only to files and systems that they need to do their jobs, and nothing more. | |||||||||
To recognize deviations from normal system use, the manager must understand how the system behaves when it is running properly. | System Use Monitoring System monitoring can be done by either the security manager or by software designed specifically for that purpose. Monitoring a system involves looking at all aspects of the system, identifying patterns of regular use, and searching for anything unusual. 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: | ||||||||
| |||||||||
While the security manager is responsible for monitoring user activity, doing so becomes much more feasible when working with and not against the staff. | It Really Happens! Steve was serious about the security of his school's computer system. And although some folks may have thought that he was perhaps too serious, it didn't stop him from making them toe the security line all the same. He was a no-nonsense kind of security manager. When he noticed some extraordinarily odd system activity one afternoon during his daily (but randomly timed) monitoring operations, he was fast on the trail of the troublemaker. Steve knew he was an efficient security manager, but he surprised even himself by so quickly tracing the violations back to Mrs. Todd, the fifth-grade teacher. He should have known to never have trusted Mrs. Todd. No one could be that nice- it had to be a ruse. Steve marched down the hall and through the door into the empty classroom in time to find the culprit still seated at her computer. He could barely control himself, "What in the world do you think you're doing? You could lose your job for hacking my system. In fact, I'm going to do my best to see that you do!" As Steve could have predicted, Mrs. Todd denied that she had done
anything improper. "But, Mr. Johnson, what are you talking about?... And please don't use that tone with me." Mrs. Todd looked puzzled, "No, I've been in my grade book since the children left. Why?" Mrs. Todd was quick to defend herself. "He did no such thing, Mrs. Yow. He couldn't have caught me doing that because I would never do such a thing. Look, I'm working on my own grade book." Steve was surprised that Mrs. Todd was able to maintain such a straight face when he had caught her nearly red-handed. But before he could say anything, Mrs. Yow reached for Mrs. Todd's keyboard. She hit a few function keys and clicked the mouse once or twice. Steve could tell that she was pulling up an audit trail of the computer's use. He loved having a principal who knew her way around the equipment! "Steve," Mrs. Yow asked, "what time did the violation take place?" "Three o'clock," he replied, "right after last period. That's when Mrs. Todd said she got on the computer. Quite a coincidence, huh?" The principal stared at him, "It must have been a coincidence, because the audit trail shows that she's been in her grade book file since 3:02 p.m. No activity before that since eight o'clock this morning." Mrs. Yow frowned at Steve before looking apologetically at the fifth-grade teacher, "I'm sorry Mrs. Todd. He may get carried away sometimes, but he does have a big job in keeping our network safe." She looked back at Steve, "Did you really need to make such a scene when you weren't even sure that you were accusing the right person?" Steve tried to reply, but Mrs. Todd cut him off. "That's okay, he must have really thought he had found the culprit." She laughed, "Me, a computer hacker, isn't that a story?" Steve looked at the woman who now defended him. Just moments earlier, he had wrongly accused her of hacking and had threatened her job. So, she might really be that sweet after all. "Come on, Steve," Mrs. Yow finally said, breaking the silence, "we've got a hacker to identify. This time, no going off half-cocked with accusations until we know what we're talking about." Post-script: Over the next two weeks, Steve and Mrs. Yow monitored a hacker who was masquerading as several different staff members (including Mrs. Yow) and attempting to enter protected report card files. After much analysis, Steve identified a bug in the password software that allowed the hacker to misrepresent himself as an authorized user. Once this was accomplished, they were able to trace the unauthorized activities back to the machine from which the intruder was working- and, subsequently, were able to catch the eighth-grade student who was trying to pull off the charade. After dealing with the troublesome student appropriately (during which time Steve let Mrs. Yow do most of the talking), Steve again apologized to sweet Mrs. Todd for his unwarranted accusations and unprofessional behavior. | ||||||||
| The task of systems 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 seeing "normal" activities and become better able to spot things that are out of the ordinary. 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. Despite the advantages that regular system monitoring provides, some intruders will be aware of the standard log-in mechanisms used by systems they are attacking and will actively attempt to evade these mechanisms. Thus, while regular monitoring is useful in detecting intruders, it does not guarantee that your system is secure and should not be considered an infallible method of detecting unauthorized
use. | ||||||||
A Final (But Very Important) Question A. 1) Read this document and follow the security guidelines as outlined in the checklists at the end of each chapter. 2) Practice, drill, and test each and every security measure being implemented.
Security Management Checklist While it may be tempting to simply refer to the following checklist as your security plan, to do so would limit the effectiveness of the recom-mendations. They are most useful when initiated as part of a larger plan to develop and implement security policy throughout an organization. Other chapters in this document also address ways to customize policy to your organization's specific needs- a concept that should not be ignored if you want to maximize the effectiveness of any given guideline. Security Checklist for Chapter 4
|