RFQQ 2023HCA17 - Exhibit E.pdf

Office of the Chief Information Officer, Washington State Standard No. 141.10: Securing Information Technology Assets

Office of the Chief STANDARD NO. 141.10

Information Officer (OCIO)

Securing Information Technology Assets Purpose: Set requirements for maintaining system and network security, data integrity, and confidentiality.

Effective Date: November 13, 2017

See Also:

Policy No. 141 - Securing Information

Technology Assets

Policy No. 143 - IT Security Incident

Communications

Appendix C: IT Security Non-

Compliance/Deviation Form

Media Handling and Data Disposal Best

Practices

PURPOSE

The state has a fiduciary responsibility to protect the IT systems, applications and data entrusted to it by its citizens. Therefore, it is necessary to take appropriate measures to ensure the security of these public IT assets.

INTRODUCTION

To enable the mission of state agencies and the state enterprise, reduce business risk and cost and protect the state’s reputation, it is required that agencies adopt and implement common IT security standards. Common standards will help ensure that agencies have an effective means of protecting vital IT assets, and can securely store and share data between agencies and with citizens and business partners. Agencies may, and should, exceed these IT security standards based on their assessment of the risk and complexity of their IT environment or system implementation.

These IT security standards apply to all IT systems and applications, inside and outside the

State Government Network (SGN), whether government-owned IT systems or contractor or vendor-owned systems that process state information, and define the processes, procedures, and practices necessary for implementing an agency-specific IT security program. They include specific steps that will be taken to ensure that a secure IT environment is maintained and all agency systems provide appropriate levels of privacy, confidentiality, integrity and availability.

Responsibly protecting public IT assets is made possible through an enterprise approach to security in state government that:

http://www.ocio.wa.gov/policy/securing-information-technology-assets http://www.ocio.wa.gov/policy/securing-information-technology-assets http://www.ocio.wa.gov/policy/it-security-incident-communication http://www.ocio.wa.gov/policy/it-security-incident-communication http://www.ocio.wa.gov/policy/14110-appendix-c-it-security-non-compliancedeviation-form http://www.ocio.wa.gov/policy/14110-appendix-c-it-security-non-compliancedeviation-form http://www.ocio.wa.gov/policy/media-handling-and-data-disposal-best-practices http://www.ocio.wa.gov/policy/media-handling-and-data-disposal-best-practices http://ofm.wa.gov/ocio/policies/documents/data_disposal_best_prac.pdf

(1) Recognizes an interdependent relationship among agencies, such that strengthening security for one strengthens all and conversely, weakening one weakens all.

(2) Assumes mutual distrust until proven friendly, including relationships within government, with trading partners, and with anonymous users in a least-privilege approach to access control.

(3) Supports industry standards where applicable.

Agencies are responsible for adherence to these IT security standards to protect IT systems and applications, whether they are operated by or for an agency, and whether they operate internally on the SGN, or external to the SGN. Examples of environments external to the SGN include the Inter-Governmental Network (IGN), the Public Government Network (PGN), business partner hosted services and cloud services.

IT security planning is primarily a risk management issue. Therefore, the OCIO requires agencies to follow the IT Security policy and standards to mitigate security risks in a shared and trusted environment. Agencies will:

(1) Ensure secure interactions between and among governmental agencies take place within a shared and trusted environment.

(2) Ensure secure interactions between and among business partners, external parties, and that state agencies utilize a common authentication process, security architecture, and point of entry.

(3) Close unauthorized pathways into state networks and to the state’s data.

(4) Prevent misuse of, damage to, or loss of IT hardware and software facilities.

(5) Ensure employee accountability for protection of IT assets.

(6) Ensure and oversee compliance with these IT security standards, including the annual verification of security compliance from the agency heads to OCIO.

This document contains the following IT Security Standards:

Section 1: Agency IT Security Program Standard

Section 2 – 11: Standards for IT security functional areas

Agencies must develop, document and implement policies and procedures for the IT security program in Section 1 and the functional areas in Sections 2 through 11. Agencies may, and should, exceed these IT security standards based on the risk and complexity of the IT environment.

SCOPE

(1) The IT security policy applies to state of Washington executive branch agencies, agencies headed by separately elected officials, and institutions of higher education.

(2) These IT security standards apply to state of Washington executive branch agencies and agencies headed by separately elected officials, referred to as “agencies” throughout this document.

(3) Institutions of higher education shall develop standards that are appropriate to their respective missions and that are consistent with the intended outcomes of the OCIO to secure data, systems and infrastructure. At a minimum, higher education institutions’ security standards shall address:

Standard No. 141.10: Securing Information Technology

a. Appropriate levels of security and integrity for data exchange and business transactions.

b. Effective authentication processes, security architectures(s), and trust fabric(s).

c. Staff training.

d. Compliance, testing, and audit provisions.

Academic and research applications and infrastructure at institutions of higher education are exempt.

STANDARDS

1. Agency IT Security Program

1.1. Documentation

The agency IT Security Program documentation must:

(1) Align with the agency’s risk management strategy.

(2) Clearly identify the security objectives for agency systems.

(3) Contain policies, processes and procedures for all sections of OCIO IT security standards.

(4) Contain detail commensurate with the size, complexity, and potential business exposure based on the results of the agency's IT Risk Assessment process.

(5) Contain details of the security controls applied to agency systems.

(6) Contain details, justifications and approvals by OCIO for any deviation from the

OCIO IT security standards.

(7) Contain results, logs, and records from risk and security assessments to demonstrate that the assessments performed met the intended security objectives of the agency.

(8) Identify mechanisms for receiving, documenting, and responding to reported security issues.

Agency Security Program documentation may contain information that is exempt from public disclosure as defined in RCW 42.56.420.

1.2. IT Risk Assessment

The agency must:

(1) Define and implement a formal IT Risk Assessment process to evaluate risks resulting from the use of information systems to agency operations, systems and personnel.

(2) Conduct an IT Risk Assessment when introducing new systems. When changes are made to an existing computing environment that impacts risk, conduct an IT

Risk Assessment with a scope that is in proportion to the changes made.

(3) Identify assets that are within the scope of the agency IT Security Program and the entity that has responsibility for the production, development, maintenance, use, and security of the assets.

(4) Identify potential threats to assets identified as within scope.

(5) Identify the vulnerabilities that might be exploited by the threats.

(6) Identify the impacts that losses of confidentiality, integrity, and availability may have on assets identified as within scope.

(7) Assess the likelihood that security failures may occur based on prevailing threats and vulnerabilities.

(8) Conduct an IT Risk Assessment on Systems processing Category 3 data or higher once every three years. Please refer to Section 4 for data categories.

(9) Take into account business, legal, or regulatory requirements, and contractual security obligations.

1.2.1 Security Design Review and Risk Assessment

The agency must request a Security Design Review and Risk Assessment for maintenance and new development of systems and infrastructure projects when one or more of the following conditions exist:

(1) An agency is required to submit an investment plan to OCIO commensurate with the IT Investment Standards.

(2) An agency project or initiative requires OCIO or OCIO oversight as determined by OCIO policy and standards.

(3) An agency project or initiative impacts risk to state IT assets outside the agency.

(4) An agency project or initiative meets criteria for a Security Design Review and Risk Assessment as defined and documented by the agency IT security program.

Agencies are encouraged to consult with OCIO and CTS regarding any project to determine whether a Security Design Review and Risk Assessment is recommended.

The agency must provide the following to the state Chief Information Security

Officer at CTS for the Security Design Review and Risk Assessment:

(1) The IT Security Checklist for the system. Please refer to Section 1.5.

(2) A system architecture diagram showing security controls and information flows.

(3) Security risk assessments identified for the system and IT infrastructure.

(4) The planned security controls and how they will be implemented.

The Chief Information Security Officer at CTS must:

(1) Review the results of the agency IT Security Checklist and other documents specific to the System.

(2) Determine whether the security design complies with OCIO IT security standards.

(3) Provide design recommendations as necessary for the agency to satisfy

OCIO IT security standards.

Agencies may submit appeals regarding Security Design Review and Risk

Assessment results to the OCIO.

1.3. IT Security Assessment

IT Security Assessments must be conducted periodically to review and assess the effectiveness of existing security controls. These assessments must include testing of security controls to make sure unauthorized access attempts can be identified or stopped. Examples of periodic testing include penetration tests, vulnerability assessments and system code analysis. The agency must:

(1) Establish an IT Security Assessment framework and schedule to identify a sampling of agency systems, applications, and IT infrastructure to test.

(2) Conduct IT Security Assessments against the sample in the framework to verify security controls and identify weaknesses at least once every three years.

(3) Conduct an assessment through testing scenarios relevant to changes made when the following conditions exist:

a. A significant IT infrastructure upgrade or modification since the last IT

Security Assessment was performed. Examples of a significant infrastructure upgrade or modification include but are not limited to: the addition of a new sub-network, DMZ or security perimeter device; upgrades to firewalls, switches or routers.

b. Applications have been added or significantly modified.

(4) Correct weaknesses identified with appropriate controls.

1.4. Education and Awareness

The agency must:

(1) Ensure that personnel assigned responsibilities defined in the agency IT Security

Program are competent to perform the required tasks.

(2) Document the knowledge, skills, and abilities required for personnel performing work affecting the agency IT Security Program.

(3) Require that all employees receive annual security awareness training that includes the risks of data compromise, their role in prevention, and how to respond in the event of an incident as relevant to the individual’s job function.

(4) Ensure that personnel assigned responsibilities defined in the agency IT Security

Program must, at a minimum, receive training that addresses the OCIO Security

Policy and Standard and the agency’s security policies and procedures.

1.5. Compliance

The agency must:

(1) Ensure compliant implementation of systems and IT infrastructure funded and approved after adoption of these IT security standards.

(2) Include estimates to implement these IT security standards and resulting security controls in schedules, budgets, and funding requests for maintenance and new development of applications, infrastructure, and operations.

(3) Complete the IT Security Checklist and include costs of required security controls in budgets and schedules of new development or maintenance when:

a. Significant changes are made to the application, IT infrastructure or operations.

b. An IT Investment Plan must be prepared.

c. It is required to complete a Security Design Review and Risk Assessment

(Section 1.2.1)

d. The IT Security Checklist is required by the agency IT security program.

(4) Select and apply the appropriate security controls commensurate with the risk and complexity of the system after completing the agency IT Risk Assessment

(Section 1.2), IT Security Assessment (Section 1.3), the IT Security Checklist, and the Security Design Review and Risk Assessment (when required) to comply with the requirements in the OCIO IT security standards.

(5) Require contractor’s compliance with OCIO IT security standards relative to the services provided when:

a. The scope of work affects a state IT resource or asset.

b. The agency contracts for IT resources or services with an entity not subject to the OCIO IT security standards.

Contractor compliance may be demonstrated by mapping comparable contractor controls to these IT security standards, and by adding supplemental controls that close gaps between the two.

(6) Confirm in writing that the agency is in compliance with OCIO IT security standards. The head of each agency will provide annual verification to the OCIO by August 31 of each year or Office of Financial Management budget submittal date, whichever is later, that an agency IT Security Program has been developed and implemented according to the OCIO IT security standards. The annual security verification letter will be included in the agency IT portfolio and submitted to OCIO. The verification indicates review and acceptance of agency security policies, procedures, and practices as well as updates since the prior verification.

(7) Document instances of non-compliance with OCIO IT security standards beginning no later than August 2010 and during the funding and approval process for new initiatives referenced above in Section 1.5. For those components that do not comply, agencies complete the IT Security Non-Compliance/Deviation

Form, Appendix C. Update the form and submit annually with the annual security verification letter. The form is submitted to the state CIO for approval through the state Chief Information Security Officer at CTS. For security reasons, please submit only hardcopy IT Security Non-Compliance/Deviation Forms. Do not submit these forms via email. Agencies may submit appeals to the OCIO.

1.6. Audit

The agency must:

(1) Ensure an independent audit is performed once every three years to assess compliance with OCIO IT security standards.

(2) Ensure the audit is performed by qualified parties independent of the agency's IT organization.

(3) Submit the results of the audit to the state chief information security officer at

CTS.

(4) Maintain documentation showing the results of the audit according to applicable records retention requirements.

(5) Validate that security controls are implemented appropriately based on OCIO IT security standards, the agency security program, and applicable regulatory requirements.

(6) Identify nonconformities and related causes.

(7) Track progress to correct nonconformities.

(8) Implement the corrective action needed.

1.7. Maintenance

The agency must:

(1) Conduct an annual maintenance and review of the agency IT Security Program.

(2) Identify areas to improve the effectiveness of the agency IT Security Program.

2. Personnel Security

These Personnel Security controls are designed to reduce risks of human error, theft, fraud, or misuse of facilities. They help agencies ensure that users are aware of information security threats and are equipped to support the OCIO security policy in the course of their normal work.

Agencies must:

(1) Provide IT security orientation and supervision of employees and monitor contractors who have access to agency IT Assets.

(2) Ensure that appropriate staff conduct is achieved and maintained related to security matters.

(3) Conduct reference checks and background investigations as required by the agency

IT security program and authorized by the agency.

(4) Require employees to receive appropriate awareness training and regular updates on agency and OCIO IT Security Policies and standards as described in Section 1.4.

(5) Provide opportunities for IT Security support staff to obtain technical training.

(6) Impose appropriate sanctions for security violations.

(7) Establish processes for the timely removal of system access for employees and contractors when duties change or when separating from service.

(8) Include appropriate language in vendor contracts to require compliance with OCIO and agency security policies, standards, and requirements.

(9) Require employees and contractors to comply with these IT security standards and agency IT policies and procedures. Each user should be made clearly aware of this responsibility.

(10) Identify, document, and implement rules for the acceptable use of IT assets consistent with rules provided by the Washington State Executive Ethics Board.

3. Physical and Environmental Protection

Agencies are responsible for ensuring that adequate physical security and environmental protections are implemented to maintain the confidentiality, integrity, and availability of the agency’s computer systems. Agencies must prevent unauthorized access, damage, or compromise of IT assets. Investments in physical and environmental security must be commensurate with the risks, threats, and vulnerabilities unique to each physical site and location.

3.1. Facilities

Agencies must develop, document, and implement policies and procedures for the following:

(1) Location and layout of the facility.

(2) Physical security attributes for computer or telecommunications rooms.

(3) Design and enforcement of physical protection and guidelines for working in secure areas.

(4) Facility access control.

(5) Physical data storage and telecommunications controls.

(6) Off-site media storage.

(7) Physical security controls for mobile devices.

4. Data Security

Data security components outlined in this section are designed to reduce the risk associated with the unauthorized access, disclosure, or destruction of agency data.

4.1. Data Classification

Agencies must classify data into categories based on the sensitivity of the data.

Agency data classifications must translate to or include the following classification categories:

(1) Category 1 – Public Information

Public information is information that can be or currently is released to the public.

It does not need protection from unauthorized disclosure, but does need integrity and availability protection controls.

(2) Category 2 – Sensitive Information

Sensitive information may not be specifically protected from disclosure by law and is for official use only. Sensitive information is generally not released to the public unless specifically requested.

(3) Category 3 – Confidential Information

Confidential information is information that is specifically protected from either release or disclosure by law. This includes, but is not limited to:

a. Personal information as defined in RCW 42.56.590 and RCW 19.255.10.

b. Information about public employees as defined in RCW 42.56.250.

c. Lists of individuals for commercial purposes as defined in RCW 42.56.070

(9).

d. Information about the infrastructure and security of computer and telecommunication networks as defined in RCW 42.56.420.

(4) Category 4 – Confidential Information Requiring Special Handling

Confidential information requiring special handling is information that is specifically protected from disclosure by law and for which:

a. Especially strict handling requirements are dictated, such as by statutes, regulations, or agreements.

b. Serious consequences could arise from unauthorized disclosure, such as threats to health and safety, or legal sanctions.

4.2. Data Sharing

Agencies must ensure that sharing data with the public at large complies with the OCIO

Public Records Privacy Protection Policy and other applicable statutes or regulations.

When sharing Category 3 and above data outside the agency, an agreement must be in place unless otherwise prescribed by law. The agreement (such as a contract, a service level agreement, or a dedicated data sharing agreement) must address the following:

(1) The data that will be shared.

(2) The specific authority for sharing the data.

(3) The classification of the data shared. (4) Access methods for the shared data.

(5) Authorized users and operations permitted.

(6) Protection of the data in transport and at rest.

(7) Storage and disposal of data no longer required.

(8) Backup requirements for the data if applicable.

(9) Other applicable data handling requirements.

4.3. Secure Management and Encryption of Data

(1) Outside the SGN

The storage of Category 3 and Category 4 information outside the SGN requires agencies to ensure that encryption is selected and applied using industry standard algorithms validated by the National Institute of Standards and

Technology (NIST) Cryptographic Algorithm Validation Program. Encryption must be applied in such a way that it renders data unusable to anyone but authorized personnel, and the confidential process, encryption key or other means to decipher the information is protected from unauthorized access.

(2) New Systems and Applications Inside the SGN

Systems storing Category 3 and Category 4 information deployed within the SGN after [effective date of this revision] requires agencies to select and apply encryption using industry standard algorithms validated by the National Institute of Standards and Technology (NIST) Cryptographic Algorithm Validation

Program. Encryption must be applied in such a way that it renders data unusable to anyone but authorized personnel, and the confidential process, encryption key or other means to decipher the information is protected from unauthorized access; unless, after completing an IT Risk Assessment, other compensating controls are identified and approved by the agency CIO and are fully implemented.

4.4. Secure Data Transfer

Agencies must appropriately protect information transmitted electronically. The transmission of Category 3 and above information outside of the SGN requires encryption such that:

(1) All manipulations or transmissions of data during the exchange are secure.

(2) If intercepted during transmission the data cannot be deciphered.

(3) When necessary, confirmation is received when the intended recipient receives the data.

(4) Agencies must use industry standard algorithms, or cryptographic modules validated by the National Institute of Standards and Technology (NIST).

(5) For agencies not on the SGN, this standard applies when transmitting Category

3 and above information outside of the agency’s secure network.

5. Network Security

Agencies must ensure the secure operation of network assets through the use of appropriate layered protections commensurate with the risk and complexity of the environment.

5.1. Secure Segmentation

Agencies must:

(1) Define and implement logical boundaries to segment networks as determined by system risk and data classification.

(2) Enforce controls to protect segments and individual assets within each segment.

The methods to achieve secure segmentation include but are not limited to those detailed in Sections 5.1.1- 5.1.3.

5.1.1 Network Devices

Agencies must:

(1) Securely segment Internet-available systems from internal networks.

(2) Disable unnecessary functionality such as scripts, drivers, features, subsystems, file systems and services.

(3) Harden devices based on industry best practice such as NIST, SANS, and vendor configuration standards.

(4) Change default or initial passwords upon installation.

(5) Display banner text conveying appropriate use at system entry points and at access points where initial user logon occurs.

(6) Disable remote communications where no business need exists.

(7) Standardize and document the device configurations deployed.

(8) Document deviations from device configuration standards along with the approval.

(9) Mask internal addresses from exposure on the Internet as necessitated by the risk and complexity of the system.

(10) Implement controls to prevent unauthorized computer connections and information flows through methods such as:

a. Authentication of routing protocols.

b. Ingress filtering at network edge locations.

c. Internal route filtering.

d. Routing protocols are enabled only on necessary interfaces.

e. Restrict routing updates on access ports.

f. Secure or disable physical network connections in public areas.

5.1.2 Firewalls

Agencies must:

(1) Securely segment DMZ interfaces, where utilized, from interfaces connected directly to the internal network.

(2) Configure network firewalls protecting production systems to:

a. Allow system administration only through secure encrypted protocols.

b. Prevent access by unauthorized source IP addresses or subnets.

c. Block ingress of internal addresses from an external interface into the

DMZ or internal interface.

d. Block services, protocols, and ports not specifically allowed.

e. Allow only necessary egress communications from the internal network to the DMZ, Internet, wireless networks and SGN.

f. Allow only necessary ingress communications to the internal network from the DMZ, Internet, wireless networks and SGN.

g. Maintain comprehensive audit trails.

h. Fail in a closed state if failure occurs.

i. Operate boundary/perimeter firewalls on a platform specifically dedicated to firewalls.

(3) Document services, ports and protocols allowed through firewalls, with supporting business purposes, in the agency IT security program.

(4) Review configurations annually.

5.1.3 Device Administration

Agencies must:

(1) Use authentication processes and mechanisms commensurate with the level of risk associated with the network segment or device.

(2) Encrypt non-console administrative access using technologies such as

Secure Shell (SSH), Virtual Private Network (VPN), or Secure Sockets

Layer (SSL)/Transport Security Layer Security (TLS) for Web-based management and other non-console administrative access.

5.2. Restricted Services

Agencies must implement controls to prohibit the use of the following service and application types listed in this section unless specifically authorized. The use of restricted services must be documented in the agency IT security program and approved by agency management. Restricted services include but are not limited to:

(1) Dial-in and dial-out workstation modems.

(2) Peer-to-peer sharing applications.

(3) Tunneling software designed to bypass firewalls and security controls.

(4) Auto-launching applications such as U3 that execute from a mobile device and do not require installation on a host system.

(5) Publicly managed e-mail, chat services, and video.

(6) Products that provide remote control of IT assets.

(7) Information systems audit tools.

5.3. External Connections

Agencies with devices connected to the SGN must:

(1) Prohibit direct public access between external networks and internal systems.

(2) Connect agency networks to the SGN through a CTS-managed security layer.

(3) Ensure connections between internal networks on the SGN and external networks are made through a CTS-managed security layer. The CTS-managed security layer includes, but is not limited to, firewalls, intrusion detection systems, proxy servers, security gateways, VPN and other security and monitoring systems as deemed necessary by CTS to protect the integrity of the SGN.

5.4. Wireless Connections

Agencies are responsible for the secure deployment of wireless networks. Agencies must ensure:

(1) The agency IT Security Program addresses the use of wireless technologies including but not limited to:

a. 802.11

b. Bluetooth

(2) Wireless devices that extend their Local Area Networks (LANs):

a. Securely segment wireless access point connections from the agency network and the SGN.

b. Use WPA or its successor for authentication and encryption. Use WPA2

Enterprise on all new equipment purchased and existing equipment that supports the protocol.

c. Change wireless vendor defaults including but not limited to pre-shared keys and passwords.

d. Disable Simple Network Management Protocol (SNMP) unless there is a clear business need. If enabled, change the vendor defaults.

e. Follow wireless access security practices developed within the agency.

f. Continuously monitor for rogue wireless devices.

(3) Wireless devices that do not extend the agency’s local area network or connect to the SGN:

a. Securely segment wireless access point connections from the Internet.

b. Use authentication and encryption appropriate for the environment.

c. Change wireless vendor defaults including but not limited to pre-shared keys and passwords.

d. Disable Simple Network Management Protocol (SNMP) unless there is a clear business need. If enabled, change the vendor defaults.

e. Follow wireless access security practices developed within the agency.

f. Monitor for rouge wireless devices as defined in the agency security program.

(4) Open or public access wireless environments do not share assets or traverse infrastructure components that connect to the agency network or SGN unless wireless traffic is securely segmented, encapsulated or tunneled over shared infrastructure.

If wireless networks are prohibited, the agency IT Security Program documentation must define how this is periodically verified and enforced.

5.5. Security Patch Management

Agencies must develop and document in the agency IT Security Program a patch management process commensurate with the risk and complexity of the IT environment that at a minimum includes:

(1) Identification of the responsibilities required for patch management.

(2) Identification of the authorized software and information systems deployed in the production environment.

(3) Timely notification of patch availability.

(4) A method of categorizing the criticality of patches in route or on delivery.

(5) Testing procedures, when required, before deployment into production environments.

(6) Time-specific criteria for deploying patches as soon as reasonably possible after notification, including criteria for zero-day patches.

(7) Regular verification that available patches are managed according to the agency patch management process.

(8) A requirement for current patches on agency or non-agency remotely attached devices.

(9) A requirement for current patches on agency or non-agency devices attached to agency networks, whether on agency local area networks or wireless networks.

(10) Restrict access from devices that do not conform to the agency patch management policy.

5.6. System Vulnerabilities

Agencies must:

(1) Establish a process to identify newly discovered security vulnerabilities such as subscribing to alert services freely available on the Internet.

(2) Use processes that manage the installation and modification of system configuration settings.

(3) Harden systems before deployment using hardening standards that meet or exceed current best practices and manufacturer recommendations at the time of system deployment and throughout the lifecycle.

5.7. Protection from Malicious Software

Agencies must:

(1) Use anti-malware protection.

(2) Address malware prevention, detection, and removal.

(3) Keep malware protection current when connecting devices to the agency network or the SGN.

(4) Ensure that file transfers, e-mail, and Web browser-based traffic are examined for known viruses.

(5) Implement detection, prevention, and recovery controls to protect against malicious code.

(6) Integrate malicious software detection reporting with the Washington Computer

Incident Response Center (WACIRC) incident reporting processes.

5.8. Mobile Computing

Examples of mobile devices include laptops, smart phones, Personal Digital Assistants

(PDAs), accessible equipment, and portable data storage devices such as tape drives, zip drives, removable hard drives, and USB data storage devices.

Agencies must implement policies and procedures controlling the use of Category 3 and above data on mobile devices. At a minimum, agencies must:

(1) Approve and document the use of category 3 data or above on mobile devices.

(2) Encrypt Category 3 data or above on mobile devices using industry standard algorithms or cryptographic modules validated by the National Institute of

Standards and Technology (NIST).

(3) Implement policies and procedures that address the use of portable data storage devices.

6. Access Security

6.1. Access Management

6.1.1 Policies

To ensure proper access controls that conform to the principle of least privilege agencies must:

(1) Implement policies and procedures that address access security controls for mainframe, client/server, wireless LANs, and stand-alone workstation-based systems that are consistent with the agency's classification of the data processed.

(2) Restrict access to data, application, and system functions by users and support personnel in accordance with the agency defined access control policy.

(3) Authentication and authorization controls must be appropriately robust for the risk of the application or systems to prevent unauthorized access to IT assets.

(4) Manage and group systems, data, and users into security domains and establish appropriate access requirements within and between each security domain.

(5) Implement appropriate technological controls to meet access requirements consistently.

(6) Restrict the use of programs or utilities capable of overriding system and application controls.

(7) Implement policies and procedures for identity proofing individuals.

6.1.2 Accounts

To ensure appropriate management of user accounts on system components agencies must:

(1) Establish a formal procedure for issuance, management and maintenance of UserIDs and passwords.

(2) Establish formal user registration and de-registration procedures for granting and revoking access to information systems and services.

(3) Identify users with a unique identifier, for their individual use only, before allowing them to access components, systems, networks, or data.

(4) Ensure that accounts are assigned access only to the services that they have been specifically authorized to use.

(5) Ensure the access rights of users to information and information processing facilities are removed upon suspected compromise, termination of their employment or contract, or are adjusted upon change in status.

(6) Control the addition, deletion, and modification of UserIDs, credentials, and other identifier objects.

(7) Implement mechanisms to restrict and control the use of privileges.

(8) Verify user identity before performing password resets.

(9) Set first-time passwords to a unique value per user that must be changed immediately after first use.

(10) Use time of day, and day of week restrictions as appropriate.

(11) Enable accounts used by vendors for remote maintenance only during the time needed.

(12) Prohibit the use of group, shared, or generic UserIDs/passwords.

(13) Establish a maximum of five incorrect login attempts and lock the account for a minimum of 15 minutes or until reset by an administrator.

6.1.3 Sessions

To ensure appropriate management of sessions on system components agencies must:

(1) Establish procedures to shut down or reauthorize inactive sessions after a defined and reasonable period of inactivity.

(2) Restrict user access to shared systems, especially those extending across the agency’s boundaries, in accordance with the access control policy and requirements of the business applications.

(3) Ensure that access to operating systems is controlled by a secure log-on procedure.

6.1.4 Auditing

To ensure system controls are effectively enforcing access policies agencies must:

(1) Periodically review user access rights based on the risk to the data, application, or system using a formal process.

(2) Implement mechanisms to monitor the use of privileges.

6.2. Password Requirements

Agencies must ensure:

(1) Administration of password rules must be technically or procedurally enforced.

(2) UserID/password combinations are Category 3 data and must be protected.

(3) Individuals are prohibited from submitting a new password that is the same as any of the last four passwords used by the individual.

(4) Passwords used for External Authentication Types outlined under section 6.3.1 must:

a. Be a minimum of 10 characters long and contain at least three of the following character classes: uppercase letters, lowercase letters, numerals, special characters.

b. Not contain the user’s name, UserID or any form of their full name.

c. Not consist of a single complete dictionary word, but can include a passphrase.

d. Be significantly different from the previous four passwords. Passwords that increment (Password1, Password2, Password3 ...) are not considered significantly different.

(5) Passwords used for Internal Authentication Types outlined under section 6.3.2 must:

a. Be a minimum of 8 characters long and contain at least three of the following character classes: uppercase letters, lowercase letters, numerals, special characters.

b. Not contain the user’s name, UserID or any form of their full name.

c. Not consist of a single complete dictionary word, but can include a passphrase.

d. Be significantly different from the previous four passwords. Passwords that increment (Password1, Password2, Password3 ...) are not considered significantly different.

(6) PIN codes used in multi-factor authentication schemes must:

a. Be a minimum of five digits in length.

b. Not be comprised of all the same digit. PINs consisting of 11111, 22222 are not acceptable.

c. Not contain more than a three consecutive digit run. PINs consisting of 12347, 98761 are not acceptable.

(7) Pass codes used to secure mobile devices must:

a. Be a minimum of six alpha numeric characters.

b. Contain at least three unique character classes. Pass codes consisting of

11111a, aaaaa4, are not acceptable.

c. Not contain more than a three consecutive character run. Pass codes consisting of 12345a, abcde1 are not acceptable.

d. Render the device unusable after 10 failed login attempts.

6.3. Authentication

Authentication is used to validate the identity of users performing functions on systems.

Selecting the appropriate authentication method is based on risks to data.

6.3.1 External Authentication

Six methods of authentication are defined for users accessing agency owned systems from resources outside the SGN.

6.3.1.1 Type 1 - External

Access to category 1 data, if authenticated, requires authentication via the SecureAccess® Washington infrastructure (OCIO Identity

Management User Authentication Standards 7/10/2008) with the following controls:

(1) Requires UserID and hardened passwords as defined in Section

6.2.

(2) Password expiration period not to exceed 24 months.

(3) Successful authentication requires that the individual prove through a secure authentication protocol (in other words, encrypted) that the individual controls the password.

(4) Category 1 data may be accessed using type 2 or 3 authentication.

6.3.1.2 Type 2 - External

Access to category 2 data or a single category 3 record belonging to the individual requires authentication via the SecureAccess® Washington infrastructure (OCIO Identity Management User Authentication

Standards 7/10/2008) with the following controls:

(1) Requires UserID and hardened passwords as defined in Section

6.2.

(2) Password expiration period not to exceed 24 months.

(3) Successful authentication requires that the individual prove through a secure authentication protocol (in other words, encrypted) that the individual controls the password.

(4) Category 2 data may be accessed using type 3 authentication.

6.3.1.3 Type 3 - External

Access to category 3 data or a single category 4 record belonging to the individual requires multi-factor authentication via the SecureAccess®

Washington infrastructure (IOCIO Identity Management User

Authentication Standards 7/10/2008) with the following controls:

(1) Requires multi-factor authentication supported by SecureAccess®

Washington.

(2) Passwords must meet the criteria outlined in Section 6.2.

(3) Password expiration period not to exceed 13 months.

(4) Requires that the individual prove through a secure authentication protocol (in other words, encrypted) that the individual controls the password or token.

(5) Category 3 data may be accessed using type 4 authentication.

6.3.1.4 Type 4 - External

Access to category 4 information requires multi-factor authentication via the SecureAccess® Washington or Transact™ Washington infrastructure (OCIO Identity Management User Authentication

Standards 7/10/2008) with the following controls:

(1) Requires multi-factor authentication using hardware or software tokens or digital certificates.

(2) Requires that the individual prove through a secure, encrypted authentication protocol that the individual controls the token by first unlocking the token with a password, PIN or biometric in a secure authentication protocol to establish two factors of authentication using a hardware or software token or digital certificate.

6.3.1.5 Type 5 - External

Employee and contractor access to agency resources or the SGN via common remote access methods outlined in Section 6.4 requires two-factor authentication with the following controls:

(1) Requires that the individual prove through a secure, encrypted authentication protocol that the individual controls a hardware or software token by first unlocking the token with a password, PIN or biometric in a secure authentication protocol to establish two factors of authentication.

6.3.1.6 Type 6 - External

Authenticated access that does not meet the criteria outlined in the

OCIO Identity Management User Authentication Standards, 7/10/2008, requires, at a minimum, the use of the same controls specified in

Authentication Types 1,2 and 3 above, as determined by the category of data.

6.3.2 Internal Authentication

Four methods of authentication are defined for users accessing agency owned systems from resources inside the agency network, SGN or already authenticated via common remote access methods outlined in Section 6.4.

6.3.2.1 Type 7 - Internal

Access to category 4 data and below requires authentication via the

Enterprise Active Directory infrastructure (OCIO Identity Management

User Authentication Standards, 7/10/2008) with the following controls:

(1) Requires UserID and hardened passwords as defined in Section

6.2.

(2) Password expiration period not to exceed 120 days.

6.3.2.2 Type 8 – Internal

Access to system administration functions requires the following controls:

(1) Requires a discrete account used only for interactive system administration functions.

(2) Where passwords are employed as an authentication factor:

a. Requires a hardened password as defined in Section 6.2 with an extended password length of 16 characters.

b. Password expiration period not to exceed 60 days.

6.3.2.3 Type 9 – Internal

Accounts used for system service, daemon or application execution

(service accounts) require documentation in the agency security program and the following controls:

(1) Requires a discrete account used only for the defined privileged functions, and never used by an individual.

(2) Requires a hardened password as defined in Section 6.2 with an extended password length of 20 characters.

(3) Password expiration requirements must be documented in the agency security program.

(4) The principle of least privilege must be employed when determining access requirements for the account.

6.3.2.4 Type 10 – Internal

Authenticated access that does not meet the criteria outlined in the

OCIO Identity Management User Authentication Standards, 7/10/2008, requires the following minimum controls:

(1) Requires a hardened password as defined in Section 6.2 or stronger authentication.

(2) Password expiration not to exceed 120 days.

(3) Additional controls documented in the agency IT Security Program.

6.4 Remote Access

Agencies must:

(1) Implement policies and procedures for remote access that mitigate the threat or risk posed by users or devices authorized to connect remotely to the agency network or the SGN including but not limited to:

a. Monitoring practices for remote access sessions.

b. Requirements for remote access devices.

c. Remote access session controls that conform to the principle of least privilege.

(2) Ensure mitigation is not susceptible to end-user modification.

(3) Prohibit the use of dial-up unless there is no other way to satisfy a business need.

Dial-up access, if used, must be approved by management and documented in the Agency IT Security Program.

(4) Use industry standard protocols for remote access solutions.

(5) Use the state’s common remote access services such as IPSec or SSL VPN when remotely accessing agency resources and services on the SGN.

(6) Ensure remote access solutions prompt for re-authentication or perform automated session termination after 30 minutes of inactivity.

(7) Ensure that agency operated remote access solutions, not connected to the agency network or the SGN, use equivalent technologies that require multi-factor authentication and include documentation of the configuration in the agency IT

Security Program.

7. Application Security

7.1 Planning and Analysis

Agencies must specify security controls when developing business requirements for new or enhanced information systems including but not limited to:

(1) Ensure applications provide for data input validation to ensure the data is correct and appropriate and cannot be used to compromise security of the application, IT infrastructure, or data.

(2) Procedures are in place to manage the installation of software on operational systems including but not limited to servers and workstations.

(3) Access to program source code is restricted to only those individuals whose job requires such access.

(4) Include specific requirements in contracts for outsourced software development to protect the integrity and confidentiality of application source code.

(5) Implementation of changes will be managed by the use of formal change management procedures.

(6) Appropriate access and security controls; audit trails; and logs for data entry and data processing.

(7) Requirements for appropriate data protection.

7.2 Application Development

Agencies must develop software applications based on industry best practices and include information security throughout the software development life cycle, including the following:

(1) Separate development, test, and production environments.

(2) Implement separation of duties or other security controls between development, test and production environments. The controls must reduce the risk of unauthorized activity or changes to production systems or data including but not limited to the data accessible by a single individual.

(3) Production data used for development testing must not compromise privacy or confidentiality. Prohibit the use of Category 3 data or higher in development environments unless specifically authorized by the IT security program.

Production data in any environment must meet or exceed the level of protection required by its data classification.

(4) Removal of test data and accounts before production systems become live.

(5) Removal of custom application accounts, usernames, and passwords from production environments before applications become active or are released to customers.

(6) Review of custom code prior to release to production or customers to identify potential coding vulnerabilities as described in Section 7.4 Vulnerability

Prevention.

(7) Appropriate placement of data and applications in the IT infrastructure based on the risk and complexity of the system.

(8) Use of appropriate authentication levels.

7.3 Application Maintenance

Agencies must:

(1) Review and test system changes to ensure there are no adverse impacts on agency operations or security.

(2) Obtain timely information about technical vulnerabilities of information systems being used, evaluate the agency’s exposure to such vulnerabilities, and take appropriate measures to address the associated risk.

7.4 Vulnerability Prevention

Agencies must prevent common coding vulnerabilities in software development processes. Agencies must:

(1) Develop software and applications based on secure coding guidelines. An example is the Open Web Application Security Project guidelines. See www.owasp.org – “The Ten Most Critical Web Application Security Vulnerabilities” which include:

a. Un-validated input.

b. Weak or broken access control such as malicious use of UserIDs.

c. Broken authentication/session management such as use of account credentials and session cookies.

d. Cross-site scripting (XSS) attacks.

e. Buffer overflows.

f. Injection flaws such as SQL injection.

g. Improper error handling that creates other conditions, divulges system architecture or configuration information.

h. Insecure storage.

i. Denial of service.

j. Insecure configuration management.

(2) Review code to detect and mitigate code vulnerabilities that may have security implications when significant changes have been made to the application.

7.5 Application Service Providers

Applications hosted by an Applications Service Provider or other third party outside of the shared, trusted environment must comply with:

(1) The OCIO IT Security Policy and Standard as described in Section 1.5.

(2) Agency security standards and procedures.

The operation of such applications must not jeopardize the enterprise security environment.

8. Operations Management

8.1 Change Management

Agencies must implement an effective change management process that:

(1) Ensures that duties and areas of responsibility are…