OIT Project Portfolio Report

In response to the CU-Boulder data center assessment, it was determined that SPSC N190 data center is to be vacated. To accomplish this declaration, there are two distinct activities that need to occur:

1. Move existing services from SPSC N190 to COMP data center or SPSC N180
2. Install infrastructure at Anschutz data center to support CU-Boulder servers
3. Begin populating initial 6 racks at Anschutz with systems still-to-be-identified (will be identified by March 2024).
4. Plan for network separation of SPSC N190A from SPSC N190.

Lowers risk of data center component failure Provides more geographical separation between data centers

The AD operating system will no longer be supported after December 31, 2022 and there is need to rebuild the infrastructure to meet security standards and apply recommendations from an external consultant following an incident in January. In this project, the 8 domain controllers (DCs) will be rebuilt and the 2 temporary DCs will be decommissioned. A new design will be developed, reviewed, and approved, to include the incorporation of such recommendations as group policy objects (GPO) evaluation, firewall rule changes, privileged access workstations (PAWs), and other security measures as identified.

CU will have a more resilient AD infrastructure to help protect the University from cyber-attacks and security incidents Move the AD infrastructure from the temporary DCs built after the January AD attack to permanent hosts hardened by remediation measures

To better ensure the integrity of the shared information technology environment as it relates to end-user devices, all university-owned end-user devices, and personally-owned end-user devices that access or store university data, must meet the following conditions: For university-owned devices: • Enrollment in an approved endpoint management tool that reports security posture, such as MECM or Jamf Pro • Hardware and software asset tracking using the campus standard asset tracking tool (Eracent) • Public safety emergency notification client software (Alertus) • Up-to-date antivirus and anti-malware software • Full disk encryption • University data stored on enterprise standard cloud storage (OneDrive) For personally-owned devices: • Up-to-date antivirus and anti-malware software • Full disk encryption • University data stored on enterprise standard cloud storage (OneDrive) There are three overarching objectives of this project to reach this goal:

1. Develop and obtain approval for the Certified End-user Device policy by having it run through the official policy proposal & adoption process. This policy will address both university owned and personal owned devices.
2. Create the infrastructure and processes needed for ensuring all new end-user devices procured through the university comply with the end-user device policy requirements. Create guidance, best practices, and certification process.
3. Create the infrastructure and processes needed for remediating existing university owned end-user devices to comply with the certified end-user device policy.

Increased security of university computing assets including personal and university owned data Reduce risk to university intellectual property Simplicity and consistency to procure and deploy Lays groundwork for consistency in support Visibility into enterprise procurement practices to drive efficiencies and cost savings

Account provisioning is the process of making information technology (IT) systems available to users, groups, and other entities. Deprovisioning is the process of removing access to software and network services. Put simply, it’s the exact opposite of provisioning—and typically occurs when employees change roles or leave the university. Both provisioning and deprovisioning play an important role in securing IT systems and applications. CU Boulder (UCB) has processes and systems in place to provision and deprovision user, administrative, and service accounts. Historically these systems have focused on provisioning accounts, but very little has been implemented on the removal of these accounts at the appropriate time. Additional focus is needed to ensure that there are processes in place for all user, administrative and service accounts managed by OIT and that they properly address the evolving security needs of the organization. This project will define the totality of entity account deprovisioning, reprovisioning, and provisioning (d/r/provisioning) managed by OIT at UCB. It will define the desired end state, where things are today, and map out the path to make the transition. Business systems, processes, and organizational/cultural aspects will all be considered. A result of this project will be a value-based plan for incrementally improving OIT’s d/r/provisioning practices.

Prevent data exposure – User accounts can potentially pose huge security risks if they remain provisioned to individuals no longer entitled to access, whether because they have left the university (withdrawn/graduated/separated from employment) or have moved into a role at UCB that is not authorized for the same level of access (for ex. Employee -> retiree, or student -> alumni). Reduce the number of active accounts - User accounts should only be active when an individual has an active affiliation with UCB. Once an individual is no longer affiliated, the account must be disabled. Failure to disable accounts of those who are no longer affiliated poses a significant security risk. Reclaim resources – Users may no longer be entitled to certain resources when their affiliation changes. Reclaiming resources, such as software licenses, will help financially and ensure the university is compliant with licensing agreements. Improve ease of provisioning and deprovisioning entity accounts – standard or automated processes will add consistency and structure to how entity accounts are provisioned and deprovisioned. cent

This project will transition the Data and Analytics website from Web Express to a new site managed by OIT’s Customer Engagement and Information Design team. The primary components of the current ODA Web Express websites are:

1. General information about the organization
2. Data and links to data related to institutional research including data about students, departments, institutes, faculty and staff. The format of the data includes web pages, PDFs, excel files and Tableau dashboards. The information is sourced from various CU data sources, public data sources and surveys. Some characteristics and uses of the data: a) Data available to the CU Boulder community b) Public and SSO restricted data c) Information written for news and information sources d) Information mandated by the regents e) Data that must be publicly available for institutional accreditation and to follow state and federal rules and laws. f) Data that is made available to national higher education data consortiums and partner institutions
3. Information about program level assessment at CU Boulder including resources for programs conducting assessments. Program assessment is necessary for Institutional accreditation.
4. Descriptive and training information about the Faculty Course Questionnaires program administered for the Boulder, Denver and Anschutz campuses. The explanatory information is primarily web pages, with some PDF’s and videos. Data results for the FCQ’s are Tableau dashboards.
5. Links to a Faculty Information Services Web Express site with information about their software products and services
6. Data and analysis request forms for the CU Boulder community and the public. The forms generate an email message to ODA’s Service Desk

Accessible data visualizations Improved information architecture Custom access parameters for content that requires limited access

This project will address the ~113 Red Hat Enterprise Linux (RHEL) 7 servers within OIT that will reach end-of-life support on June 30, 2024. RHEL 7 will no longer receive stability patches and security updates after June 30, 2024. As such, the services on these servers must either be migrated to new servers, migrated to other platforms (cloud native or containers), or retired/decommissioned. The breakdown of these systems and the service teams responsible for them are as follows: Group RHEL 7 Systems Description DATA 15 Data driven services (Data + Analytics, including EDB) AS 31 Academics and Student Services (FIS, ATAP, Buff Portal) SEC 36 Security, IAM, M&C NEO 15 NEO, Data Center, VOIP, Paging PE 5 Platform Engineering LNX 11 Linux Platform Engineering As part of the project, we will document the systems that have campus border firewall exceptions and how many do not. We will also determine which systems will require Red Hat Enterprise Linux Extended Lifecycle Support. Failing to prioritize upgrades has resulted in ~113 RHEL 7 OIT servers owned by OIT service teams in production, and so we are turning upgrades into a project to gain visibility and resource allocation. This project approach is similar to the Red Hat Enterprise Linux 6 upgrade, However, a BIG difference between the Red Hat Enterprise Linux 6 upgrade and this upgrade process is Linux administrators will be embedded into service teams as part of the new DevOps model SE Linux is shifting to. This will shift the responsibility of ensuring timely upgrades from the SE Linux team to each service manager whose service is reliant upon the Red Hat 7 server. This project will help service managers prioritize these upgrades as well as track progress and risk throughout. A typical system upgrade, and steps therein, are outlined in 1.9. On average, based on previous upgrade data, an upgrade requires around 2 business weeks. The service team may need to refactor or rewrite their applications to function on the new server. This usually involves new underlying software stacks, such as PHP or Python, which necessitates a rewrite on the service team end.

Reduce our security risk as an organization. Services migrated to supportable platforms allowing for continued development/improvement of the service if desired by service managers.

The purpose of this project is to support the Discovery for Phase 1 of the Learner Lifecycle CRM. The goal is to be ready for Phase 1 implementation kickoff. Through the campus CRM Strategy Steering Committee governing body, there is a desire and demand for a CRM to support the student/learner academic lifecycle, from initial outreach by the learner to completion of academic goals. Today, the CU Boulder campus does not have such a comprehensive service. The campus is planning to implement a CRM strategy called Learner Lifecycle (LL) CRM, aimed at delivering comprehensive support throughout the entire learner journey. This project is to support the building of the business and technological strategy to achieve this vision. We are starting with the defining of business requirements. To get ready to support such a large effort this project will focus on breaking down the Use Cases created and refined as part of the Accenture engagement and the Technical Architecture engagement efforts, and create business requirements, feature definitions, and technical user stories to create a requirements traceability matrix (RTX), both to support and inform the changes that business units will have to make to their daily business processes, and the technical effort needed to install and integrate. This project effort, phase 1 discovery, will focus on learners and business units that support B3 and Continuing Education, limited to these learner populations and the business processes and technology ecosystem that support these populations to build a scalable platform for future phases. This effort will include engaging with business and technical teams to determine if there is bandwidth to elicit requirements for the Constituent Data Platform (CDP).

Properly plan and prepare for the launch of Phase 1, wherein we bring in vendors to execute the technical Moving requirements to the initiating phase to shift cost during the Phase 1 discovery, shortening the RFP timeline.

Aurora is an application that has grown out of necessity to become an application that many teams depend on, including ITSC (Help Desk), IAM (Identity Management), M&C (Messaging and Collaboration), among others. The application has developed in to 5 distinct functions: • Search and display user data • Modify user attributes • Initiate provisioning • Request Portal • Reporting / Reconciliation / Proactively fixing user data. As part of the above functionalities, the Aurora application is built with access to data available through different services throughout OIT, including Office365, Azure, Google, Grouper, OIM, AD, JAMF, Sympa, EDB, LDAP and ServiceNow. As the users are aware of this, there are requests to see information from those systems through a simple and unified user interface, I.e Aurora user interface. To paint the picture of Aurora usage, here are some statistics: • Admin portal has 460 users with diverse access levels and capabilities from 52 unique departments. • Automation process has created 10,000 secondary accounts since Jan 2019. • Remediated 6000 compromised accounts since Oct 2020. • Scrambled 400,000 account passwords during Active Directory security incident in Feb 2022. • Resolved 2,500 requests to M&C team (that is about 75% of all requests to M&C) in 2022. New group of users requiring access to Aurora will present difficulty as currently there is no clear process and governance procedures in deciding who can get access to which data. This typically just delays the assignment of the access, as the team must consult to security team. New feature requests from end users also do not go through a formal review whether the feature should be built or not. In the meantime, the application today is supported by a single developer (Youcef Baouchi) and a student employee. This project request was created with the goal of having a formal project to define the right scope for Aurora application, define the Aurora user provisioning process, and define the future roadmap of Aurora.

Better organization for the effort to define Aurora. Better support to the Aurora application. Better and clear definition of the application. Better governance process and access control. Improve access request speed (when they are appropriate)

This project will manage the design and implementation of the new Video Delivery Network service, as well as the migration of all content from Kaltura to YuJa. It will include the configuration of the new platform and integrations with Canvas, Zoom & Playposit, change management, user support, IT security and accessibility reviews, and the retirement of the Kaltura service.

Implementing the new video delivery network, designed for educational purposes, will lead to a better user experience for students and instructors. Implementing the new video delivery network will result in cost savings for CU Boulder.

The need for this project is from internal and external forces that are working together to change the landscape of data storage in higher education. CU Boulder’s storage vendors, Google and Microsoft, have each determined that unlimited storage for high education users is an unsustainable business model. Google implemented storage quotas, which kicked off the storage war, with Microsoft following suit in the summer of 2023. CU’s current Microsoft multi-campus contract runs through 9/31/2025, allowing a short runway to create and implement a storage strategic plan. In addition to the changes made by our vendors, our Federal and State research and grant partners have begun migrating towards stricter Data Lifecycle Management (DLM) and Data Loss Prevention (DLP) standards, meaning CU Boulder must adapt, or potentially lose research grants and researchers. To addresses these changes, OIT is proposing a broad ranging effort that hopes to establish a strategic plan and roadmap for the storage of data of all classifications, origination sources and retention periods on the CU Boulder campus. In addition to the strategic plan, known tactical and operational deliverables to communicate and enforce the strategic plan are also in scope. Currently unknown tactical and operations deliverables may spawn future projects as part of the roadmap deliverable.

Unified storage strategy, regardless of vendor, or affiliation type Enhanced and unified view into data loss prevention and data classification labeling Campus wide plan for data lifecycle management Campus education of data classification levels, DLP policies, data related policies and the enterprise storage options available to meet CU business requirements

This project intends to enable sensitivity labels for data, email and Teams chats on the O365 environment as a step towards closing security and compliance gaps within the commercial O365 tenant. Closing these gaps is a prerequisite for future projects on the O365 space, including storage futures, AI initiatives and email security. Sensitivity labels allow users to set boundaries on how their data, emails and chats are shared with others. They persist across the O365 environment and to many 3rd party applications and can prevent forwarding, sharing and can be used to set encryption requirements for the data. Enabling these labels would immediately help users of confidential and highly confidential data on campus, such as OIEC, HR, researchers, and the Registrar. The technical aspects of this project were largely completed a few years ago, although some testing is needed to ensure the policies created are compatible with O365 changes since the first effort closed. This is being chartered to cover the communication and training needs to roll out sensitivity labels to the campus and to cover the resources needed to conduct a pilot with OIEC or HR. Once the rollout of sensitivity labels is complete, many users who rely on the Large File Transfer service to share sensitive information can share this same data straight from OneDrive or Teams, reduce the number of copies of that file that are being created. Likewise, departments who rely on PGP to protect highly confidential data and must first decrypt the data prior to sharing it can now transition their storage of the data from UCB and the PGP solution to a Teams storage solution.

Prevent data leakage and move the commercial tenant to a higher security level, closing the gap with LASP and GCC. Educate users on the usage, importance and need for sensitivity labels. Prepare the O365 environment for AI integrations in the future. Meet the needs of HR and OIEC data storage in the O365 environment Take a step towards meeting higher compliance requirements in NIST 800-171

This project intends to enable Domain-based Message Authentication, Reporting, and Conformance (DMARC) for email on the Colorado.edu main and subtenants. DMARC is an email authentication protocol designed to help prevent email spoofing and phishing attacks by allowing email domain owners (@colorado.edu) to specify policies on how their emails should be handled when they are received by email servers. With DMARC, CU can publish a policy in our DNS records that specify how to manage emails that fail authentication methods (either Sender Policy Framework (SPF) and/or DomainKeys Identified Mail (DKIM)). CU Boulder currently has the DMARC policy in our DNS record set to “DMARC = None”. In this “monitoring mode”, we request emails servers to send reports about email authentication results but no specific action is taken for emails that fail authentication. This project will move DMARC policy to “DMARC = Quarantine”, which is the next level mode (the strictest is “DMARC = Reject” which rejects all email that fails authentication and will not deliver it to the recipient’s inbox). Moving to “DMARC = Quarantine” on our colorado.edu domain forces users of 3rd party senders, sending on behalf of @colorado.edu to adhere to global authentication standards. This ensures delivery of their sends to both internal and external partners. Government agencies, other R1 institutions, and the major public email providers have begun to enforce DMARC on mail they receive. OIT fully expects additional government agencies and schools to enforce DMARC in the coming months which will further create problems for @colorado.edu users trying to send e-mail to these entities using third-party senders such as InfoEd, MarketingCloud and our student facing systems. CU is behind other R1 institutions in enabling DMARC. The Universities of California, Berkley, South Florida, and Nebraska have set “DMARC to reject” while Iowa and Kentucky are set to “DMARC to quarantine”. Technically this is a simple change, but it carries a heavy change management effort due to the unregulated use of various schools and departments using third-party vendors to send email on behalf of @colorado.edu addresses. The recent eComm policy change and our move to add external email banners has forced most of the campus’s largest senders into compliance already. Smaller senders remain and will require outreach to move them into compliance.

Reduced phishing and spoofing attacks Meet email standards that will allow the campus to communicate with .mil and .gov. research sponsors Improved email security Increased trust in university communications Protection of sensitive data Enhanced reputation of the university Automated email security enforcement Cost savings from preventing data breaches Better alignment with industry standards Reduced risk of email-based cyber threats Improved compliance with data protection regulations Streamlined incident response due to fewer security breaches Support for a sustainable security model Improved user experience with fewer malicious emails

The Platform Engineering (PE) team has all the necessary building blocks of a top-tier hosting/developer platform: OpenShift, GitHub, Vault, ACS (Container Security), and Observability (WIP). We’ve taken the first steps toward assembling these individual tools into a cohesive platform (including end-user documentation, User Workload Monitoring, Namespaces as a Service), but true development of an internal platform must be informed by the workloads it hopes to support and the developers/administrators who will be using it. This may sound like a large undertaking, but we believe these efforts will be more than offset in the following ways: • Thinnest Viable Platform Do just enough work to integrate the tools we have, so developers can request an instance of our standardized “hosting stack,” rather than just a namespace. Developers would interact with each tool directly but start with a functional configuration across all of them and have access to documentation that matches that exact configuration. • Simplification of individual services This is best illustrated with a specific example. Vault is currently offered as a standalone service, so teams must decide how to organize their secrets, then request roles and policies based on that structure and manually copy role secrets into OpenShift. After collecting feedback about typical secret layouts, it would be much more efficient to simply provision a standardized structure within Vault along with each namespace request and preconfigure appropriate roles and policies. • Reduced developer toil The standard “stack” may not be a perfect fit for every application out of the box, but adjusting a common template will require much less developer time than building an entire pipeline from scratch for each application. This project will assist with the onboarding of new customers by: • Creating list of prospective customers by reaching out to OIT Service teams. • Meeting with prospective customers to understand how their applications work, what kind of dependencies they have, and translate those into platform requirements. • Helping PE prioritize their work to meet customer expectations. • Creating timelines for each prospective customer so that the PE team may prioritize the onboarding of each. • Establishing a 2-year roadmap that includes development, implementation of new features, and enhancing the stability, security, and performance of the Kubernetes platform. • Establishing a feedback loop so we may refine needs as requirements or priorities shift over time.

The container platform is already used by several groups in OIT and has been proven to reduce toil. There are other groups wanting to migrate, and this project will help us spread the knowledge gained by early-adopters and continually make the platform more inclusive and easier to use as more teams come on board. Undertaking this work with help from the PMO should help PE refine and improve our work management and prioritization capabilities - helping with work visibility, aligning our work with customer needs, and understanding our capacity. A 2-year roadmap is created that includes development, implementation of new features, and enhancing the stability, security, and performance of the integrated platform. A container platform decision tree is created and shared to assist customers with deciding where to host their application/service.

M365 Apps for Faculty, formerly called ProPlus, is a license entitlement added to A1 licenses that allows users to download the desktop version of Office 365 apps. Formerly provided at no cost by Microsoft, the cost model is changing so that ProPlus is an extra expense. Traditionally, we provisioned M365 Apps to A1 licensed users because it was provided to us at no additional cost. Because of the increase in cost (from $0 to $20 per user), we must reduce the licensed users and change ongoing provisioning rules to maximize our license use and minimize the cost impact. This involves removing the license from existing users. Concrete objectives for this project include:

1. Check with MS licensing specialist to validate our plan
2. Change eligibility rules for O365 license groups a. OIT-A1-Faculty-License group: No longer receives M365 Apps b. OIT-A3-Faculty-License group: Receives M365 Apps by default; A3 license provided upon request c. OIT-A5-Faculty-License group: Receives M365 Apps by default; A5 license provided upon request
3. Clean up O365 license groups a. Remove M365 Apps license from those who do not use it or should not be entitled to it (within the OIT-A3-Faculty-License group: remove 1805 inactive/ineligible accounts) b. Move O365 accounts to more appropriate groups (move 3072 accounts in OIT-A1-Faculty-License group to OIT-A3-Faculty-License group) c. Remove M365 Apps license from OIT-A1-Faculty-License group (affects 19,222 accounts)
4. Change provisioning rules for O365 license groups a. Only provision A1, A3, or A5 Faculty license and not M365 Apps to new employees
5. Develop request process for A1 Faculty license group members to request M365 Apps a. If approved, there will be a process to apply the A3 license to the user’s account.
6. Implement buy-your-own option for those we don’t/won’t provision a. OIT’s cost per license is $20/year (cost recovery model may change the charge to the user; estimated at $40/year)
7. Communicate and manage change to impacted users

Make MS Office software available to eligible CU affiliates that need it Ensure licenses that are purchased are consumed and used to receive the benefit of that license

The goal of this project is to determine the feasibility of leveraging SaaS observability and alerting solutions by: • Creating a breakdown of the devices/systems to be monitored in these OIT domains: Systems Engineering, Software Engineering, Data Center, Research Computing, IAM, Learning Spaces Technology, and Networking. • Collecting the number of devices/systems/applications/services that require basic monitoring vs. full observability for each OIT domain. • Identifying 5 to 8 Common Solution Group (CSG) schools to compare their observability offerings. • Researching and recommending which SaaS or OIT provided solutions (Prometheus/Grafana) we should consider based on our requirements for basic monitoring, full observability, and alerting solutions. • Developing a cost estimate for the monitoring, observability, and alerting solutions for the OIT domains. Includes any cost avoidance figures if OIT moves away from developing its own observability solution. • Developing and presenting the findings of this project. Based on the outcome of this project, if it is determined SaaS observability and alerting solutions are feasible, a new project will be developed to identify, procure, and implement the solutions.

Potential future consolidation of OIT monitoring, logging, and alerting solutions. Understanding of the SaaS observability and alerting features that OIT would struggle to custom develop. Greater understanding of the current Systems Engineering, Software Engineering, Data Center, Research Computing, IAM, Learning Spaces Technology, and Networking monitoring, logging, and alerting services. Number of devices/systems/applications/services and if they require basic monitoring or full observability. Understanding of the estimated costs to implement SaaS observability and alerting solutions. Ability to decide to proceed or not to proceed with SaaS observability and alerting solutions based on the data collected and estimated costs.

This is a project charter for RedHat 6 Linux Operating System Upgrades. RedHat 6 reached end-of-life November 30th 2020 and security updates are no longer available for this Operating System. As such, the services on these servers must either be migrated to new servers, migrated to other platforms (cloud native or containers), or retired/decommissioned. The Systems Engineering team can no longer maintain/support RedHat 6 operating systems or any services running on top of RedHat 6.Failing to prioritize upgrades has resulted in 68 RedHat 6 systems owned by OIT/OIS service teams in production, and so we are turning upgrades into a project to gain visibility and resource allocation. This will allow resources from groups within OIT/OIS who own RedHat 6 systems to be tasked with assisting the ITSE-Unix team in the upgrade process. An expected deliverable will be an upgrade cadence be developed to address this RedHat 6 technical debt generated by the 68 systems in production. A typical system upgrade, and steps therein, are outlined in 1.9. On average, an upgrade requires around 16 hours of an ITSE admin, and around 40 hours from a service team to refactor or rewrite their apps to work on the new system. This usually involves new underlying software stacks, such as PHP or Python, which necessitates a rewrite on the service team end.

Reduce our security risk as an organization. Services migrated to supportable platforms allowing for continued development/improvement of the service if desired by service managers.

Customers on the CU Boulder campus have a need for flexible and continuous access to software, either through remote access to physical computers or via virtual applications or desktops. The COVID-19 pandemic brought an emphasis on remote learning and hybrid/remote work modalities that require more flexible options that allow students, faculty and staff to access software from anywhere. This project will focus on the implementation of a new solution for remote and virtual access to LST software. Based on decisions from an earlier project, LST will deploy the Apporto cloud solution for use by LST campus customers. This project will:

1. Issue PO to vendor
2. Buildout Apporto cloud environment
3. Integrate with SSO
4. Integrate with Canvas
5. Create and deploy images
6. Test Apporto environment
7. Create & implement new LST operational/maintenance procedures
8. Cutover as production environment
9. Scale down of current remote-desktop solution.

24/7 access to software by students, faculty, and staff. Delivery and support for solution can be scaled to support access from all campus customers. Seamless and efficient experience for customers accessing software

In conjunction with Financial Futures, a campus strategic initiative, OIT has recognized the need to provide campus-wide software licensing services to campus units and employees in the form of a Software Asset Management (SAM) program. This program serves the entire CU-Boulder campus, and not just specific units or individuals. This program will significantly expand the scope of OIT’s current software licensing activities (termed “OIT Site Licensing”) in order to meet campus service demands and strategic goals. The new SAM program will: ● Maximize the value of software assets by tracking, reporting on, and taking or recommending action for software licenses, entitlements, and installations across campus ● Improve awareness and customer service by creating a global software database, software catalog and contracts repository, and by creating standard processes for requesting, purchasing, and planning for support around software ● Improve services to campus ITPS by data sharing and reporting on software assets, and software-centric knowledge resources ● Improve support to customers by streamlined access, improved communications, expanded catalog offerings, facilitating cost-sharing models, and proactive license management ● Reduce campus spending on software by working to eliminate duplicative and redundant software purchases, reducing over-licensing, re-using licenses when available, and reclaiming unused software ● Reduce data security exposure, architecture exposure, and business risk by proactively planning and managing the entire software lifecycle ● Reduce campus compliance and audit risk by creating a proactive audit readiness plan and coordinating software audit response to vendors. This project will establish the SAM program as a centralized campus manager of all business- and mission-critical software, including integration into IT governance activities and creation of new or modification of existing IT policy. This project will also establish standard software processes (including purchasing, lifecycle management, and compliance), establish metrics and KPIs to track program effectiveness, create and publish a global software catalog, identify the best SAM enterprise tool(s) to use (based on defined business requirements), implement and/or integrate the identified SAM management tools into the enterprise IT environment.

Track and report on software installed on campus-owned computers Create software database and contracts repository Time gained from centralizing administrative tasks, and planning for expected outcomes Reporting on software assets and usage Expanded software-centric knowledge resources Publishing a global software catalog and streamlining access to available software Campus-centric, holistic, and proactive approach to license management, including vendor engagement Reduce overall campus spending on software Reduce business risk, data security exposure, and architecture exposure Reduce legal risk of software audits and noncompliance

The procurement of IT services and products (software, hardware, peripherals) requires coordination from the purchasing department, the PSC, and risk review teams (e.g. Accessibility, Security) in OIT and the campus controller’s office (CCO). Without adequate coordination, the purchasing process can become confusing, duplicative, protracted, and can lead to inadequate or misunderstood risk review recommendations. The purpose of this project is to evaluate the resources central OIT would need to optimize and organize the initial work required of IT purchase prior to submission to the PSC as a purchase request or ‘requisition’. Examples of such work may include but are not limited to: budget review/justification, IT Governance review, review of business terms in the vendor’s/supplier’s term’s and conditions (“T&Cs), security review, digital accessibility review, evaluation of purchase against OIT’s software catalogue and other similar purchases, and initial assessment of necessary exception waivers. This project supports campus goals of fiscal and operational resiliency and aligns with OIT’s technical and business principles of User Experience Matters, Security is Foundational, Simple and Sustainable, Strategic Use of Governance, Act as Good Financial Stewards, Limit Redundancy and Control IT Sprawl, Understand Higher Ed Landscape. Additionally, this initiative can be linked to many goals including improving the student experience (by removing the risk of acquiring new software that doesn’t cover security, accessibility, and reputational risks), allowing project teams to plan ahead with clear requirements and choose the right software before a PR gets to the PSC, and preventing duplication of contracts or purchasing of duplicate software when existing software was already present.

Consolidated procurement process is well understood with greater user agency for decision making before procurement, allowing efficiencies in timing, planning, etc. Reduced IT Sprawl

The Event Management Software (EMS) is an established, vendor provided (Accruent), event planning and management tool managed by the UMC. It is used by 80 departments and accessed via 400 client users and 30K web application users. This service has been running for many years as an on-prem solution. It was configured to use LDAP authentication and today OIT’s Systems Engineering (SE) team manages the server it runs on. After the Spring 2023 graduation, the LDAP authentication mechanism failed. Since then, the UMC staff member supporting EMS, along with a student employee, have been manually supporting p/r/deprovisioning needs. This consumes their capacity and, as a result, the UMC has been unable to add additional departments who want to use EMS. Fixing their identity & access management mechanism is a priority for UMC. In addition, the UMC set up an optional Accruent component, the HR Toolkit (HRTK), to automate the creation and maintenance of user and group accounts. Working with contacts from UIS, they created a one-way feed to EMS and planned to receive updates 1-3 times per year. This update ran in 2021 and hasn’t since. For UMC, the functionality that this feed allows is a secondary priority. OIT has engaged with UMC several times in the past to support EMS identity and access management, but OIT has not had a formal support role for the tool outside SE’s server hosting. In addition, OIT’s engagement on identity and access management was before OIT had the IAM standards, governance, and data service capabilities it has today. Options exist today that allow for potentially streamlining identity and access management for EMS. This is a short, focused project to reassess EMS requirements for data, access management, and authentication mechanisms. Based on the requirements, the project will create a roadmap for making updates to data, access management, and authentication that works within current standards and allows for clarification of OIT and UMC responsibilities. The project will prioritize identifying a minimal viable product (mvp) solution to alleviate the manual account provisioning/reprovisioning/deprovisioning UMC is doing today.

Reassessment of EMS identity and access management needs Clarified technology roadmap Clarified roles and responsibilities

Qualtrics is an OIT common good service used by over 6,000 CU students, faculty, and researchers at the University of Colorado Boulder annually. Students account for 81 percent of all Qualtrics accounts. Qualtrics is currently not approved for the collection or storage of highly confidential data and there is no alternative approved solution on campus for collecting highly confidential data. Currently users must submit a secure computing exception request prior to collecting highly confidential data, a temporary process that has been developed by the Security and the Academic Technology teams to meet the needs of campus community. The process, however, is time-consuming for all the parties involved and is not sustainable. We regularly encounter surveys that collect highly confidential data in Qualtrics without going through the approval process. The goal of this project is to provide a comprehensive and sustainable solution to the campus community that will allow users to collect highly confidential data using Qualtrics for both surveys and forms, which are the most common applications of Qualtrics. This solution will benefit the University as it will reduce the security risks associated with data collection in Qualtrics. In the last couple of years, several significant use cases for collecting highly confidential data in Qualtrics have come up. Groups such as the Office of Institutional Equity and Compliance have a legal obligation to complete a Sexual Assault and Related Harms Survey. The Office of Data and Analytics receives approximately 10,000 responses annually for the New Student Survey which also has a business need to collect highly confidential data. Additionally, the Security Team and OIT have received numerous requests from researchers and other departments such as Student Affairs and Medical Services with business needs to collect highly confidential data via surveys. The Qualtrics Service Manager and the Security Team have done preliminary work to review the criteria necessary to allow collection of highly confidential data using Qualtrics, and to create a new Qualtrics instance called CUBoulderData designated for the collection and storage of highly confidential data. Configuration of the instance still requires the Security team’s review and approval before being offered to the campus community. The Qualtrics Service Manager completed the requested Systems Security Plan (SSP) security review including the evaluation of over 110 security controls and the next steps are for the Security Team to review this documentation, and to create an Action and Remediation Plan. Link to Qualtrics SSP Review. The issue is that Qualtrics doesn’t meet many of the necessary security requirements for collecting highly confidential data and risks need to be assessed and compensating controls need to be established to ensure Qualtrics can be approved for collecting highly confidential data.

This project will improve the security of the data being collected and stored in Qualtrics. This project will allow departments to collect and store highly confidential data such as gender, race, ethnicity, and sexual orientation properly without the risk of this information being shared inappropriately. This project will enable existing compliant processes to utilize Qualtrics in the collection and storage of HIPPA and FERPA data. Wardenburg, Student Affairs, Office of Institutional Equity and Compliance, and other departments have several initiatives waiting on this solution The solution will standardize a complex and time-consuming security exception process for collecting highly confidential data in Qualtrics.

CU Boulder has expressed a need for a generative AI sandbox where members of the campus community can leverage generative AI technology in a safe and secure space. This project aims to build an environment with two goals: i. Build GenAI literacy ii. Provide a safe and secure space to use Generative AI with university data leveraging a choice in model providers (providers could include Anthropic Claude to OpenAI GPT-4o and others) This project will build upon work from Vanderbilt University which has developed their Amplify GenAI Gateway (https://www.suppamplifygenai.org/). Based on the initial evaluation, this provides CU Boulder a good starting point for this sandbox. This specific phase of the project will: i. Identify 20-30 initial pilot group users from a cross section of campus ii. Deploy Amplify GenAI Gateway in CU Boulder’s AWS environment iii. Obtain approval for use of the Amplify GenAI Gateway for confidential data iv. The 20-30 initial pilot group users will provide feedback to guide future phases

Sandbox environment to build AI Literacy Confidential data approved for use Feedback mechanism to determine demand and need for future service offering

OIT maintains several private cloud infrastructures including the OIT Private Cloud, the NEO private cloud, the Security private cloud, and the RC private cloud. All these separate instances have their own hardware, their own VMware licensing, and their own R&R schedules. Historically, System Engineering’s VM pricing model was cost prohibitive for groups like Security, NEO, and RC to leverage resulting in a proliferation of multiple “clouds” under OIT’s management. This project will combine the NEO and Security private clouds into the OIT Private Cloud reducing overall hardware and VMware costs to OIT as well as simplifying management overhead. The NEO server hardware cluster supporting the NEO virtual infrastructure has reached 5 years of service life and is transitioning to extended hardware support via a third-party vendor, Service Express. OIT attempts to retire server hardware when it reaches 5 years due to the increased likelihood of hardware failures and incompatibility with the most current vSphere release. The NEO server hardware cluster is near full capacity and is not able to accommodate future virtual server/appliance growth. The Security server hardware cluster is approaching 5 years of service and should be replaced in calendar year 2025 for the same reasons the NEO server hardware cluster should be replaced. These dedicated clusters are only located in the COMP datacenter which does not allow those teams to have VMs hosted in the SPSC datacenter which could be beneficial to both teams. After developing and reviewing several cost models, the OIT Finance, Planning & Asset Management (FPAM) group approved the migration of the NEO and Security virtual systems to the OIT Private Cloud. This decision will allow OIT to more efficiently leverage the investments and capacity available in the OIT Private Cloud and avoid procuring new server hardware and VMware licensing to create new NEO and Security standalone virtual infrastructures. As of September 2024, the OIT Private Cloud has the capacity to support the existing NEO and Security virtual servers/appliances without any additional investment in server hardware or VMware licensing. OIT may need to invest in the OIT Private Cloud virtual infrastructure in the future if the NEO, Security, and other teams continue to expand their virtual server/appliance footprint without decommissioning existing systems. Migrating virtual systems into the OIT Private Cloud from standalone virtual infrastructures is the most efficient option from an infrastructure and staff labor perspective.

By consolidating the NEO and Security virtual infrastructures into the OIT Private Cloud, the University will avoid ~$474,000 in server hardware and VMware licensing costs over 5-years. The NEO + Security teams will not be required to procure servers or maintain server support contracts after this project is completed. Consolidating virtual infrastructures allows for simplification of the virtual infrastructure environment and reduces support efforts, which allows the VI team more time to focus on supporting and securing the OIT Private Cloud virtual infrastructure. Consolidating virtual infrastructures allows for simplification of the virtual infrastructure environment and reduces the number of physical server hardware in the data centers. Consolidating virtual infrastructures allows for simplification of the virtual infrastructure environment and reduces support efforts, which allows the VI team more time to focus on improving automations in the OIT Private Cloud virtual infrastructure.