30DOE-S1482 Identity Access Management - Final~1.docx

STATE OF NEVADA

DEPARTMENT OF ADMINISTRATION

Purchasing Division 515 East Musser Street, Suite 300 │ Carson City, NV 89701 Phone: 775-684-0170 │ Fax: 775-684-0188

Request for Proposal: 30DOE-S1482

For

IDENTITY ACCESS MANAGEMENT (IAM)

Release Date: 2/24/2021

Deadline for Submission and Opening Date and Time: 4/06/2021 @ 2:00 PM

Refer to Section 9, RFP Timeline for the complete RFP schedule

For additional information, please contact:

Heather Moon, Purchasing Officer II

State of Nevada, Purchasing Division

515 E. Musser Street, Suite 300

Carson City, NV 89701

Phone: 775-684-0179

Email address: hmoon@admin.nv.gov

Refer to Section 11 for instructions on submitting proposals

VENDOR INFORMATION SHEET FOR RFP 30DOE-S1482

Vendor Shall:

A) Provide all requested information in the space provided next to each numbered question. The information provided in Sections V1 through V3 shall be used for development of the contract;

B) Type or print responses; and

C) Include this Vendor Information Sheet in Section III of the Technical Proposal.

Street Address:

City, State, Zip Code:

Telephone:

Fax:

Toll Free:

including address if different than above

Name:

Title:

Address:

Email Address:

Telephone Number:

Fax:

Name:

Title:

TABLE OF CONTENTS

Prospective vendors are advised to review Nevada’s ethical standards requirements, including but not limited to NRS 281A, NRS 333.800, and NAC 333.155.

All applicable Nevada Revised Statutes (NRS) and Nevada Administrative Code (NAC) documentation can be found at: www.leg.state.nv.us.

PROJECT OVERVIEW

The State of Nevada Purchasing Division, on behalf of the Nevada Department of Education (NDE) is issuing this Request for Proposal (RFP) to procure, develop/customize and implement an Identity and Access Management (IAM) system.

Identity Management includes the creation, management and removal (deletion) of a digital identity. Access Management includes the authorization of access to only the data an entity needs to have access to in order to perform required duties efficiently and effectively. This section discusses the requirements of secure Identity and Access Management, and the tools in use to provide IAM security in the cloud.

Single Sign-On (SSO) is the functionality within Access Management where the user is authenticated once and the credentials for the session are trusted across different applications within a security domain. This is typically done within one security or risk domain. SSO is a critical requirement within organizations that operate all applications within a specific cloud infrastructure.

GOALS AND OBJECTIVES

The Nevada Department of Education (NDE) is in the process of upgrading its data management environment, starting with updating/replacing its Identity and Access Management (IAM) system. This Request for Proposal (RFP) is to understand the Security as a Service (SecaaS) IAM options which meet the NDE’s needs and requirements. The NDE will be on the AZURE cloud and would like to hear from security experts about how best to meet NDE’s needs. The NDE requirements include both required elements and those that might be thought of as nice to haves, both are defined below along with an explanation of the current configuration and goals of the project.

The primary objective is to replace the existing Forms Based Authentication security access model with a new Identity and Access Management (IAM) system. Responses to this RFP will be used to identify current best practices and available solutions and will assist in establishing the criteria for replacing the current FBA system.

The RFP will be evaluated by a committee formed from members of the respective governance boards. The NDE intends to collaborate with current system vendors, stakeholders and partner agencies in determining the best solution to improve interoperability and security among systems.

The IAM system will need to integrate with Infinite Campus (State SIS), existing SharePoint portal (Bighorn), our Educator Credentialing system (OPAL) and planned needs and systems, offering a simpler and integrated security solution. The solution will provide seamless access to these systems with Single-Sign-On (SSO) using a single user ID and password issued by any of the three systems. The system will also allow for auto provisioning of accounts, new system linkages, dual authentication and user self-service. System will comply with all existing State and Federal security and data privacy requirements. The Department will work in collaboration with the Nevada Department of Enterprise Information Technology (EITS) to ensure systems meet or exceed State information security standards and can be enhanced to include authentication into other State Department data systems.

Completion of this objective will allow the Department to provide data to the classroom and to the teacher and student/parent level through the use of new data visualization tools and user portals. The solution will increase accessibility of data while improving security and ensuring a high level of data privacy.

BACKGROUND

PROJECT

NDE has an access management system that was built in 2005 based on an open-source product called Forms Based Authentication (FBA). FBA is an access list-based system that uses Microsoft SharePoint as a platform and is dependent on SharePoint and MSSQL as an application layer and a data source. NDE highly customized the FBA product in 2005 to allow school-level access into K-12 longitudinal data available in our proprietary PK-12 Operational Data Store (ODS) called SAIN (Student Accountability Information Network).

The major weakness of the existing FBA solution is its proprietary nature and inability to connect with other security and access management solutions or pass credentials between systems. An example of this is the Nevada Pre-K to Workforce Reporting (NPWR) system that connects data between NDE, Nevada System of Higher Education (NSHE), and the Department of Employment, Training and Rehabilitation (DETR) but much of that data is extracted and exchanged manually through secure file transfers or batch processes that transform data, adding to administrative overhead and margin of error. Security risks increase as data now lives in multiple places and different security systems. NDE would like to connect NPWR to our existing ODS and use a standard API or Web Service to call data directly from our ODS to the NPWR system but FBA and our proprietary ODS prohibit it. The NPWR system also has a research engine that allows external clients to log-in and request data. The system has a complex workflow that requires periodic electronic approvals. If we could allow secured access to the source data in NPWR, the research engine could be used to alleviate many of the internal data requests we get at the department as well as data we provide to other agencies. However, FBA would prevent us from allowing student-level access because the most restrictive we can get with FBA is the school level. We could not limit access to specific students, teachers or classrooms, preventing us from making student-level data available.

The implementation of a statewide Student Information System (SIS), Infinite Campus (IC) in 2015 brought with it more access challenges. As an example, Nevada which has 34 independent charter schools that operate under a State Public Charter School Authority (SPCSA) also get reported as a single District for accountability. The new IAM solution would need to support a multi-hierarchy organizational structure, and also support multi-tenant access (i.e. user belonging to multiple organizations/roles.

The current system provides the ability to report information related to the achievement of pupils, student growth over time, demographic traits and trends, school accountability and performance, attendance, and graduation rate, as well as teacher data such as work assignments, course roster, and contact information. Going forward, the NDE would like to provide individual data back to students and/or teachers, with self-service abilities (registration, authorization, password management, etc.).

The expansion and enhancement of the Nevada SLDS is a priority in order to more effectively use data to inform short-term and long-term strategic planning for education. The current FBA security solution is antiquated, poses a high risk of failure and is limiting the ability of the Department to provide additional tools to the classroom or student/parent level. The NDE must expand and enhance its internal systems to allow for increased transparency and equitable access to educational data.

In addition to the data from the Department of Education, the Department also plans on expanding upon its P20W SLDS, NPWR. The State envisions the expansion of the NPWR system to include additional agency data from the Department of Health and Human Services, Department of Motor Vehicles, Department of Corrections and any other agency that could provide insightful data regarding education or educational outcomes. The security/IAM solution would need to be able to extend to include access and authorization by these other potential data partners.

Nevada has a federated P20W SLDS which allows each participating agency to retain their data in house. A P20W Governance Committee was created to support the work of NPWR and govern how data was going to be exposed and reported. The Committee was originally composed of members from each partner agency, Education, Higher Education and Workforce. The Committee was then formalized by Executive Order in 2013 providing support from the Governor’s Office. In 2017 legislation was passed to form the Governor’s Office of Workforce Innovation (OWINN). The fiscal responsibility for the NPWR system was moved to the OWINN office and the operations of the P20W Committee were solidified in law. The OWINN office is now legally required to form the P20W Committee from members from each participating agency and continue to govern P20W data. The P20W Committee actively supports this grant application.

AGENCY

The Nevada Department of Education (NDE) is a state educational agency responsible for overseeing public instruction across the state. NDE has approximately 180 staff members and is divided into 4 divisions (Superintendent’s Office, Business and Support Services, Educator Effectiveness, and Family Engagement and Student Achievement). There are 15 departments within the 4 divisions with offices in Carson City and in Las Vegas.

Nevada has 17 county school districts with nearly 425,000 students and one local educational agency dedicated to serving 43 state sponsored charter schools and approximately 48,000 students. The State has approximately 650 schools and over 23,000 classroom teachers.

CONCURRENT IMPACTS/PROJECTS

The NDE received a federal grant in March of 2020 to upgrade existing infrastructure that supports the State’s Longitudinal Data System (SLDS). The current SLDS is made up of many components that allow for the collection, warehousing and reporting of student and school information. Nevada has a statewide student information system (SIS) that is in place in all 17 Districts and Charter Schools. There are 60 local instances of Campus that synchronize data in near real-time to one State Edition of Infinite Campus. NDE Collects the data from the SIS and populates an Operational Data Store that is then used for various applications and reporting tools to satisfy State and Federal reporting requirements. In addition to the ODS, the NDE also has developed a Student Accountability Information Network (SAIN) comprised of several custom applications and a MS SharePoint portal used for collaboration with the LEAs. The SAIN SharePoint portal is called Bighorn, named after the Nevada state animal, the Desert Bighorn Sheep (Ovis canadensis nelsoni). Bighorn was developed in 2006 and used an opensource security system Forms Based Authentication (FBA). The Bighorn portal has been upgraded several times to advance through iterations of SharePoint. Bighorn currently operates on SharePoint 2016 in an on-prem deployment.

Nevada also has a statewide student information system, Infinite Campus, deployed in each of our school districts and charter schools. This state edition is maintained by the Department and is used to collect all required student data from each of our LEAs

The federal grant project has three components. First, to replace the existing FBA security system used for the Bighorn Portal with a more robust and granular security access model and to provide a new Identity and Access Management (IAM) and Single-Sign-On (SSO) experience for the major systems in use in the Department. Second, to replace or add a standards based ODS to replace or compliment the current proprietary ODS in use today. Third, to create an automated end-to-end federal reporting system using the statewide SIS, a standards based ODS and a new reporting tool developed by the US Department of Education called Generate. This RFP is to satisfy the first objective of the grant. However, the other grant objectives are largely dependent on the IAM system.

In addition to the grant project, the recent pandemic has forced many students, teachers and NDE staff to telecommute. The fact that the majority of NDE staff is working from home requires a more automated way to assign and manage identities and access to systems.

CURRENT COMPUTING ENVIRONMENT

In addition to the SLDS and SAIN systems mentioned above, the NDE has recently migrated to MS Office 365 and migrated our Exchange server to the O365 environment as well. Nevada has a State Department of Enterprise Information Technology (EITS) that was previously responsible for providing Exchange email services to all agencies. EITS entered into a statewide contract with Microsoft to provide O365 services to all Departments and migrate all Exchange services to O365. Since EITS used to provide only Exchange services, most State agencies already had their own Microsoft domains. The NDE was no different and operates its own set of Microsoft domains and Active Directories.

The NDE has also developed several custom applications tailored to the business of the Department. The Licensure office within NDE developed an Online Professional Accreditation and Licensure system (OPAL) for the application and licensure processes for educators to become licensed, track their qualifications and allow for self-service to update their credentials and renew their licenses. This application is a .net type web application with its own security module.

The NDE has also developed several .net application that interface with SharePoint to collect, validate and report information that originates outside SAIN and OPAL or that is used to report information to the public. The Nevada Accountability Portal is one such application. The Accountability Portal is made up of two primary parts, the Nevada Report Card and the Nevada School Performance Framework (NSPF). The Report Card is a web application that is used to report information related to Nevada schools. The Report Card contains aggregate information about school populations, demographics, teachers, technology and special populations. The NSPF is a school rating system that uses data from the SAIN system as well as some external data collected through the Bighorn Portal to assign a star rating to schools. The Report Card and the NSPF are critical parts of the Every School Succeeds Act (ESSA) that fulfill the Federal reporting requirements of ESSA.

PROJECT SOFTWARE

NDE is currently using Windows 10 and all users have Office 365. NDE employees are clients in the Departments Active Directory Domain. Web access is typically achieved via the latest versions of Edge or Google Chrome. Development tools include MSSQL Tools, Visual Studio, Teams Foundation Server and Telerik Tools for SharePoint.

DEVELOPMENT SOFTWARE

All proposed software used in the design, development, testing and implementation of the deliverables outlined in this RFP shall be approved by the State.

If the application software is not public domain, the awarded vendor shall provide a licensing strategy.

STATE RESOURCES

The following paragraphs describe the resources the State has committed to this project.

Project Sponsor

The Nevada Department of Education is the project sponsor. All project activities shall be conducted under the authority of the Nevada Department of Education.

Project Manager

A Project Manager has been appointed to coordinate the activities of all individuals and organizations involved in the project. The Project Manager shall provide on-going daily direction and oversight to the State project staff and the contractor and report progress and problems to the Project Manager. The Project Manager shall coordinate all organizations involved in the project and ensure resource requirements are identified and addressed. The Project Manager sets priorities when choices of alternatives are required.

Quality Assurance Monitor

A Quality Assurance (QA) monitor may be utilized and shall act as technical assistant to the State. The QA monitor shall report to the State Project Manager. Major functions shall include, but not be limited to the following.

Review of project tasks;

Validation of results;

Provide recommendations, as required;

Review of deliverables; and

Project plan monitoring.

SYSTEM REQUIREMENTS

VENDOR RESPONSE TO SYSTEM REQUIREMENTS

Vendors shall explain in sufficient detail how the vendor shall satisfy the Nevada Department of Education’s project requirements described below. If subcontractors shall be used for any of the tasks, vendors shall indicate what tasks and the percentage of time subcontractor(s) shall spend on those tasks.

COMPUTING PLATFORM

Microsoft tool set, Azure or Amazon Cloud Services, State provided LAN WAN infrastructure. Solution should preferably be cloud based.

TECHNICAL REQUIREMENTS

Business Application Requirements

The solution shall be browser-based and shall be accessed via the Internet and can be executed on standard PCs and other devices, whether owned/managed by the State of Nevada or not. The solution user interface must:

Be based on a standards-based browser environment (e.g. HTML5) or widely used Rich Internet Application (RIA) container within the browser.

The solution software code shall be maintained solely by the awarded vendor.

The solution’s pricing model is well-defined (e.g., by subscription) and ensures that sufficient subscriptions to cover all internal and external users as needed.

Any limitations to the usage of the solution (e.g., limits on the number of users, connections to systems, trainings, etc) must be disclosed.

The solution must follow Federal and State security guidelines.

The solution must meet or exceed industry quality standards. Provide product ratings, customer review scores, industry reviews, or similar data to establish proficiency in this area.

Cloud Solution Requirements

The solution must use a software as a service (SaaS), platform as a service (PaaS), infrastructure as a service (IaaS) or other similar products hosted in a third-party cloud.

The physical location of the hosting data center(s) is known and shall be contractually identified.

The hosted data/solution must be contractually identified to reside only in the United States. Any proposal that does not meet this requirement will be deemed non-responsive.

If the solution is hosted by additional third-party providers/subcontractors other than the primary, contractual cloud vendor, the third-party provider must adhere to the terms of the primary contract for security, backups, recovery, performance, etc.

All the cloud providers (i.e., primary vendor, subcontractors, related third parties, etc.) supporting the solution must give advanced notice if they discontinue or change the circumstances related to the cloud hosting agreement.

The awarded vendor and state shall agree to identify cloud service levels to cover uptime and availability; planned downtime; service response times; simultaneous users; problem response and resolution times; data security; etc.

Suspension of service, withholding of services, and other similar cloud hosting agreement clauses shall be mitigated for the State.

The termination agreement and exit strategy shall define a reasonable timeline for the State to obtain its data when the agreement is discontinued.

Training for the cloud product shall be provided by the awarded vendor.

The State must contractually secure ownership of the data that shall reside in the cloud.

The cloud solution must include all cloud platform environment certifications required by law or State information security policy, standards and procedures, including State Security Standard S5.06.01, Cloud Hosting.

End-User Training and Acceptance Requirements

The solution shall include end-user training.

End-user training, materials, courses, schedule, facilities and data content development shall be provided by the awarded vendor.

The solution shall include end-user acceptance testing.

The User Acceptance Test Plan (UAT) shall be developed and executed as a joint effort between the State and the awarded vendor.

The State and the awarded vendor shall work together to identify between 25 and 100 system artifacts including screens, forms, workflows, reports and other end-user items to be tested.

The State and the awarded vendor shall work together to identify between 25 and 100 test cases and scenarios to be produced and tested.

Data Conversion Requirements

The solution shall include a data conversion effort. The State expects to migrate all existing Active Directory accounts, OPAL administrative accounts, Department SIS accounts and FBA roles and accounts to the new service.

Completion of the data conversion planning, development, testing and execution shall be a joint effort between the State and the awarded vendor.

Disaster Recovery Requirements

The solution includes a systems disaster recovery element.

The agreement shall include contract terms related to business continuity and disaster recovery of the State’s data.

Customer Support and Service Requirements

Customer support assistance for systems administrators must be available by one or more methods to include telephone support, email support, or Live Chat support.

Online support (e.g., tutorials, frequently asked questions, help library) must be available for all software features and be updated in tandem with solution upgrades.

Customer service standards must meet or exceed industry standards. Provide customer ratings, customer satisfaction surveys, Better Business Bureau ratings, or similar data to establish proficiency in this area.

Software Updates and Upgrade Requirements

For software updates and upgrades, vendor employs staging, quality assurance, and testing processes that align with industry best practices.

Security updates and maintenance upgrades to solution shall be available throughout the contract period without any additional cost to the State.

Communication or notification of maintenance upgrades and system changes should be available to all end users.

State interfacing/integrations shall continue to work with new versions of the solution.

If the selected vendor chooses to upgrade the solution or make changes to its data model, the selected vendor takes all responsibility for migrating the State’s data to the new version or for the continuous conversion of the State’s data through the life of the contract.

If continuous development and deployment of new solution functionality is not included in the solution service for the contracted period, vendors must disclose the schedule of functionality enhancements and the additional fees charged for such enhancements.

FUNCTIONAL REQUIREMENTS

The scope of this project is to develop/customize and implement an IAM within the NDE data management environment in the AZURE cloud. The RFP is seeking information from industry knowledgeable vendors that will enhance the State’s understanding of available IAM solution options. Interested vendors are encouraged to provide insight to different approaches for deploying an IAM system by responding to the Request for Information.

The following are the requirements of the NDE, please provide a solution to meet all requirements defined below. In case there are one or two items which make the solution either very difficult or expensive, the NDE encourages vendors to also submit alternate approaches to meet the requirement.

RFP responses will provide general product and vendor experience overviews, high-level project approach information, and solution costing information for planning purposes.

IAM Components

Centralized Directory Services

The NDE would like a Centralized Directory service to manage identity and access. In a cloud environment, directory services are heavily utilized by the Identity and Access Management framework as a secure repository of identity and access information. Access to Directory Services should be part of the Identity and Access Management solution and should be as robust as the core authentication modes used.

The use of Privileged Identity Management features is also strongly encouraged for managing access to the administrators of the directory. If these are hosted locally, rather than in the cloud, the IAM service will require connectivity to the local Lightweight Directory Access Protocol (LDAP) servers, in addition to any applications and services for which it is managing access.

Access Management Services

Authorization and access management form a broad category of services that are required to be fulfilled in order to ensure security in the cloud. Authorization determines the user’s right to access a certain resource, access management, in general, has the responsibility to enforce that users’ access to a certain resource is managed with respect to each user’s credentials and attributes associated with the identity.

Authorization management in the cloud should ensure that users have appropriate rights to access cloud as well as enterprise managed resources. Both policy definition and enforcement functions need to be available. User access needs to be approved or disapproved in real-time with respect to the authorization policies in place.

Completely trusted and anonymous authorization should be restricted, and detailed user authorization should be implemented. This needs to work seamlessly across on-premise systems and the enterprise in the cloud, offering real-time synchronization for both provisioning and de-provisioning.

Access Policy Management

Access Policy Management functions should be available at each layer of the cloud solution, including infrastructure, platform, and software as a service. In a SecaaS environment, there is a requirement to have end-to-end management of an Access Policy so that security is not compromised at any level. Access policies usually emanate from a common set of security policies. Access policy management is critical because if the policy that is to be enforced is incorrect, unmanageable, or not verifiable (compliance), then the entire access control system is effectively rendered useless.

The NDE needs Federated identity services to allow an organization to manage both the identity and access of its users to resources of partner organizations providing services authorized for those specific users. The NDE interacts and shares data with other agencies within the State, and having the ability to manage the lifecycle of the users’ identities and accounts in the partner systems, Federated Single Sign-On assists with the authentication of users internally, then relays that identity to its cloud services provider, as a trusted token. This enables the NDE to maintain control of the authentication process.

Audit and Reporting

The Identity and Access Management function of Security as a Service should be able to track and furnish information for all basic audit requirements found in traditional IAM implementation which includes, but is not limited to, the information regarding:

Who has access to what information.

If the access is appropriate for the job being performed.

If the access is monitored, logged and reported properly.

Monitoring cloud resources for user access is critical. An appropriate evaluation of the risk of exposure is not possible without having the right measures in place for monitoring and reporting, which could provide the metrics that will be used by audit. Monitoring cloud resources for user access is required to:

Identify and prevent access violations.

Quantify risk exposure and residual risk.

Enforce segregation of duties.

Have a role-based access control mechanism.

Audit logs are a critical part of the IAM process. Logs of activity, including all authentication and access attempts (both successful and failed), should be kept by the application/solution. Different types of reports need to be created and used within the scope of IAM as security information and events. Many of the reports that are typically created are used for operational purposes, such as reports of system performance activities, tasks and queue management functions, and reconciliation events. Typical audit reports include for following:

User identities and their associated access.

Access approval information.

Administrative and privileged accounts and their associated owners.

User count and associated statistics for a particular resource.

Access Failures.

Privilege Access Failures

The processes and supporting systems should be able to provide reports that detail access approvals and reviews. Reporting on both the data and process is equally important and should be included.

Authentication

Authentication must follow the published State of Nevada Information Security Committee standards and provided below:

State Standards

Access to State systems must be adequately protected against unauthorized modification, disclosure, or destruction. Secure authentication to State resources requires either strong passwords or a multi-factor authentication solution to include the following:

Multi-factor authentication is the preferred method for providing secure authentication to state resources and, when used, must include at least two of the three authentication factors. Multi-factor authentication is highly encouraged for access to any systems containing confidential data.

All passwords for State IT systems will adhere to the following minimum requirements unless the hardware/software system is incapable of meeting these requirements:

Passwords for standard user accounts must be a minimum of eight (8) characters long. Passwords for administrative accounts, or accounts with elevated privileges, must be a minimum of twelve (12) characters long.

Passwords must not contain values known to be commonly-used, expected, or compromised. Passwords must be validated against a dictionary of bad passwords before being allowed on any state system. The dictionary should include, but is not limited to:

Passwords obtained from previous breaches.

Dictionary words.

Repetitive or sequential characters (e.g. ‘aaaaaaaa’, ‘1234abcd’).

Context-specific words, such as the name of the service, the user’s first or last name, the username, and derivatives thereof.

When a newly selected password does not meet these requirements, the users must be told to select a different password, why the password was rejected, and given an opportunity to select a different value.

Users should have the option to display the password when entering it, rather than seeing a series of dots or asterisks. The password may be fully displayed using this option, or the individual characters may display for a short time after each character is typed.

The use of passphrases should be encouraged. A passphrase is a series of words or other text strung together that hold meaning to the user but not to anyone else. When combined with the rules for complex passwords they can be very secure (Ex: MyBLu3NiS$@n, 0uRD0gM@x).

Each user will agree in writing to not disclose or loan their credentials or access hardware to any other person, to change any password immediately if it has been disclosed (or suspected to have been disclosed) to another party, and to immediately report the loss of their access hardware to the Help Desk or their agency ISO when it is identified as missing.

Each system user-ID must uniquely identify only one user, whenever possible. Shared or group user-IDs and/or passwords are likewise prohibited unless the hardware/software system only allows/recognizes a single user-ID.

The display and printing of passwords/PINS/secrets must be masked, suppressed or otherwise obscured so that unauthorized parties will not be able to observe or recover them.

All user passwords must be changed at least every 90 days, but not more than once per day, as well as anytime a compromise or problem, is suspected or reported.

Service account passwords are an exception to this rule and must be changed at least annually. Passwords must not be set to infinite expiration periods.

Non-existent (blank) or default-supplied credentials are explicitly prohibited and must be changed before connection to any State IT resource.

Passwords granting access to sensitive data or elevated access to the system must not be saved, stored, or hard-coded in any system or application in plain-text format. Password hashes and passwords stored in encrypted files are permissible. Password hashing algorithms on State systems must be approved by the governing agency and must use a 32-bit or longer salt value. LANMAN hashes of passwords are strictly prohibited.

System managers must immediately change every potentially affected password on a system if password file integrity is, or is suspected of being compromised. An incident response form must be completed and submitted to the Office of Information Security (OIS) after the passwords are changed.

Passwords cannot be re-used or rotated on a given system within ten previous password changes.

All accounts shall be locked out on the third-consecutive unsuccessful login attempt. The system may release a locked-out account after 30 minutes has elapsed. If a system administrator assists with releasing a locked-out account, and is reasonably certain of no unauthorized user access, the elapsed time of 30 minutes is not applicable.

If locked-out accounts are automatically released after 30 minutes, the agency will monitor all systems for repeated failed login attempts which could indicate malicious activity.

The use of agency approved password management software is allowed and should be encouraged.

Passwords cannot be entered or changed in a computer system for authentication and authorization purposes unless the representative for the system granting access has taken reasonable steps to positively identify the requestor. All requests for entry or change of passwords must be confirmed by:

Direct contact or voice recognition is established between the representative and employee.

Confirmation is received from the employee’s management or network administrator.

The requestor has correct responses for predefined keywords/phrases for manual or automated password changes.

Call-back is initiated by the granting agency through the employee’s immediate supervisor.

Passwords for access to critical systems will be separate and unique from any other system passwords, with the exception of accredited multi-factor authentication or single sign-on solutions.

Passwords for accounts with administrative or elevated privileges must be separate and unique from other system passwords.

Passwords shall not be transmitted in “clear text” or make use of any protocol which uses “clear text”, unless the mode of transmission is encrypted.

User IDs that are inactive on the system for 30 days or more should be disabled.

Definitions

Credentials: A set of claims used to prove the identity of a client. They contain an identifier for the client and a proof of the client's identity, such as a password. They may also include information, such as a signature, to indicate that the issuer certifies the claims in the credential.

Multi-factor authentication: Two or more factors positively identifying a user. The factors that make up multi-factor authentication include:

Something you know (a password, PIN, mother’s maiden name, etc.)

Something you have (a hardware token, smart card, smartphone, etc.)

Something you are (fingerprint, retina/iris scan, facial recognition, etc.)

Service accounts: Accounts on which automated system functions (services) are dependent to execute. A service account does not correspond to an actual person. These are often built-in accounts that an automated system function (service) uses to access resources it needs in order to perform its activities. However, some automated functions may require actual user accounts to perform certain functions, and others may be employed using domain accounts to run services.

System Administrator: The individual(s) responsible for maintaining the stable operation of the IT environment (including software and hardware infrastructure and application software) and/or has system authorization/access to perform the following administrative function(s):

Add, change, or delete user accounts and associated user provisioning for database, operating system, and network layers;

Modify operating system, database, and application security and policy parameters;

Add, change, or delete system exception logging information; or

Add, change or delete permissions to data files and folders.

NOTE: The above standards are based on the S.5.01.01 User Identification and Authentication (version D, dated: 8/29/2017). Any updates to this document, can be found on the NDE website:

http://it.nv.gov/Governance/Security/State_Security_Policies_Standards___Procedures/ (State Information Security Policies, Standards, and Procedures) and must be followed.

Additional Requirements

Risk-Based Authentication (RBA) is a dynamic response to the changing conditions of the risk rating attached to any user (agent) at a particular time. Risk ratings are assigned to both the transaction and the agent. The higher the risk rating of the transaction, the higher the authentication level required of the agent in order to complete the transaction.

RBA determines the agent's risk level by examining behavioral contexts, such as a history of similar requests, location of the agent/transaction, and timing of the request. Any behavioral anomalies can trigger a reaction ranging from a request for further authentication to a denial of the transaction.

Portability

In order to avoid vendor lock-in, cloud environments and services should be portable. Without data portability, it would be impossible to switch cloud service providers. For IAM functions serviced in the cloud, there could be a great challenge to business function portability as much as for data portability. IAM functions are known to be complicated in terms of implementation and are usually tied to a particular implementation type. However, changing cloud vendors could pose a great challenge to migration, as there are no specific standards for business function migration like there are for data transformation and migration. The use of standard protocols and interfaces for integration with cloud-based IAM services can simplify technical aspects of portability.

To ensure portability, the IAM vendor can use standardized formats for data exchange and provide connectors to various cloud platforms which will enable the enterprise to switch cloud platforms if so required. The core engine in this case remains the same, while the connectors provide the ability to connect to different types of cloud platforms. At the very least, the IAM solution should have an SDK/ API interface built in which can be used by the enterprise to determine portability strategies.

Performance/Availability

Attacks on Identity Services or network connectivity, such as DDoS attacks or resource hogging, could jeopardize the availability or degrade the performance of an IAM SecaaS service. Since high availability and performance are required, redundancy and fail-over options should be available.

Identity Governance

The Identity Governance tools help manage digital identity and access management across multiple systems and applications. These tools help ensure that only the right people have access to the appropriate resources (e.g., applications and data) based on their role, level and need. To accomplish this, Identity Governance tools aggregate, correlate disparate identity and entitlement data that is distributed throughout the IT landscape, and analyze rights to enhance control over user access by providing the following functions (as defined in the Gartner report):

Identity life cycle: Maintaining digital identities for people and things (including software), their relationships with the organization, and their attributes during the entire process from creation to eventual archiving and deletion, using one or more identity life cycle patterns. Identity life cycles for people cover business-to-employee (B2E), B2B and B2C use cases.

Entitlement management: Maintaining the link between identities and entitlements to be able to tell who has access to what and who is responsible for maintaining an entitlement. This includes maintaining and curating the entitlements catalog to describe the types of entitlements, such as accounts, roles, group memberships, etc.

Access requests: Enabling users, or others acting on behalf of users, to request entitlements through a business-friendly user interface.

Workflow: Orchestrating tasks to enable functions such as access approvals, notifications, escalations, manual fulfillment requests and integration with other business processes. For example, this allows managers or resource owners to approve or deny requests.

Policy and role management: Maintaining rules that govern automatic assignment (and removal) of entitlements; providing visibility of entitlements for selection in access requests, approval processes, dependencies and incompatibilities between entitlements (such as segregation of duties [SOD] violations); etc. Roles are a common vehicle for policy management.

Access certification: Enabling people like managers and resource owners to review and certify the entitlements that users have on a periodic basis to ensure that access is appropriate and complies with policies. (This is sometimes called “attestation.”)

Fulfillment: Propagating changes initiated by the IGA tool to account repositories. Automatic fulfillment (often called “provisioning”) connects with account repositories, while manual fulfillment utilizes a workflow or external process and tool (such as ITSM tools) to complete actions.

Auditing: Evaluating the current state of identities and entitlements against business rules and controls, providing a means for alerting control owners of exceptions (such as changes made directly on target systems) and allowing for orderly remediation (case management).

Identity analytics and reporting: Providing means to: (a) evaluate risk based on identity information insights; (b) apply techniques to cleanup excessive, outlier or wrongful entitlements; and (c) enhance the continuous process of identity governance, including risk reporting. Role mining and engineering was one of the first examples for analytics. Identity analytics has evolved to enable smarter microcertification campaigns, contextualized access requests and approvals, and enhanced policy violation detection, among other use cases.

SECURITY STANDARDS

System shall meet state security standards (http://it.nv.gov/governance/state-policy-procedures/) as outlined in NRS 205.4742 and NRS 603A, with amendments from the 2019 Legislative Session (SB302), signed into law by the Governor.

Cloud Hosting: State of Nevada Information Security Standard S5.06.01 must be adhered to in its entirety for all cloud-based systems, operations, or initiatives. Exception requests must be requested through the Department of Administration Information Security Officer for processing.

System shall meet State security standards for transmission of personal information as outlined in NRS 205.4742 and NRS 603A.

REQUIREMENTS MATRIX

Vendor shall:

Present the platform requirements for efficient operation of the system;

Review the requirements matrix carefully to insure that the proposed system design addresses all of the requirements;

Tie each data element/function to the vendor’s project plan by task number; and

Respond to all of the requirements by properly coding and indicating how the requirement is satisfied. The proposed costs and project plan shall reflect the effort needed to satisfy the requirements.

Identify, for each of the system requirements identified in the requirements matrix, whether it is:

Identify whether each requirement is in the firm fixed price included within the cost proposal.

Describe how the proposed system meets the requirements specified within this RFP.

SCOPE OF WORK

The scope of work is broken down into tasks, activities and deliverables. The tasks and activities within this section are not necessarily listed in the order that they shall be completed. Vendors shall reflect within their proposal and preliminary project plan their recommended approach to scheduling and accomplishing all tasks and activities identified within this RFP.

All tasks performed by the awarded vendor may be reviewed by the QA monitor as well as State staff.

VENDOR RESPONSE TO SCOPE OF WORK

Within the proposal, vendors shall provide information regarding their approach to meeting the requirements described within Sections 4.4 through 4.9.

If subcontractors shall be used for any of the tasks, vendors shall indicate what tasks and the percentage of time subcontractor(s) shall spend on those tasks.

Vendor's response shall be limited to no more than five (5) pages per task not including appendices, samples and/or exhibits.

DELIVERABLE SUBMISSION AND REVIEW PROCESS

Once the detailed project plan is approved by the State, the following sections detail the process for submission and review of deliverables during the life of the project/contract.

General

The contractor shall provide one (1) master (both hard and soft copies) and four (4) additional hard copies of each written deliverable to the appropriate State Project Manager as identified in the contract.

Once a deliverable is approved and accepted by the State, the contractor shall provide an electronic copy. The State may, at its discretion, waive this requirement for a particular deliverable.

The electronic copy shall be provided in software currently utilized by the agency or provided by the contractor.

Deliverables shall be evaluated by the State utilizing mutually agreed to acceptance/exit criteria.

Deliverable Submission

Prior to development and submission of each contract deliverable, a summary document containing a description of the format and content of each deliverable shall be delivered to the State Project Manager for review and approval. The summary document shall contain, at a minimum, the following:

Cover letter;

Table of Contents with a brief description of the content of each section;

Anticipated number of pages; and

Identification of appendices/exhibits.

The summary document shall contain an approval/rejection section that can be completed by the State. The summary document shall be returned to the contractor within a mutually agreed upon time frame.

Deliverables shall be developed by the contractor according to the approved format and content of the summary document for each specific deliverable.

At a mutually agreed to meeting, on or before the time of delivery to the State, the contractor shall provide a walkthrough of each deliverable.

Deliverables shall be submitted no later than 5:00 p.m., per the approved contract deliverable schedule.

Deliverable Review

General

The State’s review time begins on the next working day following receipt of the deliverable.

The State’s review time shall be determined by the approved and accepted detailed project plan and the approved contract.

The State has up to five (5) working days to determine if a…