WHITE PAPER: Technical Computing Marketplace Security

Nimbis Services, Inc. (Nimbis) is a privately held technology corporation bringing an innovative technical computing marketplace to the cloud computing industry. Nimbis offers a suite of brokerage and ecommerce web services that connects clients with third-party high performance computing (HPC) resources, commercial application software, and domain-specific expertise. Nimbis provides low-risk, low-effort, on-demand, pay-as-you go access to HPC for small to midsize companies who are currently unable to move beyond technical computing on the desktop. Another differentiating characteristic of Nimbis’ clients is that they tend to be experimental and occasional HPC users, regardless of size.

The Nimbis Services Technical Computing Marketplace (Nimbis marketplace) illustrated in Figure 1 is a web-based cloud-deployed brokerage service that brings together buyers and sellers of HPC resources into a technical computing marketplace providing a familiar and simple to use ecommerce frontend to a set of highly complex backend resources and services. For sellers, the complexities of configuring and inserting their products into the backend services and publishing their product in the catalog are vastly simplified with a set of form-based seller tools. For buyers, the high cost of acquiring and maintaining an HPC infrastructure and the high cost and long delays of negotiating, purchasing, and maintaining software licenses are completely removed. Buyers get on-demand pay-as-you-go click-through licensing of applications that are pre-configured and proven on secure cloud-based HPC platforms. Billing to buyers and payments to sellers are processed monthly with full reporting of activities over the previous month.

There are two primary types of users of a Nimbis marketplace deployment: anonymous users and authenticated users. Anonymous users (visitors) have the least amount of access to the system’s data; there is no data storage for an anonymous user and data transfers of  content may optionally be over HTTP without encryption. Visitors cannot add content. Visitors can view only the content (descriptions of products and services) that sellers have listed in their public facing storefronts.

There are three primary roles of authenticated users of a Nimbis marketplace deployment: administrator role, seller role, and buyer role. Administrators are those persons responsible for maintaining the Nimbis marketplace deployment and have the highest amount of access to the system’s data. Administrators can add and remove system capabilities and add and remove users. Sellers can create a store within the marketplace and add and remove their products within their store. Buyers can buy and use the sellers’ products. The ability to maintain the privacy and access privileges between these different roles is maintained by the underlying content management system (CMS) implemented within the deployment. Each user is assigned to a group of role permissions that maintains the security between roles and the users within that role. The CMS implements and enforces these roles and permissions using the operating system’s owner, group, read, write, and execute permissions. The user types and user roles are illustrated in Figure 2.

Authentication methods are implemented that result in the assignment of role permissions to a user. There are different levels of authentication. The first level is signup authentication. All users must first signup for an account. The signup process is automated and employs email verification before the account is activated. All signed up users are granted buyer role permissions. To become a seller, a second level of authentication is required. The user must complete and submit the seller registration form. This level of authentication is not automated. System administrators will receive and process the seller registration. If approved, an administrator will enable the seller role permissions for the user’s account. The user will be notified by email with the results of their registration. The seller can then create a store, insert a product, and deploy their product on a Nimbis supported platform. If the seller requires that they authenticate buyers before using the products in their store, they may implement a third level of authentication by requiring buyers to complete and submit a store registration form before the buyer may buy products from their store. A final and forth level of authentication occurs when the buyer, after purchasing a product, uses the product. If the product is hosted on a Nimbis partner’s platform and that platform requires login authentication, the buyer’s Nimbis account is linked to the partner’s system forming a single sign on (SSO) authentication.

In summary, users signup for an account and receive by default, buyer role permissions. Successful activation and login is the first level of authentication. There are two levels of registration and associated authentication: the first is registration/authentication to add the seller role permissions and the second is the registration/authentication to purchases the products in a seller’s store. Lastly there is SSO authentication when a buyer uses a seller’s product on a Nimbis partner platform.

There are four primary types of user generated data (content) that are secured within the Nimbis marketplace: personal, payment, technical, and social. Personal data refers to the user’s account profile information which includes real name, email address, billing address, phone number, etc. Payment data refers to a buyer’s payment processing information. Technical data refers to a user’s actual working files when using a product, for example input simulation models and output simulation results. Social data refers to comments that a user might post in areas of the system that allow users to post social networking content, for example catalog comments, forums, and blogs.

Personal data security is maintained through the user security mechanisms described in the previous section as well as the use of Hypertext Transfer Protocol Secure (HTTPS). HTTPS provides a reasonable guarantee that the user is communicating with the Nimbis marketplace (not an imposter) by authentication with the web site and the web server through security certificate authentication. HTTPS also provides bidirectional Transport Layer Security (TLS) encryption between the user’s browser and the web site to ensure that the contents of communications between the user and site cannot be read or forged by a third party.

Payment data, for example credit card numbers, are not stored in the Nimbis marketplace. The services of an external payment processor are integrated into the Nimbis marketplace’s ecommerce subsystem. For users with recurring monthly billing against a credit card, the payment processor secures the transmission and storage of this information. The payment processor forces HTTPS for all services. All card numbers are encrypted in storage with AES-256 and the decryption keys are stored on separate machines. No internal servers or daemons are able to obtain plaintext card numbers. The infrastructure for storing, decrypting, and transmitting card numbers runs in a separate datacenter, and doesn't share any credentials with their primary services (API, website, etc.). Nimbis’ payment processor is certified to Payment Card Industry (PCI) Service Provider Level 1 which is the most stringent level of certification available.

Technical data, for example a user’s input simulation models and output simulation results, are uploaded to, stored on, and download from the user’s SSO account maintained on the Nimbis partner’s compute platform. For horizontal applications, for example finite element analysis (FEA) and computational fluid dynamics (CFD) software suites, Nimbis serves up remote desktops to those applications over virtual network computer (VNC) sessions. Depending on the level of security required (see section 5) the VNC session may be tunneled over a secure shell (SSH) connection or virtual private network (VPN) connection with secure socket layer (SSL) encryption. Separately from the remote desktops, file uploads and file downloads may be performed over the same SSH or VPN tunnels using a web-based file transfer application. For vertical applications, for example a web application that wraps a complex FEA or CFD horizontal app into a web application with a very narrow set of input parameters, the user’s session operates within the user’s web browser using HTTPS.

For VPN tunneling and encryption, Nimbis uses OpenVPN. OpenVPN is freely available at http://openvpn.net/. In this configuration, the OpenVPN server software is installed on the compute provider’s server and the OpenVPN client software is installed on the user’s desktop machine. The client desktop machine is configured to connect to the server machine which includes authentication of each other by a pre-shared key (PSK) and security certificates signed by trusted certificate authorities. Bidirectional encryption over the VPN tunnel between the client and server is by OpenSSL encryption which encrypts both the data and control channels. OpenSSL is an open-source implementation of the SSL and TLS protocols and supports a number of different cryptographic algorithms. For the Nimbis implementation, AES is used for data encryption and the MD5 hash function with RSA encryption is used for key exchange and certificate signing.

The information presented in this paper is marked as Nimbis confidential and proprietary. Nimbis may choose to share this information with business partners or potential customers with a need to know for technical evaluation, business development, marketing, or sales purposes.

Specifically, this paper describes the mechanisms implemented to ensure the security of the data transferred and stored in the cloud by users of the Nimbis marketplace. Security in this context refers to the privacy of the users’ data from other users of the system and the public in general. The Nimbis marketplace security mechanisms are categorized and described according to the following topics:

• User security
• Data security
• Cloud security
• Levels of security

Each of these is described in the following sections.

There are three levels of security that a Nimbis marketplace product may be deployed on: academic, commercial, and government. The academic level represents the lowest level of security and therefore the lowest overall cost to implement, manage, and maintain. The government level represents the highest level of security and therefore the highest overall cost to implement, manage, and maintain. The commercial level is a midrange price point offering the best overall value for the Nimbis target market comprising small to medium sized commercial businesses.

The same user security mechanisms described previously (user types, user roles, and user authentication) apply equally to all three levels of security. Differences come into play in the data security mechanisms. All three levels contain the same data types (personal, payment, technical, and social) and the security of these apply equally as well. It is the data storage and data transfer security mechanisms and the complexities required to implement, manage, and maintain them that vary.

Let’s start with the highest level of security, the government level. This level does not include US Department of Defense (DoD) classified information, for example “confidential”, “secret”, or “top secret”. Nimbis does not store, transfer, or process DoD classified information in its marketplace deployments. The government level is for users that have US federal government requirements to safeguard their technical data according to US export control regulations. The US federal government categorizes this information as Controlled Unclassified Information (CUI). For Nimbis marketplace deployments this includes both the Export Administration Regulations (EAR) and the International Traffic in Arms Regulations (ITAR). EAR and ITAR export controlled technical data listed on the commerce control list (CCL) and the US munitions list (USML), respectively, requires that, without an export control license, only US persons (citizens or permanent residents) may have access to the data.

For government level security, Nimbis and the Nimbis partners offering their platforms and services at this level must maintain and follow a set of export control policies and procedures sufficient to ensure that EAR and ITAR regulations are met. The user authentication process requires the verification of US person status and confirmation that the person, or entity they represent, is not on any US denied parties lists and they must be operating from within the US. Data storage must be physically safeguarded against non US person access. Data transfers must be encrypted and secure. An export control administrator is identified at Nimbis and at the Nimbis partner. These administrators are responsible for executing and enforcing their respective export control policies and procedures. For Nimbis marketplace deployments requiring government level security, Nimbis utilizes AWS GovCloud (US).

In contrast to the government level, commercial level product deployments use SSH tunneling between the user’s desktop machine and the compute platform. This ensures that any commercial proprietary data transferred is encrypted. US person status is not required at the commercial level. Products deployed at the commercial level must be checked, according to the Nimbis and partner export control plans, to ensure they are not EAR or ITAR export controlled. If a product is or contains EAR or ITAR export controlled data, then it must be deployed at the government level.

Academic level product deployments do not require secure tunnels or encryption between the user’s desktop machine and the compute platform, although an academic level user may choose to do so. This level relies on the security mechanisms in place by the user on their local machine and by the compute platform datacenter’s normal security measures. US person status is not required at the academic level. Products deployed at the academic level must be checked, according to the Nimbis and partner export control plans, to ensure they are not EAR or ITAR export controlled. If a product is or contains EAR or ITAR export controlled data, then it must be deployed at the government level.

Nimbis marketplace deployments are currently implemented using the Amazon Web Services (AWS) cloud infrastructure. The specific AWS products that Nimbis employs and reference links to the AWS pages that describe the products and their security features are listed in Table 1.

TABLE

Across all AWS products, Amazon maintains an “AWS Security Center” at http://aws.amazon.com/security/ which provides an overview of AWS security features and practices and an “AWS Compliance Center”  at http://aws.amazon.com/compliance/ which lists the security certifications and accreditations it maintains. Following is a list of AWS security certifications and accreditations:

• US International Traffic in Arms Regulations (ITAR) compliance (in AWS GovCloud US region)
• U.S. Health Insurance Portability and Accountability Act (HIPAA)
• Service Organization Controls 1 (SOC 1) for the International Standards for Assurance Engagements No. 3402 (ISAE 3402)
• Service Organization Controls 2 (SOC 2) for the American Institute of Certified Public Accountants (AICPA) Trust Services Principle
• Service Organization Controls 3 (SOC 3) for the AICPA SysTrust Security Seal
• Level 1 compliant under the Payment Card Industry (PCI) Data Security Standard (DSS)
• International Organization for Standardization (ISO) 27001
• Department of Defense (DoD) Cloud Security Model (CSM) Levels 1-2 and 3-5
• Multi-Tier Cloud Security (MTCS) 3
• Federal Risk and Authorization Management Program (FedRAMP)
• Federal Information Security Management Act (FISMA), Risk Management Framework (RMF) process defined in NIST 800-37 and DoD Information Assurance Certification and Accreditation Process (DIACAP)
• Federal Information Processing Standard (FIPS) 140-2

AWS GovCloud (US) consists of an AWS region and framework that provides AWS products to users that must comply with United States (US) federal government regulations. Cloud deployments suitable for AWS GovCloud (US) include all categories of Controlled Unclassified Information (CUI) including the International Traffic in Arm Regulations (ITAR). AWS GovCloud (US) is physically and logically accessible by US persons only.

This paper described the mechanisms implemented to ensure the security of the data transferred and stored in the cloud by users of the Nimbis Services Technical Computing Marketplace. We first looked at different “user security” mechanisms that include user types, user role permissions, and user authentication. We then looked at different “data security” mechanisms that include different data types (personal, payment, technical, and social) and data storage and data transfer methods to ensure data security. Next, we looked at the “cloud security” measures implemented by Amazon in their Amazon Web Services cloud products. AWS products are used by Nimbis for Nimbis marketplace deployments. Finally, we looked at the three different levels of Nimbis marketplace security that products can be deployed in. These include academic, commercial, and government. These levels are defined by the user security, data security, and cloud security mechanisms described. For more information please email Nimbis Services at info@nimbisservices.com.