All Curator instances deployed by InterWorks (new and ongoing releases) go through a rigorous security analysis to ensure that security controls meet our standards.
Information Security Requirements Analysis and Specification
All Curator instances deployed at InterWorks must have their security controls analyzed to ensure that they meet InterWorks standards. This process is followed for both new development additions and deployment of Curator systems and is a necessary early step to ensuring the system meets our security requirements.
The following security requirements should be considered for each system:
Elevated Security: If analysis determines that data in the system requires heightened security, a plan will be put in place to create those additional security controls.
User Provisioning – All user roles required for the system will be defined and what level of access is required for each role.
User Education – All users will be educated on their responsibilities within the system and specifically any potential security issues.
Asset Protection – Assets requiring special protections should be identified and proper access controls should be in place via role-based controls.
Securing Application Services on Public Networks
HTTPS/SSL should be used on all publicly available Curator installations. In addition, end users should be redirected to the HTTPS route using Curator’s “Force SSL (https)” setting.
Unless specifically necessary for the end Curator application, iframe embedding should be prohibited to avoid XSS attacks, such as “clickjacking.' Curator’s “Allow iframe embedding” option controls the system’s availability to iframe embedding and is defaulted to off.
Curator’s “Forced Curator Domain” setting should be specified on every installation to prevent host-header injection attacks.
When available, implementations of enhanced user authentication methods, such as multifactor authentication through SAML/SSO are recommended.
Protecting Application Services Transactions
When available, end to end HTTPS/SSL transmission of data should be used.
When not available, clients must be highly encouraged to implement such measures. This requires that both Curator, as well as relevant systems such as Tableau Server, implement HTTPS/SSL endpoints.
Secure Development Policy
In order to maintain a secure development environment, access to Curator’s development environment is only provided on an as needed basis to development personnel. Regular audits ensure that access is removed from personnel when no longer required.
Application security is considered early on in all development projects and identifying the proper security protocol will be completed during the initial architecture phase. The implementation of the security protocol is performed by a senior engineer and peer reviewed to ensure security requirements are met.
All source code is peer-reviewed throughout the SDLC by senior engineers and architects with experience in building secure applications. Secure coding practices are emphasized throughout the SDLC by senior engineers and architects.
Changes to source code are audited against two automated code-level security scans: the Greenwolf ESLint Security Scanner and the Floe Design Security Audit for PHP CodeSniffer.
Nessus vulnerability audits are performed against prerelease software prior to any code release.
Source code is secured in an internal Git repository. Access to version control repositories is given on an as needed basis. Repositories are protected by InterWorks’ standard security protocol and access is audited regularly.
System Change Control Procedures
During the SDLC any system changes required are submitted to the appropriate parties, i.e. Internal IT, Hosting Dept or Development Team Lead. This party will vet the change request and ensure that sign off from the appropriate persons is received. They will also determine what systems and what personnel will be impacted by the changes and communicate this prior to make changes. That party will then execute the changes and provide notice that they are completed.
Technical Review of Applications After Operating Platform Changes
When applications are migrated to a new platform, those applications are tested to ensure that they function properly and that all ancillary functions associated with them (e.g., backups, monitoring and security settings) have been updated properly.
Restrictions on Changes to Software Packages
Altering third-party software is discouraged at InterWorks due to the possibility of unknown bugs being introduced to the software. If InterWorks needs to integrate with third-party software a supported API or SDK is preferred
In the event third party software is modified, InterWorks will use our standard SDLC process to ensure that the software has been thoroughly tested and source code properly maintained in version control.
Secure System Engineering Principles
InterWorks uses the best practices set forth in the Open Web Application Security Project v2.0. These are industry standard best practices and InterWorks’ Senior Engineers use these principles during code reviews to ensure all code is secure.
InterWorks Has Standards in Place to Ensure the Development Environment Is Secure
Access to servers, data and any other securable items is granted only as required.
InterWorks uses only employees for all development work.
Different development teams’ access to each other’s work is completely separate and access across team repositories and data is granted only if necessary.
Access to the environments is controlled using the same standards outlined in our InterWorks’ security policy.
InterWorks does not currently outsource any software development. If a case occurs in which InterWorks does outsource development, the following requirements must be in place:
System Acceptance Testing
InterWorks’ Quality Assurance team performs full regression testing prior to every release to ensure no regressions are present. Software modifications must pass code-level and vulnerability scans prior to release.
InterWorks takes steps to ensure that test data is secure throughout the development process.
If test data is operational, production data or otherwise sensitive, InterWorks’ Development team will remove the data from development machines and servers once testing has been completed.
Access to sensitive test data is controlled in the same way any other securable would be under InterWorks security policy.