Attachment 4 - System Security Plan 2.5.5 Template.docx

System Security Plan—Ver2.5.5

CDPHE - WQCD

User Interface Permits Modernization - OIT

RFP 2025-0282

PLEASE NOTE: Any and all correspondence regarding the System Security Plan or the SSP process should be copied to the OIT_CISO@state.co.us mailbox. Quick questions, as they come up can be brought to the Security Talk open bridge held Wednesdays at 9am. Please see OITPlaza calendar for access details.

CONFIDENTIAL

For Official Use Only - Portions of this information may be exempt from disclosure under the Colorado Open Records Act. Colorado Revised Statute 24-72-204(2) (a) (VIII) (A)

Table of Contents

Table of Contents System Security Plan Introduction System Identification General System Description General System Design Description & Architecture System Scans requested by Security Architecture Team Technical Specifications Compliance Requirements (regulatory risk) Additional Details:

System Classification per business risk relevant to Dept Mission Security Controls Web - Based Applications (updated for 11/2017 release) Appendix Roles and Responsibilities

Project Document Revision History

Modifications made to this plan, since the last printing, should be documented here for audit and process management purposes

System Security Plan

Introduction

The purpose of a System Security Plan (SSP) is:

· To document the security requirements of the system and describe the controls in place or planned to meet all applicable State Cyber Security Policies requirements and ultimately reduce the risk introduced by the system/application.

· It is a project deliverable document that is part of the system delivery.

· To delineate responsibilities and expected behavior of all individuals who access the system.

· To establish and document the security controls, and form the basis for the authorization of individuals to perform security related activities in the system.

· This document provides a baseline for security needs of a solution and serves throughout the system life cycle with the system until its end of life and should be regularly updated as changes to the system occur.

· This document will serve as a template for solution engagement with the CISO’s office for solution review.

· If a vendor-provided SSP is supplied for provided technical components, this document shall serve as an integration artifact also describing business interfaces, decisions and project-specific security needs. Such artifacts shall be provided with project documentation and referenced here-in for specific areas of interest.

The objectives of this SSP are:

· To assist in providing assurance to the system customer that their solution security requirements are met.

· To improve protection of information system resources.

· To document the protection of the system security.

· To respond to Internal and External system security Audits.

· To demonstrate documented compliance to state and federal mandates.

*This is a living document subject to annual review and regular updates as needed.*

System Identification

Project Manager Guidance Section: Supply two pieces of information in this section.

1. Record the system/application name as it is known by the platform/program, OIT, and end-users.

For example: LegalFiles – case management system for the Office of Administrative Courts

General System Description

Project Manager Guidance Section: This section requires a brief description of the project scope and a brief explanation of the goal of the agency pursuing this project. You may cut and paste a brief synopsis of the system in this section from the Project Charter. This section helps to create a brief solution context/ecosystem.

General System Design Description & Architecture

Project Manager Guidance Section: This section requires a brief description of the architectural design for the solution, in the context of the project.

1. Ensure the Project Architectural Plan has been completed and is available in the project folder shared with those who need to know.

2. Include a system-connectivity / data-flow diagram, below:

Note: This should summarize the solution design, provide a general overview of how, and by whom, the system will be used. The Design/Architectural Plan drawing must include user-clouds, network zones, ports, protocols, IP addresses and dataflows, cloud instances, API type (ie: REST/SOAP).

Paste detailed, high-resolution drawing and supporting context here.

System Scans requested by Security Architecture Team

<Based on the previous section design, these are the scans requested by Security Architecture. This section is completed during an OIS courtesy review of the plan, after the design, and before implementation. Scans will be performed by OIT staff where applicable and/or expected from vendor contributors depending on system hosting solution and boundary. If hosted in a state data center, OIT may perform the scan.> Application security verification involves techniques such as application security vulnerability scanning, application penetration testing, static analysis, and manual code review. Additional details on what these activities typically involve can be found at http://www.owasp.org.

System and workstation scanning shall show, at a minimum, a scan resulting 100% compliance with the CIS level-1 (CISecurity.org) benchmark (less any approved exceptions) is applied to every instance and role type in the solution. If standard imaging is used, only one scan of each type is required.

☐ Application Scan (code/web/etc)

Attachment 4 <The above system scans are requested from teams proving the service, by the project lead, throughout the project and ahead of deployment to assist with timely scan and mitigation scheduling. The appropriate technical resources for server, applications, network, etc. have access to provide scans early and often. Bring the scans and remediation plans, with progress, for review with OIS, along with this SSP.

CONFIDENTIAL: OIT System Security Plan template version 2.5.5 1

Technical Specifications

Describe here what technologies are part of the solution. This may include servers and desktop operating systems, language and platform for application design, network devices, zones and firewalls, etc.

Architecture & Operating Environment (SaaS, PaaS, IaaS, Hybrid)

Software Software Bill Of Materials - list external library dependencies, list language interpreter versions (runtime environments) and development platform, list any other application or software dependencies and versions, even OS version constraints. (Resource: https://www.cisa.gov/sites/default/files/2023-04/sbom-types-document-508c.pdf)

Physical Environment Physical barriers around the area where the system resides. If at a known data center or cloud-hosted, simply list the data center, cloud availability zone. If a provider/business-owned datacenter, get and show evidence of their compliance, like SOC2. Note: We already have SOC2s for state owned and contracted data centers--just list all centers that apply. Include data-center geographic location/description, especially if it extends beyond the lower 48-states.

Interfaces (across zones) list Cross-zone (VPC, clouds, datacenters, across internet) communications ports/protocols/services, routes if any, and how users of various types connect. These should be reflected in the architecture diagram, as well.

Independent Attestations Any custom services (hosting, software, infrastructure) provided a vendor must be covered in scope of the vendor-provided independent audit/attestation such as SOCw-type2, ISO27000-series, Fedramp and/or Stateramp. Provide current reference link or document reference, here.

Compliance Requirements (regulatory risk)

There are several standards/acts/regulations that apply to the IT systems depending on type of data that is hosted within the application. For example HIPAA, FISMA, PCI, SSA etc. List, below any such standards/acts/regulation that the IT systems needs to adhere to. Seek assistance from your Risk and Compliance team member for assistance (oit_risc@state.co.us) ( i.e. What organization audits this system, to what standards, and what level?)

Regulatory Data Classification (high, medium, or low): _____

FTI

SSA

CJIS

HIPAA

FISMA

PCI

SSA

DoD

Other:

Other:

Other:

System Classification per business risk relevant to Dept Mission

System Data Owner (the business champion):

Risk with regard to how this system supports the Departmental Mission. List the Business RISK Assessment ratings, below, with respect to respective areas in Confidentiality, Integrity and Availability (CIA).

Definitions (same as in Clarity/CA PPM):

Component Rating (C/I/S) Additional Comments/Requirements/Detail

Confidentiality

Integrity

Availability

Security Controls

Planned controls are those which are planned (for a spec date) to remediate any security risk identified as needing to be fixed. Existing controls are those systems and configuration decided upon to have in place for rollout. These Existing Controls are the items that will be scanned and audited.

(Responses should be approx 3-5 summary sentences and documentation shall be retained with the solution for future reference)

(at rollout) Planned Controls (post go-live)

1. For electronic commerce systems or components involving financial transactions, describe how the solution is ensuring that the parties in a transaction cannot deny that the transaction took place. For instance, system and user nonrepudiation can be handled by preshared certificates on the back end, multi-factor authentication on the front/user end.

If no payment account information is collected by or stored on a state system, enter 'N/A' or, place the payment processing provider details and evidence of current PCIDSS certification.

State and solution systems should store only payment confirmation data from the payment processing provider.

2. Describe the application or system access controls and their rules for all levels of the system and/or application. Briefly describe the roles and how those roles (RBAC) offer different system views and/or access. ***New Projects with complex user roles, attach system-access-RACI as an Appendix.

We are looking for a separation of roles in the system differentiating access to data, admin and edit functions based on role. (Background; The role is typically held accountable by the solution customer's internal policy or applicable MOU or data agreement.)

Also, are you using Zero-Trust principles? (added bonus)

3. Describe the audit trails (auditable events) that will be captured and the audit items and event types captured.

What we look for:

Do the audit trails capture administrative actions and user account changes?

Do logs capture Create, Read, Update, Delete (CRUD)?

Do logs retain user data? (They shouldn't) Do logs capture system exceptions/errors/failures?

6. Workstation security: If using state systems, then their security should meet state policy and standards. If users are not or could not be using state-owned systems to access data, we will be asking how sensitive data and residue is being kept from persisting on the user's system, including any other point along the way.

If systems are not issued by the state, describe security measures and/or agreements put in place for assurance. (i.e. AV/AM, IDS, mobile device management, vulnerability assessment and monitoring, data sharing agreements or MOUs)

7. What is the backup frequency? Full backup and incremental.

This information is used to assess whether the backup plan can meet the customers' RTO (recovery time) and RPO (recovery point) objectives. The information here should provide enough to assess how much data the customer may lose, if the system goes down just before the backup process.

8. Is the backup handled by the standard state backup system, and if not... where are the backups stored, are they encrypted and secured, and what is the brief process to obtain and/or recover from backups?

9. Disaster Recovery Plan:

Does one exist?

Briefly summarize DRP--whom to call.

Note if there are any special conditions for recovery time and point objectives--any special arrangements to bring the system up and how much data is acceptable to lose should an outage and recovery occur. (Depending on frequency of data changes correlating with backup & frequency, is a day or a week loss acceptable with regard to effort and cost?)

10. Business Owner: We are doing a security review during the project release phase. After go-live, the solution enters into run and maintenance. Please discuss and summarize the outcome of how often the program needs this solution reviewed for security. Note that the security landscape is under constant change from developing threats and tech debt, as well as facing regulation changes.

*** It is the system owner's responsibility to request such a review.

11. Exceptions: Will you be requesting an exception from a State policy or standard? (e.g., password complexity or an unpatched vulnerability)

If yes, note which ones?... short title that also explains what is the exception from. Example: "CDxx SystemBleep Password expiration exception"

12. Business: Describe the business process to define user access levels based on the individual's need to view and manipulate data within the application or system. Also, does the business have a documented frequency and process for reviewing (auditing) access levels? Per CISP policy, it is a business requirement to timely add, revoke and modify user access to state systems. This question helps assess whether this process is congruent to the solution's criticality and/or regulatory needs.

13. Solution provider. Technical question. Describe procedures for granting, establishing, issuing, and closing user accounts in the system or application.

This is a technical question--is access federated to a central state managed directory where authority and authentication are applied? Is user management a local repository managed by an admin role dedicated to just this system? etc.

14. Business: Describe the procedures for identifying and reporting security violations. (Does the business unit have a documented escalation path for an event, prior to executing the state incident response plan?)

15. Project: Are vulnerability/penetration testing documents available?

(Have scans been run and reviewed? What & Approx when?)

Scans at different layers of the solution OSI layers may fall on different providers in solutioning... for instance, cloud solution configuration may be one team, the application layer another, and the hosting provider be another. A vendor's independent audit attestation may replace the need to provide scans, and an executive summary may suffice.

16. Solution provider:

Interface Security (transmission security and user interface access):

Are encrypted versions of data transmission protocols being utilized per state standard? Which?

17. Solution provider: If vendor is providing support of the system, is there a contract or SOW language detailing how and when a vendor will access this system and any restrictions on their use of the data with which they come in contact?

How will the vendor access the system technically?

18. User Access: This is a technical question for system access by all user types. How do they access the system? Web Browser, RDP, SSH?

19. Solution provider:

Server patch installs/upgrades: What is the patch cycle, plan, if not on state system management plan?

20. Solution provider:

Application patch installs/upgrades:

What is the patch cycle and application update plan?

21. Change Management: If using State CAB process detail here. If SaaS solution, is the State notified of the impending change and how?

22. System Admin Procedures and Responsibilities (Who? What? When? Where? How often?)

23. Server Access/Administration Control How do the administrators technically access the server system for maintenance and development?

24. For human user access, is two-factor authentication (2FA) being used? If yes, at what entry point(s) to the system?

If two back-end systems are communicating, how is that authentication, verification and identification of systems taking place? (i.e. certificate exchange)

25. Application: Have you reviewed the proper OWASP Top 10 (there are more than one) for the application?

Please address the appropriate categories, below, and comment on whether and briefly how those vulnerabilities are addressed strategically. Does the service provider have and adhere to a comprehensive application security program?

https://owasp.org/Top10/ https://owasp.org/www-project-api-security/

26. Modern-day secure software development encompasses a multi-tier approach to ensuring software robustness, accuracy, privacy-centered user interface design, reduction of attack surface and resilience to evolving attack vectors. Such programs fall under different names depending on the organization.

In this section provide, a brief statement of the approach used to develop, provide and maintain a secure software layer in this solution.

In-house developers: Mention CI/CD, scanning performed for security, architecture approaches to minimize application-layer risks, open-source security approaches and other dependency software composition analysis, etc..

3rd party software or hired development services; Provide how the application layer will be maintained and patched, what processes exist to assure best practice is being followed throughout the development and use lifecycle of the software and components. Examples: Independent audit attestation such as SOC2type2, ISO27000 compliance, StateRamp or FedRamp, or equivalent. Mention how Application Security skillsets are maintained, scanning and/pen-testing cadence, time for vulnerability discovery-to-resolution, automatic or peer review approaches, etc. Please keep it brief and to the point, no marketing materials.

(see below for guidance)

(at rollout) Planned Controls (post go-live)

Useful Guidance for Above Question #26

Helpful References for the above question:

OWASP Web Top 10 (most current) https://owasp.org/www-project-top-ten/

OWASP API Top 10 (most current) https://owasp.org/www-project-api-security/

OWASP Cloud-Native Software Top 10 (most current) https://owasp.org/www-project-cloud-native-application-security-top-10/

OWASP IoT Top 10 (most current) https://github.com/scriptingxss/OWASP-IoT-Top-10-2018-Mapping https://www.cisa.gov/sites/default/files/2023-04/sbom-types-document-508c.pdf https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ https://www.veracode.com/blog/secure-development/what-are-security-implications-ai-coding https://www.cisa.gov/sites/default/files/2023-01/Zero_Trust_Principles_Enterprise_Mobility_For_Public_Comment_508C.pdf

Appendix

Roles and Responsibilities

1. Add a document reference to the Project RACI

2. This section requires the names and contact information for specific key contacts related to the platform (application) in question and their role.

BUSINESS SYSTEM OWNER

The Business System Owner has sufficient knowledge of the system to be able to provide additional information or points of contact regarding the security plan and the system, as needed. They are the decision making authority as to budgetary and operational function of the system or solution.

Name:

Address:

Title:

Phone:

Agency:

E-mail:

SYSTEM DATA OWNER

The Data Owner is the designated individual who is ultimately responsible for the Confidentiality, Integrity and Availability (CIA) of the data owned by the System Owner. This individual typically determines how data is accessed, who the data is accessed by, its distribution and security. This individual has a clear understanding of all state, national, federal or international laws and regulations governing the security and access of the data. This is usually the project sponsor.

Name:

Address:

Title:

Phone:

Agency:

E-mail:

AGENCY IT DIRECTOR

The Agency IT Director is the designated OIT representative responsible for the general management of the IT system or solution utilized by a system owner or agency. This individual is the decision making authority over budgetary requirements, project design, disaster recovery and ongoing maintenance and support of the system or solution for the system owner or agency.

Name:

Address:

Title:

Phone:

Agency:

E-mail:

CHIEF INFORMATION SECURITY OFFICER (For non-consolidated agencies with a resident CISO) The Chief Information Security Officer (CISO) or delegate is ultimately responsible for the security of the system and has assigned responsibility to ensure that the application has adequate security and is knowledgeable of the management, operational, and technical controls used to protect the system.

Name:

Address:

Title:

Phone:

Agency:

E-mail:

SYSTEM SUBJECT MATTER EXPERT/ ADMINISTRATOR

The Subject Matter Expert (SME) is the individual responsible for the overall business management and administration of the system. This individual is involved in all operational discussions for the system to include user access control, documentation, applications, data, design and disaster recovery requirements for the system and is the primary business contact for all security events affecting the system.

Name:

Address:

Title:

Phone:

Agency:

E-mail:

AUTHORIZING SECURITY OFFICIAL

The Colorado Chief Information Security Officer (CISO) or delegate after review of each System Security Plan (SSP) is the individual responsible for sponsoring and approving the operation or denying operation of state computing systems and solutions for the state of Colorado.

Denver CO 80203

PROJECT MANAGER

a) The Project Manager (PM) is responsible for the delivery of the System Security Plan (SSP) as part of the project deliverables prior proceeding to the final gate of the PMO process. The PM will work with Business and IT staff to complete the SSP. The PM will continuously throughout the project lifecycle consulate and work with the Security Architect assigned to the project to integrate security and document security design controls in the SSP.

b) The Portfolio Manager (or project manager if assigned) prior to Gate 1 is responsible to complete the RISK Assessment with consultation with the Business and, if necessary, with IT Staff prior gate 1. The result of the RISK Assessment will determine whether a SSP is required or not.

c) The RISK Assessment results will inform the SSP discussion at the GATE 1 phase.

d) The PM is responsible to provide the SSP, RISK Assessment results, and vulnerability scan package to the Security Architect to review for completeness and accuracy.

Name:

Address:

Title:

Phone:

Agency:

E-mail:

PROJECT GATING PROCESS OWNER

a) The Project Gating Process Owner is responsible to ensure that the RISK Assessment, in addition to other documents, is completed prior scheduling Gate 1 review.

b) The Project Gating Process Owner document the output of Gate 1 discussion in the meeting notes.

Name:

Address:

Title:

Phone:

Agency:

E-mail:

SECURITY ARCHITECT

a) The Security Architect will discuss during the Gate 1 the Business RISK assessment results and advise the PM whether and which Vulnerability scans are required or not prior the final gate.

b) The Security Architect will be available to work with the PM throughout project lifecycle to integrate security design and assist in completion of the SSP.

c) The Security Architect is responsible to review and provide feedback on the SSP based in the context of the RISK Assessment results and vulnerability scan results to the PM.

d) The Security Architect is responsible to provide their final feedback to the PM, The Project Gating Process Owner, and the Risk and Compliance Manager confirming the review has been completed give a go-ahead to the Project Gating Process Owner to proceed with the final gate.

RISK & COMPLIANCE MANAGER

a) The Risk and Compliance Manager is responsible to assess risk and compliance requirements of the project using the result of the Security Architect review

b) The Risk and Compliance Manager is responsible to discuss project risk and compliance during the final project gate review.

c) The Risk and Compliance Manager is responsible to whether to issue an Authorization To Operate (ATO), issue an Authorization To Operate (ATO) with condition, or not issue an Authorization To Operate. The ATO is verbally provided/informed at the final gate review, and a document is provided within several days afterward.

d) The Risk and Compliance Manager is responsible to communicate back to the PM the ATO decision and The Project Gating Process Owner

Template Revision History

01/26/2022 03/01/2022

V2.5.4

image2.jpg image1.png