LA LECTURA LIBRE COMO ESTRATEGIA EN EL AULA

As discussed previously, standards can minimize the amount of customi- zation of employee workstations and this can minimize the difficulty in performing system and network maintenance. This can be extended further through the use of operating system standards. These standards ar e provided by a number of sources, including the manufacturer, third-party security organizations, and the government. One of the most common sources of operating system standards is the National Institute of Standards and Technology (NIST). NIST provides standard profiles for varying levels of system security configurations for most common operating systems. In some cases, there are utilities to audit the system against the standard configuration and point out where the system configuration is lacking in meeting the required security profile. These standards cover the complete range of operating system security, from the typical workstation to the highly secure server. These standards allow the information security man- ager to have a more detailed account of the modifications necessary to appropriately configure system security. The NIST standards are available from http://csrc.nist.gov.

6.4.2

Change Control Management

One of the most unglamorous areas of information security is the change control process. In many small organizations, change control is omitted altogether and administration changes are made through an ad hoc pro- cess. While not having a change control process reduces administrative overhead, the resulting drawbacks are pretty severe. I know that there were a number of organizations where I was the primary security admin- istrator and spent the first few weeks of the job just running through the existing configurations trying to figure out what the previous administrator had done. This process can be as simple or as complex as your organi- zation requires. In one organization, we implemented a simple change control process wherein a simple paper form was filled out, the changed was discussed at the next staff meeting, and the form was then stored in a folder next to the server on which the change was made. With a small number of servers and a tiny support staff, this process was adequate. With very large companies where the number of information technology support personnel can number in the hundreds or thousands, a process needs to be much more scalable and detailed. A more advanced change control process follows.

Step 1: Request of change is formally made. This requires that the proposed change is documented in written form.

Step 2: Analyze request. After the written request is made, a formal risk assessment may be necessary to determine if the change will have a severe impact on network security.

Step 3: Develop the implementation strategy. During this step, the actual way the change will be made is discussed, responsibilities are defined, and the implementation schedule is devised.

Step 4: Calculate the costs of this implementation. This step will allow for the appropriate budget to be put together to implement the change. A cost analysis may be done to see if the change makes fiscal sense for the organization.

Step 5: Review any security implications. This step determines how the level of risk for the organization will change once the change is made. Often, the change will be made in a development (non- production) environment before the actual change is made to production systems. Having the change made in the development network allows for security testing to be done prior to any changes that would affect the production network.

Step 6: Record change request. In this step, all of the documentation from the previous step is compiled.

Step 7: Submit change request for approval. At this point, all of the documentation is put together and submitted to the information security steering committee for approval.

Step 8: Develop change. If the change requires that code be written or new software be acquired, the basis for the plan is done here.

Step 9: Recode segments of the system. In this step, if the change requires that software be written, then the software is written. This would also be where a new system is developed in the develop- ment network and tested.

Step 10: Link these changes to the formal change control request.

Step 11: Submit software for testing and quality approval. Here, the quality control or quality assurance group would review the change for adequacy.

Step 12: Repeat until quality is adequate.

Step 13: Implementation. The code, system, or configuration change is move into production at this point. If your organization has a formal promotion to production sequence, it should be followed.

Step 14: Update the version information. At this point, all the changes have been implemented, so the next phase is to update the documentation and the user training materials, and to inform the user community of the change.

Step 15: Report changes to management. In this step, tell manage- ment that the change has been made and is working properly. AU1957_C006.fm Page 152 Monday, September 20, 2004 3:23 PM

The process listed above includes many steps that are not needed for all organizations. Each organization is unique and the change control process should be modified to fit the organization. The most important steps are there to ensure that all changes are submitted, approved, tested, and recorded. This ensures that no changes are made without the change control process.

6.5 Monitoring System Access