ATTACHMENT II - System Security Plan.pdf

System Security Plan— Ver2.5

Colorado Department of Public Safety

Digital Video Evidence System

RFP RBAA 2019-0099

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.

CONFIDENTIAL

mailto:OIT_CISO@state.co.us

CONFIDENTIAL: OIT System Security Plan 1

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

System Classification (CARE Assessment Results)

Security Controls

Web - Based Applications

Appendix

Roles and Responsibilities

RFP RBAA 2019-0099

CONFIDENTIAL: OIT System Security Plan 2

Revision History

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

Date Item Description Author Version

12/2/2014 Revised SSP Update of roles and responsibilities

Mohamed Malki V2.0

12/29/2014 Revised SSP Comments, tips, clarification

Daniel Teyf V2.1

1/6/2015 Revised SSP Formatting Emily Shea V2.2 4/23/2015 Revised #18 Added clarity Daniel Teyf V2.2 `11/1/2015 Page 8 scan list Added a checklist for scan requirement

Daniel Teyf V2.2.1

11/4/2016 Migrated doc to Google format David Mullaney 11/8/2016 Revised SSP Template simplification Demi Minos v2.2.2

11/8/2016 Revised SSP Explained “living document”

Demi Minos V2.2.3

01/10/2017 Revised SSP Compile previous work

Dennis Henry / Suman Batra

V2.2.4

03/16/17 Revised SSP Compile feedback from CISO

Jerrod Roth V2.3

12/22/17 Revised OWASP 2017 Updated Daniel Teyf v.2.4 05/01/18 Risk Assessment Updated Risk

Assessment section to denote where Risk Assessment is located in the new version of CA PPM

Jerrod Roth v2.5

CONFIDENTIAL: OIT System Security Plan 3

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

➢ NOTE: Please see associated FAQ document to assist with completion of the SSP.

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

CONFIDENTIAL: OIT System Security Plan 4

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

System/Application Name: Fill in the required here as noted above in the PM guidance.

Architectural Plan: The Architectural Plan is located here.

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.

CONFIDENTIAL: OIT System Security Plan 5

General System Design Description & Security 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 Clarity.

Note: This should summarize the solution design, provide a general overview of how, and by whom, the system will be used. The Security Design/Architectural Plan drawing must include user-clouds, network zones, protocols, IP addresses and dataflows.

2. Include a system-connectivity / data-flow diagram, below, as described in above:

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.

Scan Type System List (list system names, URLS, Apps, Servers) ☐ Web Application Scan ●

☐ System Vulnerability Scan ●

☐ CIS Hardening Scan ●

<The above system scans are requested via ticketing system, by the project lead, ahead of deployment to assist with timely scan scheduling, when the project is ready, before the final gate.> http://www.owasp.org/

CONFIDENTIAL: OIT System Security Plan 6

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.

System Attributes Description

Architecture & Operating Environment

Software

Physical Environment

Interfaces

CONFIDENTIAL: OIT System Security Plan 7

Compliance Requirements

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 HIPPA, FISMA, PCI, SSA etc. List, below any such standards/acts/regulation that the IT systems needs to adhere to.

System Classification (CARE Assessment Results)

Prior to completing this System Security Plan, this system was classified per State of Colorado Data Classification Policy to assess the minimum necessary system classification/protection level. Further, the System Data Owner (the business champion) added additional classification requirements, with regard to how this system supports the Departmental Mission, through the use of the CARE Assessment artifact (Classification of Assets based on Risk Evaluation). List the final CARE Assessment ratings, below, with respect to their respective areas in Confidentiality, Integrity and Availability (CIA). These ratings are now configured through the CA PPM tool on the Size and Risk page. Please provide those security requirements, here, with a brief 1-sentence explanation describing justification.

***Please see FAQ for definitions.

CARE

Component

Rating (L/M/H)

Additional Comments/Requirements/Detail

Confidentiality

Integrity

Availability

CONFIDENTIAL: OIT System Security Plan 8

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.

Security Requirement Existing Controls Planned Controls

1. For electronic commerce systems involving financial transactions, describe how you are ensuring that the parties in a transaction cannot deny that the transaction took place.

2. Describe the application or system access controls and their rules for all levels of the system and/or application.

3. Describe the audit trails that will be captured and the details included in the audit trail for tracking administrative actions that impact access or change to critical data.

4. Security Control selection (how did we select the controls)

5. Physical barriers around the area where the system resides

6. Workstation security

7. Backup Frequency

8. Backup Plan

9. Disaster Recovery Plan

10. System Review

11. Policy Waiver

12. Describe the process to define user access rights based on the individual's need to view and manipulate data within the application or system.

13. Describe procedures for requesting, establishing, issuing, and closing user accounts in the system or application.

These procedures must include the process for reviewing and confirming access rights on a specified schedule.

CONFIDENTIAL: OIT System Security Plan 9

14. Describe the procedures for identifying and reporting security violations.

15. Vulnerability/Penetration testing documents available?

16. Interface Security (transmission security, access control)

17. Vendor Access

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. Server patch installs/upgrades

20. Application patch installs/upgrades

21. Change Management

22. System Admin Procedures and Responsibilities

23. Server Access Control

CONFIDENTIAL: OIT System Security Plan 10

Web - Based Applications (updated for 11/2017 release)

For all Web Based Application, the following OWASP TOP 10 must be addressed:

*NOTE: Web-Based application is defined as the part of the system viewed through a web browser, such as Internet Explorer, Mozilla Firefox, Chrome, or any other industry or OIT accepted web browser.

Vulnerability Description Mitigation Status

A1 Injection

Some of the more common injections are SQL, NoSQL, OS command, Object Relational Mapping (ORM), LDAP, and Expression Language (EL) or Object Graph Navigation Library (OGNL) injection. The concept is identical among all interpreters. Source code review is the best method of detecting if applications are vulnerable to injections, closely followed by thorough automated testing of all parameters, headers, URL, cookies, JSON, SOAP, and XML data inputs.

Organizations can include static source (SAST) and dynamic application test (DAST) tools into the CI/CD pipeline to identify newly introduced injection flaws prior to production deployment.

A2 Broken Authentication

Confirmation of the user's identity, authentication, and session management are critical to protect against authentication-related attacks.

There may be authentication weaknesses if the application:

• Permits automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords.

• Permits brute force or other automated attacks.

• Permits default, weak, or well-known passwords, such as "Password1" or "admin/admin“.

• Uses weak or ineffective credential recovery and forgot-password processes, such as "knowledge-based answers", which cannot be made safe.

• Uses plain text, encrypted, or weakly hashed passwords (see A3:2017-Sensitive Data Exposure).

• Has missing or ineffective multi-factor authentication.

• Exposes Session IDs in the URL (e.g., URL rewriting).

• Does not rotate Session IDs after successful login.

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

CONFIDENTIAL: OIT System Security Plan 11

• Does not properly invalidate Session IDs. User sessions or authentication tokens (particularly single sign-on (SSO) tokens) aren’t properly invalidated during logout or a period of inactivity.

A3 Sensitive Data Exposure

The first thing is to determine the protection needs of data in transit and at rest. For example. passwords, credit card numbers, health records. personal information and business secrets require extra protection, particularly if that data falls under privacy laws, e.g. EU’s General Data Protection Regulation (GDPR), or regulations, e.g. financial data protection such as PCI Data Security Standard (PCI DSS). For all such data:

• Is any data transmitted in clear text? This concerns protocols such as HTTP, SMTP, and FTP. External internet traffic is especially dangerous. Verify all internal traffic e.g. between load balancers, web servers, or back-end systems.

• Is sensitive data stored in clear text, including backups?

• Are any old or weak cryptographic algorithms used either by default or in older code?

• Are default crypto keys in use. weak crypto keys generated or re-used, or is proper key management or rotation missing?

• Is encryption not enforced, e.g. are any user agent (browser) security directives or headers missing?

• Does the user agent (e.g. app. mail client) not verify if the received server certificate is valid?

A4 XML External Entities (XXE)

Applications and in particular XML-based web services or downstream integrations might be vulnerable to attack if:

• The application accepts XML directly or XML uploads, especially from untrusted sources, or inserts untrusted data into XML documents, which is then parsed by an XML processor.

CONFIDENTIAL: OIT System Security Plan 12

• Any of the XML processors in the application or SOAP based web services has document type definitions (DTDs) enabled. As the exact mechanism for disabling DTD processing varies by processor, it is good practice to consult a reference such as the OWASP Cheat Sheet ‘XXE Prevention.

• If your application uses SAML for identity processing within federated security or single sign on (SSO) purposes. SAML uses XML for identity assertions, and may be vulnerable.

• If the application uses SOAP prior to version 1.2, it is likely susceptible to XXE attacks if XML entities are being passed to the SOAP framework.

• Being vulnerable to XXE attacks likely means that the application is vulnerable to denial of service attacks including the Billion Laughs attack.

A5 Broken Access Control

Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification or destruction of all data, or performing a business function outside of the limits of the user.

Common access control vulnerabilities include:

• Bypassing access control checks by modifying the URL, internal application state. or the HTML page, or simply using a custom API attack tool.

• Allowing the primary key to be changed to another users record, permitting viewing or editing someone else’s account.

• Elevation of privilege. Acting as a user without being logged in, or acting as an admin when logged in as a user.

• Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token or a cookie or hidden field manipulated to elevate privileges, or abusing JWT invalidation

• CORS misconfiguration allows unauthorized API access.

CONFIDENTIAL: OIT System Security Plan 13

• Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user. Accessing API with missing access controls for POST, PUT and DELETE.

A6 Security Misconfiguration

The application might be vulnerable if the application is:

• Missing appropriate security hardening across any part of the application stack, or improperly configured permissions on cloud services

• Unnecessary features are enabled or installed (e.g.

unnecessary ports, services, pages, accounts, or privileges).

• Default accounts and their passwords still enabled and unchanged.

• Error handling reveals stack traces or other overly informative error messages to users.

• For upgraded systems, latest security features are disabled or not configured securely.

• The security settings in the application servers, application frameworks (e.g. Struts, Spring, ASP.NET), libraries, databases, etc. not set to secure values.

• The server does not send security headers or directives or they are not set to secure values.

• The software is out of date or vulnerable (see A9:2017- Using Components with Known Vulnerabilities).

Without a concerted, repeatable application security configuration process, systems are at a higher risk.

A7 Cross-Site Scripting (XSS)

There are three forms of XSS, usually targeting users’ browsers:

Reflected XSS: The application or API includes unvalidated and unescaped user input as part of HTML output. A successful attack can allow the attacker to execute arbitrary HTML and JavaScript in the victim’s browser. Typically the user will need to interact with some malicious link that points to an attacker-controlled

CONFIDENTIAL: OIT System Security Plan 14 page, such as malicious watering hole websites, advertisements, or similar.

Stored XSS: The application or API stores unsanitized user input that is viewed at a later time by another user or an administrator. Stored XSS is often considered a high or critical risk.

DOM XSS: JavaScript frameworks, single-page applications, and APIs that dynamically include attacker-controllable data to a page are vulnerable to DOM XSS.

Ideally, the application would not send attacker-controllable data to unsafe JavaScript APIs.

Typical XSS attacks include session stealing, account takeover, MFA bypass, DOM node replacement or defacement (such as Trojan login panels), attacks against the users browser such as malicious software downloads, key logging, and other client-side attacks.

A8 Insecure Deserialization

Applications and APIs will be vulnerable if they deserialize hostile or tampered objects supplied by an attacker.

This can result in two primary types of attacks:

• Object and data structure related attacks where the attacker modifies application logic or achieves arbitrary remote code execution if there are classes available to the application that can change behavior during or after deserialization.

• Typical data tampering attacks, such as access-control-related attacks, where existing data structures are used but the content is changed.

Serialization may be used in applications for

• Remote- and inter-process communication (RPC/IPC)

• Wire protocols, web services, message brokers

• Caching/Persistence

• Databases, cache servers, file systems

CONFIDENTIAL: OIT System Security Plan 15

• HTTP cookies, HTML form parameters, API authentication tokens

A9 Using Components with Known Vulnerabilities

You are likely vulnerable:

• If you do not know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies

• If software is vulnerable, unsupported, or out of date.

This includes the OS, web/application server, database management system (DBMS), applications, APIs and all components, runtime environments, and libraries.

• If you do not scan for vulnerabilities regularly and subscribe to security bulletins related to the components you use.

• If you do not fix or upgrade the underlying platform.

frameworks, and dependencies in a risk-based, timely fashion. This commonly happens in environments when patching is a monthly or quarterly task under change control, which leaves organizations open to many days or months of unnecessary exposure to fixed vulnerabilities

• If software developers do not test the compatibility of updated, upgraded, or patched libraries.

• If you do not secure the components’ configurations (see A6:201 7-Security Misconfiguration).

A10 Insufficient Logging and Monitoring

Insufficient logging, detection, monitoring and active response occurs any time:

• Auditable events, such as logins, failed logins, and high-value transactions are not logged.

• warnings and errors generate no, inadequate, or unclear log messages

• Logs of applications and APIS are not monitored for suspicious activity.

• Logs are only stored locally.

• Appropriate alerting thresholds and response escalation processes are not in place or effective.

CONFIDENTIAL: OIT System Security Plan 16

• Penetration testing and scans by DAST tools (such as OWASP‘s) do not trigger alerts.

• The application is unable to detect, escalate, or alert for active attacks in real time or near real time.

You are vulnerable to information leakage if you make logging and alerting events visible to a user or an attacker (see A3:2017-Sensitive Information Exposure).

CONFIDENTIAL: OIT System Security Plan 17

Appendix

Roles and Responsibilities

1. Add a link to the Project RACI

Project RACI The Project RACI is located here.

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:

CONFIDENTIAL: OIT System Security Plan 18

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.

Name: Deborah Blyth Address: 601 E. 18th Ave., Ste. 130, Denver CO 80203

Title: Chief Info. Security Officer Phone: 303.764.7994

Agency: OIT / OIS Email: deborah.blyth@state.co.us

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 Gate 4 of gating 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 CARE Assessment with consultation with the Business and, if necessary, with IT Staff prior gate

1. The result of the CARE Assessment will determine whether a SSP is required or not.

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

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

CONFIDENTIAL: OIT System Security Plan 19

Name: Address:

Title: Phone:

Agency: E-mail:

PROJECT GATING PROCESS OWNER

a) The Project Gating Process Owner is responsible to ensure that the CARE 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 CARE assessment results and advise the

PM whether the SSP and Vulnerability scan are required or not prior Gate 4.

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 CARE Assessment results and vulnerability scan results to the PM.

d) The Security Architect is responsible to provide his 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 Gate 4.

Name: Mohamed Malki Address: 601 E. 18th Avenue, Denver, CO 80203

Title: Enterprise Security Architect Phone: 303.764.7627

Agency: OIT/OIS Email: Mohamed.Malki@state.co.us

RISK & COMPLIANCE MANAGER

a) The Risk and Compliance Manager is responsible to assess risk and compliance 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 Gate

4 phase.

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.

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

CONFIDENTIAL: OIT System Security Plan 20

Name: Greg Williams Address: 601 E. 18th Avenue, Denver, CO 80203

Title: Audit & Compliance Manager Phone: 303.681.5476

Agency: OIT/OIS E-mail: greg.williams@state.co.us