Why a Cloud Strategy is Your Umbrella

Over the last decade, our institution has moved from occasionally adding cloud services to adopting a cloud-first strategy. Along the way we have made our share of mistakes and I hope, for those starting out, this post can help you avoid some of these.

Before jumping in and discussing our campus strategy I looked at some data that Dr. Kenneth Green has on his website from the 2014 Campus Computing Project (CCP). First, the CCP showed that over 80 percent of the institutions responding (close to 500) have outsourced student email to either Google or Microsoft. In addition, 47 percent of the institutions now run their learning management system as a vendor-hosted system. The other interesting fact is that only 29 percent of campuses have a strategic plan for cloud computing, a mere 2 percent increase from a year earlier.

In essence, higher education institutions are moving to the cloud for critical operational systems with limited planning. This article will discuss a streamlined approach to managing cloud services that campuses can use to get started.

As background, UMBC joined InCommon in 2005 and adopted our first enterprise cloud service at that time. The first of my presentations that I can find where I mention the term SaaS was July 2008 when I spoke to the International Association of Internal Auditors on Identity Management. Also in 2008, I was appointed to the Internet2 Applications and Middleware council and had the opportunity to work with other community leaders on an effort to improve the way cloud services are provided to higher education.

This program, now referred to as Internet2 NET+, was organized by Internet2 to support campuses as they began working to implement cloud services. To support the NET+ program, Internet2 developed a service validation process for universities to evaluate potential cloud services. From being a university participant in a number of these service validations and listening to the comments of very thoughtful peers, I think there are four fundamental questions that institutions must ask and answer as they move to cloud services:

1.  Does the cloud service you are considering meet the functional requirements and the necessary service level agreements for your institution?
2. What are the procurement and legal issues you need to consider, especially long-term pricing terms and the exit clause for leaving a contract?
3. How do you adequately assess the risk and determine if appropriate security controls are in place for a cloud service?
4. How do you technically integrate a variety of cloud services into a coherent system that works for the people using those cloud services?

For UMBC, asking and answering these questions led us to rethink a number of assumptions and change long-standing procedures. In answering the first question about meeting functional requirements and the necessary service level agreements, for example, we realized that we needed a new type of system analyst to support units that were looking at cloud services. As a result, we created the position of cloud analyst, who supports units planning to make cloud service purchases for systems that will broadly support the campus. The cloud analyst works with the sponsoring departments to get the materials together to meet with our cloud service review team. The cloud service review team has representation from our CISO, legal, procurement, and our AVP for business services. Once the review committee has validated the cloud service meets campus requirements, the cloud analyst works with the department to finalize a business case and present it to our Campus System Executive Committee for approval. These processes add 30-90 days to most procurements but makes certain that we are doing things right.

A second change is the development of new procedures for procurement. Two years ago our Campus System Executive Committee approved a rule that all cloud service procurements must be reviewed by the cloud review team before the procurement will move forward. The CISO works closely with the purchasing unit to understand what data will be stored in the system and to apply the same risk management process we use for on-campus systems. Based on the outcome of the risk assessment, that will trigger the security controls that must be in place. This information is then used to inform the Office of General Counsel when they review the contract terms. In general, we have found that the best legal contracts in terms of fairness are the ones developed for cloud services under the Internet2 NET+ program.

The third change we have implemented is extending our security model to the cloud. This effort utilizes the work that the EDUCAUSE Higher Education Information Security Council (HEISC) has done with the Internet2 NET+ team to partner with the Cloud Security Alliance to create version 3 of the Cloud Control Matrix. Version 3 added many more controls based on the type of data used and is an excellent product. The Internet2 NET+ program requires vendors to adopt this framework for documenting their security controls and Increasingly other vendors are adopting this as well. For UMBC, this tool allows us to adequately document the security controls in cloud services, for all our higher risk services we require this to be done.

Finally, to ensure that we can create a highly integrated set of services we have a procurement requirement that all cloud services must support the InCommon Shibboleth system. There are 238 commercial service providers in InCommon. We know that we can safely integrate with those providers in less than a day and the service will seamlessly work with our portal and single-sign-on environment. The other aspect of integration we look at is identifying the data from the cloud service that should be extracted and loaded into our data warehouse system. We want the data warehouse to provide a unified view of the student or employee experience. By integrating the most important data back into our data warehouse we also develop some protection should we decide we want to change vendors.

In conclusion, asking and answering these four questions have required us to rethink staff positions, develop new cross-unit teams to review services, extend and adjust our approach to security, and require specific identity management and data warehousing standards to ensure interoperability.