EPLC Security_Risk_Assessment_v . .doc

Risk Assessment --- Custom Document Property (SysName) Document Version 2.0

Risk Assessment (RA)

--- Custom Document Property (SysName)

--- Custom Document Property (SysAcronym)

--- Custom Document Property (DocDate)

Food and Drug Administration

(FDA)

Record of Changes

Tip: This page tracks changes to template. Remove these template entries when developing this document for a specific system and enter changes for this specific document. (Remove this tip prior to submission.)

Tip: Items that begin with the text “Custom Document Property” and NOT to be typed over. Go to File>Properties> and modify the values of these properties on the Custom tab. After the changes are made, press Ctrl A to select the entire document and then press F9 to update the fields throughout the document. Custom Document Properties in the Header can only be updated when the Header is open. Select View>Header and Footer, select the Custom Document Properties and press F9. (Remove this tip prior to submission.)

Table of Contents Introduction

21.1 Results Summary

31.2 Purpose

31.3 Scope

31.4 Scope Exclusions

Risk Assessment Methodology

42.1 Risk Assessment into the System’s Life Cycle

42.2 System Characterization

42.2.1 System Name/Title

52.2.2 Responsible Organization

52.2.3 Information Contact(s)

62.2.4 Assignment of Security Responsibility

62.2.5 Designated Authorizing Agent (DAA):

General Description/Purpose

73.1 Operational Status

73.2 Information System Type

73.3 Users

System Environment

84.1 Hardware

84.2 Software

84.3 Information Flow

General Description of Information Sensitivity

105.1 Threat Identification

125.2 Vulnerability Identification

135.3 Control Analysis

135.4 Threat/Vulnerability Pairs

Risk Results and Control Recommendations

A-1Appendix A Risk Calculation

B-1Appendix B Schedule of Control Testing

Table of Tables

2Table 1: Risk Assessment Results

5Table 2: Information Contacts

6Table 3: Designated Persons

9Table 4: System Information Types & Categorization

10Table 5: Threat Sources and Description

13Table 6: Controls Status Summary

13Table 7: Controls Status Summary Table

15Table 8: Detailed Results

A-1Table 9: Likelihood of Occurrence Values Criteria

A-2Table 10: Assignment of Likelihood Values

A-2Table 11: Definitions

A-3Table 12: Threat Impact and Security Sensitivity Mapping

A-3Table 13: Risk Level Matrix

A-4Table 14: Risk Value Matrix

B-1Table 15: Critical Controls

B-1Table 16: Annual Controls Year 1

B-3Table 17: Annual Controls Year 2

B-4Table 18: Annual Controls Year 3

Risk Assessment Approval I have reviewed the --- Custom Document Property (SysAcronym) Risk Assessment and accept the analysis and findings contained within.

Mark Gregory

Date

System Owner

[First Name Last Name]

Date

--- Custom Document Property (SysAcronym) Information System Security Officer

Risk Assessment Review

This Risk Assessment has been updated and approved on the following dates to account for the latest changes. This task will be completed at least annually.

1 Introduction This document is the Risk Assessment for --- Custom Document Property (SysName) (--- Custom Document Property (SysAcronym)). It identifies the level of risk for the system and provides risk mitigation recommendations for management to implement into the risk management program. This Risk Assessment allows managers to evaluate the security of the Information Technology (IT) systems and to determine the potential for loss or harm to organizational operations, goals, and its stakeholders should system security be breached. The Risk Assessment provides management with the capability to:

· Provide an adequate level of security protection for IT applications and systems.

· Meet Federal requirements for information and system security.

· Satisfy oversight organizations.

· Establish an acceptable level of risk.

This report documents the evaluation of --- Custom Document Property (SysAcronym) measured against possible threats and vulnerabilities to determine the potential loss from certain events based on an estimated probability of occurrence. The risks identified and their associated recommendations will be tracked in the Plan of Actions and Milestones (POA&M).

This Risk Assessment identifies those threat and vulnerabilities presented at the time of the assessment. Any changes or implementation of various technologies, risks, etc. will be reviewed at a different time.

The results of the --- Custom Document Property (SysAcronym) Risk Assessment indicated that the risks to system resources in the areas of Management, Operational, and Technical controls are as follows:

Tip: Summarize risks below. This section can be filled out at the very end after all the Results Details have been completed in Section 10. Remove this TIP before submission. (Remove this tip prior to submission.)

Tip: Summarize weaknesses in management controls here, e.g., “weaknesses in the approval of security plan and risk assessment documentation; lack of rules of behavior; and, the lack of a formal authorization to operate.”). (Remove this tip prior to submission.)

· Management Controls: The most significant management control related risks include:

Tip: Summarize weaknesses in operational controls here, e.g., “the lack of media controls; background screening controls; lack of documented instructions for requesting, establishing, issuing and closing user accounts; lack of periodic validation of user accounts; and, lack of restrictions on software/hardware maintenance personnel.”) (Remove this tip prior to submission.)

· Operational Controls: Significant operational control risks include

Tip: Summarize weaknesses in technical controls here, e.g., “the failure to implement a log-on banner; failure to detect unauthorized access attempts through editing; and the lack of periodic vulnerability scanning.”) (Remove this tip prior to submission.)

· Technical Controls: The most significant technical control risks include

Risks in areas such as natural, environmental, human intentional and human unintentional threats were assessed. The assessment found that identified risks could be fully mitigated through the implementation of security controls specified in section 6.

[Enter the number] vulnerabilities found in --- Custom Document Property (SysAcronym) controls are ranked as low, medium and/or high risk. Therefore, --- Custom Document Property (SysAcronym) is categorized as having a low, moderate or high level of risk.

1.1 Results Summary

The results summary is based on the technical risk description and prioritized by Risk Ranking.

Table 1: Risk Assessment Results

1.2 Purpose

The Risk Assessment serves as a decision making tool. It provides the FDA system owner and authorizing official with evidence documenting the capability of --- Custom Document Property (SysAcronym) to operate with an acceptable level of risk to their information technology resources, the information processed, stored and transmitted in the application, and their connections to other information systems. In addition, this information can be used to implement potential safeguards to mitigate the risks identified in this report. This will provide the --- Custom Document Property (SysAcronym) management with an assessment of the adequacy of the management, operational and technical security controls that are currently in place, and identify those items necessary to --- Custom Document Property (SysAcronym).

As mentioned, the Risk Assessment fulfills a number of legislative initiatives requiring that all federal agencies conduct periodic or yearly Risk Assessments as part of their risk management program. Such legislative initiatives include the Federal Information Security Management Act (FISMA), the Office of Management and Budget Circular A-130 (OMB A-130). The security Risk Assessment methodology is adapted from National Institute of Standards and Technology (NIST) Special Publication (SP) 800-30 Risk Management Guide for Information Technology Systems.

1.3 Scope

Tip: Clearly indicate the boundary of the information system and the scope that the risk assessment is based upon. Specify information systems that are not included within the scope. (Remove this tip prior to submission.)

The scope of this Risk Assessment is to evaluate risks to --- Custom Document Property (SysAcronym) in the areas of management, operational, and technical controls. This Risk Assessment is limited to the --- Custom Document Property (SysAcronym) Accreditation Boundary as documented in the --- Custom Document Property (SysAcronym) System Security Plan (SSP).

1.4 Scope Exclusions

Tip: Identify the exclusions from this Risk Assessment. For example: Excluded from this assessment are the General Support Systems, which will be described within its respective certification. (Remove this tip prior to submission.)

Excluded from the scope of the --- Custom Document Property (SysAcronym) Risk Assessment are the following management, operational, and technical controls.

· [Control number]

· [Control number] 2 Risk Assessment Methodology Prior to conducting a Risk Assessment, security requirements must be identified. Security requirements are determined based on executive, legislative, and technical guidance in addition to departmental policy. Additionally, security requirements specific to the hardware, software, or operating system are also identified. The Risk Assessment is performed to identify the management, operational, and technical controls, or other appropriate countermeasures necessary for the protection of the system.

Risk Assessment methodology implementation is structured as nine distinct steps:

Step 1: System Characterization

Step 2: Threat Identification

Step 3: Vulnerability Identification

Step 4: Control Analysis

Step 5: Likelihood Determination

Step 6: Impact Analysis

Step 7: Risk Determination

Step 8: Control Recommendations

Step 9: Results Documentation

2.1 Risk Assessment into the System’s Life Cycle

Tip: Determine which of the following Life Cycle phase the system is currently in. The descriptions are for the use and understanding of the document owner/writer to assist in determining the appropriate phase. Note that the system may be in more than one of these phases and address them as such. Identify the appropriate Life Cycle phase(s) the system is currently under. Choose only those applicable to the system. (Remove this tip prior to submission.)

The System Development Lifecycle (SDLC) starts with the initiation of the system planning process, and continues through system acquisition and development, implementation, operations and maintenance, and ends with disposition of the system. Specific decisions about security must be made in each of these phases to assure that the system is secure.

--- Custom Document Property (SysAcronym) is currently in the [Initiation, Acquisition & Development, Implementation, Operational and Maintenance, or Disposal] phase of the System Development Lifecycle.

Tip: Explain further when the plans are for this system. Are there any other major changes planned? When will they happen?] (Remove this tip prior to submission.)

2.2 System Characterization

2.2.1 System Name/Title

Tip: This information will be filled in automatically if you updated the custom document properties. (Remove this tip prior to submission.)

--- Custom Document Property (SysName)/--- Custom Document Property (SysAcronym)

2.2.2 Responsible Organization

Tip: The responsible organization owns the data, and controls the use of the data. List the federal organizational sub-component responsible for the system such as a contractor, what role that contractor performs, and describe the relationship with the System owner organization. Be specific about the organization and do not abbreviate. Include phone numbers, physical locations, and addresses. (Remove this tip prior to submission.)

The following responsible organization owns the system, the data it contains, and controls the use of the data.

Center for Devices and Radiological Health (CDRH)

Office of the Director

U.S. Food and Drug Administration

202-555-1234 x1234

555 99th Street S.W., Washington, DC 20410 The System is maintained by:

Appropriate Contractor Firm

123-456-7890 x0000

1234 Main St

Anywhere, USA, 12345

2.2.3 Information Contact(s)

Tip: Specify the program owner, program manager, Information System Security Officer (ISSO), and the system manager for the system. Include their address, telephone numbers, and e-mail. List the contact information for one or more persons designated to be the point(s) of contact for this system. The designated persons should have sufficient knowledge of the system to be able to provide additional information or points of contact, as needed. (Remove this tip prior to submission.)

The designated person(s) have sufficient knowledge of the system to be able to provide additional information or points of contact regarding the security plan and the system, as needed.

Table 2: Information Contacts

Program Manager

System Manager

Information System Security Officer (ISSO)

Designated Representative

2.2.4 Assignment of Security Responsibility

Tip: List the Information System Security Officer(s) (ISSO), or other person(s) responsible for the security of the system, including their address and phone number. An individual must be assigned responsibility in writing to ensure that the GSS or MA has adequate security. To be effective, this individual must be knowledgeable of the management, operational, and technical controls used to protect the system. (Remove this tip prior to submission.)

The designated person(s) responsible for the security of the system has/have been assigned responsibility in writing to ensure that the GSS or MA has adequate security and is knowledgeable of the management, operational, and technical controls used to protect the system.

Table 3: Designated Persons

2.2.5 Designated Authorizing Agent (DAA):

The designated person formally assumes responsibility for the operations of --- Custom Document Property (SysAcronym) at an acceptable level of risk to agency operations, agency assets, or individuals.

Lori Davis

Chief Information Officer (CIO)

U.S. Food and Drug Administration

1350 Piccard Drive Rockville, MD 20850 301-255-6700

3 General Description/Purpose

Tip: Provide a description (one to three paragraphs) of the function and purpose of the system (e.g., economic indicator, network support for an organization, business census data analysis, and crop reporting support). Be sure to include the type(s) of information that the system processes. Describe each application's function and the information processed. (Remove this tip prior to submission).

<Start typing here>

3.1 Operational Status

Tip: Select one or more of the following for the system’s operational status: operational, under development, or undergoing a major modification. ALSO: Include date of operation, expected implementation, or completion of modification. In this section discuss: the history of the system; the date the system became or will become operational; if the system is undergoing modification; and all other pertinent information. All milestones until operational status should be stated. If the system is about to go through a major revision, all milestones along the way should be listed as well. (Remove this tip prior to submission).

<Start typing here>

FORMCHECKBOX

Undergoing major modification

3.2 Information System Type

Tip: Identify if the system is a major application, non-major application or a GSS. If the system is a GSS, list all applications supported by the GSS. Specify if the application(s) is or is not a major application and include unique name/identifiers, where applicable. If the system is a major application then indicate what GSS it relies on. A non-major application is a system that relies entirely on the General Support System (GSS) for security. A non-major application doesn’t have identification or authentication and can not have a Security Categorization higher then a Low. (Remove this tip prior to submission).

FORMCHECKBOX

Non-major Application

<Start typing here>

3.3 Users

Tip: Identify the user community that utilizes this system, whether they are internal or external to the system owner’s organization, and a general description of the type of information they process. Identify how the users are assigned rights, explain the different roles. Identify what group/contractor performs administration and how the roles are defined. (Remove this tip prior to submission).

<Start typing here>

4 System Environment

Tip: Provide a brief (one-three paragraphs) general description of the technical system. Identify where the system physically resides. Include any environmental or technical factors that raise special security concerns, such as:

System model – Client/server, Web, backend database etc;

The system is connected to the Internet;

It is located in a harsh or overseas environment;

Software is rapidly implemented;

The software resides on an open network used by the general public or with overseas access;

The application is processed at a facility outside of the organization’s control;

The system is congressionally/federally mandated

Tip: Describe the primary computing platform(s) used (e.g., mainframe, desktop, Local Area Network [LAN] or Wide Area Network [WAN]). Discuss the type of communications included (e.g., dedicated circuits, dial circuits, public data/voice networks, Internet). Describe controls used to protect communication lines. (Remove this tip prior to submission).

<Start typing here>

4.1 Hardware

Tip: Include a list of the principal system components, including hardware and function. Provide server names and IP addresses. (Remove this tip prior to submission).

[Server Name – role/function] – X.X.X.X

4.2 Software

Tip: Identify the manufacture and make of software and the versions running on the system. Include any security software protecting the system and information. (Remove this tip prior to submission).

Windows 2003 Server Service Pack 2(SSP2)

Adobe Acrobat Reader 8

Cisco IOS v12

4.3 Information Flow

Tip: Describe how the users connect to the system, what they use, how they are identified and authenticate. Describe in general terms the type of security protection provided (e.g., access control to the computing platform and stored files at the operating system level or access to data records within an application). Insert the system architecture diagram in this section after the text description. Remove this tip prior to submission.

<Start typing here>

[Insert System Diagram Here]

5 General Description of Information Sensitivity

The information processed by --- Custom Document Property (SysAcronym) requires safeguards to ensure its confidentiality, integrity, and availability. The risk and magnitude of harm from the loss, misuse, or unauthorized access to or modification of information in the system would significantly impact the mission and reputation of the Administration. The sub-sections that follow describe the requirements with respect to confidentiality, integrity, and availability for each system category and are summarized for the system’s overall system security categorization in Table 4.

As stated in NIST 800-37 Rev 1, Guide for Security Authorization of Federal Information Systems, FIPS 199 establishes three potential impact levels (low, moderate, and high) for each of the stated security objectives (confidentiality, integrity, and availability) relevant to securing federal information systems. These impact levels focus on the potential impact and magnitude of harm that the loss of confidentiality, integrity, or availability would have on agency operations, agency assets, or individuals.

It is recognized that an information system may contain more than one type of information (e.g., privacy information, medical information, proprietary information, financial information, contractor sensitive information, system security information), each of which is subject to security categorization. The security category of an information system that processes, stores, or transmits multiple types of information should be at least the highest impact level that has been determined for each type of information for each security objective of confidentiality, integrity, and availability.

The following subsections have been analyzed for --- Custom Document Property (SysAcronym) to determine the security objectives, their impact levels and their criticality.

The following table describes Information Category, from NIST SP 800-60 and a general description of the information handled by the system and the need for protective measures.

Tip: This section provides a description of the types of information handled by the system and an analysis of the sensitivity of the information. The sensitivity of the information stored within, processed by, or transmitted by a system provides a basis for the value of the system and is one of the major factors in risk management. Populate the System Information Types table by relying on the FDA Security Categorization process that is based on FIPS 199 and NIST SP800-60. (Remove this tip prior to submission.)

Table 4: System Information Types & Categorization

5.1 Threat Identification

A threat is the potential for a particular threat-source to successfully exercise a particular vulnerability. The goal of threat identification is to identify the potential threat-sources and compile a threat statement listing potential threat-sources that are applicable toError! Unknown document property name.. A vulnerability is a weakness that can be accidentally triggered or intentionally exploited. A threat-source does not present a risk when there is no vulnerability that can be exercised. Threat agents or actions used in the risk assessments are based on the threats identified in NIST Risk Management Guide for Information Technology Systems, SP 800-30. Although threats can be realized in various forms (i.e., threat agents), threats to systems, leased telecommunications systems, and public telecommunications services can be categorized into three main groups:

· Natural Threats: Floods, earthquakes, tornadoes, landslides, avalanches, electrical storms, and other such events.

· Human Threats: Events that are either enabled by or caused by human beings, such as unintentional acts (inadvertent data entry) or deliberate actions (network based attacks, malicious software upload, unauthorized access to confidential information).

· Environmental and Physical Threats: Long-term power failure, pollution, chemicals, and liquid leakage.

The end result of a threat capitalizing on any vulnerability creates a potential compromise of the agency’s protected assets and information. Threats result in one or more of five general consequences: unauthorized disclosure, data corruption, or destruction, denial of service, system failure, and communications loss. Table 5 identifies threats and actions that may affect Error! Unknown document property name.

Tip: Choose only those applicable to the system and remove those from the document that do not apply. (Remove this tip prior to submission.)

Table 5: Threat Sources and Description

Natural Threats

Human Threats

Environmental and Physical Threats

5.2 Vulnerability Identification

Vulnerability is a flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system’s security policy.

A variety of vulnerability identification techniques were used to obtain the information required for this Risk Assessment, and to help determine the security posture and define operational boundaries for --- Custom Document Property (SysAcronym). The vulnerability identification approach included:

[These are examples – add and remove as necessary] Document Reviews dated mm/dd/yy

Application Scanners dated mm/dd/yy

Vulnerability Scanners dated mm/dd/yy

Information System Self-Assessment dated mm/dd/yy

Tip: Explain the collection process method. See the following example. (Remove this tip prior to submission.)

Vulnerability Scans - Vulnerabilities can be calculated through various vulnerability scanning tools and through various checklists that are specific to the software, hardware, or operating system with which is configured.

5.3 Control Analysis

Control Analysis documents number of management, operational and technical controls requirements for the system and their status as being either in place, planned, or not applicable (NIST SP 800-18 Rev. 1.)

Table 6: Controls Status Summary

Risk Assessment

Planning

Systems and Services Acquisition

Certification, Accreditation, and Security Assessments

Personnel Security

Physical and Environmental Protection

Contingency Planning

Configuration Management

Maintenance

System and Information Integrity

Media Protection

Incident Response

Awareness and Training

Identification and Authentication

Access Controls

Audit and Accountability

System and Communications Protection

Totals

5.4 Threat/Vulnerability Pairs

This section identifies vulnerabilities, threat sources and threat action description.

Table 7: Controls Status Summary Table

Hacking/Social Engineering Several components of the system are missing software patches/updates. These vulnerabilities could be exploited by an unauthenticated user.

6 Risk Results and Control Recommendations

This section presents the results of the risk assessment performed on --- Custom Document Property (SysAcronym) after applying the analysis shown in Appendix A. The results of that analysis are presented below. These observations are stated based on the actual findings from --- Custom Document Property (SysAcronym) Security Control Assessment Report, risk, control identification and recommended remediation activity. The assessment found that identified risks can be successfully remediate through the implementation of security controls specified in each Results Detail, the --- Custom Document Property (SysAcronym) System Security Plan, and in the accompanying Plan of Action and Milestones.

Table 8: Detailed Results

Control Number

Description

Risk

Business Risk

Technical Risk

Likelihood rating

Impact Rating

Recommended Remediation controls

Continue adding tables as necessary to detail all results.

Appendix A Risk Calculation This section discusses vulnerabilities, the threats that can exploit those vulnerabilities, and the probable impact of that vulnerability exploited. System vulnerabilities are identified as required security controls that are not fully implemented. These are classified as vulnerabilities because the lack of required controls result in vulnerability that a threat can be exploited successfully.

The analysis of system vulnerabilities, the threats that can exploit those vulnerabilities, and the probable impact of that vulnerability exploitation resulted in a risk rating for each missing or partially implemented control. The risk level was determined based on the following two factors:

· Likelihood of Occurrence - The likelihood to which the threat can exploit a vulnerability given the system environment, threat frequencies, and other mitigating controls in place

· Impact of the threat exploiting the vulnerability in terms of loss of tangible assets or resources and impact on the organization’s mission, reputation, or interest.

The following sections discuss the areas of potential impact and how the values for the above two factors, magnitude of impact and likelihood of occurrence, and the level of risk were determined. The factors used in these sections are derived from NIST Risk Management Guide for Information Technology Systems, SP 800-30.

Likelihood of Occurrence

The likelihood that a threat will exploit a vulnerability and cause damage for each of the four areas listed above was determined based on the following factors: the frequency of the threat and the existence of mitigating controls. Likelihood of occurrence was determined qualitatively to be high, moderate, or low using the criteria in Table 9.

Table 9: Likelihood of Occurrence Values Criteria

In accordance with NIST guidelines, a numerical value was assigned for likelihood of occurrence as follows:

Likelihood values are based on the threat frequency (Information Sensitivity High, Moderate and Low) and the value entered in the security control implementation status of “I” (Implemented), “P” (Partial), “NI” (Not Implemented), and “N/A” (Not Applicable) a likelihood value is assigned to the threat-vulnerability pairs listed in the RA table using the mappings shown in Table 10.

Table 10: Assignment of Likelihood Values

Impact

An impact analysis prioritizes the impact levels associated with the compromise of an organization’s information assets based on a qualitative or quantitative assessment of the sensitivity and criticality of those assets. The system and data sensitivity can be determined based on the level of protection required to maintain the system and data’s availability, integrity, and confidentiality. To determine overall risk levels, the analysis first looked at how important the security goals (availability, integrity, and confidentiality) of the system and/or its data are to the mission’s ability to function as intended. The system sensitivity values of this report were mapped to the magnitude of impact qualitative values of high (100), moderate (50), and low (10) as defined in the NIST guidelines and shown below in Table 11.

Table 11: Definitions

To determine overall risk levels, the analyst must first look at how important the availability, integrity, and confidentiality of the system is in relation to it being able to perform its function, and the types of damage that could be caused by the exercise of each threat-vulnerability pair. Exploitation of vulnerability may result in one or more of the following types of damage to a system or its data:

· Loss of Availability/Denial of Service – Access to the system, specific system functionality or data is not available (Asset is not destroyed).

· Loss of Integrity/Destruction and/or Modification – Total loss of the asset either by complete destruction of the asset or irreparable damage, or unauthorized change, repairable damage to the asset, or change to asset functionality.

· Loss of Confidentiality/Disclosure – Release of sensitive data to individuals or to the public who do not have a “need to know.”

Table 12 shows the mapping of security goals (availability, integrity, and confidentiality) to the maximum threat impact values for the system as follows:

Table 12: Threat Impact and Security Sensitivity Mapping

The impact of a specific threat exploiting vulnerability is determined by adding all applicable impact values for the given threat. The formula for Threat Impact is as follows:

Given the security sensitivity values for the environment, the total possible Impact value for the environment is 300. For example, if Threat #1 (Fire) is mapped to a specific vulnerability, the threat impact areas are Denial of Service and Destruction. Therefore, the impact value for the threat-vulnerability pair is 100. If multiple threats are applicable to a single vulnerability, the threat with the greatest number of impact areas is used to determine the overall impact value.

Risk Level

A relative risk level was determined for each vulnerability. The purpose in defining this risk level is to determine both the overall level of risk for the system as well as the degree to which each vulnerability contributes to that risk. The risk level for each control also serves as the basis for prioritizing controls for implementation.

The determination of risk for a particular threat/vulnerability pair can be expressed as a function of the likelihood of occurrence and magnitude of impact. The overall level of risk for each control was determined by the following formula:

Table 13 indicates the range of possible risk values.

Table 13: Risk Level Matrix Risk Level Range of Values

High = 1 Med = .5 Low = .1 High = 100 Med = 50 Low = 10 High = 1 Med = .5 Low = .1 High = 100 Med = 50 Low = 10 High = 1 Med = .5 Low = .1 High = 100 Med = 50 Low = 10

As illustrated in Table 13, three is the lowest possible value for risk, 75 is the median value, and 300 is the highest possible value using this methodology.

Table 14 shows the possible risk ranges for the system. Given the sensitivity values for the environment, the maximum possible risk value is 300, which falls in the high level of risk.

Table 14: Risk Value Matrix

10 x 1.0 = 10 Moderate

50 x 1.0 = 50 High

100 x 1.0 = 100

10 x 0.5 = 5 Moderate

50 x 0.5 = 25 High

100 x 0.5 = 50

10 x 0.1 = 1 Moderate

50 x 0.1 = 5 High

100 x 0.1 = 10

Risk Scale: Low (3 to 99), Moderate (100 to199), and High (200 to 300) Appendix B Schedule of Control Testing The Security Authorization process consists of three annual security control assessments during a given ATO (Authorization to Operate) period totaling 36 months; or until significant change to the system. Below lists all controls tested distributed into three, one year cycles. Notice critical controls are tested annually due to their importance in securing the system.

Table 15: Critical Controls

Table 16: Annual Controls Year 1

Table 17: Annual Controls Year 2

Table 18: Annual Controls Year 3

� EMBED MSGraph.Chart.8 \s ���

PAGE

_1320565275