Scottish Pride, Inc.

Scottish Pride Licensing Application

Plan of Action and Milestones Guide

Version 1.00

February17, 2015

Scottish Pride, Inc. Scottish Pride Licensing Application
Information Technology Department Plan of Action and Milestones Guide

DOCUMENT CONTROL

Change Record

Date / Author / Version / Change Reference
2-17-2015 / Ed Wilson / 1.00 / Initial Draft

Quality Review History

Date / Reviewer / Comments
Page 1 of 15
Scottish Pride, Inc. Scottish Pride Licensing Application
Information Technology Department Plan of Action and Milestones Guide

Table of Contents

1Introduction

1.1Purpose

1.2Background

1.3Scope

2POA&M Overview

2.1POA&M Purpose

2.2Roles and Responsibilities

2.2.1CIO

2.2.2Business Owners

2.2.3System Developers/Maintainers

2.2.4Program Project Manager

3Weakness Remediation Process

3.1Identify IT Security Weaknesses

3.1.1Analyze Weakness Risk Level

3.1.2Document Weakness Risk Acceptance and Decision

3.2Identify Corrective Action Options and Funding Required to Determine Optional Solutions

3.3Determine Funding Availability and Weakness Prioritization

3.4Prioritize Weaknesses

3.5Estimate Completion Dates

3.6Monitor and Report Corrective Action Items

3.7Validate and Document Evidence of Completed Weakness

3.8Retire and Transfer Weaknesses

4POA&M Components and Formatting

4.1Weakness Identifier

4.2Weakness Description

4.3Point of Contact

4.4Resources Required

4.5Scheduled Completion Date

4.6Milestones With Completion Dates

4.7Changes to Milestones

4.8Identified in Audit or Other Review?

4.9Completion Date

4.10Status

4.11Comments

4.12Risk Level

4.13Weakness Severity

List of Tables

Table 1: Sample Format of Quarterly Summary Update to CIO

Table 2: POA&M Field Descriptions

List of Figures

Figure 1: The Weakness Remediation Process

Figure 2: Sample System Weakness Identifier

Page 1 of 15
Scottish Pride, Inc. Scottish Pride Licensing Application
Information Technology Department Plan of Action and Milestones Guide

1Introduction

The Information Technology Department(IT) is responsible for implementing and administering an information security program to protect its information resources, in compliance with best practices identified in Florida Information Technology Resource Security Policies and Standards identified in 71A-1.001-.010, F.A.C. and applicable laws, regulations, and Executive Orders. ITemploys the process defined by the Agency for State Technology (AST)in its Plan of Action and Milestones (POA&M) Guide. The IT POA&M Guidance is based on the National Institute of Standards and Technology (NIST) guidelines identified in Florida Information Technology Resource Security Policies and Standards identified in 71A-1.001-.010, F.A.C.

1.1Purpose

The IT POA&M Guidelines provides ITmanagement and Business Owners with the necessary information and instructions for developing, maintaining, and reporting their weaknesses in information security as it relates to the Scottish Pride Licensing Application (SPLA) system.

1.2Background

TheIT POA&M guidelines comply with the requirements prescribed by ASTbest practices identified in Florida Information Technology Resource Security Policies and Standards identified in 71A-1.001-.010, F.A.C. Information is included in this document to account for the emphasis that has been placed on formalizing the weakness mitigation process and ensuring weaknesses are appropriately prioritized for mitigation.

1.3Scope

This document applies to IT Business Owners and third-party System Developer/Maintainers. Any personnel tasked with completing POA&M activities should read this document in its entirety to become familiar with the IT POA&M process.

2POA&M Overview

A POA&M is a management process that outlines risks or weaknessesand delineates the tasks necessary to mitigate them. TheIT POA&M process is used to facilitate the remediation of system-level weaknesses, and will provide a means for:

  • Planning and monitoring corrective actions
  • Defining roles and responsibilities for weakness resolution
  • Assisting in identifying the security funding requirements necessary to mitigate risks or weaknesses
  • Tracking and prioritizing resources
  • Informing decision makers

2.1POA&M Purpose

The POA&M and its supporting processes enhance the Information Technology Department’s ability to identify, assess, prioritize, and monitor the progress of corrective actions pertaining to information security weaknesses found within systems. IT uses the POA&M process to minimize security vulnerabilities, assist the Office of the Inspector General (OIG) in evaluating the agency’s security performanceand provides ASTwith insight into the health and maturity of IT’sInformation Security program.

2.2Roles and Responsibilities

POA&Ms are designed to be used predominately by Directors, Chief Information Officers (CIOs), Program Project Managers, Business Owners, System Developer/Maintainers, and Information System Security Officers (ISSOs) to track the progress of IT weakness corrective actions.

The CIO should develop, implement, and manage POA&Ms for all systems that they operate and control. The overall responsibility for the POA&Ms rests with the CIO, but others have significant roles as well.

2.2.1CIO

  • Assignresponsibility for oversight and management of the IT POA&M
  • CommunicateIT progress in correctingweaknesses reflected in the POA&M
  • Allocate proper resources to permit identification and remediation of
    weaknesses

2.2.2Business Owners

  • In conjunction with theCIO, develop, implement, and manage system-level corrective action plans for weaknesses in the SPLA system supporting its operations and assets
  • Update IT management regularly (at the direction of the CIO or the management of their functional component) on the progress of weakness remediation efforts, enabling the CIO to monitor program-wide remediation efforts
  • Request adequateresources to permit identification and remediation of weaknesses.

2.2.3System Developers/Maintainers

  • Develop and implement corrective actions that involve system modifications and enhancements
  • For the POA&M process, provide estimated dates of completion for these corrective actions

2.2.4Program Project Manager

  • Work with Business Owners and System Developers/Maintainers to develop, implement, and manage an corrective action plan for the SPLA system
  • Verifythe POA&M contains appropriate details, as required by (AST) best practices identified in Florida Information Technology Resource Security Policies and Standards identified in 71A-1.001-.010, F.A.C.
  • Conduct follow-up activities to verify a corrective action’s status
  • Update CIO at least quarterly, regarding the progress of the mitigation activities of each weakness.

3Weakness Remediation Process

Weakness remediation is the process whereby security vulnerability is identified, corrective actions are initiated, and the weakness is properly mitigated. This process is depicted inFigure 1: The Weakness Remediation Process, and the steps by which the process is carried out are described in greater detail throughout the remainder of this section.

Figure 1: The Weakness Remediation Process

3.1Identify IT Security Weaknesses

Weaknesses appropriate for tracking using the POA&M process are identified proactively or reactively. Proactive weakness determinations occur when regular system reviews are conducted by the agency responsible and vulnerabilities are identified and/or documented. Reactive weakness determinations indicate the weakness was identified using audits or external reviews.Sources of weaknesses may include findings from the following reviews:

  • State of Florida Auditor General Audits
  • System self-assessments
  • Risk assessments
  • Penetration tests

3.1.1Analyze Weakness Risk Level

All security weaknesses representing risk – of any level - to the security of SPLA and that require planned mitigation must be captured in the POA&M.

3.1.2Document Weakness Risk Acceptance and Decision

In some cases, aSPLAweakness may not be documented in the POA&M because a determination was made that the continued existence of the weakness is an acceptable risk. Such a determination must be certified by the Business Owner and documented accordingly in the System Security Plan.

3.2Identify Corrective Action Options and Funding Required to Determine Optional Solutions

Multiple weakness mitigation methods often exist. Such methods should be analyzed for their ability to fully resolve the SPLAweakness in the most efficient manner. The cost for each option should be estimated and analyzed to determine short- and long-term solution options.

3.3Determine Funding Availability and Weakness Prioritization

The cost of weakness remediation activities must be determined and included in the SPLAPOA&M. Additionally, the availability of funding required to mitigate weaknesses must be evaluated. Three funding scenarios exist in support of weakness mitigation efforts.

  • Current resources exist that may be allocated to mitigate identified weaknesses. (This is the scenario commonly adopted because the weaknesses need to be addressed in the near term)
  • Resources exist but must be reallocated to support weakness mitigation
  • Additional funding must be requested and allocated

3.4Prioritize Weaknesses

NIST guidance requires IT to prioritize POA&M weaknesses to ensure the most critical security weaknesses and/or the weaknesses identified on systems with the greatest potential impact to the agency’s mission are addressed first.

Resource limitations often prevent the Business Owner from obtaining the resources necessary to mitigate every identified weakness within the same time period. The careful prioritization of SPLAweaknesses helps to assurecritically important weaknesses are allotted resources within a time period proportionate to the risk associated with the vulnerability or system.

Rank-ordering corrective actions to address weaknesses according to specific criteria are essentialto effective prioritization. Documented rank-ordering criteria enable the Business Owner to prioritize corrective actions in a standardized fashion against factors that are specific to the IT operating environments. Criteria against which weaknesses may be prioritized include:

  • Risk level of weakness and risk impact level of system
  • Specific security control implementation
  • Cost effectiveness of implementing the corrective action
  • Length of time since the weakness was identified

Basic weakness prioritization focuses on two criteria: system categorization and weakness risk level. According to FIPS 199, the SPLA system was categorized as moderateon the confidentiality, integrity, and availability vulnerabilities of the information it stores, processes, or transmits. System characterization was determined in the system’s risk assessment.The resulting system categorization, also known as the risk impact level, should be used to help identify those weaknesses that require immediate attention.

3.5Estimate Completion Dates

The estimated date of completion for each SPLAweakness must be based on realistic timelines that allow for resources to be obtained and associated steps to be completed. The completion date should be based on the outcome of prioritization decisions and resource availability.

3.6Monitor and Report Corrective Action Items

The information in the SPLA POA&M should be maintained continuously and a quarterly status report must be provided to communicate overall progress to the CIO. The recommended format of the quarterly SPLA POA&M summary status report is shown in Table 1 below.

Quarterly POA&M Updated Information / SPLA System
Total number of weaknesses identified at the start of the quarter
Number of weaknesses for which corrective action was completed on time (including testing) by the end of the quarter / 1
Number of weaknesses for which corrective action is ongoing and is on track to complete as originally scheduled / 8
Number of weaknesses for which corrective action has been delayed, including a brief explanation for the delay / 0
Number of weaknesses discovered following the last POA&M update and a brief description of how they were identified (i.e., agency review, audit, etc.) / 0

Table 1: Sample Format of Quarterly Summary Update to CIO

3.7Validate and Document Evidence of Completed Weakness

NIST reporting guidance recommends that SPLAweaknesses should be considered “Completed” only when they have been fully resolved and tested. Testing completed weaknesses demonstrates that the system control has been adequately addressed and proven effective.

3.8Retire and Transfer Weaknesses

Weaknesses that have been mitigated for over a year should no longer be reported in the SPLAPOA&M. ITmay age off any weaknesses that have been “Completed” for at least 12 months if POA&M gets really large.

4POA&M Components and Formatting

The SPLAPOA&M is formatted using the same required fields, which contain information about the weakness and its associated remediation activities. This section describes the content and formatting for each of the prescribed fields, listed in Table 2below, inclusive of NIST requirements.

Field Heading / Contents – How to Complete
Weakness Identifier / The Weakness Identifier is a unique character string used to track weaknesses from quarter to quarter.
Weakness Description / A weakness represents any SPLA system-level information security vulnerability that poses an unacceptable risk to the confidentiality, integrity, or availability of information.
Point of Contact / The Point of Contact (POC) is the agency or position title within the Department, business unit, or third-party representative that is responsible for weakness mitigation.
Resources Required / Resources required include the funding or man-hours necessary for mitigating a weakness. The type of funding (new, existing, or reallocated) should be noted.
Scheduled Completion Date / The scheduled date of completion should be based on a realistic estimate of the amount of time it will take to organize the resources necessary to implement and test the completion of the corrective action.
Milestones With Completion Date / Milestones outline the high-level activities necessary to fully mitigate the weakness.
Changes to Milestones / At a minimum, a change to a milestone should indicate the new estimated date of completion if the original milestone data cannot be met. Actual milestone completion date should be included within this field.
Identified in Audit or Other Review? / This field must note the review type, reviewing agency, and the publication date of the document that first identified the weakness being addressed.
Completion Date / This field represents the actual date the last corrective action milestone was completed.
Status / This field is used to report the status of the weakness. Options are limited to Completed, Ongoing, or Delayed.
Comments / This field is used to document additional detail or provide clarification, and must be used if a weakness lapses into delayed status to explain the reason(s) for the delay.
Risk Level / The “Risk Level” field denotes the determined potential impact of a weakness on the system.
Weakness Security / The weakness severity field is used to categorize each weakness based on the risk it poses to the agency’s overall security. The weakness severity categories are limited to significant deficiency, reportable condition, or weakness.

Table 2: POA&M Field Descriptions

Please note, once the CIO has accepted the initial POA&M, no changes can be made to the data in the following fields:

  • Weakness Identifier
  • Weakness Description
  • Scheduled Completion Date
  • Milestones With Completion Dates
  • Identified in audits or other Review

4.1Weakness Identifier

Each POA&M weakness is assigned a unique weakness identifier. This identifier is used to track weaknesses from quarter to quarter. The numbering scheme used to generate the weakness identifier for a system consists of the name of the associated system, the quarter and State Fiscal Year (SFY) during which the weakness was first recorded on the POA&M, and a sequence number. See Figure 2below for a sample system weakness identifier using the following legend:

Legend
SPLA / System Name
4 / Quarter:
1st = July - September
2nd = October - December
3rd= January - March
4th = April - June
2014 / Fiscal Year
1 / User Assigned Sequence Number

SPLA_4_2014_1

Figure 2: Sample System Weakness Identifier

In the sample above, “SPLA” represents the IT system name or acronym. The number “4” represents the quarter in which the weakness was first identified and entered on the POA&M. The number “2014” represents the FY in which the weakness was identified and submitted. The value “1” represents the numerical order in which this weakness was entered on the POA&M for the SPLA system.

4.2Weakness Description

The term “weakness” refers to any SPLAvulnerability that poses a risk to the confidentiality, integrity, or availability of IT information. Weaknesses represent the gaps between the current SPLAsystem status and the long-term SPLA system security objectives.

When reporting weaknesses, consideration must be given to the level of detail revealed in the SPLAPOA&M. Detailed descriptions are neither necessary nor recommended; however, sufficient data is required to enable appropriate oversight and tracking, demonstrate awareness of the weakness, and articulate specific actions initiated to address the weakness. Sensitive information should never be included in the SPLA POA&M due to the risk of system vulnerability exposure and/or exploitation it enables. When necessary, additional details may be provided in the “Weakness Comments” field.

4.3Point of Contact

A Point of Contact (POC) must be identified and documented for each weakness reported. The POC is the position/role (e.g., Program Project Managers, ISSO, Business Owner, third-party representative) responsible for resolving the weakness. Since personnel in these positions may change, using specific POC names is not recommended. Verify at a minimum the following criteria is applied:

  • Personnel names and phone numbers for the POC are not listed
  • POC is listed for all weaknesses
  • Alternate POC for each weakness are identified if necessary
  • POC listed on the POA&M is aware of and accepts the responsibility for mitigating the weakness

4.4Resources Required

Weakness correction requires resources; the type and amount of which will vary. If existing personnel are assigned to correct the weakness and no new funding is required, the SPLAPOA&M should identify the amount of time it will take to complete the corrective action (e.g., 60 hours) and that it is performed by current staff. The resources required estimate must be based on the total resources needed to fulfill all the milestones necessary for weakness correction.

The type of funding (new, existing, or reallocated) should be noted in addition to the dollar amount and/or man hours. Specific information related to non-funding obstacles and challenges to resolving the weakness (e.g., lack of personnel or expertise, development of a new system to replace vulnerable legacy system) should be included in the “Weakness Comments” field. Validate at a minimum the following criteria is applied:

  • Resource(s) for mitigating each weakness are assigned
  • Resource estimatesare submitted as man-hours or an equivalent monetary value
  • Monetary funding is identified as “new funding,” “existing funding,” or “reallocated funding” These descriptors can also be applied to staffing requirements (e.g., “new staff” or “existing staff”)

4.5Scheduled Completion Date

The scheduled date of completion should be determined based on a realistic estimate of the amount of time it will take to allocate the required resources, implement the corrective action(s), and complete all associated milestones.