At the beginning of 2019, the RHEDcloud Foundation and RHEDcloud Project did not yet exist. Emory University and Emory Healthcare were finalizing provisioning and network automation to launch the AWS at Emory service it had been working on for 30 months. In 2018 Emory decided to open source the methods and software products that Emory used to implement the service to build a community of collaborators to take the work farther not only for AWS, but also for Google and Azure. However, none of the Emory institutional approvals or agreements to create this collaboration had been completed. Seven other collaborators expressed interest in joining the collaboration by October 2018. These collaborators were other research universities, pharma companies, cloud providers, and services providers. Emory originally planned a conference of these collaborators for October or November 2018, but deferred that effort to focus on finalizing and launching its own service.
Despite Emory’s decision to delay an in-person conference, several additional collaborators were identified in October and November 2018. In response to the interest in establishing this collaboration, Emory engaged the Atlanta law firm of Davis, Matthews & Quigley (DMQ) to help found the RHEDcloud Project and its corporate entity. Emory advanced DMQ $25,000 to initiate the project with the expectation that the resulting entity would return this advanced fee to Emory once it was established and the collaborators had paid their membership fees. The RHEDcloud Foundation repaid Emory University, and Emory University’s present relationship with RHEDcloud is limited to being a co-equal institutional member. As of January 2020, three of the five RHEDcloud officers happen also to be Emory employees, but Emory does not own or control RHEDcloud, nor is it considered to be a “related organization” for IRS purposes.
During the first half of 2019 John Connerat, Rich Mendola, and Steve Wheat from Emory served as the founding officers of the RHEDcloud Foundation and initial Board of Directors (full Board of Directors was seated in June 2019). They worked with DMQ in January and February 2019 to structure and found the RHEDcloud Foundation as a Georgia non-profit 501(c)(6) corporation. The RHEDcloud Foundation was officially formed on March 4, 2019 and its non-profit status was reviewed and accepted by the Internal Revenue Service on September 30, 2019.
“The purpose for which the Foundation is organized under § 501(c)(6) of the Internal Revenue Code of 1986, as amended, is to provide an association for businesses and individuals to collaborate in advancing research, healthcare and higher education cloud computing with enhanced security, compliance and integration.”
As such the RHEDcloud Foundation and RHEDcloud Project are first and foremost a collaboration of member organizations and individuals to work together to advance cloud computing for research, healthcare and higher education. The RHEDcloud is not primarily a software foundation or producer of software, although developing and releasing software that implements common security, automation, and integration requirements is one of the enumerated activities of the RHEDcloud Foundation. In its Internal Revenue Service Form 1024 filings in pursuit of non-profit status, the RHEDcloud Foundation enumerated the activities of the Foundation quite specifically:
1. Promoting and assisting in collaborative research and software development through data collection and documentation of security requirements and risk assessments
“Within the first year of its establishment, the Foundation will determine goals for each area of research and development. The Foundation will coordinate various collaborative research efforts to establish what security risks may be imminent, create and develop centrally managed information security and compliance controls to address such identified risks, and provide common methods of implementation and integration for both its members and the public. The Foundation will provide a consistent framework and clear standards for all software enhancements produced by its research and development. This activity will further the Foundation’s scientific purpose as the Foundation will be promoting, conducting and fostering research, studies, and analysis into the intricacies of cloud networks. This activity will account for 30% of the Foundation’s time.”
2. Releasing collected data, analysis, and common products
“Within the first two (2) years of its establishment, the Foundation will release various products that will help users and providers strengthen their security measures and product implementation. For example, the Foundation will release security assessments and various implementations of security measures. Furthermore, the Foundation will provide data and statistics with respect to its research and development to both its members and the public through its web site and resources therein. This activity will account for 30% of the Foundation’s time.”
3. Creating and releasing educational materials and coordinating educational opportunities
“Within the first two (2) years of its establishment, the Foundation will create and release educational materials in various forms. The Foundation will publish monthly blog posts and articles to keep its members and the public abreast on new developments and any issues that arise from different security measures and risk assessments. The Foundation will also create and produce manuals and booklets to further explain certain complexities of the implementation process and other products. Additionally, the Foundation will release video webinars and recorded broadcasts in order to educate both its members and the public on the security assessments, risk assessments, implementation and administration of products. Furthermore, there will be opportunities, at least annually, for Foundation members and the public to attend live educational conferences in Atlanta, Georgia that will focus heavily on the Foundation’s activities and progress in the areas of research and development. This measure will further the Foundation's activities and progress in the areas of research and development. This measure will further the Foundation’s educational purpose as it serves to help the community which is engaged in this type of practice on ways to better secure and enhance systems, which they can integrate into their own business or usage. The Foundation will also help to disseminate information and increase knowledge and understanding in relation to cloud usage. This activity will account for 40% of the Foundation’s time.”
The statement of purpose, enumeration of activities, and the distribution of activities provides specific guidance to the RHEDcloud officers and board of directors in establishing Foundation goals and conducting foundation activities.
During this period the founding officers also worked closely with the Emory Office of Technology Transfer (OTT) to facilitate the transfer of the intellectual property in the form of designs, documentation, and software of the AWS at Emory service to the RHEDcloud Foundation using an appropriate mechanism. Emory OTT identified a perpetual, irrevocable license with rights to sublicense as the most suitable approach to grant the nascent RHEDcloud Foundation rights to the intellectual property for the purpose of initiating and operating the RHEDcloud Project.
The founding RHEDcloud officers worked through the Emory OTT invention disclosure process to disclose and document all of the designs, methods, and software that implemented the AWS at Emory services. This disclosure is enumerated in the Emory AWS Service Tech Transfer Background Documentation. After several months of documentation, discussion, and research the Emory University and the RHEDcloud Foundation entered into a definitive license agreement on June 17, 2019. This agreement confers upon the RHEDcloud Foundation:
“…a perpetual, non-exclusive, no-charge or fee (including, without limitation, royalty fees), worldwide, royalty-free, irrevocable copyright license to reproduce, prepare derivative works (the “Derivative Works”) of, publicly display, distribute and sublicense, internally and externally, the Software and such Derivative Works, in source code and object code form, and to otherwise utilize the Software for its non-profit activities related to the Mission.”
In 2019 eighteen (18) organizations joined the RHEDcloud Foundation as founding members representing research universities, pharmaceutical companies, cloud platform providers, and cloud service providers. These organizations are:
Princeton University (Note: joined in January 2020)
The University of North Carolina released a statement about its membership and participation in the RHEDcloud Project and a link to that statement is provided above. If other sites have published similar statements, the RHEDcloud Project would appreciate you providing that link, so we could reference those statements on the project web site.
Each of these institutional members pay $10,000 per year in membership fees, and the billing and accounting processes for this program have been implemented.
The individual membership program in which individuals can join has not yet been implemented.
In June 2019 the full RHEDcloud Board of Directors was seated with one representative from each member organization. During this meeting, Board Chair Rich Mendola advanced Klara Jelinkova as the preferred Vice President and Vice Chair candidate. This vote was advanced and seconded with no dissension.
During the October 2019 Board meeting, a vote was convened for another Vice President position; Vice President of Industry Engagement, as a way to allow industry to have a “voice” on the Board. Hunter Ely (representing Palo Alto Networks on the Board) was elected to this position during this meeting. This position will coordinate with and provide a mechanism for industry to engage with the RHEDcloud Foundation and to utilize industry partners to advance the mission of the Foundation.
AWS at Emory
On March 6, 2019 Emory implemented AWS at Emory in production for a limited group of Emory researchers. This “soft launch” lasted for three months from March 6 through June 7 at which time Emory released the service for general availability.
In the first 10 months of operation during the soft launch and general availability, the Emory users auto-provisioned 145 accounts in production that are integrated with Emory’s network, identity, authentication/authorization, and security infrastructure. Accounts are presently in use by over 40 research teams, one Emory Healthcare administrative system, and central IT. There is a nearly even split of 45% HIPAA compliance class accounts and 55% standard compliance class accounts. These accounts are used for applications such as cytometry, metabolomics, metagenomics, proteomics, genome sequencing, methylation and microbiome data, deep brain stimulation, and more. See the appended worksheet for a detailed listing of the research groups, their applications, and the primary AWS services they are using. In November, Emory Healthcare began using AWS at Emory to develop and test a clinical workflow application and run it in production for the Orthopedics department. There are several other departments interested in rolling out this same clinical workflow application in their own accounts if this implementation is successful with Orthopedics. The primary drivers for hosting this clinical workflow app in AWS at Emory were the ability to run the service on AWS managed services that required much less administration than traditional on-prem, full-stack administration and the ability to clone and deploy the application for other departments in an automated manner.
Customer feedback on the AWS at Emory service has been positive, citing the automation, integration with Emory infrastructure, security features, and the white glove support provided for users adapting their applications the cloud environment. Many AWS at Emory users are implementing solutions in the cloud for the first time and some are migrating their work from non-Emory AWS accounts to Emory-managed accounts. Both categories of users need support in both the form of the AWS at Emory support team and AWS Enterprise Support to work efficiently and be successful.
Emory Cloud Infrastructure Migration Project
In addition to implementing the AWS at Emory service with RHEDcloud applications and services, Emory University also deployed select RHEDcloud applications and services to support its separate Cloud Infrastructure Migration Project (CIMP). In Fall 2019, Emory deployed the follow RHEDcloud components for the following purposes:
Provide a user interface for AWS account metadata management, account and user notifications, and security risk detection
RHEDcloud AWS Account Service
Manage CIMP AWS account metadata and compliance class for security risk detection
RHEDcloud Security Risk Detection Service
Detect and log security risks for the CIMP AWS accounts
RHEDcloud Temporary Key Issuance (TKI) Client
Provide a user interface for temporary key issuance with enterprise single sign-on, multi-factor authentication, and account/role selection
RHEDcloud Temporary Key Issuance (TKI) Service
Implement backend integrations with single sign-on, multi-factor authentication, account metadata, and AWS Security Token Service for the TKI Client
These separate deployments of RHEDcloud technology serve AWS accounts that are owned and managed by Emory’s central IT department for the purpose of migrating on-premises IT infrastructure to AWS.
At the beginning of December 2019 Rice University launched a project to implement RHEDcloud for AWS as a proof-of-concept for cloud research computing. Rice engaged Surge to perform its RHEDcloud launch and knowledge transfer engagement. Rice University's internal team consisted of research cyberinfrastructure engineers as well as network, system and IAM engineers.
As of December 31, 2019 Rice has engaged Surge; created the initial AWS administrative and master accounts required to implement; performed detailed integration analysis for the identity management, directory, authentication, and authorization integrations; and identified compatible Cisco ASR routers to implement the network automation. Surge has deployed initial CloudFormation stacks to the administrative account and begun deploying the web applications and web service required to implement the solution.
The main goals of the RHEDcloud implementation at Rice are:
Test portability of Emory code and the ability to deploy it at other sites
Test integration of the InCommon Trusted Access Platform (a community developed, open source IAM suite)
Provide additional deployment documentation and roadmaps for other possible RHEDcloud AWS sites
In early 2020, Surge, Rice, and Emory will complete the deployments of web applications and web services and implement and test the integrations.
Business and Finance Infrastructure and Key Dates
RHEDcloud’s annual membership year runs from April through March 31 annually. New members pay a prorated portion of the membership fee to co-terminate the membership year to the same cycle.
RHEDcloud’s fiscal year run from September 1 through August 31 annually. In its first year of operation, the financial period was from March 4, 2019 through August 31, 2019 for the inception period.
RHEDcloud Foundation, Inc. uses Axos Bank and Capital One, N.A. for various banking and credit relationships. Like any small business, RHEDcloud has daily operational accounts and credit cards to handle its daily activities. Since many of its expenses are “software-as-a-service” for the infrastructure required for its nonprofit mission, credit card usage is an integral part of it operations.
The RHEDcloud Board of Trustees has authorized an annual salary of $10,000, paid in monthly installments, for its five officer positions: President, two Vice Presidents, Secretary, and Treasurer. The Board of Directors volunteer their time and receive no compensation. Likewise, several officers have declined the salary--not because there is a conflict of interest with their primary employer--but simply to avoid the bureaucratic overhead and potential complexity of having to manage the conflict. For those officers who draw a salary, their primary employer has acknowledged and approved of the annual salary paid by RHEDcloud. All payroll payments, tax withholding, and related payroll functions are managed through the Quickbooks payroll modules.
RHEDcloud Foundation maintains Directors & Officer insurance, general liability insurance, and workers’ compensation insurance with deductibles and coverages commensurate with the types of activities engaged by the Foundation.
RHEDcloud utilizes Quickbooks online for all of its financial functions, including invoicing, customer management, payroll, accounts payable, accounts receivable, reconciliations, and management and Board reporting.
Tax Reporting and Filings
RHEDcloud complies with all federal, state, and local laws and regulations with regard to tax filings. Such tax filings include but are not limited to:
IRS Form 940 Federal Employer’s Annual Federal Unemployment Tax (FUTA)
IRS Form 941 Federal Employer’s Quarterly Federal Tax Return
RHEDcloud engages Tomkiewicz Wright, LLC as its independent external auditors. The audit begins in late September once the August 31 books are completely closed and lasts approximately 8-10 weeks with the final report and governance letters being available around mid-December.
Web Site, E-mail, Telephone, Wiki, Jira, and Bitbucket Resources
In January through April 2020, the RHEDcloud officers established the RHEDcloud web site at https://www.rhedcloud.org in addition to e-mail, telephone, wiki, issue tracking, and Bitbucket code repository infrastructure. The following is a list of infrastructure and the providers used.
In 2019 the RHEDcloud Project established its Bitbucket team at https://www.bitbucket.org/rhedcloud. The RHEDcloud project presently has 35 public repositories for RHEDcloud for AWS and RHEDcloud for GCP for the following products:
AWS Account Web Service
AWS Admin Master Account CloudFormation Templates and Deployment Automation
AWS Organizations HIPAA Compliance Class Service Control Policies
AWS Organizations Standard Compliance Class Service Control Policies
AWS Pipeline Scripts
AWS Account-Level CloudFormation Templates and Tests
AWS Type 1 VPC CloudFormation Templates and Tests
AWS Type 2 VPC CloudFormation Templates and Tests
Common AWS Python Test Utilities
AWS Firewall VPC CloudFormation Templates and Tests
AWS Resource Tagging Profile Web Service
AWS Temporary Key Issuance Web Service
AWS Elastic Beanstalk Extensions
RHEDcloud Landing Page for AWS Web Application
RHEDcloud Console for AWS Web Application
GCP Project Web Service
GCP Project-Level Deployment Manager Configurations and Tests
GCP Type 1 VPC Deployment Manager Configurations and Tests
GCP Pytest Docker Base Image
GCP Organization-Level Deployment Manager Configurations and Tests
GCP Pipeline Scripts
GCP HIPAA Compliance Class Organization Policies
GCP Standard Compliance Class Organization Policies
RHEDcloud Landing Page for GCP Web Application
RHEDcloud Console for GCP Web Application
Network Operations Web Service
Cisco ASR Web Service
Security Risk Detection Web Service
E-mail Address Validation Web Service
Identity Management Web Service
RHEDcloud Message Object APIs
ServiceNow Web Service
Firewall Web Service
Lightweight Directory Web Service
Directory Web Service
Emory migrated 25 AWS at Emory repositories from Emory Bitbucket to RHEDcloud Bitbucket. This process involved migrating the repositories, changing the repository pipelines to deploy to RHEDcloud environments instead of Emory environments, and then implementing deploy-only repositories and pipelines back at Emory that pull software products from the RHEDcloud repositories and deploy them at Emory. These deploy-only pipelines established the pattern for RHEDcloud sites to adopt RHEDcloud products and stay plugged into the project to easily accept the most recent features and new components. In addition to AWS at Emory, deploy-only pipelines have also been implemented for the Emory Cloud Infrastructure Migration Project (CIMP) and Rice University.
Emory, Burwood, and Google worked closely in Fall 2019 to implement 10 new repositories for RHEDcloud for GCP products. These GCP repositories have been public from the time of their creation.
Soup-to-nuts demo of the entire service using the production deployment at Emory University & Emory Healthcare. If you have time for only one demo, watch this one for the big picture with many details.
How to access RHEDcloud web services using common web services protocols.
In Fall 2019 Brad Sanford, CISO for Emory University and Emory Healthcare, convened the RHEDcloud Security Risk Assessment Committee. The committee met several times and Brad walked the group through Emory’s approach to performing and recording security risk assessments for cloud platform services.
To date, Emory has reviewed one hundred and twenty four AWS services, with one hundred services approved for use in standard accounts, seventy two services approved for use in HIPAA accounts, and twenty four services are restricted from use in both standard and HIPAA accounts. The remaining eighty five AWS services are presently blocked pending review.
In Fall 2019 Jimmy Kincaid, Network Architect for Emory University and Emory Healthcare, convened the RHEDcloud Network Committee. The committee met once and Jimmy walked the group through the potential activities of the committee.
The next committee meeting is being planned. The goal of the next meeting is to get participants up-to-speed with the current network automation environment as well as what updates and enhancements are currently being considered or worked on. Once the group is level-set, the committee will prepare a presentation to the board for approval of the committee’s general focus and activities.
Marketing and Communication
The Marketing and Communication Committee is preparing a strategy and plan to present to the officers and board for approval.
Automation, Infrastructure, and Integration
Steve Wheat, Chief IT Architect for Emory University and Emory Healthcare, convened the Provisioning and Automation Committee in March 2019 shortly after the incorporation of the Foundation and RHEDcloud Project launch. The group has established two types of meetings, biweekly committee meetings for 90 minutes and three 90-minute work sessions each week. With the initiation of the Microsoft Azure proof-of-concept project in January 2020, the committee will add two additional 90-minute work sessions per week for a total of five 90-minute work sessions per week.
The primary objectives for the Provisioning and Automation Committee in 2019 were to define proofs-of-concept for GCP and Azure and initiate those projects. Development team members met with Google and Microsoft to define these projects and prepare the RHEDcloud for GCP Proof-of-Concept Proposal and the RHEDcloud for Azure Proof-of-Concept Proposal. These proposals each define specific goals and a timeline for their respective proofs-of-concept projects. The full committee reviewed the project proposals and all have been invited to participate in the work sessions if they have availability.
The Provisioning and Automation Committee proposed the name be changed to Automation, Infrastructure, and Integration (AII) to better reflect this broader focus of the committee’s work.
Google Cloud Platform
In August and September 2019 Google and Automation, Infrastructure, and Integration Committee members met to define the scope of a RHEDcloud for GCP Proof-of-Concept project that would prove all major aspects of the RHEDcloud for AWS service for Google Cloud Platform. The group defined specific goals to demonstrate the following 10 aspects of the service:
The group estimated it would take approximately 1,100 hours of effort and cost approximately $156,000 to implement the proof-of-concept. Google agreed to fund this effort by paying both for RHEDcloud’s consulting resources and Google’s preferred GCP expert partner Burwood. The project was structured such that the RHEDcloud development team would perform most of the development and implementation work and Burwood would provide the GCP expertise, training, and help to get the RHEDcloud for AWS team up to speed with GCP.
The proof-of-concept team has completed its work on defining a GCP domain, organization, user and group directory integrations, project-level structures, VPC-level structures, templating, template testing strategy, and a number of other aspects of the planned service. At the end of December 2019, the team started working with the Emory Network team and walked them through all of this information. In January 2020 the team will try to use the same approach to connecting the GCP projects to the Emory network using the current AWS at Emory production site-to-site VPN automation. The development team is also deploying and adapting the RHEDcloud for AWS applications and web services now to auto-provision GCP projects using the new templates the team developed.
As of December 2019 the proof-of-concept team would like to bring everyone up to speed on what it accomplished during October, November, and December 2019 and get approval to plug these GCP projects and automation into the Emory network to achieve the final goals of the proof-of-concept project by demonstrating auto-provisioning and security risk detection and remediation. To that end in January 2020 the team will also need some realistic risk assessments for several GCP services from the Emory Information Security or the RHEDcloud Security Risk Assessment Committee, so that the proof-of-concept team can implement realistic controls. Both GCP and Azure seem to have more capabilities for over-arching declarative controls than AWS does, so security risk detection and remediation may be less of a focus than it is for AWS, but the team needs risk assessments and specifications for controls to implement for GCP. The team implemented the framework in which to implement these controls at the organization, folder, and project level, and has implemented many of the foundational controls that are all familiar from RHEDcloud for AWS such as restricting traffic to ingress and egress through the on-prem network through the site-to-site VPN tunnel, developing example organization policies and IAM policies for the same roles that were established for AWS, etc.
In the next and final phase of the proof-of-concept the team will focus on demonstrating the automation, implementing realistic security requirements, recording demos, and estimating costs for a production build-out of the service so that it could be implemented at one or more RHEDcloud sites. Presently the team expects to complete this work by March 1, 2020.
In September and October 2019 Microsoft and Automation, Infrastructure, and Integration Committee members met to define the scope of a RHEDcloud for Azure Proof-of-Concept project that would prove all major aspects of the RHEDcloud for AWS service for Microsoft Azure. The group defined specific goals to demonstrate the following 10 aspects of the service:
The group estimated it would take approximately 1,200 hours of effort to complete by ACS, Microsoft’s preferred Azure expert partner, and the RHEDcloud development team. Microsoft has agreed to fund both the RHEDcloud development team and their partner ACS to perform this work. Final approvals are expected in early January 2020. The group estimates this work will take four to five months to complete and the proof-of-concept project will run from January through May 2020.
Surge and Emory worked together to design a RHEDcloud for AWS Launch and Knowledge transfer engagement to help sites get up and running quickly with RHEDcloud for AWS with minimum cost and effort. The engagement costs about $28,000 and is intended to run over one to two month depending on the availability of resources at the implementing site. Surge has performed this work at Emory in implementing RHEDcloud environments both for AWS at Emory and the Emory Cloud Infrastructure Migration Project (CIMP). As of December 2019 Surge is also performing this engagement for Rice University.
This engagement is designed to accelerate RHEDcloud for AWS launch by bringing in several RHEDcloud and DevOps experts to setup RHEDcloud for AWS and show your team how everything works as they go. After this engagement the implementation site should have four working environments of RHEDcloud for AWS that are integrated with the RHEDcloud project infrastructure and several of the site’s own enterprise systems. The specific goals of the engagement are to:
Set up an AWS administration account with all Beanstalk environments, RDS, Amazon MQ, account series master accounts, and other infrastructure (60 hours):
The following are required:
RHEDcloud AWS Account Service (Account Metadata Repository and Provisioning)
RHEDcloud Console for AWS (Account, VPC, Service, Network, Provisioning, and Notification Management)
RHEDcloud Landing Page for AWS (Launch page with links into the AWS Console, RHEDcloud Console, Service Request System, AWS Service Inventory and Risk Assessments, etc.)
Security Risk Detection Service (Security Overwatch deployed with any or all of the existing detectors developed by the RHEDcloud project)
E-mail Address Validation Service (E-mail Address Validation for Addresses used with Cloud Accounts)
Temporary Key Issuance (TKI) Service (Accelerates and Simplifies User Access without Long-lived Credentials)
IDM Service (Exposes Roles and Role Assignments/Memberships to the Other Services listed here---presently implemented for NetIQ, but also implementing for Grouper and others)
Directory Service (Exposes an organization’s person search features to the other services listed here)
Financial Account System Service (Exposes financial account system numbers to the rest of these applications and services for validation)
The following are optional and require 20 more hours added to this engagement if the site chooses to deploy them (depending on what the site is doing and what network, firewall, and other infrastructure they have):
Network Operations Service (Network Automation for Site-to-Site VPN and Static NAT)
Cisco ASR Service (Router-level automation for Site-to-Site VPN and Static NAT---presently implemented for Cisco ASR routers using NETCONF/YANG, but could be extended to other equipment and standards)
Elastic IP Service (Orchestrates On-Prem Static NAT for the Cloud)
Firewall Service (Exposes On-prem and Cloud-based Firewall rules for VPCs---presently implemented for Palo Alto firewalls, but could be extended to others)
Implement the implementation site’s deploy-only Bitbucket pipelines in a Bitbucket account for the site to deploy DEV, TEST, STAGE, and PROD environments that pull from the master RHEDcloud repositories, including SAML 2.0 SSO integration (40 hours)
Required deploy-only repos and pipelines
RHEDcloud AWS Account Service
RHEDcloud Console for AWS
RHEDcloud Landing Page for AWS
RHEDcloud Security Risk Detection Service
RHEDcloud Email Address Validation Service
RHEDcloud TKI Service
RHEDcloud TKI Client
RHEDcloud IDM Service
RHEDcloud Directory Service
RHEDcloud Account CloudFormation Templates
RHEDcloud Type 1 VPC Template
RHEDcloud Standard Service Control Policies
Financial Account Service
Optional repos and pipelines (depending on what the site is doing and what network, firewall, and other infrastructure they have)
RHEDcloud Network Operations Service
RHEDcloud Cisco ASR Service
RHEDcloud Firewall Service
RHEDcloud Elastic IP Service
Perform training and knowledge transfer on RHEDcloud account series, pipelines, and environment administration (20 hours)
Demonstrate the purpose and function of all of the RHEDcloud for AWS middleware and serverless infrastructure
Demonstrate the purpose and function of RHEDcloud AWS master accounts and account series
Implement initial release of custom data providers for IDM, directory, and financial account number validation web services (approximately 120 hours, depends on directory, IDM, and financial system complexity)
Unless the implementing site uses NetIQ, a new data provider must be implemented to expose the site’s roles and role assignments or role memberships to the rest of these services. The RHEDcloud project is presently already working on a data provider for Grouper, but any IDM solution that has an API, database, or directory store should be able to be plugged into this IDM web service
Almost every implementing site will have a directory, which needs to be exposed to these applications as a web service. In some cases sites will have multiple directories---like for Emory University and Emory Healthcare---that need to appear as one directory. The directory service web service sits on top of an LDAP or other directory mechanism and exposes person search to the rest of these components.
An organization’s financial system or general ledger is authoritative for financial account numbers that can be associated with AWS Accounts. The Financial System Service exposes a service operation to validate whether the account number associated with an AWS Account is valid. A new data provider must be implemented at each site. The RHEDcloud project has already implemented one for PeopleSoft Financials, but given the site-specific nature of financial system account numbers this validation query is something that is likely to be site-specific at every site.
Project management, coordination, and scheduling (20 hours)
Total hours: 260
Approximate Cost: $28,600
Additional optional services such as the Network Operations Service, Cisco ASR Service, and others can be deployed with training and knowledge transfer for approximately 20 hours per service. Note that the engagement does not cover comprehensive integration testing or production readiness, although other services are available for executing and training on the RHEDcloud automated test suite. The engagement also does not cover implementing the billing integration, but such a service is anticipated once RHEDcloud publishes detailed materials on its implementation.
The implementation site pays for cloud resources used during the engagement, provides their own technical staff to participate in knowledge transfer, as well as subject matter experts for IDM, directory, and financial system analysis.
Smartronix has proposed designing a cloud strategy consulting service that would include implementation of RHEDcloud for AWS, perhaps using Surge for the implementation work. More details should be forthcoming from Smartronix on the RHEDcloud wiki.
Developing and Implementing Marketing and Communication Plan
A key objective of the RHEDcloud Foundation as defined in its founding documents is marketing, communication, and advocacy for its cloud security research, methods, practices, and solutions. To date the project has not been able to formulate an actionable marketing and communication plan.
Some members of the RHEDcloud development team and members Automation, Infrastructure, and Integration Committee prepared a list of 10 potential RHEDcloud communications that could be prepared and released covering accomplishments and collaborations in 2019. However, none of these communications were ever prepared or released, because the development team is busy with the technical work outlined above and the RHEDcloud Foundation does not have any dedicated marketing and communications staff or consultants to step in and do that work. So, identifying resource to perform basic internal and public communications has been challenging.
The RHEDcloud Foundation also lacks an overall marketing strategy that would outline a multi-faceted approach to communicating its value proposition to its members, prospective members, and the public. All these activities are prescribed in specific detail in the RHEDcloud Foundation’s founding documents.
Initiating Risk Assessments
The Security Risk Assessment Committee has convened and framed the tasks of risk assessment well by presenting Emory’s approach to risk assessment. However, no specific goals to review existing risk assessments nor perform new risk assessments have been specified. No staffing or resources have been specified to perform this work on a daily basis. No roadmap or schedule for performing risk assessments has been discussed or presented to the board. These goals and resources must be specified and execution and delivery of risk assessments must begin in 2020 in order to support the GCP and Azure proofs-of-concept as well as to deliver on the purpose of the RHEDcloud Foundation as defined in its founding documents. The purpose of the foundation is largely about this collaboration to perform risk assessments and collect and publish results. If the RHEDcloud Foundation does not succeed in delivering and publishing valuable assessments and proposed controls, it will fail to achieve many of its purposes defined in its founding documents. This is an existential risk to the RHEDcloud Project.
Implementing RHEDcloud Environments
The RHEDcloud development team implement DEV, TEST, STAGE and PROD environments for all RHEDcloud products as part of migrating repositories from Emory to RHEDcloud and changing those pipelines to deploy to RHEDcloud-owned AWS accounts instead of Emory-owned AWS accounts. However, the entire solution cannot completely function in these environments without an Identity Management (IDM) system and some remote network to serve as an “on-prem” network for RHEDcloud with VPN concentrators of some sort.
RHEDcloud has contracted with UNICON to setup Grouper as an IDM system. This work should be completed in January 2020. Once completed, the team will be able to bring up the RHEDcloud solution with all features working with the exception of network automation.
The RHEDcloud Project presently does not have a strategy for providing or simulating an “on-prem” network and site-to-site VPN connections for the RHEDcloud environments. The RHEDcloud Network Committee should develop a strategy to implement or simulate a RHEDcloud “on-prem” network.
Implementing Vendor Environments
The same strategy the team used to implement the AWS at Emory environments, the Emory Cloud Infrastructure Migration Project (CIMP) environments, and the Rice University environments can be used to implement sandbox environments for vendors like Palo Alto Networks to test compatibility of their products with RHEDcloud methods and technology. However, it has proven challenging to focus resources on implementing vendor environments when the priority has been Emory and Rice environments.
Once the Rice implementation is complete the team should focus on implementing a set of RHEDcloud vendor environments.
Implementing the Individual Membership Program
The RHEDcloud Project has implemented billing processes for the organizational membership program but not for the individual membership program. Implementing billing for the individual membership program requires setting up recurring, subscription billing for individuals to pay their $100/year membership fee and then charge it automatically on a recurring basis until the member discontinues their membership.
Prospective (Potential Goals for 2020)
Successful RHEDcloud AWS deployment at Rice
Rice University volunteered to be the pilot deployment site for RHEDcloud on AWS. In December 2019 Rice engaged Surge to test their deployment services. We expect successful completion of Rice’s deployment in early 2020. This deployment will provide additional insights and reference process for other RHEDcloud AWS sites.
Successful RHEDcloud for GCP Proof-of-Concept
All metrics indicate that the RHEDcloud for GCP proof-of-concept will achieve its goals and complete by March 2020. In order to be successful the project needs continued cooperation from Emory Identity Management and Network teams as well as IT Architecture, Google, and Burwood. Most critically this effort needs several realistic security risk assessments from the RHEDcloud Security Risk Assessment committee so that the proof-of-concept team can implement realistic controls and security overwatch for several GCP services.
Identify a RHEDcloud for GCP Implementation Site
The RHEDcloud project has identified Emory and Rice as initial implementation sites for RHEDcloud for AWS and Duke University as a proof-of-concept and initial implementation site for RHEDcloud for Azure. Emory has been working with the RHEDcloud for GCP Proof-of-Concept Project to support Identity Management and Network integration work, but the project ideally needs to find a RHEDcloud member site or a new site that has already implemented with GCP that would be willing to prove out the RHEDcloud for GCP service.
Successful RHEDcloud for Azure Proof-of-Concept at Duke University
Duke University has volunteered to host the RHEDcloud for Azure proof-of-concept work that will be funded by Microsoft and performed by the RHEDcloud development team and ACS, Microsoft’s preferred expert partner. This opportunity to work with Duke from the inception sets the project up for a successful proof of concept and initial implementation site.
Publishing Risk Assessment Method Documentation
A number of project participants need to be trained in the method and practices of cloud service risks assessments. Providing documentation, demos, and training on how to perform these assessment and cultivating a productive team that is actively performing these assessments will help achieve these project goals.
Setting Risk Assessment Goals and Begin Delivery
Many of the RHEDcloud Project’s fundamental purposes are about collaborating to define security risks, specify controls, and publish and communicate about these findings. Establishing specific goals for the Security Risk Assessment Committee and specific mechanisms for publishing these findings such as the monthly blog posts and progress updates specified in the RHEDcloud founding documents will serve these purposes.
Establishing an Operational Individual Membership Program
Creating processes to allow individuals to sign up and provide a credit card number to charge their recurring annual subscription will allow individuals to participate in the project without sponsorship from a larger organization.