Purpose of this Documentation

The purpose of this documentation is to provide the detailed, supplemental information on the software applications that implement the Emory AWS Service for the Emory Office of Technology Transfer Intellectual Property Disclosure Form. This form is a cursory declaration of and invention and ownership of the intellectual property, but for a large project such as this it requires significant background.

Background on Preparing and IP Disclosure

In early 2018, LITS contacted OTT about preparing an IP disclosure for the software applications that implement the Emory AWS Service. This project was a large initial effort and will be a large on-going effort to maintain and operate. Tens of thousands of person hours went into the nearly two-year design discussion and proof-of-concept and one-year long implementation project. All of the work performed on this project was implemented by Emory employees and consultants under contract to perform works for hire for Emory. In our initial discussions with OTT due to the scale of this project, it was decided we could forego the customary personal attribution of contributions of intellectual property by individual inventors in this description and deal with any requirements for that in some other document if required.

Emory AWS Service Description

Emory maintains a master description of the Emory AWS Service that is used to describe its overall purpose, features, and operation at any given point in time. This description is used to prepare documentation for customers, training materials, and write test cases to verity the service.

• Emory AWS Service Master Service Description

• Emory AWS Service Integration Test Cases

General Applicability of the Solution

The Emory AWS Service is comprised of the software products and projects listed below. At a high level all of these products are useful to other organizations that have similar infrastructure to Emory, but specifically the following components could be immediately implemented in other organizations looking to provision, secure, and manage AWS.

1. Account and VCP CloudFormation Templates

2. Service Control Policies 

3. The Security Risk Detection Service

4. The AWS Account Service  (sites that do not use NetIQ for Identity Managment would need to implement a service to expose their roles and role membership to the AWS Account Service)

5. VPC Provisioning Web App  (sites that do not use NetIQ for Identity Managment would need to implement a service to expose their roles and role membership to the AWS Account Service)

6. AWS Landing Page

7. Temporary Key Issuance (TKI) Service

8. Temporary Key Issuance (TKI) Command-Line Client

9. Network Operations Service

10. Cisco ASR Service (other sites that use the Cisco ASR series routers)

Account and VPC CloudFormation Templates

These templates provide the basis for all structures, IAM policies, and roles related to AWS accounts and how all assets within accounts will be accessed. There are separate type 1 and type 2 VPC templates that implement structures specific to these two VPC types. Emory had developed comprehensive unit tests for the structures and intended functions of the policies implemented in these templates and automated the execution of these tests in DevOps pipelines. These practices make them readily maintainable and suitable for collaboration and enhancement with larger teams.

Service Control Policies

Service Control Policies are used to restrict access to services and features of services for all accounts and principals within an organization. Emory has implemented SCP for both HIPAA-compliant and Standard class accounts and implemented a large test suite to validate their intended function and automated the execution of these tests in DevOps pipelines, which make them readily maintainable and suitable for collaboration and enhancement with larger teams. Other sites may disagree with the specifics of Emory's policies, but they can implement different policies within this framework if desired. Emory anticipates that many of these policies will be of common interest and value to other implementing sites.

Security Risk Detection Service

What cannot be controlled by IAM or Service Control Policies Emory controls with the Security Risk Detection Service. This service is a framework for holding a constant watch over a series of AWS accounts and executing a series of Security Risk Detectors which are paired with Security Risk Remediators to detect and remedy security risks. Emory has implemented detectors and remediators for approximately 50 risks that cannot be managed by policy. The components of this service in addition to Detectors and Remediators are the core web service itself which receives requests to perform detections/remediations in accounts, the scheduler that requests these detections on a schedule, and consumers that listen for detections and permanently persist them and create alerts for specific risks. This service runs in mulitple threads and is horizontally scalable in that it can be run in multiple instances concurrently to reduce the interval on which detections and remediation are run. The service can reduce the overall check interval in an account to under one minute and if enough instances are run down to seconds, dramatically reducing the window of opportunity for bad actors to exploit any vulnerabilities. Other sites may disagree with the specifics of Emory's defined security risks or remedies, but they can implement different detectors and remedies within this framework if desired. Emory anticipates that many of these security risks will be shared by other implementing sites even if some specifics details of the detection or remedy differ. These differences are easily accounted for with small variations in custom detectors or remediators.

AWS Account Service

An AWS account and service metadata repository is necessary to provision and manage accounts, assess AWS services for risks, to scan accounts for security risks, and to integrate AWS consolidated billing with an organization's finance systems. The Emory AWS Account Service is a backend application exposed as a web service to perform these functions. Specifically, it implements the following high-level features:

1. Persists AWS Account Metadata such as account number, account, owner, compliance class, financial account number, e-mail addresses, etc.

2. Persists VPC metadata for the VPCs in accounts including their ID, type, CIDR range, VPN connection profile, etc.

3. Exposes the AWS account alias for accounts to a number of service components that need to display the account alias.

4. Persists account notifications for security risk detections and remediations as well as other administrative events. The service also creates a user notification for all users associated with the account for every account notification.

5. Persists user notifications to record delivery of notifications to specific users and also delivers notifications to the user via other modalities they have selected in their user profile (presently e-mail).

6. Exposes organization-specific logic for who is allowed to provision new accounts for other components of the solution that need to make this determination such as the provisioning orchestration and the ServiceNow request form.

7. Exposes a multi-step, transactional orchestration for automatically provisioning AWS accounts that are integrated into Emory's identity, network, and security infrastructure. Presently there are approximately 45 steps in total for provisioning that have been identified for accounts with type 1 and type 2 VPCs. Emory has successfully implemented the 30 step process for provisioning accounts with type 1 VPCs.

8. Picks up and processes the monthly master account bill, persisting the data for permanent storage and produces a file to import into Emory's PeopleSoft financial accounting system. Each account owner will be billed in the Emory financial system for all charges pertaining to their account by associating these charges with the financial account number they provided at the time they provisioned the account.

9. Detects and persists a master list of AWS services using the AWS support API and exposes service operations to maintain all metadata about these services that Emory must manage to determine whether a service is HIPAA eligible according to AWS and according to Emory, what the display name of the service is, if it is fully available, blocked, or available with countermeasures, etc.

10. Persists and exposes service operations for managing security risk assessments for each AWS service. Implementing specific, verifiable controls and tests in the form of IAM policies, services control policies, and security risk detectors and remediators requires a highly structured security risk assessment and enumeration of required controls.

11. Persists and exposes web service operations for terms of use to which all end users must agree at relevant points of service such as from the VPCP web app and TKI client.

12. Persists and exposes web service operations for terms of use agreements by end users.

13. Persists and exposes user profile data for the AWS account service

14. Exposes web service operations for a convenience object called AccountUser which aggregates user data from the Emory directory, authoritative person system, and identity management, so many components of the solution do not have to do that themselves.

In order to implement many of these features, the AWS Account Service must invoke the services of an authorization service, which at Emory is implemented by the Identity Management web service. This service provides Emory cannonical role and role assignment data, which tells the AWS Account Service which users are associated with which accounts and roles. Other implementing sites will need to implement or adapt a service like this to expose their account roles. Emory uses a product called NetIQ for this purpose and Emory's Identity Management web service exposes this data. Other implementing site may use a directory service like LDAP or Active Directory, use AWS principals, or some other commercial or open source identity management solution. Emory has started abstracting this out into a general process with the AccountUser object that could provide a common object for all implementing sites to provide all user and authorization data the service needs.

The following is a swim lane diagram that illustrates the high-level interactions between the account and VPC provisioning process and all other components of the solution. Click to enlarge.

VPC Provisioning Web Application

The VPC Provisioning web application is the primary end user interface of the AWS Account Service and integrations with other backend systems and automations at Emory. This application performs the following major functions for five roles of account administrator, account auditor, central administrator, central auditor, and network administrator. Note that the access level to the functions of the application vary by role.

1. View and maintain account metadata

2. View and maintain VPC metadata

3. Manage firewall rule requests

4. Manage static NAT (Emory Elastic IP) requests

5. Manage AWS service metadata

6. Manage AWS service security risk assessments

7. View list of central administrators

8. Send account notifications

9. Send user notifications

10. Manage static NAT (Emory Elastic IP) public IP numbers

11. View static NAT provisioning and deprovisioning transactions

12. Manage VPN connection profiles

13. View VPN connection provisioning and deprovisioning transactions

14. View AWS account and VPC provisioning transactions

15. View account notifications

16. View user notifications

17. Download the temporary key issuance (TKI) client

18. Link to AWS@Emory support documentation and resources

All of these features with the exception of the firewall rule, static NAT, and VPN connection provisioning would be immediately useful to other sites. In order for other implementers to make use of the firewall rule, static NAT, and VPN connection provisioning features that site would either need to have the same Palo Alto firewalls and Cisco ASR routers as Emory or provide a new implementation of the Firewall Service and Network Operations Service that managed their different implementations of these functions.

The following is a swim lane diagram that depicts the high-level interactions between the VPCP web app and all other components of the solution. Click to enlarge.

AWS Landing Page

The landing page provided by AWS has several major functions:

1. Provide users with a link to order the service

2. Allow users to log into their accounts

3. Help users explore AWS services

Emory users of its brokered service cannot use the AWS-provided page for these purposes, because Emory has implemented a comprehensive provisioning process to integrate the AWS accounts with Emory's identity, network, and security infrastructure. Emory users cannot use the main AWS page to login, because Emory has integrated the AWS account login with Emory's SAML 2.0 single sing-on infrastructure. And Emory has implemented many AWS service restrictions and countermeasures, which must be communicated to users along with service descriptions and documentation.

All other sites that implement this type of brokering will require a new main AWS landing page to replace the one provided by AWS, and this landing page is immediately useful to any site implementing this infrastructure.

Temporary Key Issuance (TKI) Service

The use of temporary API keys is an AWS best practice that reduces the risk and impact associated with compromised AWS keys. The TKI service integrates the temporary key issuance process with several important pieces of Emory's backend infrastructure:

1. A SAML 2.0 identity provider which is itself integrated with Emory identity management

2. Duo two-factor authentication

3. AWS Account Service metadata repository

4. The AWS accounts the users are logging into

This service orchestrates the authentication of the user with username and password, Duo two-factor authentication, role assumption, and issues temporary credentials for the appropriate account. This service would be immediately useful to any site using this infrastructure with a SAML 2.0 identity provider and Duo two-factor authentication. If the site did not desire two-factor authentication, they could toggle it off. If a site wanted to use a different two-factor authentication provider, the TKI service would need to be modified to support other providers.

Temporary Key Issuance (TKI) Command-Line Client

The TKI command-line client is the user interface that users interact with to request temporary API keys through the TKI service. Any site that uses the TKI service could make immediate use of the TKI client. The client comes with an installer that installs the client and all of its dependencies on Windows, Mac OS, and Linux clients.

Network Operations Service

The Network Operations Service is an orchestration service that is invoked by the account and VPC automatic provisioning and the VPCP web app to:

1. Provision and deprovision static NAT (Emory Elastic IP)

2. Provisiong and deprovision site-to-site VPN connections between the Emory network and AWS accounts

3. Expose important support data for provisioning network resources the VPN connection profiles

This service interacts with the Cisco ASR service deployment to perform modifications on Emory's network routers that provision static NAT and VPN connections. Because this service is largely a generalized orchestration that could interact with any backend router service, this service should be useful to any site implementing this infrastructure. If other sites had different network equipment to implement these functions, they would need to implement different services like the Cisco ASR service to expose those devices to the provisioning orchestrations.

Cisco ASR Service

This Cisco ASR Service exposes static NAT and VPN connection provisioning and deprovisioning to the Network Operations Service which coordinates these transactions. This service would be immediately useful to any other site that use the sample equipment, specifically Cisco ASR 1002 routers. Sites using other network gear to automate these functions would need to expose those operations to the Network Operations Service. The Cisco ASR service is implemented with the Netconf libraries, which interact with an industry standard network configuration interface, so much of this would could be applicable to automating these connections on other network gear, but there would be effort to implement these configuration management transactions on other network equipment.

AT&T Netbond Service

Emory discontinued use of the AT&T Netbond Service for AWS DirectConnect and opted for the site-to-site VPN approach. However, the AT&T Netbond Service would be useful to any site that uses a DirectConnect strategy with the AT&T Netbond service.

Elastic IP Service

The Elastic IP service maintains a registry of public IP addresses available for static NAT and their assignments to owners. When Elastic IP assignments are requested by users this service registers these assignments and public to private IP mappings and invokes the Network Operations Service to orchestrate static NAT provisioning and deprovisioning as needed. This service would be immediately usable to any site that wants to implement their own alternative to elastic IP and had exposed static NAT capabilities of its routers through the Network Operations Service.

E-mail Address Validation Service

The E-mail Address Validation Service validates that e-mail addresses can be delivered to. This is useful in the provisioning process to ensure that pre-provisioning e-mail distribution lists are setup properly and to count the inventory of pre-provisioned distribution lists. This service presently uses the Neverbounce API and service as the backend provider of this validation. This service could be used by any implementing site immediately as it is today.

PeopleSoft Service Enhancements

Emory has exposed many data objects from PeopleSoft using its PeopleSoft ESB/web service. The specific object that is useful for the Emory AWS Service is the financial account number or SPEED_CHART object. The command that implements this and the service framework could be immediately deployed and used by any PeopleSoft site that uses financial account numbers in a similar manner as Emory. Other sites would need to implement their own financial account number validation service if they desired to confirm the validity of financial account numbers entered into the AWS account provisioning and administration processes.

Software that Implements the Emory AWS Service

Major Applications, Services, and Infrastructure (18)

Specific Code Projects (33)

In order to implement these applications and services, Emory developed the following software: