This document outlines the security and privacy management framework at Client Share and explains how we manage and control security and privacy risks to client data. Client Share is implemented on the Heroku and Amazon Web Services (AWS) cloud computing platforms and follows industry standards and processes described below to ensure security and availability. Since Client Share is anAWS application it is important to note that we follow the AWS Shared Responsibility Model described here: https://aws.amazon.com/compliance/shared-responsibility-model/
Security of physical infrastructure used by Client Share is managed in the EU by AWS in accordance with the terms of the service agreement between AWS and Client Share as per the AWS Shared Responsibility Model.
AWS manages the underlying network infrastructure and network security of AWS- and Heroku- hosted applications such as Client Share. In addition to network security mechanisms managed by AWS and Heroku we have implemented the following security mechanisms:
•DNS Security Extension (DNSSEC)
•Sender Policy Framework (SPF)
•DomainKeys Identified Mail (DKIM)
•Domain-based Message Authentication, Reporting & Conformance (DMARC)
•HTTP over TLS (HTTPS)
Virtual environment security
Client Share, like most modern applications, runs in a virtual environment. Client Share is implemented on the Heroku platform on top of the industry-leading cloud computing environment managed by Amazon Web Services (AWS). In this architecture AWS hosts the virtual environment, Heroku provides the tools to manage it and Client Share develops and manages the application that runs in the Heroku/AWS cloud computing environment.
Virtual server security
The Client Share application runs in virtual server containers, called dyns, created and managed on
the Heroku platform and hosted by AWS. Dyns offer additional security, manageability and scalability
on top of features provided by AWS as documented here: https://www.heroku.com/dynos
Since the Heroku platform itself is implemented on the AWS cloud computing platform it inherits the controls and security mechanisms managed by AWS. For more information refer to Heroku's security policy: https://www.heroku.com/policy/security
Client Share is responsible for the application's security mechanisms which are described below.
Access to the application
HTTPS is used to access the application to ensure integrity and confidentiality by encrypting and authenticating data exchanged between Client Share and client Web browsers. Any HTTP requests made to the application are automatically redirected to HTTPS and HTTP Strict Transport Security (STS) policy is implemented to ensure that client browsers only use HTTPS to access the application. Use of HTTPS ensures that unauthorised third parties cannot intercept or modify data traffic between client browsers and the Client Share application.
All data stored by the application is stored encrypted and access-controlled on Heroku/AWS-managed storage. Application data is stored in Heroku PostgreSQL database (https://www.heroku.com/postgres) and user-uploaded files are stored access-controlled and encrypted in AWS Simple Storage Service S3 (https://aws.amazon.com/s3/). AWS holds industry standard certifications covering data privacy which are specified below.
Application security features
The following application security features have been designed and implemented to provide control over access to and use of the application.
Client Share is a closed platform. Users can only register and join if they are invited by an existing member of a Client Share or by the Client Share Team to become an administrator of a new Client Share. There is no public registration portal where an application can be made to join a Client Share. Invitation links within emails are one time use only and unused links are invalidated if a subsequent link is created e.g. an invitation is resent.
Restricted Email Domains
Administrators are required to set approved email domains within each Client Share. New invitations can only be sent to email addresses with approved domains. This prevents unauthorised access to a Client Share by users who are not relevant to the Companies using the Client Share. Approved domains can be managed at any time by the Administrator via Settings.
Administrator control of content
The administrator(s) of a Client Share can edit or delete any post added by a user. The administrator(s) can also delete comments from all users.
Visibility of posts
When adding a post, any user can select which members of the Client Share will be able to view the post and its attachments. This allows private posts to be added. The visibility of a post can be amended after a post has been added if required. The ability to post content can also be locked down to chosen parties should you wish to enable this feature.
Administrator(s) can remove any member of a Client Share via Settings. Removing a user prevents them from accessing the Client Share or receiving any notifications from the Client Share and the removed user will not be active with the system.
If an Administrator needs to leave a Client Share e.g. due to leaving the company, then another user can be promoted to Administrator. The new Administrator will receive all Administrator rights and can remove the other Administrator(s). An Administrator can also invite colleagues to become additional administrators on the Client Share.
All pending invitations sent by members of the Client Share can be viewed, resent and/or cancelled by the other members of the Client Share.
A member can disable their own account if they no longer wish to access or be seen in a Client Share.
Users can manage whether they receive notifications for new content, comments etc. via their own user settings.
Client Share passwords must be a minimum of 6 characters and contain an uppercase letter, lowercase letter and a number. Special characters are allowed in passwords.
Application audit trail
Client Share creates an audit trail of all important actions within the application that is available for review and further investigation if required. Those actions include but are not limited to:
Invitations: the email address that was invited, when, and by which current Client Share member.
Posts: which member added the post, when, the number of attachments and the number of URL links in the post.
Attachments: which member has downloaded or viewed an attachment or URL link, the name of the file/link, when and how many times the action occurred.
Comments: which member commented, the subject of the post, when and how many times.
Likes: which member and the subject of the post.
New members: joining a Client Share; who has joined, who invited them and when.
User management: members that were removed by an administrator, members that disabled their account, members that were promoted to administrators, members whose company was changed by an administrator.
Downloads: content that has been downloaded by members.
An administrator of a Client Share can request to view information held in the audit trail via email@example.com or the integrated helpdesk.
All application logins by customer’s users and Client Share employees are logged. All changes to data in the application database are logged to an audit trail which tracks the change made, the time of the change, and the user who made the change. This audit logging applies to both customer users and Client Share staff. Audit trails are stored in a centralized database server. Every change is written to write-ahead logs, which are shipped to multi-datacenter, high-durability storage. In the unlikely event of unrecoverable hardware failure, these logs can be automatically 'replayed' to recover the database containing the audit trail to within seconds of its last known good state.
The application's live and development environments are segregated and real customer data is never used for testing.
Application security: third-party APIs
The Client Share application uses the following third-party application programming interfaces (APIs) to provide some of its functionality. To ensure security and integrity Client Share uses HTTPS with certificate validation to access these APIs.
Application security: processes
The following business processes are implemented to monitor and respond to events or incidents that may affect security or availability of the Client Share application.
The application is automatically monitored 24/7 by Pingdom and NewRelic monitoring solutions and the following events trigger immediate notifications to the support team:
Pingdom continuously monitors the application every 60 seconds to ensure it's online and available. The availability tests are performed from multiple locations around the world and as soon as the application is unreachable the Client Share team is informed instantly with a full log of the issue.
Performance of the application
Client Share uses NewRelic to measure the performance of the site and client satisfaction using an Apdex score which is an average time for request. If the average request time goes below certain threshold (Apdex T-Value is 0.5 seconds) the Client Share team is informed about platform performance issues. At Client Share we operate a zero performance issues policy, so as soon we know about any issue we prioritise against new features and functionality to ensure that the current customer experience is as good as possible.
Annual penetration testing
The application is penetration tested annually by a Council of Registered Ethical Security Testers (CREST) qualified penetration tester and the last penetration test was performed in June 2017. Certificate of testing is available upon request.
Notified or suspected security incidents are subject to the following incident response plan:
1. Suspected security incident is logged
2. Relevant team members are notified
3. Incident response conference call is held to discuss remediation
4. External security advisor is engaged if necessary
Protection of customer data privacy and confidentiality is our top priority, closely followed by the availability of the application.
Both AWS and Heroku are designed with scalability and high availability in mind. The Client Share application is automatically scaled to match customer demand and Client Share data is replicated across different Availability Zones to ensure resilience.
Application security: human resources
Client Share have implemented the following human resources security processes
●Information Technology & Security Management Policy
●Security Background Clearance / Checking
●Anti Slavery & Anti Corruption Policies
●Health & Safety Policies
●Corporate & Social Responsibility
These policies are available in full: www.myclientshare.com/policies
AWS Security & Compliance certifications
AWS holds the following independent third-party assurance certifications that underpin the security of the Heroku platform and the Client Share application implemented in the AWS cloud computing environment.
Cyber Essentials Plus (UK)
Government Cloud (UK)
Cloud Security Alliance Controls
ISO 9001 Global Quality Standard
ISO 27001 Security Management Standard
ISO 27017 Cloud Specific Controls
ISO 27018 Personal Data Protection
PCI DSS Level 1
SOC1 Audit Controls Report
SOC2 Security, Availability, & Confidentiality Report
SOC3 General Controls Report
All Client Share users are deemed to have accepted Terms and Conditions for Client Share use which are published at http://myclientshare.com/privacy
The Client Share application collects the following data: user name, job title, email and statistical usage data via cookies.
Customer data is kept in the production databases for live recovery purposes for 90 days after a customer terminates service with Client Share. Data can be purged sooner upon request.
Application and data availability
Client Share operates a change control policy to ensure controlled introduction of changes as follows.
Client Share will issue a release note to customers every time there are significant changes to the application's user interface or functionality.
Client Share operates on a target uptime of 99.9% availability for the application to be available.
Client Share will only release new software between 0400 and 0800 GMT.
All new software is tested on staging environment for a minimum of 5 business days before being released into production.