Security policy

Security policy

Version 1.0 – December 2018

 

This policy outlines: 1) mybrand.center’s security practices and resources, and 2) your security obligations.

Obligations under this policy (both ours and yours) are incorporated by reference into the mybrand.center Terms of Service.

 

Our Obligations

Without limiting any provision of the mybrand.center Terms of Service, we will implement reasonable and appropriate measures designed to help you secure Your Content against accidental or unlawful loss, access or disclosure.

 

Your Obligations

Our documentation may specify restrictions on how the Services may be configured, or specifications for mybrand.center applications. You agree to comply with any such restrictions or specifications.

You are responsible for properly configuring and using the Services and taking your own steps to maintain appropriate security, protection and backup of Your Content, which may include the use of encryption technology to protect Your Content from unauthorized access and routinely archiving Your Content. mybrand.center provides many built-in controls for you, as discussed herein. Where configurable or optional security controls (such as encryption) are offered as part of the Services, you are responsible for configuring or enabling those controls. You are ultimately responsible for determining whether the security controls applied to your Applications and data are sufficient for your requirements.

mybrand.center access credentials and private keys generated by the Services are for your internal use only. You may not sell, transfer or sublicense them to any other entity or person, except that you may disclose your private key to your agents and subcontractors performing work on your behalf.

Pursuant to Section 2 of the mybrand.center Terms of Service, you will not use the Services to create, receive, maintain, or transmit electronic HIPAA PHI or GDPR Personal Data without the corresponding agreement legal agreement (HIPAA business associate agreement or GDPR data protection agreement) in place between you and mybrand.center.

 

Requesting Penetration Testing Authorization

You may conduct penetration tests of your mybrand.center environment(s). To do so, please contact us with the following information:

  • Start and end times for the scan window (YYYY-MM-DD HH:SS format)
  • Environment(s) to be tested (dedicated stacks only please)
  • Source IPs (and owners of those IPs) for the scan
  • Peak bandwidth in Gbps
  • Expected peak requests per second
  • Whether you or the testing company have an NDA in place with AWS
  • Name, email, and phone for a point of contact for both you and the testing company

 

Reporting Security Vulnerabilities

If you discover a potential security vulnerability, please contact support@mybrand.center

 

1. Data Center Security

mybrand.center runs on the Microsoft Azure global infrastructure platform.

Microsoft publishes “Azure Security white papers” that serves as the reference material for this section. SOC 2 reports are available directly from Microsoft upon request.

https://docs.microsoft.com/en-us/azure/security/

 

1.1 Compliance

Microsoft designs and manage the Azure infrastructure to meet a broad set of international and industry-specific compliance standards, such as ISO 27001, HIPAA, FedRAMP, SOC 1, and SOC 2. Microsoft meets country-specific standards, including Australia IRAP, UK G-Cloud, and Singapore MTCS. Rigorous third-party audits, such as those done by the British Standards Institute, verify adherence to the strict security controls these standards mandate.

For a full list of compliance standards that Azure adheres to, see the Compliance offerings. https://www.microsoft.com/trustcenter/compliance/complianceofferings

 

1.2 Physical Security

Microsoft takes a layered approach to physical security, to reduce the risk of unauthorized users gaining physical access to data and the datacenter resources. Datacenters managed by Microsoft have extensive layers of protection: access approval at the facility’s perimeter, at the building’s perimeter, inside the building, and on the datacenter floor.

See https://docs.microsoft.com/en-us/azure/security/azure-physical-security for a detailed description of the physical security.

 

1.3 Environmental Security

Azure data center environmental controls include:

  • Fire detection and suppression systems
  • Redundant power systems, backed by Uninterruptible Power Supply units and generators
  • Climate and temperature controls
  • Active system monitoring

 

2. mybrand.center Network Security

Please see our Reference Architecture Diagram for an explanation of the terms in this section.

 

2.1 Secure Architecture

mybrand.center center servers run in a separate Azure virtual private cloud. Only SSL/TLS endpoints are exposed to the internet. Backend users (mybrand.center root admins) can only connect to the private cloud through the bastion host, which restricts access to network components and logs activity for review.

 

2.2 Firewalls

Azure implements robust software security and firewall features at various levels to enforce security features that are usually expected in a traditional environment to protect the core Security Authorization boundary.

https://docs.microsoft.com/en-us/azure/security/azure-production-network

All mybrand.center servers use separate individual firewalls and run on a private internal mybrand.center network.

 

2.3 Port Scanning

Azure monitors and stops unauthorized port scanning. Because most of the mybrand.center is private, and all hosts run strict firewalls, port scanning is generally ineffective.

 

2.4 DDoS Protection, Spoofing & Sniffing

Windows Azure has a distributed denial-of-service (DDoS) defense system that helps prevent attacks against Windows Azure platform services. It uses standard detection and mitigation techniques such as SYN cookies, rate limiting, and connection limits.

Windows Azure’s DDoS defense system is designed not only to withstand attacks from the outside, but also from within.
For attacks launched from the outside (Internet), IP addresses can be spoofed, although they are prevented from spoofing Windows Azure datacenter IP address ranges.
For attacks launched from within a tenant, trusted packet filters prevent impersonation (spoofing) of Windows Azure IP addresses inside the Windows Azure datacenter.
Windows Azure monitors and detects internally initiated DDoS attacks and removes offending VMs from the network.

 

3.5 Network and Host Vulnerability Scanning

mybrand.center scans both the Internet-facing network and private network of an mybrand.center environment each month. mybrand.center is responsible for network and host security, and remediates adverse findings without customer intervention, however you may request a scan of your mybrand.center environment as needed for your own security assessments and audits.

 

4. mybrand.center Platform Security

4.1 Configuration and Change Management

mybrand.center uses continuous integration and continuous delivery to develop and release new features. Once new features meet our quality control standards, they are carefully been planned to be released for a new production deployment. Before updating de mybrand.center production environment, all features within the planed deployment, need to pass a full regression test on our mybrand.center staging environment, using several client environments to test data integrity and compatibility after deployment. Once all features and migrations meet our quality standards, a deployment announcement will be sent out to all mybrand.center organization accounts. The upcoming deployment will also be announced through the mybrand.center. Deployment announcements will be made in 2 weeks advance, allowing users to anticipate in possible temporary downtime of the platform. After deployment on our production environment, a complete health check is carried out.

 

4.2 Isolation

mybrand.center uses separated customer environments, each environment is using its separate set of databases which are not shared with other environments.

 

4.3 Logging and Monitoring

mybrand.center logs Azure and mybrand.center API activity, and host activity within the complete mybrand.center center. mybrand.center monitors performance indicators such as disk, memory, compute, and logging issues, and automatically resolves them.

 

4.4 Intrusion Detection & Prevention

By default Azure has IDS/IPS in place. Every packet that enters the Azure network is going to be subject to inspection by the systems that are already in place.

Additionally, the mybrand.center Security Team monitors and investigates each event to determine the legitimacy of all activity. Crucially, the mybrand.center Security Team immediately responds to and resolves any issues that are discovered through investigation of anomalous activity and will notify you of any remediation steps taken.

 

4.5 Host Hardening

For all mybrand.center operating systems::

  • Non-default SSH ports are used.
  • No password-based services are installed automatically. Password-based services (such as MariaDB) are provisioned only with unique, per-resource, mybrand.center-generated passphrases. No default passwords are permitted.
  • Host security updates are automated.
  • All host ports are opened only via whitelist.

 

4.6 Databases

Databases run in the database layer of your stack, on a private subnet accessible only from app or bastion layer. SSL/TLS is required if the database protocol supports it.

 

4.7 mybrand.center Penetration Testing

mybrand.center conducts penetration testing of the mybrand.center infrastructure at least annually. These tests consist of open-ended, best-effort security assessments performed by our security team. The testers review the mybrand.center architecture, are given full read access to mybrand.center source code (and access to the mybrand.center engineering team to answer questions throughout the test), and are given privileged internal (i.e., backdoor) access to a mybrand.center test environment. From this context, the testers attempt to identify vulnerabilities mybrand.center’s admin panel, core API, authentication API, and related mybrand.center services.

All vulnerabilities identified as a result of our penetration tests are classified by severity level (from critical risk to low risk), and are remediated in order of severity. Critical vulnerabilities are scheduled for remediation within 24 hours.

You may conduct testing of your mybrand.center environment as described above (“Requesting Penetration Testing Authorization”).

 

5. mybrand.center Business Continuity

5.1 Backups

mybrand.center automatically backs up several different types of data:

  • mybrand.center app code and images built from that code are stored in private, redundant, access-controlled registries. In the event of a disaster, mybrand.center restores apps from the last healthy build image and restores data from the last backup;
  • Customer metadata is stored in MariaDB and MongoDB databases. Metadata includes customer account data (encrypted passwords, permissions), and environment configuration data. Backups are taken nightly and retained for one week. No customer action is required;
  • mybrand.center customer files are automatically backed up nightly and retained daily for 7 days. No customer action is required;
  • mybrand.center customer databases are automatically backed up nightly and retained daily for 7 days. No customer action is required. Two backup copies are kept: One included in the daily file backup, to facilitate fast disaster recovery; the other in a full data image snapshot to protect against loss of the file backup.

All backups are for crash and recovery purposes only. The mybrand.center center prevents accidental data deletion by the end-user by providing extensive user-feedback and data deletion protection. “Soft deleted” data will be purged from the system on a regular base (after 30 days).

Backups are stored with encryption, have local redundancy and are limited to The Netherlands.

 

5.2 Fault Tolerance

Azure data centers are clustered into regions, and sub-clustered into availability zones, each of which is designed as an independent failure zone, meaning they are:

  • Physically separated
  • Located in lower-risk flood plains
  • Equipped with independent uninterruptable power supplies and onsite backup generators
  • Fed via different grids from independent utilities, and
  • Redundantly connected to multiple tier-1 transit providers

The mybrand.center center has currently local redundancy.

 

5.3 High Availability

The mybrand.center center is by default currently not in High Availability mode, however High Availability can be requested as an additional service.

 

5.4 Disaster Prevention and Recovery

mybrand.center monitors the stability and availability of customer infrastructure. In the event of a disaster,mybrand.center restores apps from the last healthy build image and restores data from the last backup. Raw database snapshots are available upon request for testing and recovery.

 

6. mybrand.center Internal Security

6.1 mybrand.center Access

We do not access or use Your Content for any purpose other than for developing and operating the Services and as required by law. As a routine matter, mybrand.center workforce members do not require access to data processed by your environment, such as data stored in your databases. mybrand.center workforce members are granted least-privilege access to customer environments only when a specific business need arises.

 

6.2 Security Management

mybrand.center manages information security consistent with applicable legal and regulatory requirements such as HIPAA and GDPR.