Pension Benefit Guaranty Corporation INFORMATION ASSURANCE HANDBOOK VOLUME 14 SECTION II RISK ASSESSMENT PROCEDURES

VERSION 1.0 May 2007

Prepared by: PBGC Office of Information Technology (OIT) Enterprise Information Security (EIS) 1200 K Street NW Washington, DC 2005

PBGC IAH - Volume 14

Risk Assessment

ANNUAL REVIEW RECORD The following Risk Assessment Procedures should be reviewed at least annually and the date recorded on the table below. Review Date Reviewer

RAP Version 1.0 i

May 2007

PBGC IAH - Volume 14

Risk Assessment

Change/Review Record
Document Title: IAH Volume 14 –Risk Assessment Procedures Date of Initial Release:
Version No. Date Revised Version 1.0 Completed by: Approved by: Michael Zacour Version No. Date Revised Completed by: Approved by: Version No. Date Revised Completed by: Approved by: Version No. Date Revised Completed by: Approved by: Description of Revisions Date: Date: May 14th, 2007 Description of Revisions Date: Date: Description of Revisions Date: Date: Description of Revisions Date: Date:

RAP Version 1.0 ii

May 2007

PBGC IAH - Volume 14

Risk Assessment

TABLE OF CONTENTS
1 INTRODUCTION............................................................................................................. 1 1.1 Background ......................................................................................................................... 1 1.2 Purpose................................................................................................................................ 1 1.3 Scope and Applicability...................................................................................................... 1 2 2.1 2.2 2.3 2.4 3 3.1 3.2 3.3 3.4 3.5 PROCESSES ..................................................................................................................... 2 Security Categorization....................................................................................................... 2 Risk Assessment ................................................................................................................. 3 Risk Assessment Update..................................................................................................... 4 Vulnerability Scanning ....................................................................................................... 4 PROCEDURES ................................................................................................................. 7 Security Categorization....................................................................................................... 7 Risk Assessment ................................................................................................................. 8 Risk Assessment Update................................................................................................... 10 Vulnerability Scanning ..................................................................................................... 11 Compliance ....................................................................................................................... 14

APPENDIX A: ACRONYMS .................................................................................................... 15 APPENDIX B: RISK ASSESSMENT TEMPLATES & INSTRUCTIONS ......................... 16 APPENDIX C: SAMPLE VULNERABILITY SCANNING TOOLS ................................... 35

RAP Version 1.0 iii

May 2007

PBGC IAH - Volume 14

Risk Assessment

1 INTRODUCTION
1.1 BACKGROUND
Based on Federal statutes, regulations and mandates, the Pension Benefit Guarantee Corporation (PBGC) is responsible for ensuring that all PBGC information systems meet the minimum security requirements defined in the Federal Information Processing Standards (FIPS) Publication (PUB) 200, Minimum Security Requirements for Federal Information and Information Systems. All PBGC information systems 1 must meet the security requirements through the use of the security controls in the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, “Recommended Security Controls for Federal Information Systems”. The Office of Information Technology (OIT), Enterprise Information Security (EIS) has developed Risk Assessment procedures to ensure the Confidentiality, Integrity and Availability of its information and information systems. These procedures ensure that NIST guidance on risk assessments for Federal information systems is appropriately implemented. Sections I and II of this volume address the policies and procedures/standards set forth by PBGC and, in compliance with, the risk assessment family of controls found in NIST SP 800-53. The controls are then documented in the SSP. Final selection of security controls must be compliant with Federal statutes, regulations, mandates, and PBGC Information Assurance Handbook (IAH) Volume 12, Security Planning, Section I.

1.2 PURPOSE
The purpose of these procedures is to provide guidance on implementing PBGC policy for security risk assessment as defined in Section I of this volume.

1.3 SCOPE AND APPLICABILITY
The procedures in this document are applicable to all information technology (IT) systems operated by or on behalf of PBGC and are intended to address the security of PBGC IT systems. Non-IT system security risk assessments, such as program risk assessments, are not addressed in this volume.

1

Information System(s) refers to General Support Systems and Major Applications.

RAP Version 1.0 1

May 2007

PBGC IAH - Volume 14

Risk Assessment

2 PROCESSES
The PBGC risk assessment processes are based on applicable NIST guidance, including SP 80030,”Risk Management Guide for Information Technology Systems”, SP 800-42, “Guideline on Network Security Testing”, and SP 800-60, “Guide for Mapping Types of Information and Information Systems to Security Categories”. The information described in the aforementioned guides allows for consistent application of the risk assessment processes for security categorization, risk assessment, risk assessment update, and vulnerability scanning.

2.1 SECURITY CATEGORIZATION
The FIPS 199 security categorization identifies the sensitivity and impact level of the information contained in Federal information systems. This categorization process is necessary to determine the minimum baseline security controls required by Federal statutes to adequately protect the information contained in the system. A FIPS 199 security categorization must be completed in the Initiation Phase of the Information Technology Solutions Life Cycle Methodology (ITSLCM) to ensure that the most cost effective strategy is employed. The FIPS 199 security categorization must then be reviewed annually or when a significant change occurs to the system to ensure that changes have not altered the overall security categorization of the system. The process begins by evaluating the security needs of the system and the protections required for the mission and information held. The Federal Enterprise Architecture (FEA) Business Reference Model (BRM) provides an aid to identifying information contained in the system. The BRM indicates the type of information on the system based on the business area and line of business of the system. NIST SP 800-60, Volume I and II, provides guidance to identify the security categorization of the information for each security objective (i.e., confidentiality, integrity, availability). While NIST SP 800-60 provides a recommended level for the security categorization, additional security considerations may be required by department senior management. All applicable Federal laws and acts must be applied to ensure the proper security categorization of PBGC information systems. The Information System Owner then uses the resulting characterization to determine the appropriate minimum security control baseline and system specific security controls to use for protecting the information resources. Systems that are under development must use the minimum security controls baseline as requirements; systems in production must ensure that the security controls required by the minimum security controls baseline are in place and operating effectively in accordance with their security categorization. The controls are documented in a system security plan (SSP), IAH Volume 12, Security Planning.

RAP Version 1.0 2

May 2007

PBGC IAH - Volume 14

Risk Assessment

2.2 RISK ASSESSMENT
The PBGC risk assessment (RA) process was developed based on NIST SP 800-30. The process uses the following nine steps to evaluate the threats, vulnerabilities, and security controls surrounding the information system as well as the likelihood of an exploit and the impact it will have to system operations. • • • • • • • • • System Characterization Threat Identification Vulnerability Identification Security Control Analysis Likelihood Determination Impact Analysis Risk Determination Security Control Recommendations Risk Assessment Results Documentation

The process begins by characterizing the system. The system boundaries are identified and the system operating characteristics are described. The FIPS 199 security categorization, or impact level, are identified to aid the assessor in establishing the minimum security control requirements. Once the system has been characterized, the threats to the system are identified. This includes all threats to normal operations and includes environmental, human, and natural threats. The source of the threat is also identified and characterized to determine the motivation, available resources, and capabilities of the threat so that a better evaluation of the threat can be performed. The next step is to identify the vulnerabilities in the system that might allow for the system to either be misused or otherwise render the system unable to meet the mission objectives. The vulnerabilities are paired with the identified threat sources to create threat source/vulnerability pairs that are used throughout the analysis. The vulnerability list should be comprehensive and be based on all available sources. The threat action or activity that the threat source could execute to exploit the vulnerability is also listed here. Following the identification of the threats and vulnerabilities, the existing and planned security controls are evaluated. The current state of the security controls is analyzed. Each recommended control provided in NIST SP 800-53 is analyzed to determine the current status of the control. Based on the threat source/vulnerability pairs, the controls are matched to determine the level of protection the system currently has in place for a particular threat source/vulnerability pair. The likelihood that the vulnerability be exploited by the paired threat source will be exploited is then determined for each threat source/vulnerability pair. In a similar manner, the threat source/vulnerability pairs are then evaluated to determine the impact to system operations, if exploited. The impact analysis is based on the FIPS 199 security categorization impact level to the system. The security categorization process determines the maximum impact rating for the security objectives of confidentiality, integrity, and availability for the information
RAP Version 1.0 3 May 2007

PBGC IAH - Volume 14

Risk Assessment

system. The high water mark from the three security objectives determines the maximum impact rating to the system and is used to analyze each threat source/ vulnerability pair. Based on the analysis provided in the likelihood determination and the system impact rating, the risk determination is generated to demonstrate the final risk level for each threat source/vulnerability pair. The threat source/vulnerability pair residual risk levels allow the assessor to further examine the security controls. The analysis of the security controls will allow the assessor to make a recommendation as to the adequacy of the in-place controls of the system and to recommend any corrective action to lower the residual risk of each source/vulnerability pair. Finally, the resulting documentation is used to summarize the activities and results associated with the risk assessment. The results are analyzed by the assessor and used to develop a conclusion of the final risk rating of the system based on the analysis of all threat source/vulnerability pairs and the status of the controls. A final residual risk description and rating should be provided. The results are then taken and incorporated into the risk assessment report which is presented to the Designated Approving Authority (DAA), Information System Security Officer (ISSO), and Information System Owner for review and action.

2.3 RISK ASSESSMENT UPDATE
The PBGC RA update process is comprised of two ongoing procedures. The first procedure incorporates the change management process to evaluate all changes to the system. A change to the system that results in a significant change to the operating environment of a major information system, which possibly alters the overall level of risk previously accepted by the DAA, necessitates an update to the RA and must be evaluated to determine if it requires a new certification and accreditation. The second procedure related to RA update requires a review of the RA on a periodic basis, but not less than annually. The risk characteristics of an information system may change on a regular basis; therefore, PBGC requires that the RA for each major information system be reviewed and updated annually to reflect the current operating environment of the system. Once the update is performed, the Information System Owner and ISSO review the document, document the activities as part of the continuous monitoring program, and provide an updated copy to the Senior Agency Information Security Officer (SAISO).

2.4 VULNERABILITY SCANNING
Vulnerability scanning is a critical component of managing information system risk and is a part of an overall vulnerability management program. A vulnerability is an area that is susceptible to attack and may be a bug, error in configuration, or special set of circumstances that could result in an attacker or threat being able to exploit the information resources for unauthorized purposes. Vulnerability scanning is the automated process of proactively identifying vulnerabilities of computing systems in a network in order to determine if and where a system can be potentially exploited.

RAP Version 1.0 4

May 2007

PBGC IAH - Volume 14

Risk Assessment

Vulnerability scanning employs software that seeks out security flaws based on a database of known flaws, testing systems for the occurrence of these flaws, and generating a report of the findings that an individual or Information System Owner can use to tighten the network’s security. Vulnerability scanning provides information on the associated vulnerabilities. Most vulnerability scanners attempt to provide information on mitigating discovered vulnerabilities. Vulnerability scanning can also help identify out-of-date software versions, applicable patches, and system upgrades, and then validate compliance with, or deviations from, PBGC’s security policy. Generally, vulnerability scanning identifies only surface vulnerabilities (i.e., a weakness as it exists in isolation and independent from other vulnerabilities) and is unable to address the overall risk level of a scanned network. Risk levels provided by vulnerability scanning tools should be considered; however, they should not be used in place of risk levels determined a part the security risk assessment. Although the scan process itself is highly automated, vulnerability scanners themselves can have a high false positive error rate (i.e., reporting vulnerabilities when none exist). This means an individual with expertise in networking and operating system security and system administration must interpret the results. Vulnerability scanners tend to generate significant network traffic. This may have a negative impact on the hosts or network being scanned or network segments through which scanning traffic is traversing. Many vulnerability scanners also include tests for denial of service (DoS) attacks that, in the hands of an inexperienced tester, can have a considerable negative impact on scanned hosts. In general, DoS tests should always be disabled when vulnerability scanning is performed. As a result of this, extra steps and efforts should be taken to coordinate vulnerability scan activities with operation staff and incident response teams. Another significant limitation of vulnerability scanners is that they rely on constant updating of the vulnerability database in order to recognize the latest vulnerabilities. Before running any scanner, the ISSO should install the latest updates to its vulnerability database. Some vulnerability scanner databases are updated more regularly than others. The frequency of updates should be a major consideration when choosing a vulnerability scanner. Only designated individuals, including network administrators, the ISSO, or individuals contracted to perform the scanning, should conduct vulnerability scanning. The Information System Owner should develop a written rules of engagement document that outlines the proposed and authorized activities. The approval for the scans and the rules of engagement may need to come from the Information System Owner and OIT senior management depending on the extent of the scanning. For vulnerability scan activities that include coordination with parties outside of the department, the PBGC Computer Emergency Response Team (CERT) should be contacted to coordinate cross department activities. Additional precautions should take place for performing scans external to PBGC. External monitoring departments such as US-CERT as well as Internet Service Providers (ISPs) may need to be notified in advance of such activities. It would be customary for EIS to alert other security officers, management, as well as system and network administrators that vulnerability scanning is taking place. Since some types of

RAP Version 1.0 5

May 2007

PBGC IAH - Volume 14

Risk Assessment

vulnerability scans mimic some signs of an attack, the appropriate management must be notified to avoid confusion and unnecessary expense. Vulnerability scanners can be of two types: network-based and host-based. Network-based scanners are used primarily for mapping the PBGC’s network and identifying open ports and related vulnerabilities. In most cases, these scanners are not limited by the operating system of targeted systems. The scanners can be installed on a single system on the network and can quickly locate and test numerous hosts. Host-based scanners have to be installed on each host to be tested and are used primarily to identify vulnerabilities in specific host operating system and application configurations. Because host-based scanners are able to detect vulnerabilities at a higher degree of detail than network-based scanners, they usually require both host (local) access, and even “root” or administrative access. Some host-based scanners offer the capability of repairing misconfigurations. In general, automated repairing of configuration errors should always be disabled when host-based vulnerability scanning is performed. Active vulnerability scanning involves assessing the information system with the use of automated assessment tools. As previously mentioned, these tools identify known weaknesses and often suggest ways to remediate the vulnerability. Active vulnerability scanning is more common than passive vulnerability scanning, but passive vulnerability scanning is gaining ground. Passive vulnerability scanning involves monitoring network traffic at the packet level. This is performed similarly to an intrusion detection system by sniffing the network traffic on a hub, through a spanned port on a network switch or through a network tap. When initially deployed, the passive vulnerability scanner will observe network traffic for a specified period of time and establish a baseline for systems and traffic patterns and later report on deviations to the baseline. The passive vulnerability scanner can also reconstruct TCP/IP sessions and evaluate the session for known vulnerabilities. The passive vulnerability scanner has an added benefit of having no negative impact on a system. Passive vulnerability scanning augments active vulnerability scanning and in no way replaces it. When utilized simultaneously, active and passive vulnerability scanning can further identify vulnerabilities and weaknesses within an Information System.

RAP Version 1.0 6

May 2007

PBGC IAH - Volume 14

Risk Assessment

3 PROCEDURES
3.1 SECURITY CATEGORIZATION
A productivity aid is provided for all PBGC information systems to assist with the FIPS 199 security categorization of the system. This aid must be utilized during the Initiation Phase of the ITSLCM in accordance with Federal statutes, regulations, mandates and PBGC directives. This aid must also be used to complete a reevaluation of either the information types contained in the system or the FIPS 199 security categorization of the information resources. The security categorization is then used throughout the remainder of the life cycle of the system to determine the potential security impact to PBGC. Procedure 1: Determine FIPS 199 Security Categorization PBGC information systems must be categorized according to NIST SP 800-60 guidance, unless otherwise indicated by EIS. If the NIST recommendation is determined by the DAA and the Information System Owner and it does not accurately reflect the security needs of the information system, a documented alternate analysis of the security categorization of the information system must be performed along with a justification of the change in categorization.

PBGC’s required minimum standards for FIPS 199 security categorization are as follows: • Systems must be categorized per the recommendation of FIPS 199 unless justification for a change is documented. • Unless otherwise stated by EIS, the recommended security levels are those stated in NIST SP 800-60. • A general support system must be categorized as having the following: Business Area Line of Business Information Type Government Resource Management Information & Technology Management IT Infrastructure Maintenance

and must have FIPS 199 recommended impact levels of: Confidentiality Integrity Availability System High Moderate System High

• System High is the term used by NIST to reflect that the information system takes on the high water mark for corresponding attribute for any other information system that relies on this system for providing security controls. This is most common for a GSS that provides security controls to major
RAP Version 1.0 7 May 2007

PBGC IAH - Volume 14

Risk Assessment

applications. • Any system containing personally identifiable information shall be considered a major information system and have confidentiality and integrity of moderate. • Major information systems must have a security categorization high water mark of moderate..

Procedure 2: Report results to EIS During the Project Initiation Phase of a system, the completed security categorization must be reviewed by the ISSO. Following the Information System review, the ISSO shall provide the result of the security categorization to the Senior Agency Information Security Officer (SAISO) via a CD or otherwise secure transmission. Information System Owners are expected to retain a hard copy of this report on file. Any updates to the FIPS 199 security categorization must be similarly submitted to the ISSO within 10 business days of the change. Note that a change in FIPS 199 security categorization would result in a change to the inventory status to the system and should be reported as an out-of-cycle inventory modification. Additionally, the change might result in a significant change to the system due to the change in minimum security controls and require a new C&A of the system.

3.2 RISK ASSESSMENT
EIS has developed the following procedures based on NIST SP 800-30. The procedures include the use of a standard RA spreadsheet and a reporting template to ensure standardized methodology across PBGC. Procedures 1 – 8 utilize the Risk Assessment Report template (i.e., Microsoft Word document) and the Risk Assessment Spreadsheet (i.e., compilation of excel worksheets) to aid in gathering and analyzing information throughout the process. The template and worksheets can be found in the appendixes to this volume. Procedure 9 utilizes the reporting template to prepare the final report. Procedure 1: Perform system characterization Using the system characterization section of the Risk Assessment Report template, found in the Appendix B of this volume, exercises the system characterization process. This process is intended to gather system-related information based on system-specific information and the general operating environment, including the FIPS 199 security categorization process. Detailed information contained in other supporting documentation may be referenced, provided a specific version and date of the referenced document are provided. Procedure 2: Perform threat identification Using the risk assessment instructions and template, found in Appendix B of this volume, develop a comprehensive list of threats that affect the information system. Use this

RAP Version 1.0 8

May 2007

PBGC IAH - Volume 14

Risk Assessment

information to classify the threats according to the defined categories. Identify the threat sources for each threat. Procedure 3: Perform vulnerability identification Using the risk assessment instructions and template, develop a comprehensive list of vulnerabilities that affect the information system. This information should be based on several sources, including, but not limited to: • • • • • Previous risk assessments. Vulnerability scans. Vulnerability databases. Industry or vendor documentation. Security control reviews or audits.

Using the list of vulnerabilities, add in the list of threat sources that may attempt to exploit the vulnerability. List the possible threat actions that the threat source may take to exploit the vulnerability. Procedure 4: Perform control analysis A comprehensive list of NIST SP 800-53 controls is provided in the Risk Assessment Spreadsheet. Using the list of controls and the SSP, perform an analysis to determine the current status of each control. Some controls may not be applicable for all systems. These should be marked in the appropriate column of the Control Analysis worksheet as “Not Applicable”. Analyze the current status of each control. Procedure 5: Perform likelihood determination The probability that a vulnerability will be exploited by a threat source is critical when focusing on security resources. The information provided in Procedure 3 will be automatically populated into the Likelihood – Impact – Risk worksheet. The SP 800-53 security control that is employed to limit the exposure to the threat source/vulnerability pair should be listed. Based on the status of the security controls, a likelihood rating of the vulnerability being exercised by the threat source must be provided by the assessor. Procedure 6: Perform impact analysis The maximum impact that any threat source/vulnerability pair can have on the security of an information system is equivalent to the security categorization for the information system. This is based on the high watermark for the security categorization was developed based on the FIPS 199 methodology which examines all information types in the information system. As such, the security categorization for each security objective describing the overall information system determines the maximum impact rating for the system.
RAP Version 1.0 9 May 2007

PBGC IAH - Volume 14

Risk Assessment

To determine the impact rating for each threat source/vulnerability pair, provide the impact rating for each security objective. The high watermark is automatically calculated and then used to develop the risk rating. Procedure 7: Perform risk determination The risk determination is automatically calculated for each threat source/vulnerability pair and calculated based on the information provided in Procedures 3, 5, and 6. This information should be reviewed and confirmed. Procedure 8: Provide control recommendations Based on the information in Procedure 7, examine each of the SP 800-53 controls. Analyze the controls to determine if they are adequately protecting the information resources of the system or if they require enhancement. For all controls that are determined to require enhancement, provide specific recommended corrective actions. Procedure 9: Document results EIS has provided a template for reporting the results of the RA. The template summarizes the current level of risk, system characterization, and the results of the assessment. The final RA report should be prepared in accordance to this template, provide a conclusion that includes an overall risk statement, and be provided to the DAA, ISSO, and Information System Owner.

3.3 RISK ASSESSMENT UPDATE
Procedure 1: Perform continuous review of system changes All system changes must be reviewed to determine if they meet the criteria of being a significant change. A significant change is defined as a change to the operating environment of a major information system that alters the overall level of risk previously authorized by the DAA. Procedure 2: Perform annual review of risk assessment The RA must also undergo an annual review to ensure that updates, including, but not limited to, changes in essential personnel are documented. The annual review is to be performed by the Information System Owner and the ISSO and then reported to the DAA. The document review history must be updated to reflect the date the review was performed. The ISSO must notify the SAISO when the annual review of the RA has been completed.

RAP Version 1.0 10

May 2007

PBGC IAH - Volume 14

Risk Assessment

3.4 VULNERABILITY SCANNING
Procedure 1: Define a clear scope for all vulnerability scanning activities and designate individuals to perform the scans In order to meet the requirements of control objective RA-5 in NIST SP 800-53, the PBGC has implemented network-based active vulnerability scanning (hereto referred to as “vulnerability scanning”) at a minimum. The individuals who will be performing active vulnerability scanning must be authorized in advanced and specific set of guidelines for the scans must be documented and approved. A passive network scanner may be configured with a wide range of settings to meet the needs of a PBGC information system. Prior to commencing vulnerability scanning efforts, the following should be addressed: • Scanner selection – EIS should evaluate the tools for use within the PBGC WAN environment. Network and host-based vulnerability scanners are available for free or for a fee. Appendix D contains a list of readily available vulnerability scanning tools. This list of tools is provided for informational purposes and is not endorsed by EIS. Purpose – A vulnerability scan should have a defined purpose. Vulnerability scans are typically performed against all systems and for all known vulnerabilities. While this purpose is suitable for meeting quarterly or semi-annual requirements, vulnerability scans can and are encouraged to be performed on an ad-hoc basis. Some examples of why ad-hoc vulnerability scanning might occur include: Verifying patch installation through system scanning. Identifying systems running a web server on port 80/tcp and if those web servers are susceptible to a recently disclosed vulnerability or exploit. Identifying all systems to determine if they have been compromised by a known Trojan. Scanning all routers to determine if ports 445/tcp, 5554/tcp and 9995/tcp are filtered in order to prevent the spread of the Sasser worm. • Scope/Boundaries – An active vulnerability scan should have a defined scope or boundary. The scope should be clearly defined in written rules of engagement. The scan should be limited to a specific information system, system(s), subnet(s), or network(s) within the realm of responsibility for that department.

RAP Version 1.0 11

May 2007

PBGC IAH - Volume 14

Risk Assessment

If scans will occur outside the realm of responsibility for that department, then a memorandum of understanding (MOU) must be drafted and signed by the DAA of each affected department. Scans typically should be performed only on systems and networks that are known to be stable and preferably during times of least impact to the critical functionality of the system. It is expected that vulnerability scanning will occur during the deployment and Solutions Operations and Maintenance phases of the ITSLCM. • Signatures/Tests – The signatures/tests that will be run against identified scope/boundaries should be selected as appropriate for the purpose of the vulnerability scanning. Research potential negative impacts – Once signatures/tests are selected, research should occur to determine if any of those signatures/tests may have a potential negative impact on the scope/boundaries selected. Coordination/Announcement – Coordination/announcement with the affected parties should occur before an active vulnerability scan is performed, especially if that scan may result in a potential negative impact. While an department may have the realm of responsibility for particular devices or systems, it is prudent to coordinate or notify the Information System Owner, system administrators, and all incident detection and response personnel of the scanning. System administrators can then monitor their systems for potential negative impacts. Any potential negative impact discovered during research should be disclosed before scanning is performed.

Procedure 2: Train individuals responsible for performing vulnerability scanning Because of the complexity of vulnerability scanning and the implications of exercising a test incorrectly, individuals authorized to perform vulnerability scanning must be trained on the tools, procedures, and scope of the system’s testing program. This training can count towards fulfilling role-based training requirements. Procedure 3: Perform vulnerability scan in compliance with the scope of the vulnerability scanning program Prior to commencing vulnerability scanning efforts, the following should be addressed: • Update scanning software – Before the vulnerability scan is performed, the vulnerability scanner should be updated with the latest patches and database signatures/tests. Scanners that are out of date will not contain the most recent signatures/tests and therefore a vulnerability could be missed. Perform scanning exercise – The designated personnel should perform the scan of the network and devices in accordance with the rules of engagement.
May 2007 12

RAP Version 1.0

PBGC IAH - Volume 14

Risk Assessment

Verify system availability – After completing the test, the designated personnel should check system status directly or by coordinating with the system administration team to ensure that the test did not result in unintended consequences and that the system remains operational.

Procedure 4: Document the scan results and provide to the ISSO and Information System Owner • Report Results – Once the vulnerability scanning has been completed, the results should be analyzed and documented in a vulnerability scan report. Discovered deficiencies must be disseminated to the affected Information System Owner(s) and added to the system plan of action and milestones (POA&M) for correction or mitigation. The following corrective actions may be necessary as a result of vulnerability scanning: Upgrade or patch vulnerable systems to mitigate identified vulnerabilities as appropriate. Deploy mitigating measures (technical or procedural) if the system cannot be immediately patched (e.g., operating system upgrade will make the application running on top of the operating system inoperable) in order to minimize the probability of this system being compromised. Improve configuration management program and procedures to ensure that systems are upgraded routinely. Assign a staff member to monitor vulnerability alerts and mailing lists, examine their applicability to the department's environment and initiate appropriate system changes. Modify the department's security policies, architecture, or other documentation to ensure that security practices include timely system updates and upgrades.

RAP Version 1.0 13

May 2007

PBGC IAH - Volume 14

Risk Assessment

3.5 COMPLIANCE
ISSO Documentation Compliance Review The PBGC ISSO shall review the RA, security categorization and vulnerability scanning results for compliance with PBGC and department information security policies prior to submission to the Information System Owner and the SAISO. The Information System Owner shall notify the ISSO within 10 business days of a significant change that requires a new C&A. The Information System Owner shall submit updated risk assessment documents to the ISSO within 30 calendar days of completing the changes. SAISO Documentation Compliance Review To ensure the risk assessment processes are executed correctly, the ISSO will review the RA, security categorization, and vulnerability scanning results for each information system during C&A oversight process. The ISSO will periodically verify the implementation of a sample of risk assessment controls as part of the security control test and evaluation program. Identified weaknesses in risk assessment controls will be reported to the SAISO and Information System Owner for remediation. Information System Owners shall remediate identified weaknesses using the POA&M process.

RAP Version 1.0 14

May 2007

PBGC IAH - Volume 14

Risk Assessment

APPENDIX A: ACRONYMS
BRM C&A CERT DAA DoS DRI FEA FIPS GSS IAH ISA ISSO ID ISP IT ITSLCM MA MOU NIST OIT PBGC POA&M PUB RA SAISO SCA SCW SP SSP Business Reference Model Certification and Accreditation Computer Emergency Response Team Designated Approving Authority Denial of Service Disaster Recovery Institute Federal Enterprise Architecture Federal Information Processing Standards General Support System Information Assurance Handbook Interconnection Security Agreement Information System Security Officer Identifier Internet Service Provider Information Technology Information Technology Solutions Life Cycle Methodology Major Application Memorandum of Understanding National Institute of Standards and Technology Office of Information Technology Pension Benefit Guaranty Corporation Plan of Action and Milestones Publication Risk Assessment Senior Agency Information Security Officer Security Controls Assessment System Categorization Worksheet Special Publication System Security Plan

RAP Version 1.0 15

May 2007

PBGC IAH - Volume 14

Risk Assessment Appendix B - Risk Assessment Templates & Instructions

APPENDIX B: RISK ASSESSMENT TEMPLATES & INSTRUCTIONS
In order to access the most current template, please refer to the following document: Risk Assessment Spreadsheet In order to access the most current template, please refer to the following document: Risk Assessment Report Template

STEP 1: SYSTEM CHARACTERIZATION SECTION INSTRUCTIONS
Proper system characterization defines the scope of the risk assessment effort and delineates the operational accreditation boundary of the system being assessed. The purpose of this step is to identify the system, define the system boundary and components, and identify the system information sensitivity. For the sections on system identification, responsible organization, system type, system operations, general description, and system boundary and components, please reference the SCW and SSP for the relevant information. • System Boundary & Components List the primary components of the system. Include information regarding system hardware (e.g., servers, routers, switches), software (e.g., applications, operating system, protocols), data, user, and data processing facilities. Describe the boundary of the system in such a way that it is clear what part of the system is within the scope of this assessment and what is not part of the system is out of the scope of this assessment. For example, a risk assessment might be conducted only in its national headquarters assets and not on field office components. Establishing parameters in which the system operates guarantees consideration of all appropriate security issues and an explicit decision as to scope of the assessment. If a current system security plan (SSP) that has been officially signed and accepted exists for the system and the components and boundaries described in the SSP are consistent with those covered by the risk assessment, it is acceptable to merely reference the SSP. • System Connections Identify and describe the internal and external system connections (e.g., communication links), including the services provided by each interface and the relationship between the interface and the system. Identify the significant features of the communications layout. Obtain and review, or create, a complete, high-level description of the system and network architecture, including diagrams or drawings to amplify the description of all components of the system. Lastly, include a description and a diagram depicting the flow of information upstream and downstream, including inputs and outputs to the system and any interdepartment connections that exist to the system. The preceding information may already be documented in the system/application documentation. The key part of defining the system boundary is to look at where it meets other systems and to define where the dividing line is located. This applies not only to physical connections, but also to logical connections where data is exchanged. The owner of this system and the owners of the interconnected systems must agree on the boundary between their systems, so that all components are the responsibility of someone, and no components are covered more
RAP Version 1.0 16 May 2007

PBGC IAH - Volume 14

Risk Assessment Appendix B - Risk Assessment Templates & Instructions

than once. In the event that the system boundary crosses a management boundary, the details should be clearly defined in a MOU and an Interconnection Security Agreement (ISA). See Volume 4 of the IAH for instructions on completing an MOU and an ISA. The system boundary should be based on non-arbitrary characteristics, such as funding boundaries, air gaps, contractual boundaries, operational boundaries, and transfer of information custody.

STEP 2: THREAT IDENTIFICATION SECTION INSTRUCTIONS
NOTE: For Steps 2 – 9, use the Risk Assessment Spreadsheet supplied by EIS. The purpose of this step is to identify the threats posed to the system or organization. Open the Risk Assessment Spreadsheet. Go to the “Threat Identification” worksheet. It will appear as displayed in Figure B-3: Figure B-1

RAP Version 1.0 17

May 2007

PBGC IAH - Volume 14

Risk Assessment Appendix B - Risk Assessment Templates & Instructions

Potential threats are identified and organized into three classifications: • • • Natural Human Environmental

Table B-1 contains a sample of threats. You may select from this list and consult NIST SP 80030. The threats listed in the table are provided only as a sample and are not specific for any system. They are not complete, not necessarily specific or unique to your system, or detailed enough for a thorough risk assessment; therefore, it is expected that the Information System Owner and ISSO will need to augment this list. Keep in mind that threats are dynamic. A previously conducted threat identification or risk assessment may not accurately and comprehensively identify all threats in your system’s threat environment. Table B-1 - Sample Threats
Air Conditioning Failure Aircraft Accident Biological Contamination Blackmail Bomb Threats Budget Loss Chemical Spills Cold/Front/Snow Communication Loss Competition Currency Fluctuation Cyber-Terrorism Data Destruction Data Disclosure Data Integrity Loss Earthquakes Electromagnetic Interference Errors (Major) Fire (Catastrophic) Fire (False Alarm) Fire (Major or Minor) Flooding/Water Damage Fraud/Embezzlement Hardware Failure Inflation Misuse (Computer) Nuclear Mishaps Pirating Key Personnel Power Loss Resource Management Sabotage Sinking Ground Storms/Hurricanes Substance Abuse Terrorism Theft of Assets Theft of Data Vandalism and/or Rioting Violence in the Workplace

The list of threats for an average-size system is typically many pages long. It is important that as many threats as possible be identified, since you are certifying to the DAA that all threats have been identified and appropriate protections have been implemented or planned. Some of the threats you identify may have a relatively low probability of occurrence but a large impact if they occur (e.g., earthquakes). Natural disasters are tracked by the Federal Emergency Management Agency; regional disaster information is available on their website (http://www.fema.gov/). Table B- 2 shows a list of threat-sources, motivations, and actions. In addition, threats unique to the system being assessed should be developed using brainstorming sessions and collaborative techniques. The Information System Owner, system development team leader, and two to three typical users should attend these sessions.

RAP Version 1.0 18

May 2007

PBGC IAH - Volume 14

Risk Assessment Appendix B - Risk Assessment Templates & Instructions

Note that the threat-source column in Table B-2 will not be a direct one-to-one mapping into the final risk assessment matrix. Not all potential threats require risk management. Only those threats that may be paired with identified system vulnerabilities should receive risk management attention. The comprehensive list in Table B-2 will be used to apply the appropriate threatsources to their corresponding vulnerabilities, as detailed in Step 3. Table B-2 - Sample Threat-Sources
Threat-Source Motivation or Mechanism
Natural Flood Flash Flood Drought Hurricane Earthquakes Landslides Avalanches Electrical Storms & Lightning Severe Storms Tornadoes Winter Storm Illness or Epidemic Electrical Interference or Disruption Electrical Fire Wild Fire Extreme Temperatures Act of Nature Act of Nature Act of Nature Act of Nature Act of Nature Act of Nature Act of Nature Act of Nature Act of Nature Act of Nature Act of Nature Act of Nature Act of Nature Act of Nature Act of Nature Act of Nature Loss of Infrastructure or Resources Loss of Infrastructure or Resources Loss of Infrastructure or Resources Loss of Infrastructure or Resources Loss of Infrastructure or Resources Loss of Infrastructure or Resources Loss of Infrastructure or Resources Loss of Infrastructure or Resources Loss of Infrastructure or Resources Loss of Infrastructure or Resources Loss of Infrastructure or Resources Loss of Human Resources Inability To Operate Loss of Infrastructure or Resources Loss of Infrastructure or Resources Loss of Infrastructure or Resources Loss of Infrastructure or Resources Human Network-based Attacks (i.e., Hacking) Telephone-switch Attacks (i.e., Phreaking) Social Engineering System Intrusion, Break-ins, or Unauthorized System Access (e.g., Cracking) Unauthorized Disclosure Computer Crime (e.g., Cyber Stalking) Fraudulent Act (e.g., Replay, Impersonation, Interception) Information Bribery Spoofing System Intrusion System Attack (e.g., Denial of Service, Distributed Denial of Service)

Threat Actions

Hacker Cracker Phreaker

Challenge Ego Rebellion

Computer Criminals

Destruction of Information Illegal Information Disclosure Monetary Gain Unauthorized Data Alteration

RAP Version 1.0 19

May 2007

PBGC IAH - Volume 14

Risk Assessment Appendix B - Risk Assessment Templates & Instructions Motivation or Mechanism
Blackmail Destruction Exploitation Revenge

Threat-Source

Threat Actions
Bomb, Bomb Threat, or Terrorism Destruction of Assets or Information Information Warfare System Attack (e.g., Distributed Denial of Service) System Penetration System Tampering Economic Exploitation Information Theft Theft of Assets Intrusion on Personal Privacy Social Engineering System Penetration Unauthorized System Access (e.g., Access to Classified, Proprietary, or Technology-related Information) Assault on an Employee Blackmail Browsing of Proprietary Information Computer Abuse Destruction of Information or Assets Fraud and Theft Information Bribery Input of Falsified or Corrupted Data Interception Malicious Code (e.g., Virus, Logic Bomb, Trojan Horse) Sale of Personal Information System Bugs System Intrusion System Sabotage Unauthorized System or Facilities Access Unauthorized Disclosure Vandalism Inadvertent Data Entry Error Human Error or Omission Administrative Error Management Error or Omission

Terrorist

Industrial Espionage (e.g., Companies, Foreign Governments, or Other Government Interests)

Competitive Advantage Economic Espionage

Insider Threat with Intent (e.g., Poorly Trained, Disgruntled, Malicious, Negligent, Dishonest, or Terminated Employees)

Curiosity Ego Intelligence Monetary Gain Revenge

Insider Threat without Intent or Knowledge

Unintentional Errors and Omissions (e.g., Data Entry Error, Programming Error)

Environmental Transportation Accident Carelessness Lack of Procedures or Guidelines Carelessness Lack of Procedures or Guidelines Carelessness Lack of Procedures or Guidelines Loss of Infrastructure or Resources

Fire (e.g., Smoking, Playing with Matches) Hazardous Material Incident

Loss of Infrastructure or Resources

Loss of Infrastructure or Resources

RAP Version 1.0 20

May 2007

PBGC IAH - Volume 14

Risk Assessment Appendix B - Risk Assessment Templates & Instructions Motivation or Mechanism
Lack of Maintenance Carelessness Lack of Procedures or Guidelines Lack of Maintenance Lack of Contingency Planning Lack of Contingency Planning Carelessness Lack of Procedures or Guidelines Carelessness Lack of Procedures or Guidelines Carelessness Lack of Procedures or Guidelines Lack of Policy Lack of Policy Enforcement Lack of Contingency Planning Carelessness Lack of Procedures or Guidelines Lack of Maintenance

Threat-Source
HVAC Failure Hardware or Software Failure

Threat Actions
Loss of Infrastructure or Resources

Loss of Infrastructure or Resources

Power Outage or Failure Long-term Power Outage or Failure Radiological Incident

Loss of Infrastructure or Resources Loss of Infrastructure or Resources

Loss of Infrastructure or Resources

Rodent or Insect Infestation

Loss of Infrastructure or Resources

Structural Fire

Loss of Infrastructure or Resources

Substance Abuse

Loss of Infrastructure or Resources

Pollution

Loss of Infrastructure or Resources

Liquid Leakage

Loss of Infrastructure or Resources

RAP Version 1.0 21

May 2007

PBGC IAH - Volume 14

Risk Assessment Appendix B - Risk Assessment Templates & Instructions

STEP 3: VULNERABILITY IDENTIFICATION SECTION INSTRUCTIONS
The purpose of this step is to identify vulnerabilities (i.e., flaws or weaknesses) in the system visà-vis the threat environment that may expose the system or organization to significant risk. Go to the “Vulnerabilities Identification” worksheet. It will appear as displayed in Figure B-4: Figure B-4

Provide a brief description of how the vulnerabilities were determined, and prepare a comprehensive table of vulnerabilities specific to this system or application that could be exploited by the potential threat-sources. There are many methodologies or frameworks for determining system vulnerabilities. The methodology should be selected based on where the system or application is in its life cycle, as follows: • For a system/application in the Conceptual Planning Phase or the Planning & Requirements Definition Phase, where it has not yet been designed, the search for vulnerabilities shall focus on the organization’s security policies, planned procedures, and system requirements definition, and the vendor’s security product analyses (e.g., white papers).

RAP Version 1.0 22

May 2007

PBGC IAH - Volume 14

Risk Assessment Appendix B - Risk Assessment Templates & Instructions

For a system/application in the Design Phase, Development & Test Phase, or Implementation Phase, the identification of vulnerabilities shall be expanded to include more specific information. Assess the effectiveness of the planned security features described in the security and system design documentation. Address the recommended system or security corrections or enhancements resulting from the Security Controls Assessment (SCA). For a system/application in the Operations & Maintenance Phase, the identification of vulnerabilities shall also include an analysis of the security features and the security controls (technical and procedural) used to protect the system. These evaluations include activities such as executing a security self-assessment in accordance with NIST SP 800-26, “Security Self-Assessment Guide for IT Systems”; the effective application of automated vulnerability scanning/assessment tools; and/or conducting a third-party penetration test. Often, a mixture of these and other methods is used to get a more comprehensive list of vulnerabilities. The use of multiple tools provides an element of validation to the findings of each automated tool thereby solidifying the analysis and subsequent recommended mitigation strategies. Alternatively, a comprehensive list of vulnerabilities may be developed based on the failure of each specific NIST SP 800-53 control.

The description of how vulnerabilities are determined should show that the process was thorough and likely to result in a complete and comprehensive list. If a vulnerability or risk assessment report has been performed previously, it will probably contain a comprehensive list of vulnerabilities that can be used to help you develop this section. See NIST SP 800-30 Section 3.3 for additional guidance. The list of vulnerabilities also varies greatly from one system and organization to another. System and network administrators may have different processes in place for more regularly reviewing a system’s security, applying patches, correcting vulnerabilities, etc. It is important that all known vulnerabilities be identified, since you are certifying to the DAA that appropriate reviews and testing of the system’s required security controls have been performed. Table 3 shows a comprehensive list of threat-vulnerability pairs. The list in Table 3 is only a sample and is not specific to any system; therefore, it is expected that Information System Owners will augment this list as needed. Vulnerabilities are dynamic. A previous vulnerability identification or risk assessment may not have identified the current vulnerabilities. Develop a list of threat Source/vulnerability pairs that list each threat-source on a separate line. This may require you to list vulnerabilities multiple times; however, this information will carry into the following worksheets.

RAP Version 1.0 23

May 2007

PBGC IAH - Volume 14

Risk Assessment Appendix B - Risk Assessment Templates & Instructions

Table B-3 - Threat-Vulnerability Pairs Example
Threat-Source Vulnerability
Terminated employees’ application user identifiers (IDs) are not quickly removed. Default Connect and Resource roles are granted to arbitrary users rather than predefined roles. Large bogus TCP packets (greater than 50000 bytes) directed at port 1521 will cause the application to stop responding to the client software. The vendor has identified flaws in the security design of the application modules; new patches exist but have not been applied.

Threat Action
An unauthorized user accessing the client software after termination and obtaining sensitive information Unauthorized access to production data

Terminated Employees

Malicious Insiders Computer Criminals

Malicious Insiders Computer Criminals

Valid system users unable to perform their job responsibilities during an0 attack

Unauthorized Users (e.g., hackers, disgruntled employees, computer criminals, terrorists)

Obtaining unauthorized access to sensitive application data based on known system vulnerabilities

Unauthorized Users (e.g., hackers, disgruntled employees, computer criminals, terrorists)

User names and passwords were found in scripts and initialization files.

Obtaining access to these files, divulging a user Identifier (ID) and password to the system, thus granting unauthorized access Unauthorized individuals obtaining access to sensitive and critical data. Unauthorized access to administrator level accounts, providing the ability to change, modify, or destroy data Could be misused to access sensitive and critical data without accountability

Unauthorized Users (e.g., hackers, disgruntled employees, computer criminals, terrorists)

Passwords are not set to expire, nor are regular password changes enforced.

Unauthorized Users (e.g., hackers, disgruntled employees, computer criminals, terrorists)

“Generic” accounts were found in the database (e.g., test, share, guest). Remote OS authentication is enabled even though no user accounts were found to be set up with access. Login encryption setting is not properly configured.

Unauthorized Users (e.g., hackers, disgruntled employees, computer criminals, terrorists) Unauthorized Users (e.g., hackers, disgruntled employees, computer criminals, terrorists)

A potential intruder exploiting the functionality to access the database Users making repeated logon attempts sending passwords in clear text

RAP Version 1.0 24

May 2007

PBGC IAH - Volume 14

Risk Assessment Appendix B - Risk Assessment Templates & Instructions

STEP 4: CONTROL ANALYSIS SECTION INSTRUCTIONS
The purpose of this step is to analyze the current and/or planned security controls used for the system. The controls listed are those provided from NIST SP 800-53, “Recommended Security Controls for Federal Information Systems”. These controls are used to mitigate the likelihood of vulnerabilities being exploited and to reduce the impact of such adverse events. The list shall include controls specific to this system. These controls are detailed in the SSP. The Information System Owners must review the SSP to determine the current state of the control to determine if they are in place or planned. This information will be used in Step 5 to determine the likelihood that a threat source can exploit the given vulnerability. Go to the “Control Analysis” worksheet. It will appear as displayed in Figure B-5: Figure B-5

The analysis shall assess the effectiveness of in-place or planned controls in mitigating the identified vulnerabilities of the system. The controls listed in this section shall be based on the PBGC’s security requirements checklist and apply to all control families for the system. These controls shall be documented in detail throughout the system’s SSP. Compliance to these controls shall be measured on an annual basis through either a security self-assessment or security control assessment.

RAP Version 1.0 25

May 2007

PBGC IAH - Volume 14

Risk Assessment Appendix B - Risk Assessment Templates & Instructions

STEP 5: LIKELIHOOD DETERMINATION SECTION INSTRUCTIONS
NOTE: For Steps 5 – 7, use the Likelihood-Impact-Risk worksheet in the Risk Assessment Spreadsheets supplied by EIS. The purpose of this step is to assign a likelihood rating of high, moderate, or low to each threatvulnerability pair identified in Step 3 and to correlate the information to the security control analysis developed in Step 4. Go to the “Likelihood-Impact-Risk” worksheet. It will appear as displayed in Figure B-6: Figure B-6

RAP Version 1.0 26

May 2007

PBGC IAH - Volume 14

Risk Assessment Appendix B - Risk Assessment Templates & Instructions

The likelihood rating shall be determined based on the likelihood that a potential vulnerability might be exploited within the construct of the associated threat environment. The following governing factors shall be considered: • • • Threat-source motivation and capability Nature of the vulnerability Existence and effectiveness of in place or planned controls

Other factors may also be used to estimate likelihood. These include historical information, records such as the annual rate of occurrence, and information from security organizations such as US-CERT, SANS, Bugtraq, SecurityTracker, and the Disaster Recovery Institute (DRI) International. The controls listed in the “Control Analysis” worksheet from Step 4 may be considered, provided they adequately mitigate the potential vulnerability. The likelihood rating levels are high, moderate, and low, as defined in Table B-4. Table B-4 - Likelihood Definitions
Likelihood Level
High Moderate Low

Likelihood Definition
The threat-source is highly motivated and sufficiently capable, and controls to prevent the vulnerability from being exercised are ineffective. The threat-source is motivated and capable, but controls are in place that may impede successful exercise of the vulnerability. The threat-source lacks motivation or capability, or controls are in place to prevent, or at least significantly impede, the vulnerability from being exercised.

Table B-5 shows an example of the likelihood ratings assigned to a system’s vulnerabilities. Note that natural physical threats are deemed to be less likely and are assigned lower ratings, while accidents are deemed to be fairly high. Table B-5- Likelihood Ratings Example
Threat-Source Vulnerability Controls
Personnel security controls are in place for closing user accounts, but they appear to be inadequate. A mitigating factor is that this vulnerability is dependent on a terminated employee gaining access to the client application. This appears to be adequately protected. Dial-in access, physical access to the building, workstation areas, and network access are controlled.

Likelihood Rating

Terminated Employees

Terminated employees’ application user IDs are not quickly removed.

Moderate

RAP Version 1.0 27

May 2007

PBGC IAH - Volume 14

Risk Assessment Appendix B - Risk Assessment Templates & Instructions Vulnerability Controls
Personnel security control policy, which is in place, states that users must be limited to the minimum access rights needed to perform their job functions. Logical access control policies now in place enable the enforcement of the personnel security control policy, but it does not currently appear to be enforced. Intrusion detection is in place and would detect a denial of service attack. It is anticipated that until the incident is handled appropriately, users would lose application access during the attack. Application software maintenance controls now in place specify vendor advisories and subsequent critical patch releases should be monitored. These procedures, however, do not appear to be followed consistently. A mitigating factor to consider is that the vulnerability is dependent on an unauthorized user’s gaining access to the internal PBGC network. There is a PBGC firewall protecting the Internet connection and a Data Center firewall protecting the Data Center network. Additionally, dial-in access is limited and strictly controlled. Internal users still pose a significant threat. Agency policy states that clear text passwords must not exist in scripts or text files on any system. This is an inherent weakness in the client software, and there is no fix according to the vendor.

Threat-Source

Likelihood Rating

Malicious Insiders Computer Criminals

Default Connect and Resource roles are granted to arbitrary users rather than predefined roles.

High

Malicious Insiders Computer Criminals

Large bogus TCP packets (greater than 50000 bytes) directed at port 1521 will cause the application to stop responding to the client software.

High

Unauthorized Users (e.g., Hackers, Disgruntled Employees, Computer Criminals, Terrorists)

The vendor has identified flaws in the security design of the application modules; new patches exist but have not been applied.

Moderate

Unauthorized Users (e.g., Hackers, Disgruntled Employees, Computer Criminals, Terrorists)

User names and passwords were found in scripts and initialization files.

Physical protections are in place to protect access to the building and user workstation areas, and technical controls are in place to limit access to user workstations to those individuals who have been granted permission to logon to PBGC systems. Vulnerable systems would only include those that have the client software installed.

Moderate

RAP Version 1.0 28

May 2007

PBGC IAH - Volume 14

Risk Assessment Appendix B - Risk Assessment Templates & Instructions Vulnerability Controls Likelihood Rating

Threat-Source
Unauthorized Users (e.g., Hackers, Disgruntled Employees, Computer Criminals, Terrorists)

Passwords are not set to expire, nor are regular password changes enforced.

Authentication controls are built in to the application and can be enabled.

Moderate

STEP 6: IMPACT ANALYSIS SECTION INSTRUCTIONS The purpose of this step is to assign an impact rating of low, moderate, or high to each threatvulnerability pair identified in Step 3. Note: Continue to use the “Likelihood-Impact-Risk” worksheet to complete Step 6. The maximum impact that any threat source/vulnerability pair can have on the security of an information system is equivalent to the security categorization for the information system. This is based on the high watermark for the security categorization was developed based on the FIPS 199 methodology which examines all information types in the information system. As such, the security categorization for each security objective describing the overall information system determines the maximum impact rating for the system. Table B-7 provides definitions of the impact ratings to use. Table B-7 - Impact Rating Definitions
Magnitude of Impact
High

Impact Definition
Exercise of the vulnerability: (1) may result in the highly costly loss of major tangible assets or resources; (2) may significantly violate, harm, or impede an organization’s mission, reputation, or interest; or (3) may result in human death or serious injury. Exercise of the vulnerability: (1) may result in the costly loss of tangible assets or resources; (2) may violate, harm, or impede an organization’s mission, reputation, or interest; or (3) may result in human injury. Exercise of the vulnerability: (1) may result in the loss of some tangible assets or resources or (2) may noticeably affect an organization’s mission, reputation, or interest.

Moderate Low

• •

To complete this step, use the resulting information from the security categorization. Populate the “FIPS 199 Security Categorization” table in the “Likelihood-ImpactRisk” worksheet for the Confidentiality, Integrity, and Availability security objectives.

The high watermark is automatically calculated and used to automatically feed the risk determination.

RAP Version 1.0 29

May 2007

PBGC IAH - Volume 14

Risk Assessment Appendix B - Risk Assessment Templates & Instructions

STEP 7: RISK DETERMINATION SECTION INSTRUCTIONS
The purpose of this step is to calculate a risk rating of high, moderate, or low for each threatvulnerability pair identified in Step 3. NOTE: For Step 7, use the “Likelihood-Impact-Risk” worksheet in the Risk Assessment Spreadsheets supplied by EIS. The risk determination for each threat source/vulnerability pair is generated automatically using the worksheet. The calculation is based on the risk rating matrix seen in Table B-8 and provided in NIST SP 800-30. The matrix uses a standard 3x3 matrix. Table B-8 - Risk Rating Matrix Example
Threat Likelihood
High (1.0) Moderate (0.5) Low (0.1) Low (10) Low 10 x 1.0 = 10 Low 10 x 0.5 = 5 Low 10 x 0.1 = 1 Moderate (50) Moderate 50 x 1.0 = 50 Moderate 50 x 0.5 = 25 Low 50 x 0.1 = 5 High (100) High 100 x 1.0 = 100 Moderate 100 x 0.5 = 50 Low 100 x 0.1 = 10

Risk Scale: Low (1 to 10); Moderate (>10 to 50); High (>50 to 100) For a thorough description of the risk rating calculation, refer to the annotated NIST SP 800-30, Table 3-6, Risk Scale and Necessary Actions. The worksheet will automatically calculate the Residual Risk Rating based on the Likelihood and Impact levels.

RAP Version 1.0 30

May 2007

PBGC IAH - Volume 14

Risk Assessment Appendix B - Risk Assessment Templates & Instructions

STEP 8: CONTROL RECOMMENDATIONS SECTION INSTRUCTIONS
The purpose of this step is to identify the security controls recommended to mitigate the identified risks, as appropriate to the PBGC’s operations. The controls provided are based on the minimum recommended security controls as described in NIST SP 800-53. Go to the “Control Recommendations” worksheet. It will appear as displayed in Figure B-7: Figure B-7

The goal of the recommended controls is to reduce the residual risk to the system and its data to an acceptable level. This provides sufficient data supporting the DAA’s responsibility to make informed risk-based decisions ensuring the protection of the system in question and the PBGC at large. The following factors should be considered in recommending controls and alternative solutions to minimize or eliminate identified risks: • • • • • Effectiveness of recommended options (e.g., system compatibility) Legislation and regulation Organizational policy Operational impact Safety and reliability
May 2007 31

RAP Version 1.0

PBGC IAH - Volume 14

Risk Assessment Appendix B - Risk Assessment Templates & Instructions

Analyze each security control with the threat source/vulnerability pair. Then determine the current level of adequacy and provide recommendations for improvement. Recommended actions should be integrated into the system’s security POA&M.

STEP 9: RESULTS DOCUMENTATION SECTION INSTRUCTIONS
The next step in the risk assessment is to complete the results summary table located the Results Documentation worksheet shown in Figure B-9. The data gathered in the previous steps should be used to populate the matrix. (Most is populated for you.) Once the risk assessment has been completed (threat-sources and vulnerabilities identified, risks assessed, and controls assessed and recommended), the results must be documented in an official risk assessment report prepared in Step 10. Figure B-9

STEP 10: FINAL REPORT PREPARATION SECTION INSTRUCTIONS
This Risk Assessment Report Template serves as the basis for preparing the official report or management brief and documenting the risk assessment results. The risk assessment report helps senior management, the mission owners, make informed decisions on policy, procedural, budget, and system operational and management changes. A risk assessment is not an audit or investigation report, which often looks for wrongdoing and issues findings that can be embarrassing to managers and Information System Owners. A risk assessment is a systematic, analytical tool for identifying security weaknesses and calculating risk. The risk assessment report should not be presented in an accusatory manner. Rather, it should rather be a direct and open discussion of the observations of the risk assessment team. Its purpose is to inform senior management of the current threat-vulnerability environment and the
RAP Version 1.0 32 May 2007

PBGC IAH - Volume 14

Risk Assessment Appendix B - Risk Assessment Templates & Instructions

adequacy of current and planned security controls. The value of a risk assessment is that it helps senior management to understand the current system exposure so they can allocate resources effectively and efficiently to correct errors and reduce potential losses. To that purpose, perform an analysis of the risk assessment activities. Use this information to develop a conclusion based on the risk assessment that includes the overall final level of residual risk to the PBGC and system. Include a paragraph on any deviations from the standard NIST methodology used and prescribed in these procedures. Other considerations, which are beyond the scope of the risk assessment but which may be addressed in the report and should be discussed in the brief, are management’s assessment and subsequent POA&M. Depending on the severity of actions required to mitigate the discovered risks, a risk mitigation plan with detailed remedial action may be required to address the identified weaknesses. For each threatvulnerability pair management should— • • • • • • Assign a priority action. Detail the recommended control(s) that are to be implemented. Estimate the resources (in terms of hours) required for implementing the recommendation(s). Assign responsibility to an individual or identify the department that will be held accountable for implementing the recommendation(s). Provide a date for initiating the recommendation(s). Provide a date by which time all recommendations(s) must be fully implemented.

Next, develop the Introduction. The introduction shall briefly describe the purpose of this risk assessment and include a brief description of the approach used to conduct the risk assessment. The description of the approach shall include: • • • • The participants and their roles in the risk assessment in relation to their assigned responsibilities at PBGC. The technique used to gather the necessary information (e.g., the use of tools, questionnaires). The risk scale used, as described in Step 7. The risk assessment methodology flow chart from NIST SP 800-30 and any customization based on the system threat environment.

The level of risk shall be determined using a “3x3” risk-level scale that is based on inputs from the threat likelihood and threat impact categories. The risk levels for each input category shall be assessed as high, moderate, or low. These risk levels are defined in FIPS 199.
RAP Version 1.0 33 May 2007

PBGC IAH - Volume 14

Risk Assessment Appendix B - Risk Assessment Templates & Instructions

Next, copy the results of the Results Documentation worksheet into the template to provide summary information of the assessment. Copy the worksheets from Steps 2 – 8 into the appropriate appendices as references for senior management. Finally, develop the executive summary highlighting the activities undertaken and the critical elements of the analysis and conclusion. This section should highlight for senior management the core results determined by this risk assessment.

RAP Version 1.0 34

May 2007

PBGC IAH - Volume 14

Risk Assessment Appendix C- Sample Vulnerability Scanning Tools

APPENDIX C: SAMPLE VULNERABILITY SCANNING TOOLS
Tool
ISS Internet Scanner Description

Capabilities
Vulnerability scanner

Website
http://www.iss.net/

Linux/Unix
X

Win32
X

Cost
$

ISS Internet Scanner is a network-based vulnerability-scanning tool that identifies security holes on network hosts. Vulnerability scanner http://www.nessus.org/

Nessus 3

X

X

$

Description

A network-based vulnerability-scanning tool that identifies security holes on network hosts. While Nessus 3 is available free of charge is not be released under the GPL. There is a fee for a direct feed of the latest plug-ins (i.e., signatures); otherwise a feed for registered scanners is released 7 days after the direct feed. Vulnerability scanner http://www.wwdsi.com/sai nt/ X X $

SAINT

Description

SAINT is an updated and enhanced version of SATAN, is designed to assess the security of computer networks. Vulnerability scanner Passive vulnerability scanner http://www-arc.com/sara/ http://www.sourcefire.com /products/rna.html X X Free

SARA

SourceRNA

N/A

N/A

$

Description

Sourcefire RNA uses a combination of passive network discovery, behavioral profiling, and integrated vulnerability analysis to deliver the benefits of real-time network profiling and change management. Passive vulnerability scanner http://www.tenablesecurit y.com/products/pvs.shtml N/A N/A $

Tenable PVS

Description

Tenable PVS monitors your network for vulnerable systems, watches for potential application compromises, client and server trust relationships, and open or browsed network protocols in use.

RAP Version 1.0 35

May 2007