AMENDMENT NO 1 to RFP S-DASOBO-00008678_FINAL FOR RELEASE.docx

AMENDMENT NO. 1 to RFP S-DASOBO-00008678 (“RFP”) | OLCC DSSC SOLUTION December 28, 2023 The purpose of this Amendment No. 1 (“Amendment”) to the RFP is to:

1. Amend the RFP Schedule to Extend the time for Submission of Proposals.

The current RFP Schedule lists the deadline for submission of “Proposals”, i.e., the “Opening”, as January 22, 2024, by 5:00 p.m. Pacific Time. Through this Amendment, the Opening is extended to February 5, 2024, by 5:00 p.m. Pacific Time.

The amended RFP Schedule is set out below (except for events following the “Opening”, which remain unchanged). Bold underlined text depicts insertions and strikethrough text depicts deletions. All listed times are Pacific Zone Times.

January 22, 2024, by 5:00 p.m. PT

2. Amend the RFP Section 5.4.1 to clarify the scope of negotiable items. Section 5.4.1 is amended to read:

5.4.1 Negotiation

After selection of at least one successful Proposer, DAS PS may enter Contract negotiations with that successful Proposer. By submitting a Proposal, Proposer agrees to comply with the requirements of the RFP, including the terms and conditions of the Sample Contract (Attachment A), with the exception of those terms listed below for negotiation.

The State intends to enter into a Contract with the successful Proposer(s) substantially in the form set forth in the Sample Contract (Attachment A). It may be possible to negotiate some terms and conditions of the final Contract, as set forth below. However, the State is not required to accept any proposed revisions to any of the terms and conditions and many terms and conditions cannot be changed. Proposer is cautioned that the State of Oregon believes modifications to the standard terms and conditions constitute increased risk and increased price to the State.

Any Proposal that is conditioned upon DAS PS’ acceptance of any other terms and conditions may be rejected. Any subsequent negotiated changes are subject to prior approval of the Oregon Department of Justice.

All items, except those listed below, may be negotiated between DAS PS and the apparent successful Proposer in compliance with Oregon State laws:

1. Choice of law,

2. Choice of venue,

3. Constitutional requirements, and

4. Any and all federal and state laws, and their implementing administrative rules, requirements, and policies and procedures.

In the event that the parties have not reached mutually agreeable terms within 90 calendar days of the date of the Notice of Intent to Award, DAS PS may terminate Negotiations and commence Negotiations with the next highest-ranking Proposer.

3. Release a Corrected RFP Attachment H, Solution Requirements. Column I in Attachment H should be freeform text. OLCC provides a corrected version of Attachment H via this Amendment 1 to the RFP; embedded below and also separately attached in Oregon Buys.

4. Release a Corrected RFP Attachment J, Statewide Information and Cyber Security Standards Spreadsheet. The original Attachment J released with the RFP is in error. It is an inadvertent duplication of RFP Attachment L, Third Party Vendor Information (for POS). OLCC provides a corrected version of Attachment J via this Amendment 1 to the RFP; embedded below and also separately attached in Oregon Buys.

5. Respond to Questions Submitted by December 20, 2022.

Answers to the 21 timely submitted questions are set out in the PDF of a Microsoft Table Document embedded below as a document object and also included as a separate Attachment in Oregon Buys.

The Single Point-of-Contact (SPC) for the procurement remains:

Nick Betsacon IT Procurement Strategist nicholas.betsacon@das.oregon.gov

(503) 267-6636

Prospective Proposers have until January 3, 2024, by 5:00 PM Pacific Time to submit written questions via email only to the SPC regarding the content in Amendment 1 to the RFP.

-End of RFP Amendment No. 1- Amendment No. 1 to RFP S-DASOBO-00008678 OLCC DSSC Solution Extend time for Submission of Proposals | Respond to Written Questions 2

10_S-DASOBO-00008678_RFP_Attachment J_STATEWIDE SECURITY STANDARDS-corrected.xlsx Instructions

ATTACHMENT J TO RFP S-DASOBO-00008678 | OLCC DSSC SOLUTION | STATEWIDE INFORMATION AND CYBER SECURITY STANDARDS

This tool is provided to assist agencies in defining and gathering information security requirements. Agencies may have additional information security requirements required by law, regulations, or policies.

Requirements Template for Moderate Systems Description and Use Instructions:

The requirements are directly from the 2019 Statewide Information and Cyber Security Standards, as such the below sections are Static.

o Control (Column’s A-D) o Control Name (Column E): Control details can be viewed in the attached comment, or found in the 2019 Statewide Information and Cyber Security Standards.

o Applicability:

Low (All): (Column F)

Moderate (Column G)

Agency Task: Depending on agency preference, in consultation with Cyber Security Services BISO, agency can designate whether the control applies to on premise, off premise or both, in relation to the Agency.

o Location

On Premise (Column H)

Off Premise (Column I)

Proposer Task: Proposer will complete the remaining sections per instructions below.

o Requirement Implemented by (Columns J-L): Proposer responds to indicate if the control is the responsibility of the agency, the vendor, or if it is a shared control.

X: signifies the control is the responsibility of the entity

Blank: signifies the control is not the entity's responsibility o Vendor Control is (Columns M-P): The Vendor selects whether the control is provided as part of the Base solution, an Add-on, from a Third Party, or Not Supported

X: signifies where the control is provided

Blank: signifies the control is not provided o Comments (Column R): Proposer shall provide comments on how the control is met. If the control is not supported, please indicate compensating controls, or your Plan of Action and Milestones.

Requirements Template

CONTROL Control Name CONTROL ENHANCEMENT NAMES (are in caps) Applicability Location (in relation to Agency) Proposer Response

Requirement Implemented by Vendor Control is: How Control is Met. (If not supported, please indicate your Plan of Action and Milestones.)

All Moderate On Premise Off Premise Agency Vendor Shared (agency/vendor) Base Add-on Third Party Not supported Comments

Governance

PM-1 Information Security Program Plan

PM-4 Plan of Action and Milestones Process

Control Detail: Control Detail:

a.Implement a process to ensure that plans of action and milestones (see CA-5) for the agency security programs and associated organizational systems:

1.Are developed and maintained;

2.Document the remedial information security and privacy action to adequately respond to risk to organizational operations and assets, individuals, other organizations, and the State; and 3.Are reported in accordance with established reporting requirements; and b.Review plans of action and milestones for consistency with organizational risk management strategy and organization-wide priorities for risk response actions X

PM-5 System Inventory

Control Detail: Control Detail:

Develop, document, and maintain an inventory of all organizational systems that create, collect, use, process, store, maintain, disseminate, disclose, or dispose of agency information to allow the agency to regularly review its information assets and ensure, to the extent reasonably practicable, that such information is accurate, relevant, timely, and complete.

a.Develop and maintain an inventory of all hardware assets whether connected to the Agency’s network or not (CIS-1.4).

1.Utilize an active discovery tool to identify devices connected to the Agency's network, and update the Agency's hardware asset inventory as appropriate(CIS-1.1);

2.Utilize a passive discovery tool to identify devices connected to the Agency’s network, and update the Agency’s hardware asset inventory as appropriate (CIS-1.2);

3.Where Dynamic Host Configuration Protocol (DHCP) is used, employ logging on all DHCP servers or IP address management tools to support updating the organization's hardware asset inventory (CIS-1.3);

4.Ensure that the asset inventory includes information determined to be necessary by the Agency to achieve effective property accountability, including but not limited to: i)Network address;ii)Hardware (MAC) address;iii)Machine name;iv)Asset owner (including agency, division, department, program, etc.);v)Date and time that the asset record was last updated in the inventory; andvi)Network connectivity that is authorized for the asset (CIS-1.5);

5.Ensure that unauthorized components are removed from the network, quarantined, or the inventory is updated to reflect that the component is unauthorized, in a timely manner(CIS-1.6);

6.Review and update the list of authorized components: i)Utilizing automated tools or manual processes;ii)At a minimum annually;iii)When required due to system upgrades or other significant changes; andiv)As an integral part of system component installations;

7.Maintain an up to date inventory of all Agency network boundaries (i.e. points of ingress and egress)(CIS-12.1): i)This inventory must include a list of all authorized wireless access points connected to the Agency’s network (CIS-15.1); and 8.The inventory must include a list of each of the organization’s authentication systems, including those located onsite or at a remote service provider (CIS-16.1); and b.Develop and maintain an inventory of all software that is required in the enterprise for any business purpose on any business system (CIS-2.1):

1.Ensure that only software applications or operating systems currently supported by the software's vendor are added to the Agency's authorized software inventory. Software currently in use and no longer supported must be identified as unsupported in the inventory system (CIS-2.2);

2.Utilize software inventory tools throughout the organization to support the documentation of all software on Agency systems (CIS-2.3);

3.Ensure that the following items are tracked in the software inventory system:i)Name;ii)Version;iii)Publisher;iv)Agency System Owner(s); v)Term / End of Support; andvi)Install date for all software, including operating systems authorized by the organization (CIS-2.4);

4.Tie the software inventory system to the hardware asset inventory so all devices and associated software are tracked(CIS-2.5) 5.Ensure that the inventory includes a list of each of the organization’s authentication systems, including those located onsite or at a remote service provider (CIS-16.1) 6.Ensure that unauthorized software is removed, or the inventory is updated to reflect that the software is unauthorized, in a timely manner (CIS-2.6); and 7.Review and update the list of authorized software programs:i)At a minimum annually;ii)When required due to system upgrades or other significant changes; andiii)As an integral part of system component installations X

PL-1 Planning Policy and Procedures

PL-2 System Security and Privacy Plans

Control Detail: Control Detail:

a.Develop system security plans that:

1.Are consistent with the organization’s enterprise architecture;

2.Explicitly define the authorization boundary for the system;

3.Describe the operational context of the system in terms of missions and business processes;

4.Provide the security categorization of the system including supporting rationale;

5.Describe the operational environment for the system and relationships with or connections to other systems;

6.Provide an overview of the security requirements for the system;

7.Identify any relevant overlays (e.g. manufacturer, name, IP address, etc.), for appropriate distribution, if applicable;

8.Describe the security controls in place or planned for meeting those requirements including a rationale for the tailoring decisions; and 9.Are reviewed and approved by the authorizing official or designated representative prior to plan implementation;

b.Distribute copies of the system security plan(s) and communicate subsequent changes to the plans to designated Agency personnel;

c.Review the system security plan(s) on an annual basis;

d.Update the security plan(s) to address changes to the system and environment of operation or problems identified during plan implementation or security control assessments; and e.Protect the security plan(s) from unauthorized disclosure and modification.

X

PL-2(3) PLAN AND COORDINATE WITH OTHER ORGANIZATIONAL ENTITIES

Control Detail: Control Detail:

Plan and coordinate security-related activities affecting the system with appropriate agency information security oversight, change management, and other stakeholders , before conducting such activities to reduce the impact on other organizational entities that may be affected by changes to the system. X

PL-4 Rules of Behavior

Control Detail: Control Detail:

a.Establish and provide to individuals requiring access to the system, the rules that describe their responsibilities and expected behavior for information and system usage, security, and privacy;b.Receive a documented acknowledgment from such individuals, indicating that they have read, understand, and agree to abide by the rules of behavior, before authorizing access to information and the system;c.Review and update the rules of behavior at least every three years; andd.Require individuals to read and re-sign when the rules of behavior are revised or updated, or at least annually X

PL-4(1) SOCIAL MEDIA AND NETWORKING RESTRICTIONS

Control Detail: Control Detail:

Include explicit restrictions on the use of social media and networking sites, and the posting of organizational information on public websites X

PL-8 Security and Privacy Architectures

Control Detail: Control Detail:

a.Develop security architecture for the system that:

1.Describe the philosophy, requirements, and approach to be taken for protecting the confidentiality, integrity, and availability of organizational information;

2.Describe how the security architecture is integrated into and supports the enterprise architecture; and 3.Describe any security-related assumptions about, and dependencies on, external services;

b.Review and update the security architecture for the system every three years to reflect updates in the enterprise architecture, or any time there is a significant change to the system; and c.Reflect planned security architecture changes in the system security plan X

PL-10 Baseline Selection

Control Detail: Control Detail:

Select a control baseline (Low, Moderate, or Moderate +) for the system. X

PL-11 Baseline Tailoring

Control Detail: Control Detail:

Tailor the selected control baseline by applying specified tailoring actions. After selecting an appropriate control baseline, organizations initiate a tailoring process to align the controls more closely with the specific protection needs and concerns of their stakeholders, or local, state, and federal regulatory requirements. X

Risk

RA-1 Risk Assessment Policy and Procedures

RA-2 Security Categorization

Control Detail: Control Detail:

a.Categorize the system and information it processes, stores, and transmits;1.System classification must take into account:

i)The classification of the information received, stored, or processed:

(1)Level 1 Published: Low-sensitive information. Information that is not protected from disclosure, that if disclosed will not jeopardize the privacy or security of agency employees, clients, and partners. The disclosure, alteration, or destruction of Level 1 information generally has a low impact on security;

(2)Level 2 Limited: Sensitive information that may not be protected from public disclosure, but if made easily and readily available may jeopardize the privacy or security of agency employees, clients, or partners. The disclosure, alteration, or destruction of Level 2 information generally has a Low impact on security;

(3)Level 3 Restricted: Sensitive information intended for limited business use that may be exempt from public disclosure because, among other reasons, such disclosure will jeopardize the privacy or security of agency employees, clients, partners, or individuals who otherwise qualify for an exemption. Information in this category may be accesses and used by internal parties only when specifically authorized to do so in the performance of their duties. The disclosure, alteration, or destruction of Level 3 information generally has a moderateimpact on security; and (4)Level 4 Critical: Information that is deemed extremely sensitive and is intended for use by named individual(s) only. This information is typically exempt from public disclosure because, among other reasons, such disclosure would potentially cause major damage or injury up to and including death to the named individual(s), agency employees, clients, partners, or cause major Harm to the agency. The disclosure, alteration, or destruction of Level 4 information generally has a highimpact on security; and ii)The FIPS 199 categorization of the system;

b.Document the security categorization results including supporting rationale, in the system security plan; and c.Verify that the authorizing official or designee reviews and approves the security categorization decision. X

RA-3 Risk Assessment

Control Detail: Control Detail:

a.Conduct a risk assessment, including the likelihood and magnitude of harm, from:1.The unauthorized access, use, disclosure, disruption, modification, or destruction of the system, the information it processes, stores, or transmits, and any related information; and2.Problems arising from the processing of regulated data;

b.Document risk assessment results in a risk assessment report;

c.Disseminate risk assessment results to designated personnel as defined in the System Security Plan; and d.Update the risk assessment at a minimum every three years, or when there are significant changes to asystem, its environment of operation, or other conditions that may impact security. X

RA-3(1) SUPPLY CHAIN RISK ASSESSMENT

Control Detail: Control Detail:

a.Assess supply chain risks associated with systems, system components, and system services; and b.Update the supply chain risk assessment at a minimum every three years, or when there are significant changes to the relevant supply chain, when changes to the system, environments of operation, or other conditions may necessitate a change in the supply chain. X

RA-5 Vulnerability Scanning

Control Detail: Control Detail:

a.Scan for vulnerabilities using a current SCAP-compliant scanning tool on the system and hosted applications at least weekly, and when new vulnerabilities potentially affecting the system/applications are identified and reported(CIS-3.1);

b.Employ vulnerability scanning tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for:

1.Enumerating platforms, software flaws, and improper configurations;

2.Formatting checklists and test procedures; and 3.Measuring vulnerability impact;

c.Analyze vulnerability scan reports and results from any additional security control assessments;

d.Remediate legitimate vulnerabilities in accordance with an organizational assessment:

1.Utilizing a risk-rating process to prioritize the remediation of discovered vulnerabilities; and (CIS-3.7); and 2.Comparing the results from back-to-back vulnerability scans to verify that vulnerabilities have been remediated in a timely manner (CIS-3.6);

e.Share information obtained from the vulnerability scanning process and security control assessments with designated agency officials to help eliminate similar vulnerabilities in other systems (i.e., systemic weaknesses or deficiencies); and f.Employ vulnerability scanning tools that include the capability to regularly update the vulnerabilities to be scanned. X

RA-5(2) UPDATE BY FREQUENCY, PRIOR TO NEW SCAN, OR WHEN IDENTIFIED

Control Detail: Control Detail:

Update the system vulnerabilities to be scanned prior to a new scan, or when new vulnerabilities are identified and reported. X

RA-5(5) PRIVILEGED ACCESS

Control Detail: Control Detail:

a.Perform authenticated vulnerability scanning with agents running locally on each system, or with remote scanners that are configured with elevated rights on the system being tested, with the exception of systems where this is not feasible and such exceptions are approved by Agency System Owner or designee, and documented (CIS-3.2);

b.Use a dedicated account for authenticated vulnerability scans. Such accounts must not be used for any other administrative activities (CIS-3.3); and c.Where feasible, tie the account used for authenticated vulnerability scans to specific machines, at specific IP addresses (CIS-3.3). X

RA-7 Risk Response

Control Detail: Control Detail:

Respond to findings from security assessments, monitoring, and audits. X

RA-9 Criticality Analysis

Control Detail: Control Detail:

Identify critical system components and functions by performing a criticality analysis for, system components, or system services and document the analysis in the System Security Plan X

Compliance

AU-1 Audit and Accountability Policy and Procedures

AU-2 Audit Events

Control Detail: Control Detail:

a.Verify that, at a minimum, all systems are capable of auditing the following events:

1.Startup and shutdown;

2.Installation and removal of software;

3.Error messages;

4.Account creation, modification, or deletion;i)Systems must be configured to issue an alert when an account is added to or removed from any group assigned administrative privileges (CIS-4.8);

5.User logon and logoff;

6.Unsuccessful logon attempts (CIS-4.9);

7.Attempted access to deactivated accounts (CIS-16.12);

8.Successful and unsuccessful change of password;

9.Creation or modification of super-user groups; (CIS-4.8) 10.Startup and shutdown of audit functions;

11.Manual clearing or modification of the audit log file;

12.Change of file or user permissions or privileges (e.g. use of SUID/GUID, CHOWN, SU, etc.);

13.Execution of command-line processes for command shells such as Microsoft PowerShell and Bash (CIS-8.8);

14.Changes made to an application or database by a batch file;

15.Changes to database or application records, where the application has been bypassed to produce the change (via file or other database utility);

16.Modifications to the application or database;

17.Accesses to information and files;

18.Configuration changes;

19.Remote access outside of the internal network, and all dial-in access to the system;

20.Domain Name System (DNS) query logging for detection of hostname lookups for known malicious domains (CIS-8. 7); 21.Execution of command-line processes for command shells such as Microsoft PowerShell and Bash (CIS-8.8);

22.Remote access outside of the internal network, and all dial-in access to the system;NOTE: Remote access is defined as a type of network access that involves communication through external networks. Internal networks include LANs and WANs; and 23.All system and interactions concerning:

i)Information classified as Level 3 (Restricted) or above according to the statewide Information Asset Classification Policy; and b.Coordinate the security audit function with other organizational entities requiring audit-related information, to enhance mutual support and help guide the selection of auditable events; and c.Document a rationale for why the auditable events are deemed to be adequate to support after-the-fact investigations of security incidents.

X

AU-2(3) REVIEWS AND UPDATES

Control Detail: Control Detail:

Review and update audited events at least annually, or when a major change to the system occurs. X

AU-3 Content of Audit Records

Control Detail: Control Detail:

a.Configure systems to generate audit records containing sufficient information to establish what type of event occurred, when the event occurred, where the event occurred, the source of the event, the outcome of the event, and the identity of any individuals or subjects associated with the event. At a minimum, the following elements shall be identified within each audit record (CIS-6. 3):

1.Date and time when the event occurred;

2.The software or hardware component of the system where the event occurred;

3.Source of the event (e.g. network address, console);

4.Type of event that occurred;

5.Subject identity (e.g. user, device, process context);

6.The outcome (i.e. success or failure) of the event; and 7.Network traffic data on all network boundary devices (CIS-12.8). X

AU-3(1) ADDITIONAL AUDIT INFORMATION

Control Detail: Control Detail:

Generate audit records containing additional information as required by applicable laws and regulations, specific to the system. X

AU-4 Audit Storage Capacity

Control Detail: Control Detail:

Allocate sufficient audit record storage capacity to comply with State of Oregon records retention schedules and any other applicable retention requirements (CIS-6.4). X

AU-5 Response to Audit Processing Failures

Control Detail: Control Detail:

For all systems a.Configure to provide alerts to designated Agency personnel in the event of audit processing failures when the failure occurs;

b.Take appropriate action to address the restoration of logging functionality immediately upon discovery; and c.Ensure that systems receiving, processing, or storing regulated data comply with applicable laws and regulations, specific to the system X

AU-5(1) AUDIT STORAGE CAPACITY

Control Detail: Control Detail:

Provide a warning to designated officials (to include system administrators, Information Security Officers, Operational Security Officers) when allocated audit record storage volume reaches 80% utilization, or as specified by regulations specific to the system. X

AU-6 Audit Review, Analysis, and Reporting

Control Detail: Control Detail:

a.Review and analyze system audit records at least weekly for the following:

1.Indications of inappropriate or unusual activity related to potential unauthorized access(CIS-6.7); and 2.Other anomalies or abnormal events;

b.Report incidents discovered during audit record review and analysis according to agency, State of Oregon, and Federal Incident Response Policy and procedures.

1.Findings involving a potential unauthorized disclosure of FTI must be reported to the office of the appropriate special agent-in -charge for the Treasury Inspector General for Tax Administration (TIGTA)and to the IRS Office of Safeguards immediately, but no later than 24 hours after identification of the possible incident; and 2.Findings involving a potential unauthorized disclosure of Social Security Administration Provided Information (SSPI) must be reported to the Social Security Administration Regional Office or System Security Contact within one hour after identification of the possible incident.

X

AU-6(1) AUTOMATED PROCESS INTEGRATION

Control Detail: Control Detail:

Employ automated mechanisms to integrate audit review, analysis, and reporting processes to support organizational processes for investigation and response to suspicious activities. X

AU-6(3) CORRELATE AUDIT REPOSITORIES

Control Detail: Control Detail:

Analyze and correlate audit records across different repositories to gain Agency-wide situational awareness (CIS-6. 5). X

AU-6(4) CENTRAL REVIEW AND ANALYSIS

Control Detail: Control Detail:

a.Aggregate logs to a central log management system for analysis and review. Automated mechanisms for centralized reviews and analyses include, for example, Security Information and Event Management (SIEM) products (CIS-6.6); and b.Send malware detection events to anti-malware administration tools and centralized log servers for alerting and analysis (CIS-8.6) X

AU-7 Audit Reduction and Report Generation

Control Detail: Control Detail:

a.Provide and implement an audit reduction and report generation capability that:

1.Supports near real-time audit review, analysis, and reporting requirements described in AU-6, and after-the-fact investigations of security incidents;

i)The audit reduction and report capability must be tuned on a regular basis in order to better identify actionable events and decrease event noise (CIS-6.8); and 2.Does not alter the original content or time ordering of audit records.

X

AU-7(1) AUTOMATIC PROCESSING

Control Detail: Control Detail:

Provide and implement the capability to process audit records for events of interest based on individual items, or combinations of items contained in the audit records, as defined in AU-3 (CIS-6.8). X

AU-8 Time Stamps

Control Detail: Control Detail:

a.Use internal system clocks to generate time stamps for audit records.

1.Time stamps generated by the systems shall include both the date and the time; and b.Record time stamps that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT) (CIS-6.1). X

AU-8(1) SYNCHRONIZATION WITH AUTHORITATIVE TIME SOURCE

Control Detail: Control Detail:

a.Provide at least two authoritative State of Oregon time sources for synchronization;

b.The State authoritative time sources must be sourced by at least three unique Stratum One time sources;

c.Compare and synchronize internal system clocks with at least one of the Oregon enterprise-wide primary authoritative time sources, to ensure that time stamps in audit records are as accurate as possible and correlate across different systems or system components (CIS-6.1); and d.Configure internal system clocks to synchronize to the authoritative time source at least weekly, or when the time difference between systems is greater than 5 minutes. X

AU-8(2) SECONDARY AUTHORITATIVE TIME SOURCE

Control Detail: Control Detail:

a.Identify a secondary Oregon enterprise-wide authoritative time source that is in a different geographic region than the primary authoritative time source; and b.Synchronize the internal system clocks to the secondary authoritative time source if the primary authoritative time source is unavailable. X

AU-9 Protection of Audit Information

Control Detail: Control Detail:

Protect audit information and audit tools from unauthorized access, modification, and deletion. X

AU-9(4) ACCESS BY SUBSET OF PRIVILEGED USERS

Control Detail: Control Detail:

Limit access to management of audit functionality to personnel that have a need to know and have been expressly authorized for this function. X

AU-9(6) READ-ONLY ACCESS

Control Detail: Control Detail:

Ensure audit files are tamper resistant (read-only). In all cases, access to the logs must be limited only to those with a need to access. X

AU-11 Audit Record Retention

Control Detail: Control Detail:

a. Retain audit records, as defined under AU-2, to provide support for after-the-fact investigations of IT security incidents; and

b. Retain all audit records in accordance with Oregon Administrative Rule 166-300-0030 (3) for Computer System Security Records and applicable federal laws, executive orders, directives, policies, regulations, standards, and guidance, whichever is most restrictive.

X

AU-12 Audit Generation

Control Detail: Control Detail:

a. Provide audit record generation capability for the list of auditable events defined under AU-2 a., with content prescribed under AU-3 on, at a minimum, the following system components (CIS-6.2):

1. Hardware or devices:

i) Network devices (e.g. switches, routers, firewalls); ii) Workstations;

iii) Servers; iv) Cameras; v) Printers;

vi) Multi-function devices; vii) Industrial controls; viii) Other devices with wired or wireless connectivity (e.g. Internet of Things devices); and ix) Mobile devices (excluding Limited Feature Devices); and

2. Software:

i) Operating systems (excluding “limited feature” operating systems); ii) Applications; iii) Databases; and iv) Firmware;

b. Limited-Feature Operating Systems: Limited-feature operating systems are designed specifically for the mobile environment where battery life and power efficiency are primary design drivers (e.g. Apple iOS, Android, Windows Mobile, Blackberry OS, etc.). Limited-feature operating systems permit limited user control, but are inherently more resistant than a full-feature operating system to certain types of network based technical attacks due to the limited feature sets. Devices using these operating systems are required to be managed by a mobile device management solution; and

c. Agency System Owners, Agency Information Owners, Systems Auditors, and Business Information Security Officers, shall be allowed to select which auditable events are applicable to be audited by specific components of their respective systems.

X

AU-16 Cross-Organizational Auditing

Control Detail: Control Detail:

When agencies use systems and/or services of external organizations, employ mechanisms for coordinating the access and protection of audit information when transmitting across agency boundaries. The external organization or third-party service provider must be held accountable to protect and share audit information with the agency by contract. X

Workforce

AT-1 Awareness and Training Policy and Procedures

AT-2 Awareness Training

Control Detail: Control Detail:

a. Provide all personnel (including but not limited to managers, senior executive staff, contractors, and volunteers) basic security awareness training:

1. As part of initial training for new personnel and before authorizing access to state systems, and information;

2. When required by system changes; and

3. At least annually thereafter; and

b. Create a security awareness program for all personnel to complete on a regular basis to ensure understanding of the necessary behaviors and skills to help support the security of the enterprise (CIS-17.3):

1. The Security Awareness Program must be updated at least annually to address new technologies, threats, standards, and business requirements (CIS-17.4); and

2. At a minimum, training must include:

i) Information on enabling and using secure authentication (CIS-17.5);

ii) Proper identification, storage, transfer, and destruction of sensitive information (CIS-17.7); iii) Identification of common indicators of an incident; and iv) How to report incidents (CIS-17.9);

c. All personnel with access to state information assets shall complete basic statewide security awareness training as required; and

d. Provide additional training, including any training required for access to regulated data to supplement the statewide mandated awareness training.

X

AT-2(2) INSIDER THREAT

Control Detail: Control Detail:

Include security awareness training that covers the recognition and reporting of potential indicators of insider threat, including unintentional data exposure (e.g. loss of mobile devices, sending an email to the wrong recipient, etc.) (CIS-17.8). X

AT-2(3) SOCIAL ENGINEERING AND MINING

Control Detail: Control Detail:

Enterprise wide Include security awareness training that covers the recognition and reporting of potential and actual instances of social engineering and social mining (e.g. phishing, phone scams, impersonation, etc.) (CIS- 17.6).

X

AT-3 Role-Based Training

Control Detail: Control Detail:

a. Provide role-based security-related training to personnel with the following roles and responsibilities:

1. Software development personnel in secure coding practices for their specific development environment and responsibilities (CIS-18.6);

2. Personnel with privileged access; and

3. Other personnel as required by applicable laws, executive orders, directives, policies, regulations, standards, and guidance; and

b. Provide role-based security-related training:

1. As part of initial training for new users and before authorizing access to organization systems, information, and regulated data; 2. When required by system changes; and

3. At least annually thereafter.

X

AT-4 Training Records

Control Detail: Control Detail:

a. Document and monitor individual system security and privacy training activities, including basic security and privacy awareness training, and specific role-based system security and privacy training; and

b. Retain individual training records according to applicable laws, executive orders, directives, policies, regulations, standards, and guidance, but in no case less than the retention time specified by the Oregon Secretary of State Archive Division.

X

PS-1 Personnel Security Policy and Procedures

PS-2 Position Risk Designation

Control Detail: Control Detail:

a. Assign a risk designation to all organizational positions:

1. The following must be considered regarding position risk designations:

i) Program-level risk must be factored into the position risk designation;

ii) The risk level associated with each user role that has access to the system must be assessed; and iii) A position’s risk designation must consider:

(1) Physical access to the system’s hardware or software;

(2) Physical or logical access to Level 3 (Restricted) or higher data;

(3) The ability to override or bypass security controls;

(4) The scope of IT resources potentially impacted by security violations; and

(5) The FIPS 199 security categorization of the system;

b. Establish screening criteria for individuals filling those positions; and

c. Review and update position risk designations annually, or when a change to or addition of duties occurs.

X

PS-3 Personnel Screening

Control Detail: Control Detail:

a. Perform screening on individuals prior to authorizing access to the system; and

b. Rescreen individuals in accordance with applicable federal and state laws, executive orders, directives, policies, regulations, standards, guidance, and the criteria established relative to any regulated data that the position requires access to.

X

PS-4 Personnel Termination

Control Detail: Control Detail:

Upon termination of an individual’s employment, agencies must: a. Disable system access;

1. If termination of employment is voluntary, terminate system access within the same day that employment is terminated; and

2. If termination is involuntary, whenever possible, terminate system access just before or at the same time notification of such termination is provided to the employee, but in no case longer than two (2) hours following such notification;

b. Terminate / revoke any authenticators / credentials associated with the individual;

c. Upon departure counsel the terminated individual on continued obligations under system non-disclosure, confidentiality, or user access agreements;

d. Retrieve all security-related and agency system-related property (e.g. hardware authentication tokens, system administration and technical manuals, keys, identification / RFID cards, etc.);

e. Retain access to agency information and systems formerly controlled by the terminated individual; and

f. Notify appropriate agency personnel, including system management and facilities access, upon termination of the employee.

X

PS-5 Personnel Transfer

Control Detail: Control Detail:

a. Review and confirm ongoing operational need for current logical and physical access authorizations to systems and facilities when individuals are reassigned or transferred to other positions within the agency;

b. Initiate transfer or reassignment actions as appropriate following the formal transfer action for all personnel, including contractors;

c. Modify access authorizations as needed to correspond with any changes in operational need due to reassignment or transfer; and

d. Notify designated agency personnel, as required.

X

PS-6 Access Agreements

Control Detail: Control Detail:

a. Develop and document access agreements (e.g., nondisclosure agreements, acceptable use agreements, rules of behavior, and conflict-of-interest agreements) for agency systems;

b. Review and update the access agreements at least annually; and

c. Verify that individuals requiring access to organizational information and systems:

1. Sign appropriate access agreements prior to being granted access; and

2. Re-sign access agreements to maintain access to organizational systems when access agreements have been updated or at least annually.

X

PS-7 External Personnel Security

Control Detail: Control Detail:

a. Establish and document personnel security requirements, including security roles and responsibilities for third-party providers;

b. Require third-party providers to comply with personnel security policies and procedures established by the agency;

c. Require third-party providers to notify the agency of any personnel transfers or terminations of thirdparty personnel who possess agency credentials or badges, or who have system privileges; and

d. Monitor provider compliance with personnel security requirements.

X

PS-8 Personnel Sanctions

Control Detail: Control Detail:

a. Employ a formal sanctions process for individuals failing to comply with established information security policies and procedures:

1. The sanctions process must be consistent with applicable federal and state laws, Executive Orders, directives, agreements, policies, regulations, standards, and guidance where applicable; and

b. Notify designated agency personnel when a formal employee sanctions process is initiated, identifying the individual sanctioned and the reason for the sanction.

X

Assets

SA-1 System and Services Acquisition Policy and Procedures

SA-2 Allocation of Resources

Control Detail: Control Detail:

a. Include information security requirements for the system in mission / business process planning;

b. Determine, document, and allocate the resources required to protect the system or system service as part of the capital planning and investment control process;

c. Establish a discrete line item for information security in agency program and budgeting documentation.

X

SA-3 System Development Life Cycle

Control Detail: Control Detail:

a. Utilize a System Development Life Cycle (SDLC) methodology that includes information security considerations;

b. Define and document information security roles and responsibilities throughout the system development life cycle;

c. Identify positions having information security roles and responsibilities associated with the system; and

d. Integrate information security risk management processes into the SDLC.

X

SA-4 Acquisition Process

Control Detail: Control Detail:

Include the following requirements, explicitly or by reference, in acquisition contracts for systems, system components, or system services: 1. Security functional requirements;

2. Security strength of mechanism requirements (i.e. password length and complexity requirements, encryption strength, hardware security, etc.);

3. Security assurance requirements;

4. Security-related documentation requirements;

5. Requirements for protecting security documents;

6. Description of the system development environment and the environment in which the system is intended to operate;

7. Allocation of responsibility or identification of parties responsible for information security, privacy, and supply chain risk management; and

8. Security acceptance criteria.

X

SA-4(1) FUNCTIONAL PROPERTIES OF CONTROLS

Control Detail: Control Detail:

Require the developer of the system, system component, or system service to provide a description of the functional properties of the security controls to be implemented.

NOTE: Functional properties of security and privacy controls describe the functionality (i.e., security or privacy capability, functions, or mechanisms) visible at the interfaces of the controls and specifically exclude functionality and data structures internal to the operation of the controls.

X

SA-4(2) DESIGN AND IMPLEMENTATION INFORMATION FOR CONTROLS

Control Detail: Control Detail:

Require vendors and contractors to provide information in acquisition documents that describe the design and implementation details of the security controls to be employed within the system, system components, or system services (including functional interfaces among control components), with sufficient detail to permit independent analysis and testing of the controls. X

SA-4(9) FUNCTIONS, PORTS, PROTOCOLS, AND SERVICES IN USE

Control Detail: Control Detail:

Require developers of systems, system components, or system services to identify early in the SDLC, the functions, ports, protocols, and services that are intended for organizational use. X

SA-5 System Documentation

Control Detail: Control Detail:

a. Obtain administrator documentation (whether published by a vendor/manufacturer or written in-house) for the system, system component, or system service that describes:

1. Secure configuration, installation, and operation of the system, component, or service;

2. Effective use and maintenance of security and privacy functions and mechanisms; and

3. Known vulnerabilities regarding configuration and use of administrative or privileged functions;

b. Obtain user documentation for the system, system component, or system service that describes:

1. User-accessible security and privacy functions and mechanisms and how to effectively use those functions and mechanisms;

2. Methods for user interaction, which enable individuals to use the system, component, or service in a secure manner; and

3. User responsibilities in maintaining the security of the system, component, or service of individuals;

c. When system documentation is either unavailable or non-existent, the following actions must be taken:

1. Document attempts to obtain such documentation; and

2. Recreate selected system documentation if such documentation is essential to the effective implementation and / or operation of security controls;

d. Protect documentation as required, in accordance with the organizational risk management strategy; and

e. Distribute documentation to appropriate agency personnel.

X

SA-8 Security and Privacy Engineering Principles

Control Detail: Control Detail:

a. Apply system security engineering principles in the specification, design, development, implementation, and modification of the system.

b. Security engineering principles must include, but are not limited to:

1. Establishing and testing secure coding practices appropriate to the programming language and development environment being used (CIS-18.1);

2. Ensuring that explicit error checking is performed and documented for all input, including size, data type, and acceptable ranges or formats (CIS-18.2);

3. Applying static and dynamic analysis tools to verify that secure coding practices are being adhered to

(CIS 18.7);

4. Developing layered protections;

5. Establishing sound security methodology, architecture, and controls as the foundation for design;

6. Incorporating security into all phases the System Development Life Cycle (SDLC);

7. Delineating physical and logical security boundaries;

8. Ensuring system developers and integrators are trained in secure software development;

9. Tailoring security controls to meet organizational and operational needs;

10. Performing threat modeling to identify use cases, threat agents, attack vectors, and attack patterns, as well as compensating controls and design patterns needed to mitigate risk; and

11. Enabling informed risk management decisions in order to reduce risk to acceptable levels; and

c. For legacy systems, apply the above security engineering principles to system upgrades and modifications, to the extent feasible given the current state of the hardware, software, and firmware components within the system.

X

SA-9 External System Services

Control Detail: Control Detail:

a. Require that providers of external system services comply with organizational security requirements and employ applicable agency-defined security controls;

b. Define and document agency oversight, user roles and responsibilities, and service levels, with regard to external system services; and

c. Employ agency defined processes, methods, and techniques to monitor security compliance by external service providers on an ongoing basis.

X

SA-9(2) IDENTIFICATION OF FUNCTIONS, PORTS, PROTOCOLS, AND SERVICES

Control Detail: Control Detail:

Require providers of external system services to identify the functions, ports, protocols, and other services required for use. X

SA-10 Developer Configuration Management

Control Detail: Control Detail:

. Require the developer of the system, system component, or system service to:

1. Perform configuration management throughout the system development lifecycle, including: design; development; system test; and unit acceptance test;

2. Document, manage, and control the integrity of changes throughout the system development lifecycle, including: design; development; system test; and unit acceptance test;

3. Implement only organization-approved changes to the system, component, or service;

4. Document approved changes to the system, component, or service and the potential security impacts of such changes; and

5. Track security flaws and flaw resolution within the system, component, or service and report findings to appropriate personnel as identified in the system security plan.

X

SA-11 Developer Testing and Evaluation

Control Detail: Control Detail:

. Require the developer of the system, system component, or system service, at all post-design phases of the system development life cycle, to:

1. Create and implement a security assessment plan, and document the security assessment plan in the system security plan;

2. Perform security testing and evaluation according to the security assessment plan;

3. Implement a verifiable flaw remediation process that includes accepting and addressing reports of software vulnerabilities discovered during assessments (CIS-18.8); and

4. Correct flaws identified during testing and evaluation.

X

SA-12 Supply Chain Risk Management

Control Detail: Control Detail:

a. Employ safeguards to protect against supply chain risks to the system, system component, or system service and to limit the harm or consequences from supply chain-related events; and

b. Select and document the…