Project Hosts Support Plan



FedRAMP Certification of Independent Software VendorTo ensure FedRAMP compliance of Software deployed in a Project Hosts (PH) FedRAMP cloud, the Independent Software Vendor (ISV) signing below agrees to the following requirements. Software ArchitectureSUPPORTED PLATFORMS (CM-2, CP-10 (2), AC-23)If deployed on virtual servers, the Software can be deployed on either Windows Server or CentOS Linux operating systems and can use either Microsoft SQL or MySQL databases. If deployed on PaaS services, the Software can be deployed using Azure Cloud Services with the above operating systems and use the above databases or Azure SQL.ANTIVIRUS (SI-3)Sophos antivirus software will be installed on the servers (or Cloud Services) running the Software.HTTPS ACCESS ONLY (SC-7)By default, the only inbound traffic allowed from the Internet to the Software is TLS-encrypted HTTPS traffic over port 443. This inbound traffic will traverse Web Application Proxy (WAP) servers within a DMZ subnet before being forwarded to the Software’s web or application servers. A deployment of the Software must be compatible with this architecture unless an exception is approved.AUTHENTICATION VIA PH ACTIVE DIRECTORY (IA-2)By default, all users authenticate to a Project Hosts Active Directory. Customer users may authenticate directly or via an SSO connection from their organization. As a result, unless an exception is approved, the Software must either be able to: i) directly utilize a Project Hosts AD for authentication; or ii) accept an internal SSO connection from PH ADFS servers to the Software. FIPS VALIDATED ENCRYPTION (IA-7, SC-13)The Software either does not use encryption or uses only FIPS-validated cryptographic modules that are listed on the link: . If the Software runs on Windows servers, compliance is easiest if the Software operates correctly when in “FIPS mode” (or more precisely, the security option called “System Cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing.”). If the Software does not operate correctly in FIPS mode, then documentation must be provided demonstrating that the Software uses only FIPS-validated cryptographic modules. MULTITENANT APPLICATION SEPARATION (SC-4)If the Software is architected to support multiple customers within a single application and/or database instance, there is logical separation between customers that prevents unauthorized and unintended information transfer. This separation is achieved through the use of unique organizational identifiers for each customer and user identifiers for each user.DOD IL4: MCAFEE HOST INTRUSION PREVENTION (SI-4 (23))For DoD environments, McAfee HIPS will be installed on the servers running the Software.Software FeaturesLOGGING (AU-2)The Software must be able to generate logs for all “administrator activity, authentication checks, authorization checks, data deletions, data access, data changes, and permission changes”. ISV must inform PH engineers about any configurations to generate these logs and where they are stored so that Project Hosts’ Log Correlation Engine agents can pick them up. The Software must also not prevent the OS from generating logs tracking object access, policy change, privileged functions, process tracking, and system events.INACTIVITY TIMEOUT (AC-11, SC-10)To comply with AC-11 and AC-11 (1), the Software should have an inactivity timeout of web sessions and other access to the Software. After 15 minutes of inactivity, a user’s session should be locked and anything they were previously viewing in the application should be obscured. If the Software does not have an inactivity timeout, it is possible to make it Customer Responsibility to request this behavior in one of 2 ways: 1) If the Software can accommodate adding Javascript, it is possible to make it Customer Responsibility to request insertion of PH-provided Javascript to facilitate this behavior or 2) Access to the application could be provided through a user launching a browser from a Remote Desktop that has an inactivity timeout incorporated. Additional fees would apply.INPUT VALIDATION (SI-10, SI-10(3) for DoD)The Software must check the validity of inputs. For DoD deployments, the Software must behave in a documented and predictable way when invalid inputs are received (understandable error message).DOD OR HIPAA: ENCRYPTION OF DATA AT REST (SC-28 (1))For DoD IL4 or IL5 deployments or HIPAA compliant deployments, all data must be encrypted at rest. The Software must be compatible with encryption at rest mechanisms (e.g. TDE for MS SQL Server).FFEDRAMP HIGH: LOGOUT BUTTON (AC-12 (1))For FedRAMP High deployments, ISV’s application should have a logout functionality. When clicking on it, users must get an explicit message indicating termination of a session. The logout functionality should follow these guidelines: . If the Software can accommodate adding Javascript, it is possible to make it Customer Responsibility to request insertion of PH-provided Javascript to facilitate this behavior. Update & Remediation ProcessesREMEDIATION OF VULNERABILITIES (RA-5)Project Hosts performs monthly vulnerability scans of the Software as well as the OS and databases that it uses. If a scan reveals high (or moderate) risk vulnerabilities in the Software, ISV must provide an update within 30 (or 90) days to fix those vulnerabilities. If vulnerabilities with the OS, database or other software used by the Software can be fixed by updates, then ISV must approve those updates and ensure ISV Software is compatible with them within the timeframes given above.SOURCE CODE SCANS (SA-11 (1))Before initial installation of the Software or release of a Software update, ISV must perform source code scans to verify that the code is free of the following common programming errors: cross-site scripting vulnerabilities, buffer overflows, race conditions, object model violations, poor user input validation, poor error handling, exposed security parameters, and plain text passwords.DIGITALLY SIGNED UPDATES (CM-5 (3), SA-10 (1))Software updates should be digitally signed. If this is not possible, ISV must provide a description of how Software integrity is ensured (e.g. ISV engineers only pull updates from configuration controlled ISV Software repositories).SECURITY ASSESSMENT PLAN (SA-11)The ISV agrees with the following security assessment plan for the initial installation of the Software or of Software updates: ISV will perform source code scans of the Software as described above.The Software or update will be installed in a test environment first (CM-3 (2), CM-4 (1)).Project Hosts will perform OS, DB, and web app vulnerability scans of the Software in the test environment, documenting results of the scans. (SA-11 (2), SA-11 (8))Unless an exception is granted by Project Hosts, a Software version or update may only be installed in a production environment if no new High Risk vulnerabilities are found in scans of the Software in the test environment.Documentation Provided to Project HostsINSTALLATION & CONFIGURATION DOCUMENTATION (SA-4, SA-5)ISV will securely provide to Project Hosts documentation that includes:A description for how to securely install the Software, including any tools that are used to roll out updates (SA-4d, SA-5, CM-6(1))A description of the functional properties of any Software security settings and how to configure the Software securely (SA-4 (1), SA-5)A justification statement for why the configuration settings for the Software reflect the most restrictive mode consistent with operational requirements (CM-6)Specification of any ports, protocols, functions, or services required for use of the Software (SA-4 (9), CA-9b)Any required security-relevant external system interfaces (SA-4 (2), CA-3)A description for how cryptographic keys are used by the Software, whether they are symmetric or asymmetric, how they are produced, controlled, and distributed, and for FedRAMP High how availability would be maintained if a key were lost (SC-12 & (1)-(3))A description of any mobile code used for the environment (e.g. Javascript, Active-X, etc.), how it is used, and any implementation guidance for it (SC-18)Any known vulnerabilities (SA-5)SOFTWARE INVENTORY AND LICENSING (CM-8, CM-10 & CM-10 (1))If the Software requires other software to be installed in order to run, then Software Vendor must provide an inventory list of that other software along with supported version numbers. If some third-party software (“3rd-Party Software”) is incorporated into and integrated with the Software, then ISV hereby certifies that the 3rd-Party Software is being utilized in a way that does not violate any license agreement (including any open source agreement) associated with the 3rd-Party Software.RESPONSIBILITY MATRIX (AC-5, SA-3b)ISV will jointly develop with PH a matrix showing for various functions, who will be Responsible, Accountable, Consulted, and/or Informed (RACI). An example RACI matrix is in Exhibit A.FEDRAMP HIGH: DEVELOPMENT TOOLS (SA-15) For Software used in FedRAMP High environments, ISV will: Identify the standards and tools used in the development processDocument the specific tool options and tool configurations used in the development processDocument, manage, and ensure the integrity of changes to the process and/or tools used in development.Authorization and Access for ISV UsersAUTHORIZING ISV USERS (AC-2b,d)If ISV would like some ISV engineers to be able to access the Software in Project Hosts’ cloud (e.g. for Software installation, troubleshooting, updating), ISV management will designate a Deployment Admin with the authority to authorize this access to ISV users.REVIEW OF ISV USER ACCESS (AC-2j)The Deployment Admin must review all ISV users [quarterly for FR Moderate, monthly for FR High] to determine if they still require access and the access provided is appropriate. LEAST PRIVILEGE FOR ISV USERS (AC-6 (3))The ISV’s Deployment Admin will only request for Project Hosts to provision a privileged account for an ISV user if there is a compelling operational need for the user to have this access.PRIVILEGED ADMIN ACCESS AGREEMENT (PL-4)Each ISV user that is granted privileged administrative access to a PH FedRAMP environment will sign a Privileged Admin Access agreement that includes required Rules of Behavior. CHANGE CONTROL FOR PRODUCTION ENVIRONMENTS (CM-3, SA-10)Pre-approval by Project Hosts is required for any change made by an ISV privileged admin user to a production deployment. Requests for changes must be made by ISV’s Deployment Admin.BACKGROUND CHECK FOR ISV USERS (PS-3)Any ISV users that are given access to a Project Hosts FedRAMP environment must have had a background check before being provided access. The check must include both criminal and credit background checks as well as someone checking references from past employers. A background check performed upon hire is acceptable. TERMINATION OR TRANSFER OF ISV USERS (PS-4, PS-5)ISV will notify support@ as soon as possible of termination or transfer of an ISV user, so that Project Hosts can disable the user’s access. SECURITY TRAINING OF ISV USERS (AT-2, AT-2 (2), AT-3 (4))Each ISV user must undergo security awareness training and insider threat training as part of initial training, when required by system changes and annually. For FedRAMP High or DoD environments, each ISV user must also undergo training on recognition of malicious code. Project Hosts can provide all this training.ISV USER TRAINING LOG (AT-4)Before each annual audit, the ISV must provide to compliance@ a log of when each ISV user completed the required trainings.FEDRAMP HIGH OR DOD: SMART CARD REQUIRED FOR ACCESS (IA-5)For FedRAMP High or DoD IL4 deployments, ISV engineers will require smart cards provisioned by Project Hosts (or the DoD) to access environments. These smart cards will have to be handed to users in person by an ISV registration authority designated by ISV management. The ISV registration authority will also need to verify ISV user identity by viewing 2 government issued picture IDs. ITAR OR DOD: US PERSONS ONLY (SRG 5.6.2)For deployments requiring either ITAR or DoD IL4 compliance, ISV engineers may only be provided access if they are US Persons (citizens or legal residents). FedRAMP Moderate and High deployments do not have this restriction Certification by ISVI agree to the requirements specified above for a deployment of the Software specified below. _________________________________ _________________________________Signature Date_________________________________ _________________________________Printed Name Independent Software Vendor_________________________________ _________________________________Title SoftwareExhibit ARACI Matrix for ISV DeploymentsStatement of who is Responsible (R), Accountable (A), to be Consulted (C) or Informed (I)For Software provided and managed by ISVDescriptionISVProject HostsReview source code (source code static + dynamic analysis)R, AIPackage application for deployment and make availableR, AIDevelop installation/configuration instructionsR, ACDevelop system architecture documentationCR, ADocument system/hardware requirementsR, ACDevelop and deliver training on the applicationR, ASet up physical machinesCR, ASet up virtual machinesCR, ASet up and maintain firewall and firewall rulesCR, ASet up, install, harden and maintain servers (OS and middleware)CR, ASet up, configure, harden and maintain database CR, AInstall and configure application componentsR, ACSet up and configure SSO/SAML authenticationCR, ASet up, support and maintain HSM for the applicationR, ACSet up, support and maintai SES Service for emailR, ACPerform Network Security scansIR, APerform Application security scansIR, APerform Database scansIR, AIdentify and correct server/network security vulnerabilitiesCR, AApply system fixes and upgradesC, IR, AIdentify application vulnerabilitiesR, A, C, IR, ACorrect application vulnerabilitiesR, AC, IApply application fixesR, AC, IIdentify database vulnerabilitiesR, A, C, IR, ACorrect database vulnerabilitiesR, AC, IBuild SSP and other FedRAMP-required documentsC, IR, AWork with 3PAO for FedRAMP auditC, IR, APerform continuous monitoring and reporting to FedRAMP PMOIR, AFollow-up on open FedRAMP actions (POA&M)C, IR, AOnboarding of new customersR, ARApplication of customer-specific configuration and settings(e.g. account level options, branding, logos, templates, etc.)R, A, C, IRUser provisioning and managementR, A, C, IRSystem usage reportingR, A, C, IR, AMonitor application uptimeR, A, C, IR, AMonitor resource usageIR, AMonitor physical securityIR, ASystem Security and Integrity MonitoringIR, ACapacity planningC, IR, AVulnerability managementC, IR, APatch managementIR, AChange managementR, C, IR, ACustomer Support (Level 1)R, AApplication support (level 2 and 3)R, AC, IInfrastructure support (Level 2 and 3)C, IR, A ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download