This article includes frequently asked questions about Social27's Security Policies. To read our full Security Policy, check out our website.
Questions in this article are sorted into the following categories:
- Security: Data logs, access, and encryption
- Durability: Data recovery an backup
- Availability: Hosting and outages
- Performance: Load tests and concurrent/peak users
- Cost: Forecasting demand and optimizing cost
- Operational Load: Issue resolution
What logs do you maintain?
Social27 preserves detailed log data, including audit logs, transaction logs, event logs, error logs, message logs, backup logs, network flow logs and infrastructure change logs.
What is your log retention policy?
Infrastructure / system level logs for production environments are kept for one year. Testing and Staging environments have a lower retention policy. These logs are kept only for the purpose of, and as long as is necessary for, the Permitted Purpose, and are permanently deleted within 24 hours of the termination and/or expiration of the Agreement.
How do employees authenticate to internal systems?
Access is limited using a Least Privilege model: Employees are given the minimum amount of access/permissions needed in order for them to perform their jobs. Access controls are frequently audited and are subject to technical enforcement and monitoring to ensure compliance. Two-Factor Authentication is required for all production systems.
Access to systems and network resources is based on a documented, approved request process. Logical access to server platforms and management systems require two-factor authentication. Periodic checking ascertains whether the owner of a user ID is still employed and assigned to the appropriate role. Access is further limited by device permissions using a Least Privilege model, and all permissions require documented business needs.
Exceptions found during the verification process are remediated and validation is conducted on a quarterly basis to determine whether access is commensurate with the user's job function. Exceptions found during the validation process are remediated.
Business needs are validated on a quarterly basis to determine whether access levels are commensurate with the user's job function. Exceptions found during the validation period are remedied.
User access is revoked upon termination of employment or change of job role.
To authenticate to internal systems using AWS infrastructure, Social27 uses Identity and Access Management (IAM) to define and manage roles and access privileges. For customers, we use Customer Identity Management, and for employees, we use Employee Identity Management. For internal system access, we use Active Directory for centralized authentication and authorization. To authenticate to customer-facing systems, we use Customer Identity and Access Management (CIAM).
How do employees authenticate to customer-facing systems?
Through Customer Identity and Access Management (CIAM)
Who has access to customer data?
Access to production systems containing customer information require two-factor authentication through a VPN connection. Only authorized persons can access customer data. Developers and/or system admins are not authorized to access customer data, and all customer data is protected with strong encryption.
What service-level agreements do you have for maintaining customer data?
Social27’s service-level agreement (SLA) includes the specifics of data maintenance services provided and excluded, conditions of service availability, standards (such as time window for each level of service), responsibilities of each party, escalation procedures, and cost/service trade-offs.
How is data stored at rest?
All data is automatically encrypted and stored on the cloud. Azure Key Vault and AWS KMS are used to store tokens, passwords, certificates, API keys, and other secrets. Azure Key Vault and AWS KMS are used as a key management solution.
How is data encrypted at rest?
Social27 data at rest is encrypted with a symmetric encryption key and decrypted transparently with industry standard AES-256 encryption. Data at rest can be protected using Customer keys or AWS keys. The same encryption key is used to decrypt the data as it is readied for use in memory. Keys are stored in a secure location with identity-based access control and audit policies.
How is data encrypted in transit?
Communication with Social27 is encrypted via TLS 1.2 or higher over public networks. Data in transit via email is encrypted via S/MIME and TLS. We monitor community testing and research in this field and continue to follow best practices for Cipher adoption and TLS configuration.
What is your data backup policy?
Social27’s backup arrangements meet the requirements of business continuity plans. Critical systems are determined and backup arrangements made to recover all critical system information, applications, and data in the event of a disaster. Automated backup solutions are sufficiently tested prior to implementation and at regular intervals thereafter. Where confidentiality is of importance, backups are protected by means of encryption and all encryption keys are kept securely at all times with clear procedures in place to ensure that backup media can be promptly decrypted as required.
What is your disaster recovery plan in response to data loss?
Plans for disaster recovery shall be developed by organizational management. Data recovery operations are only performed by competent, authorized staff. Recovery of data from backups takes no more than 24 – 72 hours, depending on the amount of data.
Where is the platform deployed (what cloud provider, what on-premise hosting)?
On Cloud Microsoft Azure and AWS
How many distinct hosting locations do you use?
Social27 is hosted on public cloud infrastructure. Services are deployed in multiple availability zones and regions and are designed to scale dynamically in response to measured and expected loads. Cloudfront is used to distribute services globally. Simulated load tests and API response time tests are integrated in Social27’s release and testing cycles.
What is the failover process from one hosting location to another?
Social27 employs an Autoscaling Group that automatically terminates a faulty instance in one hosting location and transitions to a new healthy instance at another location. Because services are deployed in different availability zones, business can continue as usual by using other availability services.
What is the disaster recovery plan in response to a major outage?
In the event of a significant regional downturn, Social27 can deploy the application to a new hosting region. Our Disaster Recovery Plan maintains and ensures availability of services and ease of recovery in the case of a disaster. This plan is regularly tested and evaluated for improvement and automation.
Disaster Recovery Deployment is handled by the same design and release management processes as our production environment, ensuring that all security settings and controls are correctly implemented.
Can one customer cause an outage for other customers?
No, all customer environments are totally isolated from each other.
What load tests do you run?
Social27 runs load tests directly on the web application. We set up and run performance tests to maintain the availability of our services. We also run network load tests , system load tests, and Vulnerability testing on our infrastructure, application, and code before pushing them to production.
How many concurrent users do you support?
We have run events with 25,000 concurrent users and can scale further using Autoscaling to automatically scale up and scale down our infrastructure.
How many peak users do you support?
We 27 currently can scale anywhere from 10,000 to 100,000 peak user load. The platform can be scaled up or down in response to demand in 5 – 10 minutes.
How do you forecast demand and provision new computing/storage resources?
Before the event, we work with the AWS team and the client to forecast demand based on the expected user load and location.
How do you optimize costs over time?
We check our infrastructure and ensure that we are using the right services that include CPU and storage classes. For long running instances, we use reserved instances that will save 40-50% on instance cost.
What alarms do you have?
Cloud Watch alarms and Operations management alert Social27 to potential performance problems.
What is your mean time to detection of customer-impacting issues?
How quickly can you descale the platform in response to decreased demand?
5 - 10 minutes
When was the last time you performed a scaling exercise?
1 week ago.
What is your mean time to resolution of customer-impacting issues?
Our current mean time to detection of customer-impacting issues is 5 – 10 minutes, and our mean time to resolution of these issues is 15 minutes for system or application-level issues (per our SLA). Bug fixes may take time anywhere from 1 day to 1 week.