Cyrus as a Shared Service

I. Technical Advantages and ChallengesII. Administrative Advantages and

ChallengesIII. Notes on Legal Issues for Later Discussion

1

It Works

• Gmail and others show that cloud email can work under some circumstances

• What Circumstances would it work for us?

2

Several options for structuring a ownership of Cyrus “shared service”• One institution acts as a provider (e.g. UC

Berkeley provides Cyrus IMAP services for CMU and other institutions)

• Several institutions form an informal consortium to own and operate the shared service

• A 501 (c) 3 organization is created to own and operate the shared service

• Others we should be considering?

3

Choice of organizational structure influences benefits and challenges• For example: if a 501 (c) 3 operates the shared

service, concerns about “suing your friends” for poor service becomes less problematic

• For example: if a 501 (c) 3 operates the shared service the overhead costs of setting up the service (including legal fees) will mitigate the advantage of reducing costs to individual institutions

4

Decisions will turn on answering the question: Who are the “customers”

who must be served?• Certainly the email end-users• But also:– email administrators on each campus– security staff on each campus– legal staff on each campus– help desks on each campus– others?

5

Technical Benefits

• Reduce the hardware/VM footprint for email on various campuses (e.g. CMU operates around 20 servers to provide Cyrus)

• Establish a single code base for a number of campuses (eliminating local variations that make adoption of bug fixes and improvements a challenge)

• One organization does 7 x 24 monitoring

6

Technical Benefits

• One set of spam management and malware detection service (with one contact for vendor(s) involved)

• Common set of support (and updating) for each email client

• One plan and one cost structure for disaster recovery and business continuity

7

Technical Benefits

• Specialists in email can potentially be utilized more effectively in concentrating on a larger shared service than splitting their attention between email and other services as generalists on smaller, single campus installations

• Technical staffing on email support would scale well: no increased technical staffing in moving from 30K mailboxes to 60K mailboxes

8

Technical Benefits

• With respect to Cyrus in particular, various implementations aren’t widely divergent– Linux or linux/Solaris– Using Kerb 5 or moving toward Kerb 5– Many using Cyrus replication– Similar mail quotas at different universities

• Converging toward a single platform should open new opportunities (vendor negotiations, shared enhancements, common bug fixes, etc.)

9

Technical Challenges

• Integration with identity management systems and instantiating policies of multiple campuses

• Establishing a common data archive and retrieval mechanism

• email list management• Integration with campus directories

10

Technical Challenges

• Encryption – currently Cyrus stores mail in backend stores in plain text and implementing encryption involves substantial development effort

• Design for multi-tenancy – separate physical servers? separate VMs? Redesign for true multi-tenancy?

• Management tools – current management tools are not designed more multiple users or any kind of multi-tenancy

11

Administrative Benefits

• A single code base and multiple users of a service will make Cyrus more viable open source software– Critical mass makes it a more attractive

competitor for Google, Yahoo, and MS services– Combining and coordinating development, bug

fixing, and administrative efforts from multiple campuses creates a critical mass of expertise improving Cyrus

12

Administrative Benefits

• Universities running a shared email service will be more sensitive to higher-education specific needs– FERPA compliance, e.g. email containing

educational records (which includes a lot of email exchanged on campus) cannot be used for non-educational purposes

– Potentially uniquely valuable APIs for other educational applications

13

Administrative Benefits• Single, common set of documentation that can

be continuously improved and shared by the customers of the shared services

• Shared costs for spam and malware detection products

• Disaster recovery requires only 2 or 3 national sites rather than 2 sites per customer

• Potential for multi-site replication• One place to establish and assay security outside

of the complex university IT setting

14

Administrative Challenges

• Does the organization providing the service adhere to an SLA or not?

• If no SLA, what recourse do customers have in the case of poor service?

• If there is an SLA, what features are reasonable to expect “from universities, by universities”? Put another way, can we really simply “trust” each other do a higher degree than we can’t “trust” vendors?

• What can of penalties for poor service or incentives for good service can exist in a shared service among universities?

15

Administrative Challenges

• Help desk services– 7 x 24? Federation driven concerns ( Incommon)– Support for clients (including mobile clients?)– Response times?– Remote monitoring for help desks?

• Email archiving and restoration– Home campus can restore?– Depend on the shared services staff to restore?

16

Administrative Challenges

• eDiscovery holds and recovery– Policy and tools for home campus to execute?– Depend on central services staff to execute?

• Resource requirements and establishing costs– How will “adequate services” be defined?– How will “bugs” be prioritized?– How will new features be prioritized?– Who will establish adequate levels of staffing, refresh

cycles, and the associate costs, including appropriate salary levels?

17

Administrative Challenges

• Spam policies– Who will set tolerance levels for spam and how

will the decision be informed?– What if faculty on different campuses want

differential spam tolerance by individual user? (CMU actually has this issue internally)

• What tools will be used?– For development, testing, quality assurance,

security, etc? Who decides?

18

Administrative Challenges

• Achieving significant return on investment– Carnegie Mellon’s current cost for running Cyrus (all

factors including SPAM software): $380K/year or $19/mailbox/year for 2GB quota

– Berkeley’s cost appears to be around $13/mailbox/year– It seems that most services that have reached a

“commodity operations” level are likely to be the ones on which we can save the least by making them shared services because they are already fairly inexpensive

19

Administrative Challenges

• “Keeping up with the Joneses” – The email case is particularly glaring – Gmail will

be able to offer more features, update features faster, and probably offer more storage space that the Cyrus shared service ever can

– Both open source products and commercial vendors of email enabled products will actively seek integration with Gmail while we will have to pound on them to adopt standards that allow integration with Cyrus

20

Administrative Challenges

• Email for research– Many of us make anonymized features of email

available to support faculty research projects (CMU recently did this with phishing and filtering research)

– Will the shared service provide this additional service to member institutions? Will there be an associated cost. (Our faculty are not accustomed to their being an associated cost.)

21

Administrative Challenges

• Email for security– Access to metrics and metadata will need to be

addressed (some schools may like to know how many phishes delivered, read/unread, responded to, by whom, etc. This is critical information for incident detection and handling.)

22

Legal Advantages

• Providing this service in an ISP fashion solidifies a “conduit” role for this service similar to that for networking.

• Are there any more?

23

Legal Challenges

• The sheer cost. At least one estimate puts the cost of setting up a 501 (c) 3 and negotiating the associated agreements and SLAs at around $500K in legal fees. That detracts from any “cost savings”

• Resolving conflicts with university policies and faculty politics: “I don’t want my data to be under the control of anyone other that CMU, that is the only way I can be sure it is protected.”

24

Legal Challenges

• Legal responsibility and indemnification– If email under litigation is lost, will the provider

indemnify the institution depending on the shared service? (The same issue would arise with a commercial provider, but now we are operating ‘in the community.’)

– Insurance will need to be purchased for “when things go wrong” and that adds to the cost side of the cost/benefit calculation

25

Legal Challenges

• Legal advice and procedures– The provider will need to secure their own counsel– Procedures for handing subpoenas, cease-and-desist

orders, blacklisting of domains, etc. will need to be established an agreed to by participants

– A common understanding of procedures sufficient to meet e-discovery demands must be established, or different standards will have to be made available for different schools

26