CCLA Risk Report - ISACA · Web viewThis risk assessment report identifies threats and...

Scottish Pride

Scottish Pride Licensing System

Risk AssessmentSummary Report

Version 1.00

February 17, 2015

Scottish Pride, Inc. Scottish Pride Licensing Application Information Services

DOCUMENT CONTROL

Change RecordDate Author Version Change Reference

Quality Review HistoryDate Reviewer Comments

Approval Sign-offName Role Signature Date

Page of


Table of Contents1 EXECUTIVE SUMMARY..................................................................................................................................5

1.1 TOP VULNERABILITY LIST.............................................................................................................................71.1.1 DISASTER AND CONTINGENCY PLANNING.....................................................................................................71.1.2 INCIDENT RESPONSE TRAINING AND TESTING..............................................................................................81.1.3 VULNERABILITY SCANNING...........................................................................................................................91.2 ORGANIZATION COMPLIANCE......................................................................................................................101.3 NON-COMPLIANCE REPORT.........................................................................................................................11

2 INTRODUCTION..............................................................................................................................................13

2.1 PURPOSE......................................................................................................................................................132.2 SCOPE...........................................................................................................................................................14

3 RISK ASSESSMENT APPROACH.................................................................................................................14

3.1 RISK ASSESSMENT OBJECTIVE....................................................................................................................143.2 GOAL...........................................................................................................................................................153.3 RISK ASSESSMENT PROCESS........................................................................................................................163.4 PHASE I........................................................................................................................................................173.5 PHASE II.......................................................................................................................................................183.6 PHASE III.....................................................................................................................................................19

4 SYSTEM IDENTIFICATION..........................................................................................................................20

4.1 SYSTEM DESCRIPTION.................................................................................................................................204.2 SYSTEM ENVIRONMENT...............................................................................................................................234.3 INFORMATION SENSITIVITY.........................................................................................................................25

5 CONTROL ANALYSIS....................................................................................................................................26

5.1 BASELINE SECURITY CONTROL GAP SUMMARY.........................................................................................28

6 RISK CALCULATION.....................................................................................................................................32

6.1 IDENTIFICATION OF VULNERABILITIES........................................................................................................326.2 IDENTIFICATION OF THREATS......................................................................................................................326.3 IDENTIFICATION OF RISKS...........................................................................................................................326.4 CORRELATION OF RELEVANT CONTROLS....................................................................................................326.5 RISK LIKELIHOOD DETERMINATION............................................................................................................336.6 IMPACT ANALYSIS.......................................................................................................................................336.7 RISK DETERMINATION.................................................................................................................................346.8 RECOMMENDATIONS....................................................................................................................................346.9 SPLA RISK MATRIX....................................................................................................................................34

APPENDIX A – CONTROL CATEGORY DESCRIPTION.................................................................................51

APPENDIX B – GLOSSARY....................................................................................................................................52

APPENDIX H – LAWS, REGULATIONS, AND GUIDANCE.............................................................................54

APPENDIX I – RISK BASED DECISION DOCUMENTS...................................................................................57

Page of


LIST OF TABLESTable 1: IT System Inventory and Definition Document.......................................................22Table 2: Scottish Pride Licensing Application System Specifics............................................24Table 3: Server Categorization.............................................................................................25Table 4: Scottish Pride Licensing Application Information Sensitivity...................................25Table 5: High-level Security Controls Status Summary........................................................27Table 6: Baseline Security Controls Gap Summary...............................................................28Table 7: Threats Identified in IT............................................................................................32Table 8: Risk Likelihood Definitions......................................................................................33Table 9: Risk Impact Rating Definitions................................................................................33Table 10: Overall Risk Rating Matrix....................................................................................34

LIST OF FIGURESFigure 1: NIST-SP800-53 Non-Compliance............................................................................11Figure 2: NIST-SP800-53 Non-Compliance By Control Family...............................................12Figure 3: NIST-SP800-53 Compliance by Control Family.......................................................12Figure 4: Step 4 of the Risk Management Framework is In-Scope for this Project................15Figure 5: North Highland Phase Approach............................................................................17Figure 6: Scottish Pride Licensing Application Server Configuration.....................................23Figure 7: Scottish Pride Licensing Application Basic Network Diagram................................23

Page of


1 EXECUTIVE SUMMARY This report documents results of the risk assessment of the Scottish Pride Licensing Application (SPLA) for Scottish Pride Information Services (IT). The risk assessment was conducted by the Information Technology (IT) Department to satisfy the best practice recommendations of the Agency for State Technology (AST). Specifically, AST recommends agencies perform and document such an assessment on sensitive IT systems annually, or whenever a significant change is made to a sensitive system.

This risk assessment describes vulnerabilities, threats, and risks to which SPLA is exposed, derived from the Information Technology (IT) Department’s observations, interviews, and documentation reviews regarding SPLA. The report also assigns a likelihood, impact, and overall rating to each risk, based on the methodology described within the report, and makes recommendations for mitigation of each risk, based on Information Technology (IT) Department’s independent analysis.

This report documents the risks that pertain to SPLA at the time the assessment was conducted, and, as such constitutes a snapshot in time of SPLA. It is intended to be used, along with the SPLA Plan of Action and Milestone (POA&M) and Continuous Monitoring Plan risk to develop enterprise-wide plans for the further mitigation of risks to SPLA. The plan should be commensurate to the sensitivity of the data, and the extent of the risks. It does not constitute, nor does it seek to constitute, an overall assessment of the functionality of SPLA, nor of the knowledge, skills, and abilities, or professionalism of the staff charged with its development, maintenance, and operation.

The risk assessment was performed in accordance with the methodology described in NIST SP 800-53 Revision 3 Recommended Security Controls for Federal Information Systems and NIST SP 800-30 and Risk Management Guide for Information Technology Systems. Also, Information Technology (IT) Department conducted interviews with IT and Scottish Solutions staff to identify components and functions of SPLA. This methodology is detailed further in the NIST Risk Management Framework. By following the NIST SP-800-53 method, IT has already made information-protection improvements based on risks to the confidentiality, integrity, and availability of critical information technology assets.

The Information Technology (IT) Department’s analysis team conducted a knowledge base questionnaire with staff, providing information on controls, control objectives for federal/government standards and regulations. The questionnaires were mapped to the 11 fundamental elements of Information Security, to controls within Information Security requirements identified in

Page of


NIST SP 800-53, NIST SP 800-122, HIPAA, GLBA, Sarbanes-Oxley Act, California SB-1386 and USA Patriot Act, thereby acting as an interface between these myriad of information security requirements. The results indicated that the agency’s SPLA system overall is 93% compliant in meeting NIST Standard 800-53 Revision 3 Recommended Security Controls for Federal Information Systems.

Overview of Risk Assessment Results Overall, the agency is managing risks that affect SPLA system in an appropriate manner. The risk assessment found no evidence of compromise of the confidentiality, integrity, or availability of SPLA and the sensitive data in handles. In addition, the staff including both employees and Scottish Solutions contractors is exceptionally dedicated and able. Appropriate management of risks to the confidentiality, integrity, and availability of sensitive data is a primary consideration in the development, maintenance, and operation of SPLA. The risk assessment documented by this report, however, did identify nine (9) risks associated with SPLA, associated primarily with a single type of control weakness. An industry-standard methodology for categorizing controls to mitigate risks describes these controls as being of one of three types:

1. Management controls, which are policies adopted by the senior management to describe actions and behaviors required to achieve the desired reduction in risk;

2. Operational controls, which are processes and procedures implemented to put policies described by management controls into practice; and

3. Technical controls, which are executed by computer system to enforce management and operational controls, and provide automated protection from unauthorized access or misuse, facilitate detection of security violations, and support security requirements for applications and data.

The risk assessment of SPLA found management and technical controls applied to SPLA are for, all in all, adequate. The majority of risks identified in the body of this report are associated with weaknesses in operational controls. These may controls that are informal and are not fully documented.

This association of the majority of SPLA risks with operational control weaknesses is especially important in light of the relatively small size and high utilization of the staff and Scottish Solutions contractors. In this environment, the likelihood of overlooking an informal or undocumented

Page of


process or procedure under customer, service-level, or deadline pressures is high, and can inadvertently expose sensitive data to risk of compromise. As part of its enterprise risk mitigation strategy, a relatively modest investment in formalizing and documenting operational would yield value for IT in more comprehensive risk mitigation far beyond its cost.

For the staff, implementation of AST best practices identified in 71A-1, F.A.C, “Florida Information Resource Security Policies and Standards.” http://Rule 71A-1, F.A.C., Florida Information Technology Resource Security Policies and Standards.pdf is recommended to assure effective use and compliance. The results of this Risk Assessment indicate that IT must place the highest priority on the recommendations, remediation requirements outlined in the Plan of Action & Milestones (POA&M) and implement new controls that would enable IT to monitor compliance to their security and privacy objectives.

1.1 Top Vulnerability ListThe list below contains the “Top Vulnerabilities” findings, weaknesses, or vulnerabilities discovered during the site security assessment.

1.1.1 Disaster and Contingency Planning

Observation: IT will benefit from developing a Disaster Contingency Plan. The plan should detail procedures to provide an effective response to disruptions and natural disasters by explicitly indicating the intended disruption/disaster coverage. IT should include a management structure for business continuity training and testing within the agency as defined in CP-3 Contingency Training and CP-4 Contingency Plan Testing and Exercises. There are no provisions identified in the Southwood Shared Resource Center (SSRC) Service Level Agreement (SLA) pertaining to SPLA operations and recovery.

Best Practices: Whether SPLA processes or stores sensitive date, the requirement for a disaster and contingency plan impacts the availability of the system. In the case of SPLA externally facing the public, the public will demand that it be available 7 by 24. Internally, availability will impact on IT capability to carry out its mission. In both cases a disaster and contingency plan are a necessity to the image of IT in maintaining public trust

Risk: If a disaster and contingency plan are not in place, tested, and staff trained, then public and employee trust could be lost resulting in embarrassing media attention and state government officials. IT may not

Page of

http://www.myflorida.com/myflorida/cabinet/aeit/docs/NoticeofProposedRule(NewRuleChapter71A-1).pdf




be able to sustain or resume communications and IT functions that support critical business operations and essential constituent services within a specified period of time.

Recommendation: IT should implement and support an appropriate information technology business continuity program to ensure the timely delivery of critical automated business services to the State’s citizens. IT has primary leadership responsibility to identify information technology risks and to determine what impact these risks have on SPLA business operations. IT should also plan for business continuity, including disaster recovery, based on these risks and document continuity and recovery strategies and procedures in a defined business continuity plan that is reviewed, approved, tested and updated on an annual basis.

IT management and information custodians must ensure that business continuity and disaster recovery plans are developed, maintained, tested on a prescribed basis and subjected to a continual update and improvement process.

Train, Test and/or exercise the contingency plan for SPLA at least annually using defined training awareness and tests and/or exercises to determine the plan's effectiveness and the agency's readiness to execute the plan. Once per quarter, a testing team should evaluate a random sample of system backups by attempting to restore them on a test bed environment. The restored systems should be verified to ensure that the operating system, application, and data from the backup are all intact and functional.

1.1.2 Incident Response Training and Testing

Observation: The agency does not implement incident response training as defined in IR-2 Incident Response Training.

Best Practices: IT has a program in place that allows for reporting security incidents. However, not providing formal training and testing may lead to internal and external breaches occurring as a result of unauthorized people being granted improper access or intrusions being made to both the software and equipment. AST best practices require that an Agency Form Security Incident Report, be completed. These security incidents then must be tracked and corrective action taken.

Risk: Failure to provide formal training and testing to document, assess, and take corrective action on security incidents that arise may cause serious security exposures. Included in these are (1) potential damage to

Page of


the system or information contained within it; and (2) violation of privacy rights. These type of incidents need to be evaluated for the possible loss of confidentiality, loss of data integrity, denial of service, and the risk they present to the agency in terms of public and employee trust.

Recommendation: After defining detailed incident response procedures, the incident response team should develop and engage in periodic scenario based training and testing, working through a series of attack scenarios fine tuned to the threats and vulnerabilities the agency faces. These scenarios help ensure that team members understand their role on the incident response team and also help prepare them to handle incidents.

1.1.3 Vulnerability Scanning

Observation: The agency has not implemented vulnerability scanning and penetration testing as defined in RA-5 Vulnerability Scanning.

Best Practices: IT should conduct vulnerability scans to ascertain vulnerabilities inside the network perimeter demilitarized zone (DMZ). The overall objective is to identify potential vulnerabilities within the internal network and weaknesses in controls in place to prevent and/or detect their exploitation by a hacker/malicious employee/contractor who may obtain unauthorized access to information resources or cause system disruption or a system outage.

Risk: Failure to conduct formal vulnerability scanning and penetration testing does not allow the agency to identify potential vulnerabilities within the internal network and weaknesses in controls in place to prevent and detect their exploitation by a hacker/malicious employee/contractor who may obtain unauthorized access to information resources or cause system disruption or a system outage. Recommendation: Penetration tests and vulnerability assessments should be performed annually or immediately after system upgrades to verify that unauthorized connections and systems changes have not been made. Regular penetration tests identify vulnerabilities and attack vectors that can be used to exploit enterprise systems successfully. Penetration testing should occur from outside the network perimeter as well from within its boundaries to simulate both outsider and insider attacks.

Page of


1.2 Organization ComplianceBy integrating all the various requirements into a compliance matrix, the IT analysis team was able to determine the extent of non-compliance and make appropriate recommendations. The IT analysis team used an integrated compliance health check solution tool for the myriad of information security requirements in the IT. The IT analysis team used a unique way to process all information security requirements for risk assessment and present the results as a comprehensive report of areas in which the IT may have failed regulatory compliance.

The Compliantz tool the IT analysis team used consists of a knowledge base, providing information on controls, control objectives for federal/government standards and regulations. The IT analysis team then mapped the 11 fundamental elements of Information Security, to controls within Information Security requirements, such as ITO 27002 / ITO 27001, NIST SP 800-53, NIST SP 800-122, HIPAA, GLBA, Sarbanes-Oxley Act, California SB-1386 and USA Patriot Act, thereby acting as an interface between these myriad of information security requirements.

Compliantz is predicated on the Plan-Do-Check-Act methodology (established over 50 years ago in Japan).

1. Plan: Gap analysis and mapping tool for highlighting areas of security exposure and evaluating IT’s state of readiness for compliance or certification.

2. Do: Rate IT’s state of readiness. This rating is presented in actual percentage terms.

3. Check: Perform benchmarking, also known as a verification audit or gap analysis which entails a process of comparing IT’s current information security management system, if any, to ITO 27002 / ITO 27001, NIST SP 800-53, NIST SP 800-122, HIPAA, GLBA, Sarbanes-Oxley Act, California SB-1386 and USA Patriot Act, elements, identifying any non conformities in SPLA and recommending how to bring them into conformance with these elements.

4. Act: Based on answers received from questions, Compliantz determines if IT is required to comply with these standards and where they may be deficient.

Page of


1.3 Non-Compliance ReportStandard: National Institute of Standards and Technology (NIST)Owner: U.S Department of CommerceType: RegulatoryEffective date: October 2010Industry: FederalPenalties: LitigationPenalty Types: Federal The Information Technology Laboratory (ITIL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of non-national security-related information in Federal information systems.

NIST-SP800-53: Revision 3 Non-Compliance Report for SPLA Overall Rating: 7%

Figure 1: NIST-SP800-53 Non-Compliance

Page of


Figure 2: NIST-SP800-53 Non-Compliance By Control Family

Figure 3: NIST-SP800-53 Compliance by Control FamilyPage of


2 INTRODUCTIONA Risk Assessment is an important tool for Information Technology (IT) managers to use in evaluating the security of the IT systems that they manage, and in determining the potential for loss or harm to organizational operations, mission, and stakeholders. The risk assessment provides management with the capability to:

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

Meet Federal, State, and SPLA requirements for information and system security

Satisfy oversight organizations Establish an acceptable level of risk

Risk can never be totally eliminated, but can be minimized by the application of IT security controls. The decision as to what level risk will be accepted will be based on management review of the identified IT security controls needed to mitigate risk versus the potential impact of implementing those controls on available resources and system operations. The Risk Assessment identifies the current level of risk for the SPLA application and provides risk mitigation recommendations for management review. The Risk Assessment serves as the primary access control function for numerous critical applications and the loss of system availability and/or integrity that could have a debilitating impact on the agency’s mission. The sensitivity level of the system and of the information stored within, processed by, or transmitted by the SPLA system reflects the value of the system to the agency. The sensitivity level has been used as the basis for implementing the necessary IT security controls for SPLA.

This risk assessment describes SPLA vulnerabilities and associated threats based on executive, legislative, departmental, and technical guidelines. The Scottish Pride Security Program, establishes the policy, as well as organizational and management responsibility to implement the necessary controls. The security risk assessment methodology is adapted from National Institute of Standards and Technology (NIST) Risk Management Guide for Information Technology Systems, Special Publication 800-30.

2.1 PurposeThe purpose of this report is to provide the CIO with an assessment of the adequacy of the management, operational and technical security controls that are currently in place to secure SPLA. This risk assessment report identifies threats and vulnerabilities applicable to SPLA. It also evaluates the

Page of


likelihood that vulnerability can be exploited, assesses the impact associated with these threats and vulnerabilities, and identifies the overall risk level. This report documents risk assessment activities conducted by IT personnel from 1-14-2015 to 1-30-2015, and will help the CIO understand risks to SPLA resources.

2.2 Scope The scope of this risk assessment assessed SPLA’s use of resources and controls (implemented or planned) to eliminate and/or manage vulnerabilities exploitable by threats internal and external to IT. If exploited, these vulnerabilities could result in:

Unauthorized disclosure of data Unauthorized modification to the system, its data, or both Denial of service, access to data, or both to authorized users

This Risk Assessment Report evaluates the confidentiality (protection from unauthorized disclosure of system and data information), integrity (protection from improper modification of information), and availability (loss of system access) of SPLA. Recommended security safeguards will allow management to make decisions about security-related initiatives.

3 RISK ASSESSMENT APPROACH3.1 Risk Assessment ObjectiveThe objective of the project is to assess the security controls using appropriate methods and procedures to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the SPLA system.

IT has completed Steps 1, 2, and 3 of the 6-step Risk Management Framework. This project will continue the agency path towards implementing steps 1 through 6 enabling them to become compliant with AST’s best practices. Step 4 is in scope for this project.

IT shall review results of Step 4 of the Risk Management Framework and implement appropriate security controls that are cost effective in the reduction or elimination of identified risks to SPLA. NIST SP 800-30 Risk Management Guide for Information Technology Systems sp800-30.pdf and NIST SP 800-53 Revision 3 Recommended Security Controls for Federal Information Systems sp800-53-rev3-final.pdf are hereby incorporated by reference.

Page of

http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf

STEP

2SELECTSecurity

Controls FIPS 200/SP 800

-53

Define

category of information

system according to potential impact of

loss

IMPLEMENTSecurity Controls

SP 800 SeriesSele

ct minimum security controls (i.e.,

safeguards and countermeasures) planned or in place to protect the information syste

m

Implement

security controls in new or

legacy information systems; implement

security configuration

checklists

Determine extent

to which the security controls

are implemented correctly, operating as intended,

and producing desired outcome with respect to

meeting security requirements

Determine risk to operatio

ns, assets

, or individuals and,

if acceptable, authorizes information

system processing

AUTHORIZEInformation Systems

SP 800

-37

MONITOR Security Controls

SP

800

-53A

CATEGORIZEInformation Systems

FIPS 199/SP 800

-60

ASSESSSecurity

ControlsSP 800

-53A

STEP

3STEP

1

STEP

4STEP

5STEP

6

Continuously

track chang

es to the information system

that may affect security controls and

assesses control effectiveness


Figure 4: Step 4 of the Risk Management Framework is In-Scope for this Project

3.2 GoalThe fundamental goal of this engagement is to:

1. Assess the current Scottish Pride Licensing Application (SPLA) to identify the information security risks.

2. Educate the CIO about the gaps identified and what is a requirement using National Institute Standards and Technology (NIST) standards to secure those gaps.

3. Provide documentation outlining the current security posture, the gaps that exist in the current security posture and why it is so important to improve the current posture where required.

4. Plan for improvement by developing a Plan of Action and Milestones (POA&M) for agency improvement and risk mitigation to reduce the risk.

5. Provide necessary baseline security information for use with future evaluations on an annual basis at a minimum or when major events dictate another complete evaluation.

6. Update the SPLA System Security Plans (SSP) with the Risk Assessment and Privacy Impact Assessment (PIA) results.

Page of


3.3 Risk Assessment ProcessThis risk assessment methodology and approach was conducted using the guidelines in NIST SP 800-53 Revision. 3 Recommended Security Controls for Federal Information Systems and Organizationshttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final-errata.pdf

The assessment is broad in scope and evaluates security vulnerabilities affecting confidentiality, integrity, and availability. The assessment recommends appropriate security safeguards, permitting management to make knowledge-based decisions about security-related initiatives. The methodology addresses the following types of controls:

Management Controls: Management of the information technology (IT) security system and the management and acceptance of risk

Operational Controls: Security methods focusing on mechanisms implemented and executed primarily by people (as opposed to systems), including all aspects of physical security, media safeguards, and inventory controls

Technical Controls: Hardware and software controls providing automated protection to the system or applications (Technical controls operate within the technical system and applications.)

North Highland’s approach to the Risk Assessment is divided into three phases. Phases were be defined as Identification and Analysis, Plan of Action & Milestones, and Update System Security Plan and were be performed as outlined in NIST SP 800-30 Risk Management Guide for Information Technology Systems sp800-30.pdf..

Page of

http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final-errata.pdf



Figure 5: North Highland Phase Approach

3.4 Phase IThe overall objective of Phase I was to gather information regarding SPLA. North Highland analyzed all system information and documented the results in the Plan of Action & Milestones, System Security Plan, and this Risk Summary Report prioritizing recommended solutions. North Highland evaluated the existing security policies to compare them to the policies outlined in NIST standards. This involved determining whether a policy exists or another policy within the Agency covers the areas outlined in the NIST standards. It also involves structuring both the set of security policies, as well as the content contained within the documents themselves.

The IT analysis team used an integrated compliance health check solution tool from eFortresses Inc. for the myriad of information security requirements in SPLA. The analysis team used this tool to conduct a knowledge base questionnaire with staff, providing information on controls, control objectives for federal/government standards and regulations.

Phase I was divided into pre-assessment and assessment steps.Step 1: Data Collection

Page of

PHASE I - Identification and AnalysisData CollectionDocument ReviewThreat IdentificationVulnerability IdentificationRisk Determination Risk Mitigation Recommendations

PHASE II - Plan of Action and Milestones Identify IT Security WeaknessAnalyze Weakness Risk LevelDocument Weakness Risk Acceptance and DecisionIdentify Corrective Action Options and Funding Required Determine Funding Availability and Weakness PrioritizationEstimate Completion DateDocument Weakness and Corrective Action Plan

PHASE III - Update System Security PlanDocument Privacy Impact AnalysisDocument Risk Assessment ResultsValidate System CategorizationsUpdate FIPS-199 (if Necessary)Develop new SSP (if Necessary)


The data collection phase included identifying and interviewing key personnel within the agency with a compliance health check questionnaire and conducting document reviews. Interviews focused on the SPLA operating environment. Documented reviews provided the risk assessment team with the basis on which to evaluate compliance with policy and procedure.

Step 2: Document ReviewThe assessment phase began with the review of documents provided by the members of the SPLA system team. Detailed interviews with members of the SPLA system team allowed completion of the system questionnaire and identification of specific threats.

Step 3: Threat IdentificationThe IT analysis team used NIST SP 800-30 as a basis for threat identification. Through the interview process, the team also identified “most likely” system and location-specific threats.

Step 4: Vulnerability IdentificationThe IT analysis team developed a list of system vulnerabilities (flaws or weaknesses) that could be exploited by the potential threat vectors. The IT analysis team used NIST SP 800-53; Revision 3 to document vulnerabilities extracted from interviews and documents, and listed them by category.

Step 5: Risk Determination The IT analysis team determined the degree of priority risk to SPLA. The IT team identified any residual risk and documented them in the SSP.

Step 6: Risk Mitigation RecommendationsDuring this step of the process, controls that could mitigate or eliminate the identified risks, as appropriate to IT’s operations, were provided. The goal of the recommended controls is to reduce the level of risk to the SPLA and its data to an acceptable level.

3.5 Phase IIThe overall objective in Phase II was to create a separate Plan of Action & Milestones (POA&M) for the SPLA. A POA&M is a tool that identifies tasks that need to be accomplished to meet best practices in the draft Florida Information Technology Resource Security Policies and Standards identified in 71A-1.001, F.A.C. It details resources required to accomplish the elements of the plan, any milestones in meeting the task, and scheduled completion dates for the milestones.

Page of


3.6 Phase IIIThe overall objective in Phase III was to update the SPLA System Security Plan. The Privacy Impact Assessment identified in Appendix D was updated with risk assessment analysis results and the results of the Risk Assessment are documented in the System Security Plan in section 2.7 depicting priority risks to SPLA in the areas of Management, Operational, and Technical. The SPLA FIPS-199 System Categorization document was updated accordingly.

Page of


4 SYSTEM IDENTIFICATION4.1 System Description

IT System Inventory and Definition DocumentI. IT System Identification and Ownership

IT System ID

None IT System Common Name

Scottish Pride Licensing Application (SPLA)

Owned By Department of Children and Families Information Services (IT)System

Responsibility

Scottish Pride is the responsible agency and owns the system, the data it contains, and controls the use of the data. Scottish Solutions is under contract to develop and provide maintenance to the system and support Continuity of Operations Planning.

Scottish Pride, Inc.1317 Pinewood Blvd. Bldg 6Tallahassee, Florida 32399

Scottish Solutions1650 Highland Glen Drive, Suite 101Tallahassee, Florida 32317

Physical Location

Southwood Shared Resource Center (SSRC)

Major Business Function

SPLA is used to maintain child care licensing data for the Scottish Pride. The information system includes 12 modules for maintaining child care provider, personnel and inspection data. In addition to Scottish Pride, several other departments or agencies use SPLA as a primary repository for their child care related data.

System OwnerPhone

Number

Scottish Pride CIO Deborah McLeod1317 Pinewood Blvd. Bldg 6 Tallahassee, Florida 32399Main : 850.588.4900 Fax : 850.588.9584 Email: [email protected]

System Administr

ator(s)Phone

Number

Scottish Pride Program Project Manager Robert Berrie897 East Venice AveVenice, Florida 34285Direct : 941.586.2575 Fax : 941.586.2505Email: [email protected] : www.spla.com

Data Owner(s)

Phone Number(s

)


Data Custodian(

s)Phone

Number(s)

Program Business AnalystKim McDonald1317 Pinewood Blvd. Bldg 6Tallahassee, Florida 32399Main : 850.588.1315Fax : 850.588.9584 Email:

Page of

mailto:[email protected]


http://www.myflorida.com/childcare






IT System Inventory and Definition [email protected]

Security Contact(s

)Phone

Number(s)


Security Contact(s)

Phone Number(s)

Scottish Solutions Security ManagerDoug McCoy1317 Pinewood Blvd. Bldg 6 Tallahassee, Florida 32399Main : 850.588.9534Email: [email protected]

Information

Security Manager

Scottish Pride Information Security ManagerFred McleanScottish Pride, Inc. 1940 Argyll Street Tallahassee, FL 32399-1027Main : 850.587.8161 Email: [email protected]

Other Relevant Informati

on

None

II. IT System Boundary and ComponentsIT System Descriptio

n and Compone

nts

SansWrite Client software is used on portable computers to collect inspection results while at licensed child care facilities and family day care homes

The SansWrite Middleware enables licensing staff to submit completed inspection to a centralized database and receive updates to provider and personnel data

The SansWrite Web Portal allows public and private access to provider, demographic and inspection data via PDF files and statistical reports

Administrative staff can add and/or update licensed or registered providers using a secure web application

The public can access provider information and inspection reports using a variety of different search criteria

The public can access maps that show where a provider is located and identifies other providers in the same vicinity

Child Care Licensing Supervisors can access a variety of different management and staff performance reports

IT can access statistical, performance and trend reports to help determine or access the quality of child care throughout the State of Florida

Page of









IT System Inventory and Definition Document IT uses a specialized private web portal for tracking Gold Seal

Providers In addition to Scottish Pride, Brevard County, Broward County,

Hillsborough County, Pinellas County, Palm Beach County, Sarasota County, Resource and Referral organization use SPLA as their primary data repository and/or access child care related data

Six counties use SPLA as an extension of their local information systems. Data from the local information systems is synchronized with Scottish Pride on a nightly basis

Resource and Referral organization access SPLA to retrieve data on licensed child care facilities, licensed family day care homes and registered family day care homes

Scottish Pride uses SPLA to record and track information for Voluntary Pre-kindergarten (VPK) providers

IT System Interfaces

SPLA does not interface with any other systems.

IT System Boundary

The boundaries of the system are the Dell PowerEdge 2800, 2900, 2950, Hyper-V Host Server, and SansWrite Database servers and the Oracle applications on the client desktops.

System Environm

ent

System URL: https://Scottish Pridesanswrite.state.fl.us/SPLA/Administration

Licensing URL: https://Scottish Pridesanswrite.state.fl.us/SPLA/Provider

Gold Seal URL: https://Scottish Pridesanswrite.state.fl.us/GoldSeal

VPK URL: https://Scottish Pridesanswrite.state.fl.us/VPK/Administration

III. IT System Interconnections (add additional lines, as needed)Agency or Organizat

ion

IT System Name

IT System ID

IT System Owner

Interconnection Security Agreement

Status

NoneIV. IT System and Data Sensitivity (add additional lines, as needed)Type of Data Sensitivity Ratings

Include Rationale for each RatingConfidentiality Integrity Availability

Name Moderate Moderate ModerateAddress Moderate Moderate ModeratePhone Moderate Moderate ModerateDate of Birth Moderate Moderate ModerateEmail address Moderate Moderate Moderate

Page of

https://dcfsanswrite.state.fl.us/VPK/Administration


https://dcfsanswrite.state.fl.us/GoldSeal


https://dcfsanswrite.state.fl.us/ChildCare/Provider


https://dcfsanswrite.state.fl.us/ChildCare/Administration



IT System Inventory and Definition DocumentSSN (encrypted) Moderate Moderate ModerateAs required by the AEIT best practices), IT will conduct a self-assessment of this IT system annually and conduct another full Risk Assessment no later than three years from the date of this report, or sooner if required by significant changes to this IT system and/or its operating environment. These Sensitivity Ratings will be re-evaluated as part of each self-assessment and Risk Assessment, and this table will be updated as required.

Overall IT System

Sensitivity Rating and

Classification for SPLA

Overall IT System Sensitivity Rating for the Scottish Pride Licensing Application

Must be “high” if sensitivity of any data type is rated “high” on any criterion

HIGH MODERATE LOWSPLA System Classification

Must be “Sensitive” if overall sensitivity is “high”; consider as “Sensitive” if overall sensitivity is “moderate”

SENSITIVE NON-SENSITIVE

Table 1: IT System Inventory and Definition Document

Page of

System - SPLAType - DELL PowerEdge 2900 ( 9 " W x 18.75" H )Server Name - Property Tag # - IP address(es) – 199.240.36.128Back up – 192.163.90.122Type - DatabaseSerial # JG18543FD1State Tag # 2034510374Location – CS13309

System - SPLAType - DELL PowerEdge 2800 ( 9.1 " W x 17.6 " H )Server Name - Property Tag # -IP address(es) – 204.90.20.58Back up - 192.161.70.66Serial # 4K1442391State Tag # 2034409277Type - Web Portal & MiddlewareOther Info – 32 bit, very old and will be replaced and used as back up.Location – CS17702Will be pulled from the Data center

System - SPLA Type - DELL PowerEdge 2950 (17.5" W x 3.5" H )Server Name - Property Tag # - 30311115IP address(es) – 402.90.30.215, 402.90.30.216 & 402.90.30.217Serial # TTT945K1State Tag # 33250311216Type - Web Portal & MiddlewareOther info – Runs VMwareLocation – CS14502


4.2 System Environment

Figure 6: Scottish Pride Licensing Application Server Configuration

<INSERT SPLA NETWORK DIAGRAM>

Figure 7: Scottish Pride Licensing Application Basic Network Diagram

Page of


Scottish Pride Licensing Application SpecificsSystem Environment

System URL:

Licensing URL:

Gold Seal URL:

VPK URL:

https://Scottish Pridesanswrite.state.fl.us/SPLA/Administration https://Scottish Pridesanswrite.state.fl.us/SPLA/Provider

https://Scottish Pridesanswrite.state.fl.us/GoldSeal

https://Scottish Pridesanswrite.state.fl.us/VPK/Administration

Technology Standards Used xhtml (eXtended Hyper Text Markup Language)

www.w2.org/RR/xhtml1/ All web pages are xhtml compliant. This standard uses the markup of HTML pages while enforcing the standards of XML documents

xml (eXtensable Markup Language) www.w3.org/XML/ Industry Standard for transmitting data

PDF (Portable Document Format) www.adobe.com Used throughout the system to give the users and administrators forms in a printable, non-editable, industry standard format

SQL (Structured Query Language) www.iso.com (documentation of standard is not free, must be purchased) Used to interface with the database

JavaScript (Scripting language based on Livescript) www.ecmainternational. org/publications/ Ecma262.htm Used on web pages for value checking and visual manipulation

Web Services Used to exchange data between systems.

ASP.NET (Active Server Pages) www.microsoft.com Used to provide data entry functionality via the Web Portal

Implementation Standards IIT (Internet Information Server 6.0)

www.microsoft.com Used to host the SPLA Web Portal. Serves up static web pages and redirects interactive pages to the application server

.Net 1.1, 2.0 www.microsoft .com provides the application framework

Oracle Database 10 g www.oracle.com, Scottish Pride choice for the SPLA data repository

Windows Server 2003 Standard Edition

Page of









Table 2: Scottish Pride Licensing Application System Specifics

4.3 Information Sensitivity Table 3 below describes the categorization for each SPLA server located in the Southwood Shared Resource Center (SSRC). Table 4 describes the information system categorization for SPLA and will be inserted into the System Security Plan. For SPLA, the potential impact values assigned to the respective security objectives (confidentiality, integrity, availability) are the highest values (i.e., high water mark) from among those security categories that have been determined for each type of information that resides on SPLA. The System Owner and Scottish Solutions project manager have identified this system as Moderate from Table 4 below risk in accordance with FIPS-199. The system has been deemed critical and directly impacts the agency’s major mission.

SECURITY OBJECTIVE(RANKING – LOW, MODERATE, HIGH)

Server Confidentiality Integrity Availability

Security Category

(sc)Dell PowerEdge 2900 Moderate Moderate Low ModerateDell PowerEdge 2950 Moderate Moderate Low Moderate

Table 3: Server Categorization

Security Objective Ranking(Low, Moderate, High)

Confidentiality Moderate Integrity Moderate

Availability LowSecurity Category

(SC) = Moderate

Table 4: Scottish Pride Licensing Application Information Sensitivity

Page of


5 CONTROL ANALYSISTable 5 provides a high-level summary by control category of how SPLA complies with the security controls articulated in NIST SP 800-53 Rev. 3 Recommended Security Controls for Federal Information Systems. Legend:

In Place – the control is fully applied and the control requirements have been fully met.

Partially In Place – The control has been partially applied and some aspects of the control requirements have not been met.

Planned – The control is not in place and there is a planned activity to implement the control.

Not Applicable – The control does not directly apply to the information system. The system either does not perform the functions described by the control, or does not possess the technology for which the control is required.

Risk Based Decision – The control is not in place and there has been a decision reached not to put the control in place based on risk factors.

[ ] – Indicates the number of controls that are in place, partially in place, planned, not applicable to the control family, and risk based decisions identified.

Page of


Table 5: High-level Security Controls Status Summary Control Category In

Place

Partially In Place

Planned

Not Applicab

le

Risk Based Decisi

onManagement Controls

1 Risk Assessment [ 3 ] [ 1 ]2 Planning [ 5 ] 3 System and Services

Acquisition[ 9 ] [ 2 ]

4 Security Assessment and Authorization

[ 6 ]

5 Program Management [ 9 ] [ 2 ] Operational Controls

6 Personnel Security [ 4 ] [ 4 ] 7 Physical and

Environmental Protection[ 18 ]

8 Contingency Planning [ 3 ] [ 6 ]9 Configuration

Management[ 8 ] [ 1 ]

10

Maintenance [ 5 ] [ 1 ]

11

System and Information Integrity

[ 10 ] [ 1 ]

12

Media Protection [ 6 ]

13

Incident Response [ 5 ] [ 1 ] [ 2 ]

14

Awareness and Training [ 4 ]

Technical Controls15

Identification and Authentication

[ 7 ] [ 1 ]

16

Access Controls [ 14 ] [ 1 ]

17

Audit and Accountability [ 10 ] [ 1 ]

of 58


18

System and Communications Protection

[ 16 ] [ 4 ]

Totals 142 12 9 7

of 58


5.1 Baseline Security Control Gap SummaryTable 6 provides a baseline security control gap summary by control category of how Scottish Pride Licensing Application complies with the security controls articulated in NIST SP 800-53 Revision 3 Recommended Security Controls for Federal Information Systems.

Table 6: Baseline Security Controls Gap Summary

Security Control Control Status

Risk Assessment (RA)RA-5 Vulnerability Scanning (P1)

The agency: Scans for vulnerabilities in the information system and

hosted applications [Assignment: agency-defined frequency and/or randomly in accordance with agency-defined process] and when new vulnerabilities potentially affecting the system/applications are identified and reported

Employs vulnerability scanning tools and techniques that promote interoperability among tools and automate parts of the vulnerability management process by using standards for: o Enumerating platforms, software flaws, and improper

configurationso Formatting and making transparent, checklists and

test procedureso Measuring vulnerability impact

Analyzes vulnerability scan reports and results from security control assessments

Remediates legitimate vulnerabilities [Assignment: agency-defined response time] in accordance with an organizational assessment of risk

Shares information obtained from the vulnerability scanning process and security control assessments with designated personnel throughout the agency to help eliminate similar vulnerabilities in other information systems (i.e., systemic weaknesses or deficiencies)

Gap

of 58


Contingency Planning (CP)CP-2 Contingency Plan (P1)

The agency: Develops a contingency plan for the information system

that: o Identifies essential missions and business functions

and associated contingency requirements o Provides recovery objectives, restoration priorities,

and metricso Addresses contingency roles, responsibilities,

assigned individuals with contact informationo Addresses maintaining essential missions and

business functions despite an information system disruption, compromise, or failure

o Addresses eventual, full information system restoration without deterioration of the security measures originally planned and implemented

o Is reviewed and approved by designated officials within the agency

Distributes copies of the contingency plan to [Assignment: agency-defined list of key contingency personnel (identified by name and/or by role and organizational element]

Coordinates contingency planning activities with incident handling activities

Reviews the contingency plan for the information system [Assignment: agency-defined frequency]

Designated officials within the agency review and approve the contingency plan and distribute copies of the plan to key contingency personnel

Revises the contingency plan to address changes to the agency, information system, or environment of operation and problems encountered during contingency plan implementation, execution, or testing

Communicates contingency plan changes to [Assignment: agency-defined list of key contingency personnel (identified by name and/or by role and organizational element]

Gap

CP-3 Contingency Training (P2)The agency trains personnel in their contingency roles and responsibilities with respect to the information system and provides refresher training [Assignment: agency-defined frequency].

Gap

of 58


Contingency Planning (CP)CP-4 Contingency Plan Testing and Exercises (P2)

The agency: Tests and/or exercises the contingency plan for the

information system [Assignment: agency-defined frequency] using [Assignment: agency-defined tests and/or exercises] to determine the plan’s effectiveness and the agency’s readiness to execute the plan

Reviews the contingency plan test/exercise results and initiates corrective actions

Gap

CP-7 Alternate Processing Site (P1)The agency: Establishes an alternate processing site including

necessary agreements to permit the resumption of information system operations for essential missions and business functions within [Assignment: agency-defined time period consistent with recovery time objectives] when the primary processing capabilities are unavailable

Ensures that equipment and supplies required to resume operations are available at the alternate site or contracts are in place to support delivery to the site in time to support the agency-defined time period for resumption

Gap

CP-8 Telecommunications Services (P1)The agency establishes alternate telecommunications services including necessary agreements to permit the resumption of information system operations for essential missions and business functions within [Assignment: agency-defined time period] hours when the primary telecommunications capabilities are unavailable.

Gap

CP-10 Information System Recovery and Reconstitution (P1)The agency provides for the recovery and reconstitution of the information system to a known state after a disruption, compromise, or failure.

Gap

of 58


Incident ResponseIR-2(PII)

Incident Response Training (P2)The agency: Trains personnel in their incident response roles and

responsibilities with respect to the information system Provides refresher training [Assignment: agency-defined

frequency]

Gap

IR-3(PII)

Incident Response Testing and Exercises (P2)The agency tests and/or exercises the incident response capability for the information system [Assignment: agency-defined frequency] using [Assignment: agency-defined tests and/or exercises] to determine the incident response effectiveness and documents the results.

Gap

of 58


6 RISK CALCULATION6.1 Identification of Vulnerabilities

The identification of vulnerabilities for SPLA included interviews with the IT and Scottish Solutions staff, and the judgment and experience of the North Highland risk assessment team.

6.2 Identification of Threats

The North Highland risk assessment team developed a standard list of threats in Table 7 below to consider in assessing risk to SPLA. This list is based on the judgment and experience of the North Highland risk assessment team, and its evaluation of the IT environment.

Threats Air Conditioning Failure PandemicBomb Threats Power OutageCommunication Failure EmbezzlementComputer Crime Fire (Major or Minor)Fire (Major or Minor) Sabotage/VandalismFlooding/Water Damage Software FailureHardware Failure TerrorismHuman Error Tornados, Hurricanes, BlizzardsLoss of Key Personnel Unauthorized Access or Use

Table 7: Threats Identified in IT

6.3 Identification of Risks

Risks were identified for SPLA by matching identified vulnerabilities with credible threats that might exploit them. This pairing of vulnerabilities with credible threats is documented in the Risk Matrix table (see Section 6.9 Risk Matrix) columns labeled Vulnerability and Threat. All identified risks have been included.

6.4 Correlation of Relevant Controls

Correlation of the threats identified above with the relevant IT security controls documented in Table 5: High-level Security Controls Status Summary (see page 28) and with other mitigating or exacerbating factors is

of 58


documented in the Risk Matrix Table column labeled Analysis of Relevant Controls and Other Factors.

6.5 Risk Likelihood Determination

Table 8 below defines the risk likelihood matrix and definitions.

Effectiveness of Controls

Probability of Threat Occurrence (Natural Or Environmental Threats) or Threat Motivation and

Capability (Human Threats)Low Moderate High

High Low Low Low

Moderate Low Moderate High

Low Low High High

Table 8: Risk Likelihood Definitions The columns labeled Risk Likelihood Evaluation and Risk Impact of the Risk Matrix Table (see Section 6.9 Risk Matrix) document evaluation of the effectiveness of controls, evaluation of the probability of threat occurrence, and evaluation of the threat motivation/capability of each threat to SPLA, along with its associated likelihood, as defined in Table 8 above.

6.6 Impact Analysis

Table 9 documents the ratings used to evaluate the impact of risks.

Magnitude of Impact Impact Definition

High

Occurrence of the risk: (1) may result in human death or serious injury; (2) may result in the loss of major IT tangible assets, resources or sensitive data; or (3) may significantly harm or impede the IT’s mission, reputation or interest.

ModerateOccurrence of the risk: (1) may result in human injury; (2) may result in the costly loss of IT tangible assets or resources; or (3) may violate, harm or impede the IT’s mission, reputation or interest.

LowOccurrence of the risk: (1) may result in the loss of some tangible IT assets or resources or; (2) may noticeably affect the IT’s mission, reputation or interest.

of 58


Table 9: Risk Impact Rating Definitions The columns labeled Risk Impact and Risk Impact Rating in the Risk Matrix Table (see Section 6.9 Risk Matrix) document the results of the impact analysis, including the estimated impact for each risk identified and the impact rating assigned to the risk.

6.7 Risk Determination

Table 10 documents the criteria used in determining the overall ratings for risks to IT. This table is based both on the Overall Risk Rating Matrix on the Risk Level Matrix in the Risk Management Guide for Information Technology Systems, published by the National Institute of Standards and Technology (NIST) as NIST Special Publication (SP) 800-30. North Highland has augmented these matrices by defining a “moderate-high” overall risk rating to describe the intersection of moderate likelihood with high impact and of high likelihood with moderate impact. This augmentation is designed to assist IT in prioritizing its risk mitigation activities.

Risk LikelihoodRisk Impact

Low(10)

Moderate(50)

High(100)

High(1.0)

Low10 x 1.0 = 10

Moderate-High50 x 1.0 = 50

High100 x 1.0 = 100

Moderate(0.5)

Low10 x 0.5 = 5

Moderate50 x 0.5 = 25`

Moderate-High100 x 0.5 = 50

Low(0.1)

Low10 x 0.1 = 1

Low50 x 0.1 = 5

Low100 x 0.1 = 10

Risk Scale: Low (1 to 10); Moderate ( >10 to 50); High ( >50 to 100)

Table 10: Overall Risk Rating Matrix The column labeled Overall Risk Rating in the Risk Matrix Table (see Section 6.9 Risk Matrix) identifies the overall risk rating for each of the risks to IT, as defined in Table 10 above.

6.8 RecommendationsThe final column labeled Recommendations in the Risk Matrix table (see Section 6.9 Risk Matrix) documents the mitigation strategy necessary to minimize the stated risk.

of 58


6.9 SPLA Risk Matrix Vulnerabilities, threats, and risks to SPLA are outlined on the following pages in the Risk Matrix table.

of 58


Vulnerability Threat

Risk Of Compro

mise

Risk Summar

y

Analysis Of Relevant Controls

and Other Factors

Risk Likelihood Evaluatio

n

Risk Likeliho

od Rating

Risk Impact

Risk Impact Rating

Overall Risk Rating

1 The agency has not implemented a SPLA Contingency Plan as defined in CP-2 Contingency Plan.

Malicious Use, Human Error, Hardware Failure

Availability of SPLA data

Lack of documented processes could cause errors, facilitate unauthorized access, or inhibit recovery.

Undocumented, informal training procedures appear to be in place. The agency is not compliant with AEIT best practices.

Limited documentation of contingency procedures make this risk likely to materialize.

Moderate

Because documentation of a contingency plan is ad hoc the impact of this risk is moderate.

Moderate

Moderate

RecommendationsDevelop a contingency plan for SPLA that:

A Contingency Plan for SPLA shall be consistent with NIST SP 800-34 Contingency Planning Guide for Federal Information Systems sp800-34-rev1.pdf

Identifies essential mission and business functions and associated contingency; requirements.

Addresses contingency roles, responsibilities, assigned individuals with contact information, and activities associated with restoring the system after a disruption, compromise.

Is reviewed and approved by designated officials within the agency.

Distribute copies of the contingency plan to a defined list of IT and Scottish Solutions key contingency personnel.

Review the contingency plan at a minimum annually.

Revise the contingency plan to address system/organizational changes or problems encountered during contingency plan implementation, execution, or testing.

of 58

http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1.pdf


Communicate contingency plan changes to a defined list of IT and Scottish Solutions key contingency personnel.

Conduct capacity planning so that necessary capacity for information processing, telecommunications, and environmental support exists during crisis situations.

Identify circumstances that can inhibit recovery and reconstitution of SPLA to a known, secure state and provide compensating controls to mitigate risk.

of 58



Risk Of Compro

miseRisk

Summary


and Other Factors


n

Risk Likeliho

od Rating

Risk Impact

Risk Impact Rating

Overall

Risk Ratin

g2 The

agency does not implement SPLA contingency training as defined in CP-3 Contingency Training.



Lack of a documented contingency plan, training, and formal testing could inhibit recovery.

Undocumented, informal training procedures appear to be in place. The agency is not compliant with AEIT best practices.

Limited documentation of contingency training procedures make this risk likely to materialize.

Low Because contingency plan training material is ad hoc the impact of this risk is low.

Low Low

Recommendations: Define in the System Security Plan, explicitly or by reference, the frequency of refresher contingency

training and the frequency is at least annually Each review session should be documented and confirmed that appropriate training has been

completed. All staff should be trained in the business recovery process. This is particularly important when the

procedures are significantly different from those pertaining to normal operations. This training may be integrated with the training phase or handled separately. The training should be carefully planned and delivered on a structured basis. The training should be assessed to verify that it has achieved its objectives and is relevant for the procedures involved. Training may be delivered either using in-house resources or external resources depending upon available skills and related costs.

The objectives and scope of the training activities should be clearly stated within the plan. The COOP and IT/DRP should contain a description of the objectives and scope of the training phase. This will enable the training to be consistent and organized in a manner where the results can be measured, and the training fine tuned, as appropriate.

of 58


The plan should specify which person or group of persons requires which type of training. It is necessary for all new or revised processes to be explained carefully to the staff.

Once the training needs have been identified it is necessary to specify and develop suitable training materials. This can be a time consuming task and unless priorities are given to critical training programs, it could delay the agency in reaching an adequate level of preparedness.

Once it has been agreed who requires training and the training materials have been prepared a detailed training schedule should be drawn up.

Once the training is arranged to be delivered to the employees, it is necessary to advise them about the training programs they are scheduled to attend.

The individual COOP IT/DRP training programs and the overall COOP IT/DRP training process should be assessed to ensure its effectiveness and applicability. This information should be gathered from the trainers and also the trainees through the completion of feedback questionnaires.

It is vital to receive feedback from the persons managing and participating in each of the training programs. This feedback will enable weaknesses within the Business Recovery Process, or the training, to be identified and eliminated. Completion of feedback forms should be mandatory for all persons participating in the training process. The forms should be completed either during the training (to record a specific issue) or as soon after finishing as practical. This will enable observations and comments to be recorded whilst the event is still fresh in the persons mind.

The completed questionnaires from the trainees plus the feedback from the trainers should be assessed. Identified weaknesses should be notified to the COOP IT/DRP Team Leader and the process strengthened accordingly.

The key issues raised by the trainees should be noted and consideration given to whether the findings are critical to the process or not. If there are a significant number of negative issues raised then consideration should be given to possible re-training once the training materials, or the process, have been improved.

of 58



Risk Of Compro

mise

Risk Summar

y


and Other Factors


n

Risk Likeliho

od Rating

Risk Impact

Risk Impact Rating

Overall Risk Rating

3 The agency does not implement SPLA contingency plan testing and exercises as defined in CP-4 Contingency Plan Testing and Exercises.


Availability of SPLA data.

Lack of a documented contingency plan, training, and formal testing could inhibit recovery.

Undocumentedformal testing procedures appear to be in place. The agency is not compliant with AEIT best practices.

Failure to formally test the contingency plan against best practice threat scenarios make this risk likely to materialize.

Moderate

Because contingency plan testing scenarios are not developed and tested the impact of this risk is moderate.

Moderate

Moderate

Recommendations: Define in the System Security Plan, explicitly or by reference, the frequency of contingency plan tests

and/or exercises and the frequency are at least annually. Test and/or exercise the contingency plan for SPLA at least annually using defined tests and/or

exercises to determine the plan's effectiveness and the agency's readiness to execute the plan. Review the contingency plan test/exercise results and initiates corrective actions.

of 58


Use NIST SP 800-84 Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities SP800-84.pdf as guidance on test, training, and exercise programs for information technology plans and capabilities.

The COOP should contain a description of the objectives and scope of the testing phase. This will enable the tests to be structured and organized in a manner where the results can be measured, and the plan fine tuned, as appropriate.

As with all testing, the use of live data within the testing environment should be prohibited by the IT. Test data should however, be prepared which is representative of normal business transactions. Actual names or contact details should also not be used for such tests. It is recommended that a full test environment be set up for use in the applicable circumstances. Each separate test should be given a unique reference number which will identify the Business Process being recorded, the simulated conditions used, the persons involved in the testing process and the date the test was carried out. This will enable the monitoring and testing reports to be co-coordinated with any feedback received.

In order to ensure consistency of the testing process throughout the agency, one or more members of the COOP Team should be nominated to coordinate the testing process within each business unit, a nominated testing and across the agency. Each business process should be thoroughly tested and the coordinator should ensure that each business unit observes the necessary rules associated with ensuring that the testing process is carried out within a realistic environment.

In order to ensure consistency when measuring the results, the tests should be independently monitored. This task would normally be carried out by a nominated member of the COOP Recovery Team.

It is vital to receive feedback from the persons managing and participating in each of the tests. This feedback will hopefully enable weaknesses within the COOP Recovery Process to be identified and eliminated. Completion of feedback forms should be mandatory for all persons participating in the testing process. The forms should be completed either during the tests (to record a specific issue) or as soon after finishing as practical. This will enable observations and comments to be recorded whilst the event is still fresh in the persons mind.

In order for the testing process to proceed smoothly, it is necessary for the core testing team to be trained in the emergency procedures.

of 58

http://csrc.nist.gov/publications/nistpubs/800-84/SP800-84.pdf



The tests must be carried out under authentic conditions and all participants must take the process seriously. It is important that all persons who are likely to be involved with recovering a particular business process in the event of an emergency should participate in the testing process. It should be mandatory for the management of a business unit to be present when that unit is involved with conducting the tests.

In so far as it is practical, each critical part of the business recovery process should be fully tested. Every part of the procedures included as part of the recovery process is to be tested to ensure validity and relevance.

During the testing process the accuracy of employee and vendor emergency contact information should be re-confirmed. All contact numbers should be validated for all involved employees. This is particularly important for management and key employees who are critical to the success of the recovery process.


Risk Of Compro

miseRisk

Summary

Analysis Of

Relevant Controls

and Other Factors

Risk Likelihoo

d Evaluatio

n

Risk Likeliho

od Rating

Risk Impact

Risk Impact Rating

Overall Risk Rating

of 58


4 The agency does not implement system recovery and reconstitution as defined in CP-10 Information System Recovery and Reconstitution.



Lack of documented system recovery and reconstition procedures will inhibit the agency to sustain or resume communciations and IT function that support critical business operations and essential constituent services within a specified period of time.

Undocumentedformal system recovery and reconstition procedures appear to be in place. The agency is not compliant with AEIT best practices.

Failure to document formal system recovery and reconstition procedures make this risk likely to materialize.

Moderate

Because contingency plan system recovery and reconstition procedures are not developed, trainined, and tested the impact of this risk is moderate.

Moderate

Moderate

Recommendations: Provide the capability to recover and reconstitute SPLA to a known secure state after a disruption,

compromise, or failure.o Information system recovery and reconstitution to a known secure state means that all system

parameters (either default or organization-established) are set to secure values, security-critical patches are reinstalled, security-related configuration settings are reestablished, system documentation and operating procedures are available, application and system software is reinstalled and configured with secure settings, information from the most recent, known secure backups is loaded, and the system is fully tested.

Recovery of SPLA after a failure or other contingency shall be done in a trusted, secure, and verifiable manner.

of 58


of 58



Risk Of Compro

miseRisk Summary

Analysis Of

Relevant Controls

and Other Factors


n

Risk Likelih

ood Rating

Risk Impact

Risk Impac

t Rating

Overall Risk Rating

of 58


5 The agency does not implement vulnerability scanning as defined in RA-5 Vulnerability Scanning

Malicious Use, Human Error, Hardw Computer Crime, are and Software Failure


Failure to conduct formal vulnerability scanning and penetration testing will not allow the agency to identify potential vulnerabilities within the internal network and weaknesses in controls in place to prevent and/or detect their exploitation by a hacker/malicious employee/contractor who may obtain unauthorized access to information resources or cause system disruption or a system outage.

Without formal Vulnerability Scanning and Penetration Testing the agency will be able to measure security control effectiveness. A computer criminal could exploit Patched vulnerability and compromise SPLA data. The agency is not compliant with AEIT best practices.

Failure to formally conduct vulnerability scanning and penetration testing make this risk likely to materialize.

Moderate

Because vulnerability scanning and penetration testing are not being performed at a minimum annually the impact of this risk is moderate.

Moderate

Moderate

Recommendations: Define in the System Security Plan, explicitly or by reference, the frequency of vulnerability scans within

SPLA. Train selected personnel in the use and maintenance of vulnerability scanning tools and techniques.

of 58


Utilize appropriate vulnerability scanning tools and techniques to scan for vulnerabilities in SPLA every 90 days or when significant new vulnerabilities are identified and reported.

Perform external network penetration testing and conduct enterprise security posture review as needed but no less than once every 365 days, in accordance with industry best practices. Document findings and assessment results and correlate vulnerabilities to Common Vulnerabilities and Exposures (CVE) naming convention.

The information obtained from the vulnerability scanning process shall be shared with appropriate personnel throughout the agency on a "need to know" basis to help eliminate similar vulnerabilities in other information systems.

The activities of employees using agency Internet and email resources shall be subject to monitoring by system or security personnel without notice.

Use NIST SP 800-40 Creating a Patch and Vulnerability Management Program SP800-40v2.pdf for guidance on patch and vulnerability management.

of 58

http://csrc.nist.gov/publications/nistpubs/800-40-Ver2/SP800-40v2.pdf



Risk Of Compro

miseRisk

Summary


and Other Factors


n

Risk Likeliho

od Rating

Risk Impact

Risk Impact Rating

Overall

Risk Ratin

g6 The

agency does not implement alternate processing capabilities as defined in CP-7 Alternate Processing Site.

Human Error, Hardware Failure


Failure to identify and alternate processing site will inhibit the agency to sustain or resume communciations and IT function that support critical business operations and essential constituent services if a complete power outage ocurred in the local area.

No alternate processing site has been determined and no contingency is covered in the SSRC Service Level Agreement.The agency is not compliant with AEIT best practices.

Failure to identify a nm alternate processing site make this risk likely to materialize.

Low Because an alternate site has not been identified and the agency relies on Outlier Technology to help in its recovery oeprations the impact of this risk is low.

Low Low

Recommendations: Identify an alternate processing site that is geographically separated from the primary processing site

so as not to be susceptible to the same hazards.

of 58


Agreements with an alternate processing site shall be established and implemented to permit the resumption of SPLA operations for mission critical business functions when the primary processing capabilities are unavailable, and the Contingency Plan calls for application recovery in place of other accepted processes.

Identify potential accessibility problems to the alternate processing site in the event of an area-wide disruption or disaster and outlines explicit mitigation actions.

Develop alternate processing site agreements that contain priority-of-service provisions in accordance with the agency's availability requirements.

Ensure that the alternate processing site provides information security measures equivalent to that of the primary site.

Ensure all equipment and supplies required for resuming SPLA operations for critical functions are available within one week at the alternate processing site, or contracts are in place to support delivery to the site.

Define in the System Security Plan, explicitly or by reference, the time period within which processing must be resumed at the alternate processing site.

Procedures shall be developed, documented, and implemented effectively to establish contingency activities and responsibilities.

of 58


Vulnerability ThreatRisk Of Compro

mise

Risk Summar

y

Analysis Of Relevant

Controls and Other Factors


n

Risk Likelih

ood Rating

Risk Impact

Risk Impac

t Rating

Overall Risk Rating

7 The agency does not implement primary and alternate telecommunications services as defined in CP-8 Telecommunications Services.

Hardware Failure


Lack of documented processes could cause inhibit recovery.

There is no formal documented procedures that address the compelte failure of telecommunciations and its recovery with the local carrier or an alternative carrier. The agency is not compliant with AEIT best practices.

Limited documentation of recovery procedures combined with no formal contingency plan make this risk likely to materialize.

Low Because no formal contingency plan has been developed the impact of this risk is moderate.

Moderate

Moderate

Recommendations: Obtain alternate telecommunications services with consideration for reducing the likelihood of sharing a

single point of failure with primary telecommunications services. Necessary agreements should be established and implemented for alternate communications services

capable of restoring adequate communications to accomplish mission critical functions when the primary operations and communications capabilities are unavailable.

Resume system operations for critical functions within one week when the primary telecommunications capabilities are unavailable.

In the event that the primary and/or alternate telecommunications services are provided by a common carrier, the agency should request Telecommunications Service Priority (TSP) for all telecommunications services used for national security emergency preparedness.

of 58



Risk Of Compro

miseRisk

Summary

Analysis Of

Relevant Controls

and Other Factors

Risk Likelihoo

d Evaluatio

n

Risk Likeliho

od Rating

Risk Impact

Risk Impact Rating

Overall Risk Rating

8 The agency does not implement incident response training as defined in IR-2 Incident Reponse Training.

Malicious Use, Human Error, Computer Crime. Hardware and Sofwtare Failure


Failure to train personnel in incident management reponse and threats may lead to a compormise of the confidentiality, integrity of the system, and posibly lead to a Denial of Service attack affecting the systems availability.

No formal incident response training appears to be in place. The agency is not compliant with AEIT best practices.

Failure to have staff recognize threats and how to response to threats make this risk likely to materialize.

Low Because there is no formal incident response training being performed at a minimum annually the impact of this risk is moderate.

Moderate Moderate

of 58


Recommendations:Procedures and incident response training implementation should: Train personnel in their incident response roles and responsibilities with respect to SPLA. All users of

SPLA must be exposed to security awareness materials at least annually. o Users of SPLA include employees, contractors, students, guest, visitors, and others who may need

access to. o Executives should receive training in information security basics and policy level training in

security planning and management. o Program and functional managers should receive training in information security basics;

management and implementation level training in security planning and system/application security management; and management and implementation level training in system/ application life cycle management, risk management, and contingency planning.

o CIOs, Chief Information Officers (CIOs), IT security program managers, auditors, and other security-oriented personnel (e.g., system and network administrators, and system/application security officers) should receive training in information security basics and broad training in security planning, system and application security management, system/application life cycle management, risk management, and contingency planning.

o IT function management and operations personnel should receive training in information security basics; management and implementation level training in security planning and system/application security management; and management and implementation level training in system/ application life cycle management, risk management, and contingency planning.

Define in the System Security Plan, explicitly or by reference, the frequency of refresher incident response training is at least annually.

Provide the SPLA security awareness material/exposure outlined in NIST SP800-50 Building an Information Technology Security Awareness and Training Program NIST-SP800-50.pdf to all new employees before allowing them access to the systems.

Provide SPLA security refresher training for employees as frequently as determined necessary, based on the sensitivity of the information that the employees use or process and whenever there is a

of 58

http://csrc.nist.gov/publications/nistpubs/800-50/NIST-SP800-50.pdf


significant change in the information system environment or procedures or when an employee enters a new position that requires additional role-specific training.

of 58



Risk Of Compro

miseRisk

Summary

Analysis Of

Relevant Controls

and Other Factors


n

Risk Likeliho

od Rating

Risk Impact

Risk Impact Rating

Overall Risk Rating

9 The agency does not test and/or exercise incident response as defined in IR-3 Incident Response Testing and Exercises.



Failure to formally test incident management reponse towards formal threat scenarios may lead to a compormise of the confidentiality, integrity of the system, and posibly lead to a Denial of Service attack affecting the systems availability.

No formal incident response ttest scenarios have been develoepd. The agency is not compliant with AEIT best practices.

Failure to conduct formal simulated tests against predefined threat scenarios and observe staff response make this risk likely to materialize.

Moderate

Because there is no formal incident response testing being performed at a minimum annually the impact of this risk is moderate.

Moderate

Moderate

Recommendations The Incident response capability for SPLA should be tested periodically using appropriate tests,

procedures, automated mechanisms, and exercises to determine the plan's effectiveness.

of 58


Test and/or exercise and document the incident response capability every 365 days, using reviews, analyses, and simulations.

Use NIST SP 800-84 Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities SP800-84.pdf for information technology plans and capabilities.

Define in the System Security Plan, explicitly or by reference, the frequency of incident response tests/exercises is at least annually;

The test results, procedures, and exercises employed to conduct the test shall be documented.

of 58




APPENDIX A – CONTROL CATEGORY DESCRIPTIONThe following acronyms are used throughout the Federal Information Processing Standard 199 (FIPS-199) system categorization and System Security Plan (SSP) process.

Acronym MeaningSPLA Scottish Pride Licensing ApplicationCP Contingency Planning DR Disaster RecoveryFIPS Federal Information Processing StandardsFIPS PUB Federal Information Processing Standard PublicationsFIPS -199 Federal Information Processing Standard System CategorizationIR Incident ResponseITM Information Security ManagerIT Information TechnologyNIST National Institute of Standards and TechnologyOMB Office of Management and Budget PIA Privacy Impact Assessment PII Personal Identifiable InformationPOA&M Plan of Action and MilestonesPOC Point of ContactRA Risk AssessmentSSP System Security Plan

of 57


APPENDIX B – GLOSSARYThis glossary contains terms and associated definitions that are used throughout the Federal Information Processing Standard 199 (FIPS-199) system categorization and System Security Plan (SSP) process.

Term DefinitionAvailability The consequences of loss or disruption of access to system resources

or to data or information in the system are generally acceptable. The loss of availability could be expected to affect IT level interests and have some negative impact on mission accomplishment.

Confidentiality The consequences of unauthorized disclosure or compromise of data or information in the system are generally acceptable. The loss of confidentiality could be expected to affect IT level interests and have some negative impact on mission accomplishment.

Florida Information Technology Resource Security Policies and Standards identified in 71A-1.001-.010, F.A.C.

The purpose of the Florida Information Resource Security Policies and Standards is to:

Promulgate state policies regarding the security of data and information technology resources. Policies are broad principles underlying the state’s Information resource security program.

Define minimum-security standards for the protection of state information resources. Standards are required administrative procedures or management controls, utilizing current, open, non-proprietary or non-vendor specific technologies.

Integrity The consequences of corruption or unauthorized modification of data or information in the system are only marginally acceptable. Loss of integrity could be expected to affect IT level interests and have some negative impact on mission accomplishment.

Low Data stored, processed, or transported by computer or telecommunications resources, the inaccuracy, alteration, disclosure, or unavailability of which: (1) would have a minimal impact on major application or minor application missions, functions, image, or reputation, such that the impact would result in the least possible significant unfavorable condition with a negative outcome, or (2) could result in loss of some tangible assets or resources.

Low-level System An information system in which all three security objectives (i.e., confidentiality, integrity, and availability) are assigned a FIPS 199 potential impact value of low.

Management Controls

Describes the management control measures intended to meet the systems security requirements. Management controls focus on the management of risk in operating the system. This includes risk assessment processes, risk reviews, and the behavioral expectations of all individuals who work within the system.

Moderate Data stored, processed, or transported by computer or telecommunications resources, the inaccuracy, alteration, disclosure, or unavailability of which: (1) would have an adverse impact on moderate application or minor application missions, functions, image, or reputation, such that the impact would place the moderate application at a significant disadvantage, or (2) could result in loss of

of 57


Term Definitionsignificant tangible assets or resources.

Operational Controls

Address operational controls, focusing on mechanisms that are primarily implemented and executed by the systems management, administration, and technical support personnel. These security controls were put in place to improve the overall security of the system environment. This includes personnel controls, physical and environmental protections, and other operational security processes.

Risk assessment The process of identifying risks to agency operations (including mission, functions, image, or reputation), agency assets, or individuals by determining the probability of occurrence, the resulting impact, and additional security controls that would mitigate this impact. A risk assessment is part of risk management, synonymous with risk analysis, and incorporates threat and vulnerability analyses.

Security category

The characterization of information or an information system based on an assessment of the potential impact that a loss of confidentiality, integrity, or availability of such information or information system would have on organizational operations, organizational assets, or individuals.

Security controls The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information.

System Owner Official responsible for the overall procurement, development, integration, modification, operation, and maintenance of an information system.

System Security Plan

Formal document that provides an overview of the security requirements for the information system and describes the security controls in place or planned for meeting those requirements.

Technical Controls

Describe the technical security mechanisms and controls that are used to minimize or prevent unauthorized users from accessing the system and to ensure its integrity, confidentiality, and availability. These controls describe the system's user authentication control mechanisms, such as password, token, and biometrics. They also indicate the frequency of password changes, describe how changes are enforced, and identify who changes the passwords (user, system administrator, or system).

Vulnerability Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.

of 57


APPENDIX H – LAWS, REGULATIONS, AND GUIDANCEAppendix H shows the Federal laws, regulatory guidance, and directives that drive Agency for Innovation Workforce’s IT security program. This appendix also lists Office of Management and Budget (OMB) and National Institute of Standards and Technology (NIST) guidance.

Laws and Regulations:

Federal Information Security Management Act of 2002, Title III – Information Security, P.L. 107-347. http://csrc.nist.gov/groups/SMA/fisma/index.html

USA PATRIOT Act (P.L. 107-56), October 2001. http://www.usdoj.gov/oig/special/s0708/final.pdf

Computer Fraud and Abuse Act of 1986, as amended. http://www.usdoj.gov/criminal/cybercrime/ccmanual/01ccma.html

Privacy Act of 1987 http://csrc.nist.gov/groups/SMA/ispab/documents/csa_87.txt

OMB Circulars:

OMB Circular A-130, Management of Federal Information Resources, November 2000. http://www.ogc.doc.gov/ogc/contracts/cld/ecomm/65fr77677.html

OMB Memorandum M-05-24, Implementation of Homeland Security Presidential Directive (HSPD) 12—Policy for a Common Identification Standard for Federal Employees and Contractors, August 2005. http://www.whitehouse.gov/omb/memoranda/fy2005/m05-24.pdf

OMB Memorandum M-06-16, Protection of Sensitive Agency Information, June 2006. http://www.whitehouse.gov/omb/memoranda/fy2006/m06-16.pdf

OMB Memorandum, M-06-19, Reporting Incidents Involving Personally Identifiable Information and Incorporating the Cost for Security in Agency Information Technology Investments, July 2006. http://www.whitehouse.gov/omb/memoranda/fy2006/m06-19.pdf

of 57

http://www.whitehouse.gov/omb/memoranda/fy2006/m06-19.pdf



http://www.ogc.doc.gov/ogc/contracts/cld/ecomm/65fr77677.html

http://csrc.nist.gov/groups/SMA/ispab/documents/csa_87.txt

http://www.usdoj.gov/criminal/cybercrime/ccmanual/01ccma.html

http://www.usdoj.gov/oig/special/s0708/final.pdf

http://csrc.nist.gov/groups/SMA/fisma/index.html


FIPS Publications:

FIPS PUB 199, Standards for Security Categorization of Federal Information and Information Systems. http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf

NIST Publications:

NIST SP 800-18 Rev.1 Guide for Developing Security Plans for Federal Information Systemssp800-18-Rev1-final.pdf

NIST SP 800-30 Risk Management Guide for Information Technology Systemssp800-30.pdf

NIST SP 800-34 Contingency Planning Guide for Federal Information Systems sp800-34-rev1.pdf

NIST SP 800-37 Guide for Applying the Risk Management Framework to Federal Information Systems Rev. 1http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf

NIST SP 800-40 Creating a Patch and Vulnerability Management Program SP800-40v2.pdf

NIST SP800-50 Building an Information Technology Security Awareness and Training Program NIST-SP800-50.pdf

NIST SP 800-53 Rev. 3 Recommended Security Controls for Federal Information Systems and Organizationshttp://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final-errata.pdf

NIST SP 800-61 Rev. 1 Computer Security Incident Handling GuideSP800-61rev1.pdf

NIST SP 800-64 Rev. 2 Security Considerations in the System Development Life Cycle SP800-64-Revision2.pdf

NIST SP 800-84 Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities SP800-84.pdf

of 57




http://csrc.nist.gov/publications/nistpubs/800-50/NIST-SP800-50.pdf

http://csrc.nist.gov/publications/nistpubs/800-40-Ver2/SP800-40v2.pdf

http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf

http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf

http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1.pdf

http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf


NIST SP 800-122 Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)http://csrc.nist.gov/publications/nistpubs/800-122/sp800-122.pdf

Organization Policy and Guidance Documents:

Section 282.318, Florida Statutes – “Security of Data and Information Technology Resources”. http://flsenate.gov/Statutes/index.cfm?App_mode=Display_Statute&Search_String=&URL=Ch0282/SEC318.HTM&Title=-%3E2008-%3ECh0282-%3ESection+318

Chapter 815, Florida Statutes, “Computer-Related Crimes”. http://www.leg.state.fl.us/statutes/index.cfm?App_mode=Display_Statute&URL=Ch0815/titl0815.htm&StatuteYear=2000&Title=-%3E2000-%3EChapter+815

Florida Administrative Code 60DD-2, “Florida Information Resource Security Policies and Standards”. https://www.flrules.org/gateway/ruleNo.asp?id=60DD-2.006

Proposed Rule 71A-1, F.A.C , “Florida Information Resource Security Policies and Standards”. http://Proposed Rule 71A-1.pdf

Policies and Procedures of the Scottish Pride, Inc. http://www.Scottish Pride.state.fl.us/publications/policies.shtmlhttp://www.Scottish Pride.state.fl.us/publications/policies/050-2.pdf

of 57

http://www.dcf.state.fl.us/publications/policies/050-2.pdf

http://www.dcf.state.fl.us/publications/policies.shtml

http://www.dcf.state.fl.us/publications/policies.shtml


https://www.flrules.org/gateway/ruleNo.asp?id=60DD-2.006

http://www.leg.state.fl.us/statutes/index.cfm?App_mode=Display_Statute&URL=Ch0815/titl0815.htm&StatuteYear=2000&Title=-%3E2000-%3EChapter+815



http://flsenate.gov/Statutes/index.cfm?App_mode=Display_Statute&Search_String=&URL=Ch0282/SEC318.HTM&Title=-%3E2008-%3ECh0282-%3ESection+318



http://csrc.nist.gov/publications/nistpubs/800-122/sp800-122.pdf


APPENDIX I – RISK BASED DECISION DOCUMENTSThere were no risk-based decisions documented during this risk assessment on SPLA.

of 57

CCLA Risk Report - ISACA · Web viewThis risk assessment report identifies threats and...

Documents

Transcript of CCLA Risk Report - ISACA · Web viewThis risk assessment report identifies threats and...