Last modified: 01.03.2021
Security being just important to us is a huge understatement. Security is a top priority at StorifyMe and we live it in our day-to-day activities.
Our Management team is accountable for security and ensures that security capabilities and competence exist in all levels of our business. As a whole, we follow a holistic and collaborative approach to guarantee the confidentiality, availability, and integrity of your data. On this page, you can read about the various policies and security measures taken by StorifyMe to secure user content and data hosted on our platform from unauthorized access.
Our infrastructure runs purely on Amazon Web Services (AWS), which delivers infrastructure as a service with prime security capabilities.
The data centers used for storing your content and allowing it to be delivered to your users are certified for compliance with the ISO 27001 standard.
Your data is encrypted at rest in AWS S3 buckets, AWS RDS instances and block devices used by AWS EC2 instances. AES256 encryption is used by default via AWS’ encryption services. This ensures the content is preserved and safe from prying eyes and manipulation.
All user passwords are hashed using the Bcrypt password hashing function and stored in the database. Bcrypt uses salts and 11 rounds of algorithm to increase the complexity of hashing to minimize risk of passwords being cracked.
All communication between you, your services and StorifyMe, that includes your data, traverses the Internet via encrypted HTTPS traffic using TLS v1.2. In addition, data is also encrypted during transit between StorifyMe and our Content Delivery Networks (CDNs). This encryption during communication ensures information cannot be read or manipulated by unauthorized third parties.
Our infrastructure, web applications, and APIs are penetration tested by external independent parties. Any vulnerability found are fixed based our specifications in an internal SLA.
All our data, including database daily backups, is replicated between multiple regions thanks to the use of AWS. Backup data is encrypted at rest using AES-256 encryption.
Access to your data is extremely restricted. We have hand-picked and trained support staff and Engineers on support that, after your explicit permission, are able to help fix your problem by accessing the affected data that you authorize. These actions are recorded, audited and monitored.
Did we mention we are a cloud native service? We do not have data centers. Physical security to our servers and to your data is managed by AWS security certifications. Physical security at our offices is also governed by our security program.
Networking in the cloud is very different from the standard data center. All communications to and from our servers are controlled by tight security groups, an AWS security feature for stateful firewalling.
Applications available on the internet are constantly under threat of attacks. One of the protections implemented to protect our applications is the Web Application Firewall.
Provided by AWS GuardDuty, we monitor and respond to threats when they happen. We detect inbound and outbound connections from and to known malicious IP addresses, unusual or unauthorized activities in our AWS accounts and much more.
To protect our users from attacks, we leverage browser protections such as HTTP Strict Transport Protection. We also constantly monitor our SSL configuration rating, where we target to a minimum of an A grade for all our general domains and an A+ for all domains under our full control.
Your data lives in our servers for as long as you need them. Our Data Retention Policy and Data Classification Policy govern the way we manage data that needs deletion and retirement.
To prevent your account to be compromised by brute forcing our web application and APIs, we implement captchas.
Access to customer data is logged along with SSH session commands in production. This provides a trail that can be easily followed in any security audits.
Users can protect their StorifyMe accounts through two-factor authentication. 2FA verifies users through an authenticator app such as Google Authenticator, Authy, or Duo Mobile. Organization admins can see which users have 2FA enabled via the web app.
Our infrastructure runs in Amazon Web Services, where all components are deployed in at least two availability zones, minimizing disruptions caused by any failure and keeping your content constantly available. Elastic Load Balancers are used to automatically split the load and segregate traffic from the Internet to all nodes of our frontend layer.
All our software components run in managed AWS environments. The environments are automatically resized when the load on the system exceeds than the pre-defined threshold. Our platform has been designed from scratch to support high volumes of web traffic and this technology stack is the fundamental piece that caters to our high availability needs.
More than 80% of static assets is served directly by AWS CloudFront, our global choice of content delivery network. We utilize AWS CloudFront heavily for cache population and invalidation, so in the unlikely event our infrastructure ever experiences technical difficulties, content can still be served by the CDN and remain online in the meantime.
Our APIs and web application are protected in multiple ways against denial of service attacks. AWS provides volumetric denial of service protection through AWS Shield and Elastic Load Balancing to ensure high availability.
StorifyMe utilizes database replication architectures to ensure redundancy and uptime. Encrypted backups are made frequently and stored both onsite at the data center and copied to a remote storage location. Each key service layer has redundant components, such as multiple servers that provide the same service and content, to ensure any failures do not impact the rest of the system. Data centers are also equipped with controls to enforce physical security and protection against environmental hazards
All vulnerabilities are managed internally in our internal vulnerability management tool. Once a vulnerability is detected, it is assigned a score, using the CVSS scoring system, and an owner. We have an internal SLA that stipulates deadlines for fixing vulnerabilities, while progress is tracked by tools and, if necessary, a post-mortem is arranged as a learning exercise for our engineers to improve code security.
Our development process is based on Gitlab’s pull request mechanism. Once a commit is made to a branch in a specific repository, the code is reviewed by members of the engineering teams. Only once the pull request is approved by all tagged engineers is the code moved along in the development life cycle. Our developers and engineers are also heavy practitioners of pair programming, which lets them detect bugs and vulnerabilities more effectively before code makes it into the final product.
When code is committed to Gitlab, our continuous integration process automatically initiates a series of tests. One such test is automatic static code analysis, configured to find vulnerabilities both in the code and within its dependencies. Dependency management is performed locally per repository, where all dependencies are tagged by version and downloaded from reputable sources over encrypted HTTPS.
Once the code is ready to be tested, it is deployed to our staging environment. This environment runs a downscaled version of the production infrastructure and does not contain any production data. Quality assurance is performed in a different AWS environment that is configured with different domain names to ensure complete separation from production.
Security is part of the Product organization and influences the product roadmap and specific features. We implement the philosophy of “security by design” where security features are embedded in the product and architecture design to ensure existing and new functionalities are free of vulnerabilities. We believe that engineers should be responsible for the code they create and have an established culture of accountability, which leads to a high level of code quality and security being maintained.
StorifyMe continually looks out for any indicators that could potentially lead to incidents. To supplement this, any event-alerting tools we use also escalate into PagerDuty rotations for StorifyMe’s 24x7 incident response team. We also maintain an incident response plan that details ways to address an incident, including the processes of notification, escalation, managing and reporting as a result of an incident.
All StorifyMe employees and contracted third-parties are required to comply with StorifyMe policies relevant to their scope of work, including security and data privacy policies. Our standard work contract includes confidentiality clauses.
StorifyMe ensures its employees undergo regular security and privacy training.
StorifyMe uses Stripe’s infrastructure to process credit card payments, which means that no credit card information or related personal information is stored on our servers. Stripe enforces stringent PCI DSS (Payment Card Industry) compliance criteria to ensure that any data stored and/or processed on its servers is handled in a secure way.
In addition to privacy and safety measures, Stripe employs an extensive range of checks designed to minimize payment fraud and unauthorized access. These checks include 3D-Secure authorization, credit card background checks, flagging suspicious transactions for manual verification, and real-time monitoring of payment transactions with automated anti-fraud algorithms.
To ensure an acceptable level of password security, passwords that are too generic are not allowed while the use of unique passwords per website is strongly advised. We also encourage the use of password managers, for example LastPass, that help make it easier and safer for you to keep track of your credentials.
The use of multi-factor authentication (MFA) is enforced throughout the main services StorifyMe relies on. MFA is also encouraged by StorifyMe to both its employees and customers. The use of MFA provides an additional measure for verifying a user’s claimed identity over the use of just a password. Currently, the minimum requirement for our MFA implementation is the use of a password combined with an access token (for instance, a code provided by Google Authenticator). MFA is also mandatorily enforced for AWS and Gitlab access.
We provide Single Sign-On capabilities via SAMLv2. This means our customers have full control over who has access to the use of our product and how authentication takes place. Customers can implement their own password policies and multi-factor authentication implementations.
Organizations that manage access to tools and services for large amounts of users can take advantage of integration built around an industry-standard protocol known as SCIM (System for Cross-domain Identity Management). With SCIM provisioning, you can leverage a SCIM API to automatically grant access to StorifyMe to your users, or integrate through identity providers (IdPs) like Okta to synchronize membership with StorifyMe Teams - all based on user data managed centrally in your IdP platform.
Your data is protected behind multiple API keys, used in different contexts for particular use cases. Keys are assigned to the user and follow the user’s privilege associated with an organization and space. Our application enforces authorization for every API call, apart from assets.
StorifyMe highly encourages the use of roles and permissions in order to provide different users with different levels of access rights to content, features, and functionality. This is in line with “least privilege” and “need to know” security principles, which adds another safeguarding layer to prevent unauthorized access and limit damage in the event of a user’s credentials being compromised.
While all activities relevant to content and data traversing the Internet are conducted with HTTPS enforced on StorifyMe’s side, we absolutely recommend that customers and users also enforce HTTPS so that content and data integrity is maintained and free from manipulation as it is served from our service to your users’ machines. The use of HTTPS websites also safeguards your important data and credentials away from the view of unauthorized third-parties.
In order to sign up with StorifyMe, it is required to create a secure password that is a minimum of 8 characters and has a combination of alphabets, numbers, and special characters such as ‘@,!.#._’ and so on.
Some examples of secure passwords are:
The current modern digital age comprises devices in many different forms, such as desktop machines, laptops, smartphones, smart watches, and tablets. These devices are usually connected with other computing devices and share information, and in many cases, they may also connect with banks to conduct financial transactions. All of these devices are potentially vulnerable to misuse by unauthorized users, and therefore, users should always protect them with strong and secure passwords.
Following are some recommendations to create a secure password:
Learn more about insecure passwords that have previously exposed in data breaches. This exposure makes them unsuitable for ongoing use as they’re at much greater risk of being used to take over other accounts.
Incidents can happen to anyone — we are ready for such an event when it happens. We manage security incidents via a documented process, which includes notification of and cooperation with customers, data protection authorities, and law enforcement. StorifyMe will notify affected customers without undue delay following incident detection, where we share a preliminary assessment of the incident and are open to cooperation. We follow article 33 of the GDPR when personal data is involved, and alert the supervisory authority regarding breach of personal data.
StorifyMe engages with the community via our Responsible Disclosure Program, also known as our Bug Bounty Program. Our community plays an important role in helping us stay bug-free and secure.
Found a vulnerability? Would you like to report a bug or something interesting that you found? The best way to reach out to us is via e-mail to firstname.lastname@example.org. We advise abstaining from publicly announcing a vulnerability or bug before we get in touch with you and work on a fix.
The following template can be used when submitting a vulnerability:
[Description of the identified vulnerability]
# Steps to reproduce
1. Step 1
2. Step 2
[What could an attacker achieve by exploiting the vulnerability]
Any report submitted in relation to this Responsible Disclosure Policy will be handled with great care with regards to the privacy of the reporter. We will not share your personal information with third parties without your permission, unless we are legally required to do so.
Delight and engage with your customers in a way they are used to. Gather all valuable insights in our intuitive dashboard. Start today for free.Create your first story