As of other aspects of the information processing system, if security planning and management works throughout the entire computer system lifecycle from the initial plan to design, implementation and operation, it will be the most effective and efficient of. A lot of security related events and analysis work will occur in the life cycle. This chapter describes the relationships between them and how to integrate them together. It is also necessary to discuss an important role in helping to ensure that security issues is fully processed.
This chapter exams:
System Security Program, Computer System Lifecycle Components, will safely integrate into the benefits of the computer system lifecycle, and techniques for processing security issues in life cycle.
8.1 Federal System Related Problems Program Program for Computer Security Act is used to assist in ensuring that security issues are completely processed throughout the life cycle. For federal systems, the 1987 Computer Security Act puts a statutory demand for all sensitive systems' computer security programs. The intention and spirit of the bill is to improve the computers of the federal government, not just adding a copy of the writing. In order to achieve this intention, administration and budget (OMB) and NIST are responsible for the planning process of the mechanism, and emphasize the importance of computer security programs and management in institutions and each computer system. As this chapter emphasizes, computer security management should be part of the computer system management. The advantage of having a dedicated computer security program is to ensure that the computer is not ignored.
The bill requested to submit a plan to NIST and National Security Agency (NSA) to inspect and evaluate the completed work. The current guidelines for the implementation of the Act require agencies to deliver their computer security programs. According to the case of the organization, this examination can be internal or external.
"Typical" plan briefly describes systematic security considerations and provides more detailed documents such as system security programs, emergency programs, training programs, approval opinions, event handling plans, or audit results. This allows you to use it as a management tool without repeating the existing file. For smaller systems, it is planned to contain all security documents. As with other security documents, if the plan involves specific defects or other information that may destroy the system, it should be confidential. It should also remain updated.
8.2 Benefits to Integrate Safety to Computer System Life Cycles Although a computer security plan can be developed at any time of the system lifecycle, it is recommended to develop a plan at the beginning of the computer system lifecycle. Like other aspects of the computer system, it is the best way to manage all phases at all computers life cycles. The principle of the computer industry has long agreed that the system has a time in which the increasing characteristic is more than ten times more increased in the initial design phase of the system. Safe deployment during system development is mainly because it is more difficult to deploy (usually doing this more cost). It is also likely to interrupt the continuous operation of the system. Safety also needs to be integrated into the later period of the computer system lifecycle to assist in ensuring security to keep the system environment, technology, procedures, and personnel. It ensures that security issues are taken into account when upgrading the system, including the new components or new modules. Increasing new security controls in security invasion, disaster or auditing, will cause no planned security, which will be more expensive and lack of efficiency more expensive and lack of efficiency than the initial start. It also seriously reduces the performance of the system. Of course, in advance, in advance, all problems in the system life is actually impossible. Therefore, it is usually at least at the end of each phase of the lifecycle, or updates the computer security plan after each re-approval. For many systems, you may need to update more frequently.
In addition to helping to ensure that management activities are fully considering security issues in all phases, security related decisions can also be helped. This record document is useful for system management and inspector and independent auditors. System managers use documents to self-check and decision-making reasons, so it can be easier to evaluate the impact of environmental changes. Inspector and independent auditors use documents in the inspection to verify the fullness of system management work and to highlight security that may be ignored. This includes checking whether the document correctly reflects the actual operation of the system.
In the federal government, the 1987 Computer Security Act and its implementation provided a computer security program demand. These plans are a document form that helps ensure that security issues are considered not only in the system design and development phase, but also consider security issues in other stages of the life cycle. The plan can also be used to meet the needs of Appendix III in the OMB A-130 regulations, as well as other related needs. 8.3 Computer System Lifecycle Overview Computer System Lifecycle Model has a lot, but most of the five basic stages depicted in Figure 8.1.
Starting at the beginning, the need for the system and the purpose of the system are recorded. Development / Purchasing In this stage, the system is designed, purchased, programmed, developed or other forms of forms. This phase often contains other cycles defined, such as system development cycles or procurement cycles. After implementing the initial system test, the system is installed in place. Run / maintenance performs its work at this stage system. Almost always have to modify the system, increase hardware, software, or other major things. Waste When the work to the new computer system is completed, the computer system is discarded.
Each stage can be applied to the entire system, a new component or module, or a system upgrade. As with other aspects of system management, the specific cases of each activity described herein depends on many factors, including scale, complexity, system cost, and sensitivity.
Many people discover the concept of computer system life cycle to be confused because there are many cycles under the big frame of the entire computer system lifecycle. For example, an agency can develop a system using a system development lifecycle. In systemic life, agencies may purchase new components in the purchase life cycle. In addition, the computer system lifecycle itself is only part of the other life cycle. For example, consider the information life cycle. Usually the use of information such as personnel data is longer than a computer system. If an employee has worked for the organization for thirty years, it is necessary to retire for 20 years, and the employee's automation personnel record will probably experience a lot of different computer management systems with the company. In addition, some information is also used in other computer systems, such as the US domestic tax bureau and the US Social Security General Administration.
8.4 Safety Activities in Computer System Life Cycle This section examines the safety activities that occurred at each phase of the computer system lifecycle (see Figure 8.1).
8.4.1 Start determination system concepts and early design processes involve discovery of new system requirements, or enhanced existing systems; initial recommendations of system features and recommended features; freedom of architecture, performance or functional systems Seminar; as well as environmental, financial, political, or other constraints. At the same time, the main issues in system security should be considered in the early days of the system design. This can be carried out by sensitivity assessment.
8.4.1.1 Sensitivity Assessment Sensitivity Assessment The sensitivity of the information processed is examined, and the sensitivity of the system itself is also investigated. Assessment should consider regulatory requirements, institutional policies (if the federal system should include federal and institutional policies), and the functional needs of the system. Sensitivity is usually expressed in integrity, availability, and confidentiality. In assessing sensitivity, it is necessary to investigate the importance of the system's mission, system or data non-powerful changes, leaks, or unused impacts. In order to deal with these issues, people who use or have system or information should participate in the assessment.
Sensitive assessment should answer the following questions:
What information is system processing? Data or system errors, non-powerful leaks, changes or cannot use what kind of potential damage? What are the legal or regulations affect security (such as the Privacy Act or Fair Trade Act)? What threats are particularly fragile? Is there a need for a particular consideration (if the system is in dangerous location)? What security related features have a user group (such as technical master and training level or safety license)? What are the safety standards, regulations or guidelines suitable for systems?
Sensitive assessment is the beginning of safety analysis and runs throughout the life cycle. Evaluation Assistance to determine if the project requires special security inspections, in deciding whether further analysis is required before the system development (to ensure the feasibility of reasonable cost), or in a small number of cases, due to safety requirements, due to the excessive harsh and expensive Continue the development or procurement of the system. Sensitivity assessments can be included in the system initiated document, or part of other planned documents. The guarantee of the security features, procedures, and the following description is based on sensitivity assessment. Sensitivity assessment can also be carried out in the system upgrade (which can be upgraded by procurement or self-developing). In this case, the assessment is focused on the affected areas. If the upgrade largely affects the original assessment, it is possible to analyze its impact on other fields of the system. For example, do you need new controls? Some controls do not have necessary?
8.4.2 Development / Purchasing
For most systems, the development / procurement phase is more complicated than the beginning phase. Security activities can be divided into three parts:
Determine security features, guarantee and running measures; incorporate these security requirements into design specifications; and actually get these content.
These contents apply to the system of autonomous design and build, the system that is purchased, as well as systems developed using mixed mode.
At this stage, technicians and system initiators should work together to ensure technical design reflect the safety needs of the system. In order to coordinate with other system requirements, this process needs to open a dialogue between technicians and system initiatives. This is important for synchronizing and efficiently resolving security requirements throughout the system development.
8.4.2.1 Determining security requirements In the early stages of the development / procurement phase, the system planner defines the needs of the system. Safety requirements should be developed at the same time. Technical features (such as access control) can be used to ensure these needs (such as the background investigation of system developers) or run action (such as conscious training and training). System security requirements are the same as other system requirements, which are derived from legal, policy, applicable standards and guidelines, systematic features, and cost-effective balance.
In addition to specific laws involving information security requirements, such as 1974 privacy bills, legal cases, judicial opinions, and other similar legal information may directly or indirectly affect safety.
If the policy is as discussed in Chapter 5, management officials issues different types of policies. System security requirements are often exported by special policies.
Standards and guidelines for international, national and institutions standards and guidelines are another source of determining security features, guaranteeing and operating measures. Standards and guidelines are often written in the form of "if ...", if the data is encrypted, a specific encryption algorithm should be used. Many institutions have set baseline controls for different system types, such as administrative, tasks or business critical, or patents. Special attention should be paid to interoperability standards as needed.
The functionality of the system requires security purposes to support the functionality of the system, not destroy it. Therefore, many aspects of system functions are related to safety requirements.
Cost Benefit Analysis When it comes to safety, cost-effective analysis is conducted through risk assessment, assessing the assets, threats and defects of the investigation system to determine the most appropriate and cost-effective prevention measures (in accordance with relevant laws, policies, standards and system functions. need). Appropriate prevention measures are usually higher than cost. Yield and cost include money or non-money, such as the avoidance of the loss, the reputation of maintenance agencies, reduce user friendliness, or increase system management.
Risk assessment is the same as cost-effective analysis. It helps managers choose to have cost-effective measures. The degree of risk assessment is the same as other cost-benefit analysis, and should be equivalent to the complexity and cost indicators of the system and the expected earnings of the assessment. Analysis Assessment has a more detailed discussion in Chapter 7.
Risk assessment can be carried out in the design phase of the procurement needs analysis phase or system development cycle. It is usually also evaluated in the development / procurement phase of the system upgrade. One or more risk assessments can be performed according to the method of the project.
It should be noted to distinguish between security risk assessment and project risk assessment. Many system development and procurement projects analyze the risk of successful completion of the project, which is different from security risk assessments. 8.4.2.2 Incorporate safety requirements Incorporate specifications to identify security features, guaranteeing and running measures to get a lot of security information and usually numerous needs. This information needs to be confirmed, updated and organized as system designers or purchases, detailed security requirements and specifications. According to the method system of the development system, such as all or some of the purchasing finished products, specifications can have a completely different form.
Updating initial risk assessments when developing specifications. Risk Assessment Suggestions Prevention measures may be incompatible with other needs, or difficult to implement control measures. For example, security requirements prohibiting dial-up access may prevent employees from leaving their emails after leaving the office.
In addition to the system's technical operation control, it is also involved in guarantees. The required guarantee should be determined early (in order to work with the safety characteristics and measures and work effectively). Once the required guarantee level is determined, it is necessary to indicate how the system will get the test and check to determine if the specification will be met (to obtain the required guarantee). This applies to system development and procurement. For example, if you need a strict guarantee, you need to design the test system or other forms of initial and continuous guarantees to the system, or by other means. See Chapter 9 for more information.
8.4.2.3 Get system and security related activities
At this stage, the system is actually built or purchased. If you build a system, security activities may include development system security, monitor the development process itself to prevent security issues, respond to changes, and monitor threats. Threats or defects in the development phase include Trojans, incorrect code, flexible development tools, manipulation and malicious internal staff of the code.
If it is a system that purchases finished products, safety activities may include monitoring to ensure safety issues in market surveys, contract negotiate documents, and candidate systems. Many systems use development and procurement of mixed mode. In this case, the security activity includes the above two aspects.
When building or purchasing, the choice of the system can affect security. These choices include the selection of specific finished products, ultimately for the determination of the system mechanism, or select the processing site or platform. There may be more security analysis.
In addition to obtaining the system, operational measures are required. This refers to the activities of people around the system, such as emergency programs, conscious training and training, and preparation documents. The chapter of this book runs the control section discusses these contents. This needs to be developed with the system, but it is usually done by different people. These contents should be considered in the initial stage of development and procurement phases.
8.4.3 Implementation may not have a specific implementation phase in some lifecycle plans. (It is often incorporated into the early or running and maintenance of development and procurement.) However, from a secure perspective, a key security activity - approval between development and system start operation. Other activities described in this section, turn on control and testing, often included in the later stage of the development / procurement phase.
8.4.3.1 Installing / On Control is obvious, this activity is often ignored. The system is often disabled in a safe feature when obtaining. This needs to turn on and configure. For many systems, this is a complex work that requires high techniques. Targeted development systems may also require similar work.
8.4.3.2 Safety Test System Security Tests include testing and testing of systems specific parts developed or purchased. The use of safety management, physical facilities, personnel, procedures, commercial or internal services (such as network services), and an emergency plan is an example of an influence of overall system security but may be outside the development or procurement cycle. Because only parts of the development or procurement cycle will be tested in the system receiving test, you may need to separate test or review of these additional security components.
Safety certification is a formal test of safe prevention measures deployed in a computer system to determine if it satisfies relevant requirements and specifications 70. In order to provide more reliable technical information, certification is usually carried out by a separate reviewer rather than by the design system.
8.4.3.3 Approval System Safety Approval is an approval (management) official's official authorization for system operation and clear acceptance of risks. It is usually supported by system management, operation, and technical control. This check can include detailed technical reviews (such as federal information processing standards 102 certifications for complex, critical, critical or high risk systems), safety evaluation, risk assessment, auditing, or other checks. If the lifecycle process is used to manage a project (such as system upgrade), it is important to recognize approval is aimed at the entire system, not just a new part. The best way to see computer security approval is to use it as a form of quality control. It works for forced managers and technicians to discover the best safety methods under a given technical constraint, run constraints and mission. The approval process forces the manager to make a key decision to provide full safety measures. The decisions made by the effectiveness of technological and non-technical prevention measures and the reliable information of residual risks are more likely to be a good decision.
After determining security and residual risk, approval officials should issue formal approval opinions. When most of the disadvantages in system security do not have serious enough to stop the running service or block new systems from entering the running state, the disadvantage may require some limits to run (such as restricted dial-up access or electronic connections to other mechanisms). In some cases, temporary approvals may be performed, allowing the system to run and check at the end of the transition period, and the security upgrade should be completed.
8.4.4 Operation and Maintaining Many Security Activities occur during the operation phase of system life. Typically, this is divided into three parts: (1) safe operation and management; (2) guarantee of operation; and (3) regular reanalysis. Figure 8.2 Describes the process of running phase security activities with a chart.
8.4.4.1 Safety Operations and Management Systems The operation involves many security activities discussed in this manual. Perform backups, organize training courses, manage keys, update user management, and access privileges, and update security software is some examples.
8.4.4.2 Running the guaranteed system is not perfect. In addition, the system user and the operator find a new method to deliberately bypass or subversive security. Changes for system or environment may cause defects. The situation that has always strictly persists the procedures, and the procedures become outdated. It is considered that the risk is small, and the user may want to bypass security measures and procedures.
As shown in Figure 8.2, there is a change. Running guarantees are to understand whether these changes are new defects (or unclear old defects), system changes, or environmental changes. Running is an inspection that the running system is checked to understand whether automatic or manually safe control is running the correct and valid process.
To maintain operational assurance, the organization uses two basic methods: system audit and monitoring. These terms are relatively blurred in the computer security boundaries and often overlap. The system audit is a one-time or regular evaluation of security events. Monitoring refers to the persistent activities of the inspection system or user. Typically, the more "real-time", the more it is, the number of monitors. (See Chapter 9)
8.4.3 Managing Change Computer Systems and Its Operation Environment will continue to change. In response to complaints such as users, new features and services, or new threats and defects, system managers, and user modify the system and add new features, new procedures, and software upgrades.
The environment where the system runs will also change. Network and network interconnections have increased trends. A new user group may be added, which may be an external user group or an anonymous user group. The new threat may appear, such as an increase in network intrusion or the spread of personal computer viruses. If the system has a configuration control committee or other management system technology to change, you can arrange security experts to work in the committee to change whether or not, if any, how. Security issues should also be considered during the system upgrade (and planned changes) and the process of determining the impact of the plan. As shown in Figure 8.2, when it occurs or schedules changes, it is important to determine whether it is significant or smaller. Major changes, such as the structure of the redesign system, will greatly affect the system. Major changes often involve purchasing new hardware, software, services, or development of new software modules. The agency does not need to set the boundaries that determine the major-smaller change. The combination of the following method can be configured to constitute two standards with elastic discrimination.
Major change requires analysis to determine security requirements. The procedure described above can be used, of course, the analysis may only focus on the field that occurs or changes to occur. If the original analysis and system changes throughout the lifecycle are recorded in the document, analysis is generally easy. Because this change source is self-importance, development, or policy changes, the system should be re-approximated to ensure that the risk of residual is still acceptable.
Smaller changes Many changes to the system do not need to perform in-depth analysis like major changes, but still require some analysis. Each change can perform a limited analysis to measure advantages (earnings) and disadvantages (cost), which can even be done on the conference. Even in informal analysis, the decision should still be properly recorded in the document. During this process, even "small" decisions are best based on risk.
8.4.4.4 Regular re-approval is beneficial to system security for system security. Analysis for re-approval should involve this problem: Is safety still full? Need major changes?
Re-approval should involve high-level security and management attention and security implementation. No new risk assessments or certifications are required when re-approval, but these activities are supported by each other (and require regular execution). The wider range of changes in the system, the more wide range of analysis (such as risk assessment or re-authentication). Risk analysis may discover security issues related to system changes. After the system is changed, it may be necessary to test (including authentication). Then if the risk is acceptable, the management will re-approve the system's operation.
8.4.5 Disposable Computer System Life Cycle The abandonment phase involves the disposal of information, hardware and software. Information can be transferred to other systems, archive, discard or destroy. A method of retrofit information should be considered when archive information. Techniques for creating records may not be available at any time in the future.
Hardware and software can be sold, given or discarded. In addition to some storage media containing confidential information, few hardware needs to be destroyed. If necessary, the software's disposal should follow the license and other agreements with the developer. Some licenses are for sites or other protocols that prevent software transfer. It is also possible to take steps to encrypt data for future use, such as taking appropriate steps to ensure long-term and secure storage of keys.
8.5 Interrelationships Like many management controls, the plan for life cycle depends on other controls. Three tight control areas are policies, guarantees and risk management.
Policy to system policy development is an important part of determining security needs.
Guaranteed a good lifecycle management to provide guarantees for security issues in system design and operation.
Risk Management In the system's operational phase of security is a risk management process: analyzing risks, eliminating risk and monitoring preventive measures. Risk assessment is a key part of design system security and re-approval.
8.6 Fees Consider Safety is a feature of the entire life cycle. Sometimes safety options are very casual, no one analysts the reason for the choice; sometimes safety options are made based on analysis. The first case may cause the system to be in a harsh security state and it is easy to suffer a variety of losses. In the second case, the cost of life management is far less than the avoided loss. The main cost of life cycle management is a latency caused by staff costs and in the life cycle to complete the analysis, check, and obtain management approval. It is possible to override the system: unnecessarily spent a lot of time for planning, design, and analyzing risks. The plan itself does not propel the mission or business of the organization. Therefore, although the safety life cycle management can obtain considerable benefits, workloads are also commensurate with the size, complexity, sensitivity, and systematic risk of the system. Typically, the higher the value of the system, the more the system, the technology and measures, the more serious the system after system security fail, the more energy is more energy management in life cycle.
Reference Bibliography Communications Security Establishment. A Framework for Security Risk Management In Information Technology Systems. Canada.
Dykman, Charlene A. ed, and Charles K. Davis, asc ed Control Objectives Controls in an Information Systems Environment:... Objectives, Guidelines, and Audit Procedures (fourth edition) Carol Stream, IL:.. The EDP Auditors Foundation, Inc., April 1992.
. Guttman, Barbara Computer Security Considerations in Federal Procurements: A Guide for Procurement Initiators, Contracting Officers, and Computer Security Officials Special Publication 800-4 Gaithersburg, MD:.. National Institute of Standards and Technology, March 1992.
Institute of Internal Auditors Research Foundation. System Auditability and Control Report. Altamonte Springs, Fl: The Institute of Internal Auditors, 1991.
Murphy, Michael. Handbook of edp auditing, especially chapter 2 "The Auditing Profession," And Chapter 3, "The Edp Auditing Professional." Boston, Ma: Warren, Gorham & Lamont, 1989.
National Bureau of Standards. Guideline for Computer Security Certification and Accreditation. Federal Information Processing Standard Publication 102. September 1983.
National Institute of Standards and Technology. "Disposition of Sensitive Automated Information." Computer Systems Laboratory Bulletin. October 1992.National Institute of Standards and Technology. "Sensitivity of Information." Computer Systems Laboratory Bulletin. November 1992.
Office of management and budget. "Guidance for Preparation of Security Plans for Federal Computer Systems That Contain Sensitive Information." OMB Bulletin 90-08. 1990.
Ruthberg, Zella G, Bonnie T. Fisher and John W. Lainhart IV. System Development Auditor. Oxford, England: Elsevier Advanced Technology, 1991.
Ruthberg, Z., et al. Guide to Auditing for Controls and Security: a System Development Life Cycle Approach. Special Publication 500-153. Gaithersburg, MD: National Bureau of Standards. April 1988.
Vickers Benzel, T. C. Developing Trusted Systems Using DOD-STD-2167A. Oakland, CA: IEEE Computer Society Press, 1990.
Wood, C. "Building Security Into Your System Reduces The Risk of A Breach." LAN Times, 10 (3), 1993. P 47
