Vol14 Sectionii Riskassessmentproceduresv1

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 May 2007

i
Change/Review Record
Document Title: IAH Volume 14 –Risk Assessment Procedures
Date of Initial Release:
Version No. Date Revised Description of Revisions

Version 1.0
Completed by: Date:
Approved by: Michael Zacour Date: May 14th, 2007
Completed by: Date:

Approved by: Date:
Completed by: Date:

Approved by: Date:
Completed by: Date:

Approved by: Date:

ii
TABLE OF CONTENTS
1 INTRODUCTION............................................................................................................. 1
1.1 Background ......................................................................................................................... 1
1.2 Purpose................................................................................................................................ 1
1.3 Scope and Applicability...................................................................................................... 1
2 PROCESSES ..................................................................................................................... 2
2.1 Security Categorization....................................................................................................... 2
2.2 Risk Assessment ................................................................................................................. 3
2.3 Risk Assessment Update..................................................................................................... 4
2.4 Vulnerability Scanning ....................................................................................................... 4
3 PROCEDURES ................................................................................................................. 7
3.1 Security Categorization....................................................................................................... 7
3.2 Risk Assessment ................................................................................................................. 8
3.3 Risk Assessment Update................................................................................................... 10
3.4 Vulnerability Scanning ..................................................................................................... 11
3.5 Compliance ....................................................................................................................... 14
APPENDIX A: ACRONYMS .................................................................................................... 15
APPENDIX B: RISK ASSESSMENT TEMPLATES & INSTRUCTIONS ......................... 16
APPENDIX C: SAMPLE VULNERABILITY SCANNING TOOLS ................................... 35

iii
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.

1
2 PROCESSES
The PBGC risk assessment processes are based on applicable NIST guidance, including SP 800-
30,”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.

2
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

3
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.

4
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

5
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.

6
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 Government Resource Management

Line of Business Information & Technology Management
Information Type IT Infrastructure Maintenance
and must have FIPS 199 recommended impact levels of:
Confidentiality System High

Integrity Moderate
Availability 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

7
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

8
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.

9
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.

10
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.

11
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.

12
• 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.

13
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.

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

15
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 inter-
department 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

16
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

17
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 800-
30. 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 Data Disclosure Nuclear Mishaps

Aircraft Accident Data Integrity Loss Pirating Key Personnel
Biological Contamination Earthquakes Power Loss
Blackmail Electromagnetic Interference Resource Management
Bomb Threats Errors (Major) Sabotage
Budget Loss Fire (Catastrophic) Sinking Ground
Chemical Spills Fire (False Alarm) Storms/Hurricanes
Cold/Front/Snow Fire (Major or Minor) Substance Abuse
Communication Loss Flooding/Water Damage Terrorism
Competition Fraud/Embezzlement Theft of Assets
Currency Fluctuation Hardware Failure Theft of Data
Cyber-Terrorism Inflation Vandalism and/or Rioting
Data Destruction Misuse (Computer) 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.

18
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 threat-
sources to their corresponding vulnerabilities, as detailed in Step 3.
Table B-2 - Sample Threat-Sources
Motivation or
Threat-Source Threat Actions
Mechanism
Natural
Flood Act of Nature Loss of Infrastructure or Resources
Flash Flood Act of Nature Loss of Infrastructure or Resources
Drought Act of Nature Loss of Infrastructure or Resources
Hurricane Act of Nature Loss of Infrastructure or Resources
Earthquakes Act of Nature Loss of Infrastructure or Resources
Landslides Act of Nature Loss of Infrastructure or Resources
Avalanches Act of Nature Loss of Infrastructure or Resources
Electrical Storms &
Act of Nature Loss of Infrastructure or Resources
Lightning
Severe Storms Act of Nature Loss of Infrastructure or Resources
Tornadoes Act of Nature Loss of Infrastructure or Resources
Winter Storm Act of Nature Loss of Infrastructure or Resources
Loss of Human Resources
Illness or Epidemic Act of Nature
Inability To Operate
Electrical Interference or
Act of Nature Loss of Infrastructure or Resources
Disruption
Electrical Fire Act of Nature Loss of Infrastructure or Resources
Wild Fire Act of Nature Loss of Infrastructure or Resources
Extreme Temperatures Act of Nature Loss of Infrastructure or Resources
Human
Network-based Attacks (i.e., Hacking)
Telephone-switch Attacks (i.e., Phreaking)
Hacker Challenge
Social Engineering
Cracker Ego
System Intrusion, Break-ins, or Unauthorized System
Phreaker Rebellion
Access (e.g., Cracking)
Unauthorized Disclosure
Computer Crime (e.g., Cyber Stalking)
Destruction of
Fraudulent Act (e.g., Replay, Impersonation,
Information
Interception)
Illegal Information
Information Bribery
Computer Criminals Disclosure
Spoofing
Monetary Gain
System Intrusion
Unauthorized Data
Alteration System Attack (e.g., Denial of Service, Distributed
Denial of Service)

19
Motivation or
Mechanism
Bomb, Bomb Threat, or Terrorism
Blackmail Destruction of Assets or Information
Destruction Information Warfare
Terrorist
Exploitation System Attack (e.g., Distributed Denial of Service)
Revenge System Penetration
System Tampering
Economic Exploitation
Information Theft
Industrial Espionage Theft of Assets
(e.g., Companies, Competitive Advantage Intrusion on Personal Privacy
Foreign Governments, Social Engineering
or Other Government Economic Espionage
System Penetration
Interests)
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
Insider Threat with Intent Curiosity
Input of Falsified or Corrupted Data
(e.g., Poorly Trained, Ego
Interception
Disgruntled, Malicious, Intelligence
Negligent, Dishonest, or Malicious Code (e.g., Virus, Logic Bomb, Trojan
Monetary Gain
Terminated Employees) Horse)
Revenge
Sale of Personal Information
System Bugs
System Intrusion
System Sabotage
Unauthorized System or Facilities Access
Unauthorized Disclosure
Vandalism
Unintentional Errors and Inadvertent Data Entry Error

Insider Threat without Omissions (e.g., Data Human Error or Omission
Intent or Knowledge Entry Error, Administrative Error
Programming Error) Management Error or Omission
Environmental
Carelessness
Transportation Accident Lack of Procedures or Loss of Infrastructure or Resources
Guidelines
Carelessness
Fire (e.g., Smoking,
Lack of Procedures or Loss of Infrastructure or Resources
Playing with Matches)
Guidelines
Carelessness
Hazardous Material
Incident
Guidelines

20
Motivation or
Mechanism
HVAC Failure Lack of Maintenance Loss of Infrastructure or Resources
Carelessness
Hardware or Software Lack of Procedures or
Loss of Infrastructure or Resources
Failure Guidelines
Lack of Maintenance
Lack of Contingency
Power Outage or Failure Loss of Infrastructure or Resources
Planning
Long-term Power Lack of Contingency
Loss of Infrastructure or Resources
Outage or Failure Planning
Carelessness
Radiological Incident Lack of Procedures or Loss of Infrastructure or Resources
Guidelines
Carelessness
Rodent or Insect
Infestation
Guidelines
Carelessness
Structural Fire Lack of Procedures or Loss of Infrastructure or Resources
Guidelines
Lack of Policy
Substance Abuse Lack of Policy Loss of Infrastructure or Resources
Enforcement
Lack of Contingency
Pollution Loss of Infrastructure or Resources
Planning
Carelessness
Lack of Procedures or
Liquid Leakage Loss of Infrastructure or Resources
Guidelines
Lack of Maintenance

21
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).

22
• 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.

23
Table B-3 - Threat-Vulnerability Pairs Example
Threat-Source Vulnerability Threat Action

An unauthorized user accessing
Terminated employees’
the client software after
Terminated Employees application user identifiers (IDs)
termination and obtaining
are not quickly removed.
sensitive information
Malicious Insiders Default Connect and Resource

Unauthorized access to
roles are granted to arbitrary users
Computer Criminals production data
rather than predefined roles.
Large bogus TCP packets (greater

Malicious Insiders than 50000 bytes) directed at port Valid system users unable to
1521 will cause the application to perform their job responsibilities
Computer Criminals stop responding to the client during an0 attack
software.
The vendor has identified flaws in

Unauthorized Users (e.g., Obtaining unauthorized access to
the security design of the
hackers, disgruntled employees, sensitive application data based
application modules; new patches
computer criminals, terrorists) on known system vulnerabilities
exist but have not been applied.
Obtaining access to these files,

Unauthorized Users (e.g., User names and passwords were
divulging a user Identifier (ID) and
hackers, disgruntled employees, found in scripts and initialization
password to the system, thus
computer criminals, terrorists) files.
granting unauthorized access
Unauthorized individuals obtaining

access to sensitive and critical
data.
Unauthorized Users (e.g., Passwords are not set to expire,
hackers, disgruntled employees, nor are regular password changes
computer criminals, terrorists) enforced. Unauthorized access to
administrator level accounts,
providing the ability to change,
modify, or destroy data
Unauthorized Users (e.g., “Generic” accounts were found in Could be misused to access
hackers, disgruntled employees, the database (e.g., test, share, sensitive and critical data without
computer criminals, terrorists) guest). accountability
Remote OS authentication is
Unauthorized Users (e.g., A potential intruder exploiting the
enabled even though no user
hackers, disgruntled employees, functionality to access the
accounts were found to be set up
computer criminals, terrorists) database
with access.
Unauthorized Users (e.g., Users making repeated logon

Login encryption setting is not
hackers, disgruntled employees, attempts sending passwords in
properly configured.
computer criminals, terrorists) clear text

24
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.

25
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 threat-
vulnerability 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

26
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
Likelihood Definition
Level
The threat-source is highly motivated and sufficiently capable, and controls to prevent the
High
vulnerability from being exercised are ineffective.
The threat-source is motivated and capable, but controls are in place that may impede
Moderate
successful exercise of the vulnerability.
The threat-source lacks motivation or capability, or controls are in place to prevent, or at
Low
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
Likelihood
Threat-Source Vulnerability Controls
Rating
Personnel security controls are in
place for closing user accounts, but
they appear to be inadequate.
A mitigating factor is that this
Terminated employees’ vulnerability is dependent on a
Terminated
application user IDs are not terminated employee gaining access Moderate
Employees
quickly removed. 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.

27
Likelihood
Rating
Personnel security control policy,
which is in place, states that users
must be limited to the minimum
Malicious Insiders Default Connect and Resource
access rights needed to perform
roles are granted to arbitrary
Computer their job functions. Logical access High
users rather than predefined
Criminals control policies now in place enable
roles.
the enforcement of the personnel
security control policy, but it does not
currently appear to be enforced.
Large bogus TCP packets Intrusion detection is in place and
Malicious Insiders (greater than 50000 bytes) would detect a denial of service
directed at port 1521 will cause attack. It is anticipated that until the
Computer High
the application to stop incident is handled appropriately,
Criminals responding to the client users would lose application access
software. 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
Unauthorized appear to be followed consistently.
Users (e.g., A mitigating factor to consider is that
The vendor has identified flaws the vulnerability is dependent on an
Hackers,
in the security design of the unauthorized user’s gaining access
Disgruntled
application modules; new to the internal PBGC network. There Moderate
Employees,
patches exist but have not is a PBGC firewall protecting the
Computer
been applied. Internet connection and a Data
Criminals,
Terrorists) 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.
Unauthorized
Users (e.g.,
Physical protections are in place to
Hackers,
User names and passwords protect access to the building and
Disgruntled
were found in scripts and user workstation areas, and Moderate
Employees,
initialization files. technical controls are in place to limit
Computer
access to user workstations to those
Criminals,
individuals who have been granted
Terrorists)
permission to logon to PBGC
systems.
Vulnerable systems would only

include those that have the client
software installed.

28
Likelihood
Rating
Unauthorized
Users (e.g.,
Hackers,
Passwords are not set to
Disgruntled Authentication controls are built in to
expire, nor are regular Moderate
Employees, the application and can be enabled.
password changes enforced.
Computer
Criminals,
Terrorists)
STEP 6: IMPACT ANALYSIS SECTION INSTRUCTIONS

The purpose of this step is to assign an impact rating of low, moderate, or high to each threat-
vulnerability 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
Impact Definition
of Impact
Exercise of the vulnerability: (1) may result in the highly costly loss of major tangible assets or
High 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)
Moderate 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
Low
(2) may noticeably affect an organization’s mission, reputation, or interest.
• To complete this step, use the resulting information from the security categorization.
• Populate the “FIPS 199 Security Categorization” table in the “Likelihood-Impact-

Risk” worksheet for the Confidentiality, Integrity, and Availability security
objectives.
The high watermark is automatically calculated and used to automatically feed the risk
determination.

29
STEP 7: RISK DETERMINATION SECTION INSTRUCTIONS

The purpose of this step is to calculate a risk rating of high, moderate, or low for each threat-
vulnerability 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
Low Moderate High

Threat Likelihood (10) (50) (100)
High Low Moderate High
(1.0) 10 x 1.0 = 10 50 x 1.0 = 50 100 x 1.0 = 100
Moderate Low Moderate Moderate
(0.5) 10 x 0.5 = 5 50 x 0.5 = 25 100 x 0.5 = 50
Low Low Low Low
(0.1) 10 x 0.1 = 1 50 x 0.1 = 5 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.

30
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

31
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

32
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 threat-
vulnerability 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.

33
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.

34
Appendix C- Sample Vulnerability Scanning Tools
APPENDIX C: SAMPLE VULNERABILITY SCANNING TOOLS
Tool Capabilities Website Linux/Unix Win32 Cost
ISS Internet Vulnerability scanner http://www.iss.net/

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

Nessus 3 X X $
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
Description feed of the latest plug-ins (i.e., signatures); otherwise a feed for registered scanners is released 7
days after the direct feed.
http://www.wwdsi.com/sai
SAINT Vulnerability scanner X X $
nt/
SAINT is an updated and enhanced version of SATAN, is designed to assess the security of
Description
computer networks.
SARA Vulnerability scanner http://www-arc.com/sara/ X X Free
Passive vulnerability http://www.sourcefire.com

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

Tenable PVS N/A N/A $
scanner y.com/products/pvs.shtml
Tenable PVS monitors your network for vulnerable systems, watches for potential application
Description
compromises, client and server trust relationships, and open or browsed network protocols in use.

35

Vol14 Sectionii Riskassessmentproceduresv1

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Vol14 Sectionii Riskassessmentproceduresv1

Transféré par

Droits d'auteur :

Formats disponibles

Pension Benefit Guaranty Corporation

INFORMATION ASSURANCE HANDBOOK

PBGC Office of Information Technology (OIT)

ANNUAL REVIEW RECORD

Review Date Reviewer

RAP Version 1.0 May 2007

Date of Initial Release:

Version No. Date Revised Description of Revisions

Completed by: Date:

Completed by: Date:

Completed by: Date:

RAP Version 1.0 May 2007

RAP Version 1.0 May 2007

1.3 SCOPE AND APPLICABILITY

RAP Version 1.0 May 2007

2.1 SECURITY CATEGORIZATION

RAP Version 1.0 May 2007

2.2 RISK ASSESSMENT

RAP Version 1.0 May 2007

2.3 RISK ASSESSMENT UPDATE

RAP Version 1.0 May 2007

Generally, vulnerability scanning identifies only surface vulnerabilities (i.e., a weakness as it

Only designated individuals, including network administrators, the ISSO, or individuals

RAP Version 1.0 May 2007

Vulnerability scanners can be of two types: network-based and host-based. Network-based

RAP Version 1.0 May 2007

Procedure 1: Determine FIPS 199 Security Categorization

PBGC information systems must be categorized according to NIST SP 800-60 guidance,

PBGC’s required minimum standards for FIPS 199 security categorization

• Systems must be categorized per the recommendation of FIPS 199 unless

Business Area Government Resource Management

and must have FIPS 199 recommended impact levels of:

Confidentiality System High

RAP Version 1.0 May 2007

Procedure 2: Report results to EIS

Procedure 1: Perform system characterization

Procedure 2: Perform threat identification

RAP Version 1.0 May 2007

Procedure 3: Perform vulnerability identification

• Previous risk assessments.

Procedure 4: Perform control analysis

A comprehensive list of NIST SP 800-53 controls is provided in the Risk Assessment

Procedure 5: Perform likelihood determination

Procedure 6: Perform impact analysis

RAP Version 1.0 May 2007

Procedure 7: Perform risk determination

The risk determination is automatically calculated for each threat source/vulnerability

Procedure 8: Provide control recommendations

Based on the information in Procedure 7, examine each of the SP 800-53 controls.

Procedure 9: Document results

3.3 RISK ASSESSMENT UPDATE

Procedure 1: Perform continuous review of system changes

Procedure 2: Perform annual review of risk assessment

RAP Version 1.0 May 2007

3.4 VULNERABILITY SCANNING

Prior to commencing vulnerability scanning efforts, the following should be addressed:

• Purpose – A vulnerability scan should have a defined purpose. Vulnerability scans

Some examples of why ad-hoc vulnerability scanning might occur include:

 Verifying patch installation through system scanning.

• Scope/Boundaries – An active vulnerability scan should have a defined scope or

RAP Version 1.0 May 2007

• Signatures/Tests – The signatures/tests that will be run against identified

Verifying patch installation through system scanning.

Upgrade or patch vulnerable systems to mitigate identified vulnerabilities as