Statewide Standards Spreadsheet_Moderate-vOct2020.xlsx

Instructions

Requirements Template

Author: 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

Author: 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

Author: 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.

Author: Control Detail:

Author: Control Detail:

Author: Control Detail:

Author: 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

Author: Control Detail:

Author: Control Detail:

Author: 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

Author: 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

Author: Control Detail:

a.Assess supply chain risks associated with systems, system components, and system services; and

Author: 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

Author: Control Detail:

Author: 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

Author: Control Detail:

Author: Control Detail:

Author: 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.

Author: Control Detail:

Author: 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

Author: Control Detail:

Author: Control Detail:

Author: 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

Author: Control Detail:

Author: 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.

Author: Control Detail:

Author: Control Detail:

Author: 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

Author: 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.

Author: Control Detail:

Author: 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

Author: 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

Author: 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

Author: Control Detail:

Author: Control Detail:

Author: Control Detail:

Author: 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.

Author: 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.

Author: Control Detail:

Author: 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.

Author: Control Detail:

Author: 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).

Author: 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.

Author: 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.

Author: 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.

Author: 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.

Author: 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.

Author: 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.

Author: 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.

Author: 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.

Author: 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.

Author: 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.

Author: 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.

Author: 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.

Author: 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.

Author: Control Detail:

Author: Control Detail:

Author: 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.

Author: 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.

Author: 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.

Author: Control Detail:

Author: 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.

Author: 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.

Author: 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 implemented supply chain safeguards in the system security plan.

Author: Control Detail:

a. Require the developer of the system, system component, or system service to follow a documented development process that:

1. Explicitly addresses security requirements;

2. Identifies the standards and tools used throughout the development life cycle;

3. Documents the specific tool options and tool configurations used in the development process; and

4. Documents, manages, and ensures the integrity of changes to the process and/or tools used in development; and

b. Review the development process, standards, tools, tool options, and tool configurations at least annually to determine if the process, standards, tools, tool options and tool configurations selected and employed comply with applicable laws, Executive Orders, directives, regulations, policies, standards, and guidelines.

Author: Control Detail:

a. Replace systems and system components when support for the system or component is no longer available from the manufacturer:

1. Software acquired from external sources must be current and supported by the developer, or appropriately hardened based on the developer’s security recommendations (CIS-2.2) (CIS-18.3); and

2. Only current and trusted third-party system components may be used for software developed internally (CIS-18.4); and

b. Provide justification and documented approval for the continued use of unsupported systems or system components that are required to satisfy mission/business needs:

1. To reduce the risk of running unsupported systems or system components to an acceptable level, compensating controls must be implemented and documented.

Author: Control Detail:

Author: Control Detail:

(Note this change in R5 to low baseline) Author: Control Detail:

For all systems

a. Implement multifactor authentication for access to non-privileged accounts; and

For systems categorized as Moderate, or higher

b. Tie multifactor authentication to an individual.

Author: Control Detail:

Author: Control Detail:

a. Configure systems to uniquely identify and authenticate end user-operated devices (e.g., workstations, laptops, voice-over-Internet Protocol (VoIP) phones, cell phones) and servers before establishing a connection to an internal network; and

b. Use only approved procedures, mechanisms, or protocols for host or device authentication. Approved mechanisms and protocols are:

1. Port level access control, following 802.1x standards, to control which devices can authenticate to the network. The authentication system shall be tied into the hardware asset inventory data to ensure only authorized devices can connect to the network (CIS-1.7);

2. Client certificates to authenticate hardware assets connecting to the organization's trusted network

(CIS-1.8);

3. Media Access Control (MAC) for device identification; and

4. Other OSCIO approved organizational authentication solutions.

Author: Control Detail:

Manage system identifiers by:

a. Receiving authorization from the documented Agency designated approving authority to assign an individual, group, role, or device identifier;

b. Selecting an identifier that identifies an individual, group, role, or device;

c. Assigning the identifier to the intended individual, group role, or device; and

d. Preventing reuse of identifiers.

Author: Control Detail:

a. Verify the identity of the individual, group, role, or device receiving a system authenticator as part of the initial authenticator distribution.

b. Establish and define unique initial authenticator content for system authenticators in agency policy (CIS- 4.2);

c. Ensure that authenticators for individuals, groups, roles, or devices have sufficient strength of mechanism for their intended use; and

d. Ensure that authenticators for shared group/role accounts are changed when membership to those accounts changes.

Author: Control Detail:

a. Enforce the following for password construction:

1. Minimum length of ten (10) characters;

2. At least one (1) numeric (e.g. zero – 9) and one (1) non-alphanumeric character (e.g. @, #, $, %, ^, &, etc.);

3. At least one (1) English uppercase letter (e.g.