Handbook of Infosec Terms 2.0

home *** CD-ROM | disk | FTP | other *** search

/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / secpubs / doc-cert.txt < prev next >

Wrap

Text File | 1995-09-15 | 32.4 KB | 854 lines

U. S. DEPARTMENT OF COMMERCE ABBREVIATED CERTIFICATION METHODOLOGY GUIDELINES FOR SENSITIVE AND CLASSIFIED INFORMATION TECHNOLOGY SYSTEMS December 1, 1992 U. S. DEPARTMENT OF COMMERCE ABBREVIATED CERTIFICATION METHODOLOGY FOR SENSITIVE INFORMATION TECHNOLOGY SYSTEMS A. INTRODUCTION It is the policy of the Department of Commerce (DOC) to comply fully with all federal statutes and directives on information technology (IT) security and to provide protection commensurate with the sensitivity of the systems or data processed. Protection requirements for each of the individual IT systems within the Department will vary according to the unique characteristics of the system, environmental concerns, data sensitivity and mission related criticality of the system or data. Appropriate levels of security must be determined by an evaluation of the threats, vulnerabilities and risk factors associated with each system. Cost-effective controls that are adequate to achieve an acceptable level of risk for the individual system must then be implemented. The DOC "Information Technology Accreditation Policy" issued on July 6, 1992 established the requirement for accreditation of all unclassified sensitive and classified national security IT systems. Accreditation is the authorization and approval, granted to a sensitive or classified IT system to process, as an acceptable risk, in an operational environment. Accreditation is made on the basis of recommendations from a technical certification evaluation that the IT system meets all applicable federal and DOC policies, regulations, and standards and that all installed security safeguards appear to be adequate and appropriate for the sensitivity of the system; that they are operating correctly; or, that the system must be operated under certain specified conditions or constraints. The technical certification evaluation results are the basis for the system owner's certification statement in the accreditation request. B. PURPOSE The purpose of this document is to provide guidance on appropriate procedures to follow in performing the technical certification evaluations of all sensitive and classified national security systems within the Department. The DOC issued a "Methodology for Certifying Sensitive Computer Applications" in March 1987. The process described in that document was required for any new DOC applications or any modification of existing applications that handle sensitive information. It is especially suited for large complicated applications, for applications which are in- house developed or involve extensive modifications to customize for Commerce use, applications with very high sensitivity such as major financial applications which process high dollar amounts or are subject to fraud or abuse, or for new applications without existing security documentation. This original certification methodology should be used for systems meeting the above criteria. That methodology has proved to be far too complex for many of the Department's systems. The methodology described in this document is an abbreviated form of this process, developed to address existing sensitive systems with extensive documentation already available. It is intended to handle smaller systems and applications such as those associated with personal computers (PCs) or those systems with only a few users, and turn-key or commercial systems which were procured against a detailed set of security specifications. This abbreviated methodology stresses the use of existing documentation wherever possible. It can be used for completing the technical certification evaluation requirements for both application systems and general support systems. The term "system" used in this document is intended to mean either of the following, as appropriate: 1. Application Systems - Systems that perform clearly defined functions for which there are readily identifiable security considerations and needs. Such a system might actually comprise many individual application programs and hardware, software, and telecommunications components. They can be either a major software application or a combination of hardware/software where the only purpose of the system is to support a specific mission related function. The system may process multiple individual applications, if all are related to a single mission function. 2. General Support Systems - These consist of hardware and software that provide general automated data processing or network support for a variety of users and applications. Individual applications may be less easily distinguishable than in the previous category, but such applications may contain sensitive information, or be critical to the mission accomplishment of the organization. Even if none of the individual applications are sensitive, the support system itself may be considered sensitive if the aggregate of applications and support provided are critical to the mission of the operating unit. C. ABBREVIATED CERTIFICATION METHODOLOGY Certification is based on a technical evaluation of a sensitive system to see how well it meets its security requirements, including all applicable federal policies, regulations, and standards. The results of tests should demonstrate that the installed security safeguards are adequate and appropriate for the system. The certification process is the final step leading to accreditation of the system. Sensitive systems will be recertified and reaccredited when substantial changes are made to the system, when changes in requirements result in the need to process data of a higher sensitivity, after the occurrence of a serious security violation which raises questions about the validity of an earlier certification, and in all cases no less frequently than three years after a previous certification. Certification evaluations are conducted by the organization that owns the system. The certification team should get input from all who have involvement with the system, including: IT security staff, system owner staff, computer program development staff, if the application was developed in-house, and the computer operations staff, if the application is run on a computer managed by a separate organization. users Representatives from as many of these organizations as possible should be included on the Certification Review Team. The certification methodology described in this document consists of the following steps, which will be described more fully in the rest of this document: Step 1. Assemble a team Step 2. Collect existing documents Step 3. Describe the system and its sensitivity Step 4. Identify protection requirements and vulnerabilities Step 5. Identify security features needed Step 6. Test the adequacy of controls Step 7. Evaluate test results Step 8. Certify the system Worksheet forms to document each step in the certification process are provided in Appendix A. Definitions Certification is a technical evaluation of a sensitive system to see how well it meets necessary security requirements, such as appropriate federal policies, regulations, and standards. The Certifying Official is a senior manager in the organization which owns the system. The system owner is the organization which has functional responsibility for the system. The Certifying Official should be a manager who was responsible for having the system developed or the functional area that the system supports, who has a need for the results produced by the system, and can allocate resources to correct deficiencies in the security controls for the system. The Certification Review Team will collect the information needed for the certification process, identify vulnerabilities, develop a list of needed security features, develop tests of the adequacy of the features, and evaluate the test results. Security features are controls that protect against the identified vulnerabilities, such as fire and water alarms, passwords and other access protection, use of removable media for data storage, data validation controls, audit trails, uninterruptable power sources to protect against electrical outages, personnel screening, IT security awareness training of users, etc. A sensitive system is one that requires some degree of protection for confidentiality, integrity or availability. This includes data whose improper use or disclosure could adversely affect the ability of an agency to accomplish its mission, proprietary data, records about individuals requiring protection under the privacy Act, and data not releasable under the Freedom of Information Act. If the system is required for accomplishment of an agency mission it need not contain any sensitive data. Test scenarios are descriptions of the tests to be performed to check the effectiveness of the security features incorporated into the system. They may include validation of password constraints such as length and composition of the password, entry of erroneous data to check data validation controls, review of audit information produced by the system, review of contingency plans and risk analyses, etc. Vulnerabilities are ways in which the system may be attacked or may fail. They include susceptibility to physical dangers such as fire or water, unauthorized access to sensitive data, entry of erroneous data, denial of timely service, fraud, etc. Methodology Approach Step 1 - Assemble a team: The first step in the abbreviated process is to assemble a team to gather the information and documentation needed to assess and demonstrate the adequacy of security measures used. The team should include representatives of IT security, application owners, software development, computer systems, and users. For very small systems the users, software programming staff, and computer systems staffs may be the same. The IT security staff provides an outside viewpoint to ensure that the best IT security practices are used in protecting sensitive systems. Where computer system staff, software programmers, and users are in separate organizations, it is important that all points of view are represented in the process, to ensure that user expectations of protection needs are addressed, and that software and computer system constraints are understood. Step 2 - Collect existing documents needed for the certification evaluation: These documents include, but are not limited to: 1. system specifications and documentation 2. system security plan 3. risk analysis 4. contingency and disaster recovery plans 5. staff records on personnel and the IT Security Officer identification, training and position sensitivity levels 6. Internal Control Reviews, security reviews, etc., if existing Step 3 - Identify and describe the system to be certified and describe why it is sensitive: It is necessary to have a written description of the purpose of the system, the hardware and software environment on which the system is operated, and a description of the sensitivity of the system, including any special applicable laws and regulations. This information is readily available in the Sensitive System Security Plan for the system being certified. If the certification is for a software application system that will be used by others, the hardware description should address the hardware needed to operate the system, but the certification should focus on the software application program. Complete the blank sections of Sensitive System Certification Worksheet 1, System Description and attach a copy of the approved Sensitive System Security Plan for the system being evaluated. The Worksheet identifies the section numbers in the security plan where detailed information can be obtained for review. Step 4 - Identify protection requirements and vulnerabilities: Review the description of the protection requirements for the system under the headings confidentiality, integrity, and availability in Section II.B. of the Sensitive System Security Plan. Enter the levels of protection required (high, medium, low) in the blanks provided on Worksheet 1. Identify vulnerabilities for the system related to these protection requirements. Most vulnerabilities will be addressed in the existing documents collected in Step 2. All sensitive systems should have a completed risk analysis. The risk analysis will identify vulnerabilities and their consequences, such as unauthorized disclosure of information, loss of data or other resources, denial of service, decisions based on erroneous information, etc. System documentation is another source of information about the vulnerabilities. The security plan for the system being evaluated contains information about specific vulnerabilities and control measures addressed. The team should also review any existing Internal Control, Inspector General (IG) or security review reports on the system, for additional information on system vulnerabilities. In addition to the documentation, the team may need to interview managers in the user organization to ascertain their concerns about the sensitivity of the system and the level of protection required. Complete the Sensitive System Certification Worksheet 2: Identified Vulnerabilities by listing the identified vulnerabilities. Step 5 - Identify security features needed: The team next needs to review existing documents to identify the controls in place to address the vulnerabilities identified above. The risk analysis, security plans, and system documentation reviewed for vulnerabilities also contain information on controls used to reduce those vulnerabilities. System specifications, if they still exist, will also provide information on the controls designed into the system. The team will also need to review the contingency and disaster recovery plans for the system. The team should interview the IT System Security Officer to review installation IT security procedures. Staff training records will show the level of IT security training given to application and computer installation staff. Staff records should also show the sensitivity designation of staff positions and any personnel investigations, required and conducted, for staff in the affected positions. Complete the Sensitive System Certification Worksheet 3: Security Features. Step 6 - Test adequacy of controls: Once vulnerabilities and controls have been identified, the team should selectively check the adequacy of the controls. Some live tests may be needed to ensure that documented controls actually work. Other controls may be reviewed through other means. Previous system reviews and system acceptance tests may contain records of tests previously performed. It is not necessary to repeat these tests, if the system has not changed since they were done. The review of vulnerabilities and controls should identify any areas not adequately addressed. Sensitive System Certification Worksheet 4: Security Tests is used to list the tests to be performed. Use Sensitive System Certification Worksheet 5: Security Test Results to record the results of the tests. Step 7 - Evaluate the test results: Once all tests are completed, a summary of the evaluation of the tests should be prepared. The team should then prepare recommendations about certification. Sensitive System Certification Worksheet 6: Evaluation and Recommendations is used to record the evaluation of test results and the team's recommendation. The recommendation section should be signed by all members of the team and dated. If the tests results indicate that all protection requirements have been met, the team can recommend certification with no further action required. The Certification Review Team may determine from the test results that the protection requirements were not met for the system. In that case, the evaluation discussion of test results should explain the inadequacy of the controls in place. The team may alternatively certify that the basic protection requirements have been met, but recommend additional features be required. This latter form of certification is appropriate for certifying a software application system which must have certain operating system or hardware features in place for approved operation. This may also be used in recommending interim accreditation pending installation of some additional control not currently available. Step 8 - Certification: The official Certification document is signed by a senior management official in the system owning organization. A sample certification document is attached as Appendix B. There may be situations when the need for a system is such that it must be put into operation before a full certification is possible. In this case, the Certifying Official can provisionally certify the system for operation, possibly with some restrictions, pending specific actions to be completed in a predefined time frame. This interim certification cannot exceed one year. These actions should also be included as milestones in the security plan for the system. The certification process must be flexible enough that it accommodates the need for operational efficiency as well as adequate protection of the system. APPENDIX A SENSITIVE SYSTEM CERTIFICATION WORKSHEETS This Appendix contains a set of six worksheets to assist with documenting the certification evaluation of the system. Each worksheet is preceded by a set of instructions and definitions which will provide guidance for completing the evaluation and the worksheet. DIRECTIONS FOR COMPLETING WORKSHEET 1: SYSTEM DESCRIPTION Much of the information requested on Worksheet 1 is contained in the Security Plan for the system. To avoid having to rewrite this information and have a ready reference to the needed information, attach a copy of the Security Plan behind Worksheet 1. Each worksheet contains blank lines, where information must be entered. This step is important to avoid confusion with other system certification evaluation documentation. System Name/Title is the name of the system used in the Security Plan for a sensitive system (Section I.B of the Security Plan). To avoid confusion with other certification evaluation documentation this should be written on all worksheets. System ID is the unique six digit system identification number assigned for each sensitive system in the Department. Again, to avoid confusion with other certification evaluation documentation this should be written on all worksheets. System Owner is the name of the contact person in the owning organization who is knowledgeable about the system and protection requirements. It may be the person listed as Information Contact (Section I.G) in the Security Plan. Provide full address and phone number, including area code, for the owner. Developer is the name of the person who is responsible for developing the software. If this is a commercial application, put the name of the organization in this space. If there is no developer or the developer's name is unknown, put "none" in this space. General Description/Purpose is a description of the function and purpose of the system. This information is contained in Section I.E of the Security Plan. System Environment and Special Considerations is a description of the computer and software environment of the system. This information is contained in Section I.F of the Security Plan. Sensitivity of Information Handled describes why the system is sensitive. Applicable Laws and Regulations lists any laws and regulations that specifically apply to this system, such as the Privacy Act. This information is contained in Section II.A of the Security Plan. General Description of Information Sensitivity is a description of why the system is sensitive and the nature of that sensitivity. This information is contained in the introduction to Section II.B of the Security Plan. Description of Protection Requirements describes what makes the system sensitive. The descriptions of protection needs for confidentiality, integrity, and availability are contained in Section II.B of the Security Plan. Write in the designated level (high, medium, low) in the blanks provided. SENSITIVE SYSTEM CERTIFICATION WORKSHEET 1 SYSTEM DESCRIPTIONSystem Name/TitleSystem ID: System Owner Address: ______________________________________________________ _________ ______________________________________________________ _________ Phone: ______________________________________________________ _________Programmer/Developer: Address: ______________________________________________________ _________ ______________________________________________________ _________ Phone: ______________________________________________________ _________General Description/Purpose (See Section I.E. of attached security plan.) System Environment and Special Consideration (See Section I.F. of attached security plan). Sensitivity of Information Handled: Applicable Laws and Regulations Affecting the System (See Section II.A. of attached security plan.) General Description of Information Sensitivity (See Section II.B. of attached security plan.) Description of Protection Requirements See Section II.B. of attached security plan and fill in the designated level (high, medium, low) in the blanks. Confidentiality ______ Integrity ______ Availability ______ DIRECTIONS FOR COMPLETING WORKSHEET 2: IDENTIFIED VULNERABILITIES System Name/Title and System ID are the same as on Worksheet 1. Description of Identified Vulnerabilities should include the vulnerabilities that the system may have prior to putting controls in place. These should have been identified in the risk analysis. They might include physical vulnerabilities such as fire or disk crashes, entry of erroneous data, denial of service, and unauthorized access to information. SENSITIVE SYSTEM CERTIFICATION WORKSHEET 2 IDENTIFIED VULNERABILITIESSystem Name/TitleSystem ID: Description of Identified Vulnerabilities (From Risk Analysis, Security Plan, system documentation, interviews and other review reports - Risks that exist prior to putting any controls in place) DIRECTIONS FOR COMPLETING WORKSHEET 3: SECURITY FEATURES System Name/Title and System ID are the same as on Worksheet 1. Description of Security Features is a list of the security features used to protect this system. They can be taken from Sections III.C of the Security Plan and include Management Controls, Development/Implementation Controls for application systems, Acquisition/Development/Installation Controls for general support systems, Operational Controls, Security Awareness and Training, Technical Controls and Complementary Controls Provided by General Support Systems for application systems or Controls Over the Security of Applications for general support systems. Although, it is not necessary to include the level of detail contained in the Security Plan, the controls should be listed to provide a foundation for selecting tests to be performed to verify if the controls are adequate and appropriate and are operating as expected. SENSITIVE SYSTEM CERTIFICATION WORKSHEET 3 SECURITY FEATURESSystem Name/TitleSystem ID: Description of Security Features: DIRECTIONS FOR COMPLETING WORKSHEET 4: SECURITY TESTS System Name/Title and System ID are the same as on Worksheet 1. Test Scenarios should contain a numbered list of the tests to be preformed to verify the controls listed on Worksheet 3. For more detail about the controls, see Section III.C. of the security plan. If this is an existing system that has been in operation for some time, the tests may selectively test the most critical controls. If the system is under, or just completed development, or is a turn-key system, all security controls should be tested. If testing has been done for a another recent review, or during recent acceptance testing of the system, it may not be necessary to repeat the tests. It will be necessary to review records of the prior tests, and determine if the documentation of the tests and results are adequate. If it is determined that it is not justified to repeat the tests, a statement should be included on Worksheet 4 explaining the reason. Also, include enough information about all supporting documentation reviewed, to allow it to be located for future reference. At a minimum, include a list of tests from the documentation, that were performed. This list need not contain as much detail for each individual test as the referenced documentation. SENSITIVE SYSTEM CERTIFICATION WORKSHEET 4 SECURITY TESTSSystem Name/TitleSystem ID: Test Scenario: DIRECTIONS FOR COMPLETING WORKSHEET 5: SECURITY TEST RESULTS System Name/Title and System ID are the same as on Worksheet 1. Test Results reports the results of each of the tests described on Worksheet 4. The numbers on Worksheet 5 for each test result should agree with the numbers on Worksheet 4 for the test description. Indicate whether the was "Passed" or "Failed". SENSITIVE SYSTEM CERTIFICATION WORKSHEET 5 SECURITY TEST RESULTSSystem Name/TitleSystem ID: Test Results: DIRECTIONS FOR COMPLETING WORKSHEET 6: EVALUATION AND RECOMMENDATIONS System Name/Title and System ID are the same as on Worksheet 1. Evaluation of Test Results should discuss the results of the tests and their relationship to assuring the adequacy of controls. Under Recommendations check one of the three responses. Check Tests indicate that protection requirements were met if all tests resulted in correct results. Check Tests indicate that protection requirements were not met if some tests failed and corrections have not been, or cannot be implemented. Check Tests indicate that protection requirements were met; recommend certification with the following additional security features required: if there are additional security controls needed to meet the protection requirements. This category should be used when certifying software applications that require hardware or operating system features to assure adequate protection. It should also be used if an interim certification is being recommended, pending completion of specific actions. Certifying Team Signatures should included printed names of the certifying team members, a signature, and a date for each team member. SENSITIVE SYSTEM CERTIFICATION WORKSHEET 6 EVALUATION AND RECOMMENDATIONSSystem Name/TitleSystem ID: Evaluation of Test Results: Recommendations: _____ Tests indicate that protection requirements were met. RECOMMEND CERTIFICATION OF THIS SYSTEM. _____ Tests indicate that protection requirements were not met. RECOMMEND THAT THIS SYSTEM NOT BE CERTIFIED. _____ Tests indicate that protection requirements were met; recommend certification with the following additional security features required: Certifying Team Signatures Name Signature Date _______________________________________________________________ ____________ _______________________________________________________________ ____________ _______________________________________________________________ ____________ Appendix B Sample Certification Statement I have carefully examined the certification worksheets for DOC Information Technology System Number _________, "Insert system name/title", dated ___________________ . Based on the information contained in this package and the results of tests conducted on the system, it is my judgment that satisfactory information technology controls are in place to adequately protect the system and that it is operating at an acceptable level of risk. I hereby certify DOC IT System Number ________, "Insert system name/title", for a period not to exceed three years. Should substantial changes or security incidents occur during that three year period, which bring the adequacy of the protection measures for this system into question, a reevaluation and recertification must be completed earlier. Certification Official Name/Title: ______________________________________________ ______________________________________________ Signature: _____________________________________________ Date: ____________