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.

Improve aspects of the incoming student process by reducing or eliminating delays moving data between systems and reducing account provisioning times.

Reduce built-in delays and get information to admitted students sooner and allow admitted students to take certain actions sooner.

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 email 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

Prior to January 2023, all CU Boulder students were provisioned Gmail as their default email service while faculty and staff were provided Microsoft Exchange accounts as their default. Faculty and staff were offered the option to switch to Gmail via a web form on the OIT website. As a result of Google’s announced storage limits, CU Boulder is making the shift to Exchange as the default email system for all users. As of January 2023, all new students are provisioned Exchange email accounts and the option for faculty and staff to switch to Gmail is no longer permitted. We are currently in a state where CU Boulder has active users and secondary accounts on both Exchange and Gmail. As part of the Google Migration project, Faculty and Staff on Gmail were given multiple windows, beginning in August of 2023 to migrate to Exchange. This project intends to continue that task and extend it to students, POI, secondary and any other remaining account types.

Single campus email provider (security, calendaring, routing) Simplification of support Removal of barriers for future provisioning/deprovisioning projects

In March of 2021, Google notified its customers that unlimited storage will no longer be available. Google for Education is a server OIT is has offered since 2008, taking advantage of Google’s free service offering for education customers. In the announcement Google claims the service was never meant as a storage solution, but rather a collaboration platform that provides storage. As such, it is not Google’s intention to provide space for mass amounts of storage, but rather small amounts of storage to accompany their cloud services and native file types. Google’s announcement included the intent to cap data usage by July of 2022 for all education customers. Customers using the free services from Google will receive an amount of storage based on the university’s enrollment numbers across a 90-day period. In June of 2021, Google announced additional provisions provided to Internet2 members, where universities will be able to make a multi-year commitment to the paid version of Google for Education and in return, the amount of time they will be provided to reduce their consumed storage will be extended for the duration of the contract. While this is a tempting offer, CU Boulder should make every effort to reduce its usage from 3.2 PB to 300 TB by July of 2022 in order to avoid additional costs and duplication of services. Furthermore, Google currently has no plans to offer anywhere close to the amount of storage CU Boulder is currently consuming, resulting in the need to significantly reduce our storage usage regardless of purchasing licenses. This project will shift the primary focus of the Google Suite from a storage and collaboration solution to a collaboration only platform and take advantage of the Microsoft offered cloud storage solutions as a replacement by migrating all non-native google file types to Microsoft OneDrive, Teams, and SharePoint. All Google accounts will be accompanied by a small amount of allotted storage with an enforced quota, sufficient for the collaborative focused aspect and Google specific file types of Google for Education. This project will make every effort to maximize usability, specifically for the teaching and learning community, by providing alternative solutions for departmental data, research data and non-student email. This project will be charged with reducing the storage usage in Google by 3 Petabytes down to 300 TB and maximizing the usability for collaboration among active CU Boulder students and faculty. This project should also consider the creation of a steering committee that meets periodically to review the status of the project and approve large campus affecting decisions that the project could not otherwise make.

Consolidation and consistency of data storage Reduction in cost of storage Tighter integration into day-to-day work with Outlook and Teams. Scalable storage and data protection/redundancy for campus data More secure storage that meets university data classification requirements.

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.

The Office of Information Technology, IT Service Engineering (ITSE) unit requires observability solutions to perform their daily operational functions. Observability commonly entails at least three areas: • Monitoring • Alerting/Visualization • Log aggregation/analytics Additionally, it is common to include application or distributed systems tracing. Currently ITSE uses Nagios for monitoring and alerting, however the current implementation of Nagios is not meeting today’s monitoring and alerting requirements. Furthermore, there are issues with the current Nagios system where recovery alerts are being lost. We are worried that eventually outage alerts will be lost as well. Log aggregation is done with in-house infrastructure and scripting, which is rudimentary at best. Systems send some logs through rsyslog to a central logging server which merely dumps those logs onto a single disk. The purpose of the previous project charter was to establish the CU Boulder requirements, share the requirements with the potential vendors and obtain budgetary quotes. The purpose of this project charter is to allow us the time to engage with the vendors that are within our approved budget and verify the solution meets all our requirements. A good observability solution will allow us to set up common and custom monitoring, alerting on events, visualization of system/application status, log aggregation with visualization and searching abilities, and application tracing. It may well be that our “solution” is made up of a suite of tools, not necessarily a single vendor product. We will need to support multiple teams with different workloads, automated by different tools, for integrating into an observability solution. Having an observability solution that OIT can leverage will allow more efficient troubleshooting, more accurate system and application monitoring and alerting, better support for observability of dynamic services, and optimization of applications and services. Almost every service OIT provides could be improved with this type of product. The objective of this project is to: • Leverage previously gathered requirements to select possible solutions • Interview vendors and demo solutions • Collect budgetary quotes • Use the above information (as well as the current budget for this project) to select product(s) that will satisfy most requirements for monitoring, alerting, visualization, and log aggregation and analytics • Plan and implement selected product(s)

Reduce development time as we potentially would not have to shop a new solution for each application Reduce time to troubleshoot application, service, and system issues Assist with optimizing our applications and services by allowing more insight into how they run and potential problems

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

This project builds on the decisions made in the ‘Inventory, Equipment, and Asset Tracking Project” and will define the tool(s), processes, roles, and architecture that are needed to create a centralized and consistent Asset Management program in OIT. A large part of this project will be understanding the detailed requirements for tracking CU property in OIT by the various OIT units who do this. The project will then analyze internal and external tools that could be used. The project will identify the technology and associated architecture, roles, and processes that will need to be implemented for a more holistic, centralized, and consistent Asset Management program in OIT. Active participation from the areas in OIT that track CU property (FPAM, PAL, DRR, RC) will be important for the success of this project and the future implementation project. A future phase of this project, or a new project, will implement the chosen technology solution and supporting architecture, process, and people.

Comprehensive plan for technology, people, and processes needed for centralized and consistent tracking of CU property in OIT.

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

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