¤ Design security and control procedures
Security and control procedures may be an integral part of the existing computer environment. General procedures may therefore also apply to any new environment installed for a new business system. The new business system must incorporate these general procedures in its design, but it may also require the introduction of new procedures, particularly in the areas of logical access control and system integrity. The level of security to be provided by these procedures has been identified in BSD.
Identify an individual within the user department who will have responsibility for security in the new business system. This person, who should be a senior user, will eventually have responsibility for authorizing new users and reviewing security reports. The person is identified at this stage so that the design and construction of the business system security processes can be supervised by a responsible individual.
» Creates deliverable D4.26.1 Security And Control Procedures.
¤ Design security modules
Security features are normally included in the business system when the required security level is not available from a system product or when the integrity of the system software product may be compromised. For example, if a very high level of internal security is required and the system software product security must be administered by the computer system rather than by business-unit personnel, it may be necessary to include an additional level of security in the business system.
Security facilities within the business system must be designed in separate modules to business process code. Ideally, they should fit independently into the software structure, and the structure should be designed in order to prevent operation without the security module. This may necessitate some rework of the software structure. All action diagrams must be amended to accommodate the security requirements, which must also be tested.
- Attempted Security Violations -
When an attempt is made to violate security, the attempt must be reported to the security officer. It is unlikely that an individual security officer will be on duty 24 hours a day, 365 days a year. Clerical instructions must be written to be used by any person to whom the computer may report an attempted security violation. Instructions should include how to recognize a security violation and what to do about it. The person concerned must have these instructions.
» Creates deliverable D4.26.2 Security Modules Specification.
¤ Design contingency procedures
Contingency procedures are effective when the computer system has failed or has experienced a partial failure. The level of contingency planning depends on the criticality of the business system. Critical business processes require that mirror images of the data and processes prevent any system down time. Systems not critical to daily business processes may await recovery of the computer system.
When designing contingency procedures, the technical design team must determine the criticality of the business system in terms of the acceptable time the business may be without the system. If the business must always have the system available, then the processing and data must be duplicated and on-line constantly. If only a portion of the business system is critical, then contingency plans should be developed for only that portion. Recovery plans should be developed for the remaining portion of the system that did not operated during the system failure.
ð Updates deliverable D4.1.1 Procedure Definition.
¤ Select recovery techniques
Designing and constructing recovery software are complex and costly activities, and should be unnecessary. Transaction logging and recovery should be a feature of the database or teleprocessing software. Both roll-forward and roll-back recovery should be available.
- Backup - Procedures have been devised for maintaining backup copies.
Clerical instructions must be produced to document the parts of the procedures not performed by the computer. They include such information as when to make a backup copy, what to make it of, and where to keep it. It is likely that these instructions will detail in which safe and/or bank the copy is kept and how to put it there.
- Recovery - Clerical instructions must be written to address the following topics:
* How to recognize that recovery is required and whom to tell
* How to work with personnel concerned with fallback and who these people are
* How to identify which backup copies are required (which versions of what files)
* How to get the copies from the safe or bank (subject to security measures)
* What computer runs to perform
* How to recognize successful recovery and whom to tell
* What procedures to adopt to return to normal running (working with fallback personnel)
- Fallback - The following topics must be addressed in clerical instructions:
* How to recognize an error
* How to tell that recovery is required
* Whom to inform to have recovery initiated
* Which existing procedures to discontinue while awaiting recovery
* What fallback procedures to use
* How to change from existing procedures to fallback
* How to change from fallback to existing procedures
* What additional procedures are required as a result of recovery, when existing procedures are resumed
¤ Identify backup points
The operation of a business system can be divided into a number of processing cycles. A processing cycle is normally time based (e.g., daily, weekly, monthly and annual backups). The objective of contingency procedures is to recover system data after a failure.
To do this, you must repeat the processing in a cycle that rebuilds a copy of the data. It is desirable to be able to offer more than just the last cycle. For example, in a system with daily, weekly, half-yearly and annual cycles, you may keep daily backups for the last ten days, weekly backups for the last six weeks, and the last half-yearly and yearly backups.
¤ Select performance monitoring measures
To meet the objectives for which it was designed, the business system must maintain an effective operating level. System availability, throughput and response time must be maintained at the required level. To maintain the required operating level, the performance of the system must be monitored and recorded constantly. Performance can be reviewed in terms of computer performance, business system performance and system operator actions.
The most important system performance can be measured in terms of how many times users experience system errors and how many times users request help. Analysis of these measures may intimate adjustments to user training or the system to provide more effective support.
» Creates deliverable D4.27.1 Performance Monitoring Measures.
¤ Design Performance Monitoring Procedures
Performance monitoring should be designed in separate modules, and it should be possible to switch it off in certain circumstances.
Manual procedures must be designed to record and analyze the performance measures. Plotting key performance indicators can show dramatic changes or trends that will affect response time before they are noticed by the terminal user.
» Creates deliverable D4.27.2 Performance Monitoring Procedures.
¤ Design operating instructions
The business system will consist of on-line modules and batch-process modules that may operate at any number of locations. To assure that the system and its data are fully supported when the business requires support, a schedule of operations is required. The technical design team must:
* Determine the required schedule of availability of system support required by the business
* Determine the allowable lag in data concurrency as determined by the business cycle
* Determine the schedule of data-bridging updates, batch processing and on-line processing that satisfies the (above stated) business requirements
* Determine the schedule of database backup operations compatible with
the operating schedule and provide the required data protection
Previous : A4.13.3
Activity Overview : A4.13
Stage Overview : Design Stage
Overview : Table of Contents