Security policy

Security policy

Version 1.0 – December 2018


This policy outlines: 1) myBrand’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 Terms of Service.


Our Obligations

Without limiting any provision of the myBrand 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 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 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 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 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.


Requesting Penetration Testing Authorization

You may conduct penetration tests of your myBrand 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


1. Data Center Security

myBrand 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.


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.


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 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 Network Security

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


2.1 Secure Architecture

myBrand center servers run in a separate Azure virtual private cloud. Only SSL/TLS endpoints are exposed to the internet. Backend users (myBrand 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.

All myBrand servers use separate individual firewalls and run on a private internal myBrand 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 scans both the Internet-facing network and private network of an myBrand environment each month. myBrand is responsible for network and host security, and remediates adverse findings without customer intervention, however you may request a scan of your myBrand environment as needed for your own security assessments and audits.


4. myBrand Platform Security

4.1 Configuration and Change Management

myBrand 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 production environment, all features within the planed deployment, need to pass a full regression test on our myBrand 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 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 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 logs Azure and myBrand API activity, and host activity within the complete myBrand center. myBrand 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 Security Team monitors and investigates each event to determine the legitimacy of all activity. Crucially, the myBrand 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 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-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 Penetration Testing

myBrand conducts penetration testing of the myBrand infrastructure at least annually. These tests consist of open-ended, best-effort security assessments performed by our security team. The testers review the myBrand architecture, are given full read access to myBrand source code (and access to the myBrand engineering team to answer questions throughout the test), and are given privileged internal (i.e., backdoor) access to a myBrand test environment. From this context, the testers attempt to identify vulnerabilities myBrand’s admin panel, core API, authentication API, and related myBrand 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 environment as described above (“Requesting Penetration Testing Authorization”).


5. myBrand Business Continuity

5.1 Backups

myBrand automatically backs up several different types of data:

  • myBrand app code and images built from that code are stored in private, redundant, access-controlled registries. In the event of a disaster, myBrand 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 customer files are automatically backed up nightly and retained daily for 7 days. No customer action is required;
  • myBrand 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 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 has currently local redundancy.


5.3 High Availability

The myBrand 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 monitors the stability and availability of customer infrastructure. In the event of a disaster, myBrand 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 Internal Security

6.1 myBrand 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 workforce members do not require access to data processed by your environment, such as data stored in your databases. myBrand workforce members are granted least-privilege access to customer environments only when a specific business need arises.


6.2 Security Management

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