New report from G2: Ideanote chosen as Idea Management Leader
See the steps we ensure your privacy and protection with Ideanote
A deep respect for our customers and their sensitive data workflows has always been central to our values at Ideanote. This is why we have implemented rigorous security policies that we continue to build upon, with every product release.
Ideanote maintains a comprehensive information security program that includes appropriate technical and organizational measures designed to protect our customers' cluster data against unauthorized access, modification or deletion.
All customers are isolated within their own Postgres database with unique and randomly generated credentials, secured and encrypted using Kubernetes Secrets. All customers are isolated inside of their own namespace within Kubernetes, with network policies, roles, and other security measures in place to ensure each tenant is truly isolated.
Workspace owners have the option to enable secure Single Sign-On access to the platform.
We regularly check our service monitoring dashboards and have alerts set up to notify our team if anything ever looks out of place.
Unusual network patterns or suspicious behavior is monitored. Google Cloud Platform’s intrusion detection and prevention systems (IDS/IPS) rely on both signature-based security and algorithm-based security to identify traffic patterns that are similar to known attack methods. IDS/IPS involves tightly controlling the size and make-up of the attack surface, employing intelligent detection controls at data entry points, and developing and deploying technologies that automatically remedy dangerous situations, as well as preventing known threats from accessing the system in the first place.
Ideanote does not provide direct access to security event forensics, but does provide access to the engineering and customer support teams during and after any unscheduled downtime.
Ideanote audits changes to our application throughout the development lifecycle via architecture reviews and stringent automated and manual code review processes.
We've taken significant measures to ensure that Ideanote customer data cannot be read, copied, modified, or deleted during electronic transmission, transport, or storage through unauthorized means.
To reduce the likelihood of vulnerability-related incidents, the Ideanote team deploys stances based on the latest operating system kernels, and patches the computing “fleet” whenever a critical CVE (i.e., "Common Vulnerability and Exposure," in security-speak) is discovered in any component software.
Clusters are deployed behind proxies and are not visible to internet scanning. Transport Layer Security (TLS) encrypted communication from the Internet is provided in the default configuration. Ideanote nodes run in isolated containers, configured according to the principle of least privilege, and with restrictions on system calls and allowed root operations. Ideanote nodes communicate using TLS. Cluster data is encrypted at rest. API access is limited to Ideanote APIs, and no remote access to the instance or container at the Linux level is allowed. Containers have no means of setting up communication with containers from another cluster.
We do not perform Internet-based penetration testing against production Ideanote offerings, however, we do use third parties to perform application security assessments against the Ideanote software components used to deliver these services.
Ideanote recognizes that software development inherently includes the possibility of introducing vulnerabilities. We accept and disclose vulnerabilities discovered in our software in a transparent manner.
Ideanote is operating in compliance with the principles of GDPR. Ideanote customers are covered via the Ideanote Data Processing Addendum (DPA).
At Ideanote, we know that security is everyone's responsibility. That's why we bake security into the development of our products and into the foundation of Ideanote Cloud. The security and privacy of your Ideanote Cloud SaaS data also relies on you maintaining the confidentiality of your Ideanote Cloud login credentials.
Here's a quick checklist:
Ideanote respects the privacy rights of individuals. Our privacy policy makes it very clear when we collect personal data and how we use it. We've written our privacy policy in plain language to be transparent to our users and customers.
We use Google Cloud Platform for our Cloud datacenter, which means our customers benefit from GCP's comprehensive security practices and compliance certifications. We do not host customer data on our premises or store customer data with any other third party services. GCP is a leading cloud provider that holds industry best security certifications such as SOC2 and ISO 27001 and provides encryption in transit and at rest.
Ideanote Cloud is hosted on infrastructure that we control via GCP's Google Kubernetes Engine, in GCP. To allow it to communicate with your systems, we run a single NAT that all internet bound traffic flows through. We don't persist any of your data, and all computation runs in short-lived containers that terminate after tasks are completed.
Our cluster and databases are all hosted in a private VPC with all private IPs. We connect to the cluster via SSH to a bastion node set up with authorized networks. We use the GKE managed firewall rules at the VPC layer.
Ideanote is hosted on the Google Cloud Platform. Google data centers feature a layered security model, including extensive safeguards such as:
According to the Google Security Whitepaper: “The data center floor features laser beam intrusion detection. Data centers are monitored 24/7 by high-resolution interior and exterior cameras that can detect and track intruders. Access logs, activity records, and camera footage are reviewed in case an incident occurs. Data centers are also routinely patrolled by professional security guards who have undergone rigorous background checks and training.”
Ideanote employees do not have physical access to Google data centers, servers, network equipment, or storage.
Ideanote is the assigned administrator of its infrastructure on Google Cloud Platform, and only designated authorized Ideanote operations team members have access to configure the infrastructure on an as-needed basis behind a two-factor authenticated virtual private network. Specific private keys are required for individual servers, and keys are stored in a secure and encrypted location.
Ideanote undergoes vulnerability assessment and penetration testing, conducted by an independent, third-party agency on an annual basis. For our enterprise level customers we're happy to provide the results of their findings and the mitigation we applied.
Google Cloud Platform undergoes various third-party independent audits on a regular basis and can provide verification of compliance controls for its data centers, infrastructure, and operations. This includes, but is not limited, to SSAE 16-compliant SOC 2 certification and ISO 27001 certification.
Every part of the Ideanote service uses properly-provisioned, redundant servers (e.g., multiple load balancers, web servers, replica databases) in the case of failure. As part of regular maintenance, servers are taken out of operation without impacting availability.
Ideanote keeps continuous encrypted backups of data on the Google Cloud Platform. While never expected, in the case of production data loss (i.e., primary data stores lost), we will restore organizational data from these backups.
In the event of a region-wide outage, Ideanote will bring up a duplicate environment in a different Google Cloud Platform region.
All the incoming connections towards our servers are required to be encrypted with industry standard SSL encryption. Latest SSL Labs report can be found here.
Connections between our servers (i.e. web servers <-> databases) are encrypted via TLS with a AES-256bit encryption method. Secrets such as database password, API secrets are encrypted using the same AES-256bit method.</->
Once the request is processed, the response is sent back using the same HTTPs SSL encrypted connection.
All data in Ideanote servers is automatically encrypted at rest. Google Cloud Platform stores and manages data cryptography keys in its redundant and globally distributed Key Management Service. So, if an intruder were ever able to access any of the physical storage devices, the Ideanote data contained therein would still be impossible to decrypt without the keys, rendering the information a useless jumble of random characters.
Encryption at rest also enables continuity measures like backup and infrastructure management without compromising data security and privacy.
Ideanote exclusively sends data over HTTPS transport layer security (TLS) encrypted connections for additional security as data transits to and from the application.
We do store all data for up to 6 years unless your account is deleted. In which case, we dispose of all data in accordance with our Terms of Service and Privacy Policy, within 60 days. Information regarding legal transactions between customers and Ideanote will be stored for up to 10 years.
All new employees receive onboarding and systems training, including environment and permissions setup, formal software development training (if pertinent), security policies review, company policies review, and corporate values and ethics training.
All engineers review security policies as part of onboarding and are encouraged to review and contribute to policies via internal documentation. Any change to policy affecting the product is communicated as a pull request, such that all engineers can review and contribute before internal publication. Major updates are communicated via email to all employees.
Ideanote follows the incident handling and response process recommended by SANS, which includes identifying, containing, eradicating, recovering from, communicating, and documenting security events. Ideanote notifies customers of any data breaches within 2 business days via email or phone call, followed by periodic updates throughout, addressing progress and impact.
Ideanote maintains a live report of operational uptime and issues on our status page.
In case of a security incident it's best to have a clearly defined plan and responsibilities. Below you will find more details regarding the response plan that Ideanote has in place in the unlikely case of a security breach.
Level 1: Depending on how the incident is reported/discovered we generally have the first level of technical support that is likely to triage/escalate the issue. Normally that role is reserved for whoever is on the level 1 tech support shift at the time.
Level 2: Is a senior engineer or CTO that classifies the impact of the security incident.
Level 3: CTO or CEO is responsible for the communication with the affected parties regarding the details of the breach.
Before escalating the incident to the next level, the person that first finds out about it needs to verify the incident and its initial impact.
Once verified the escalation process should be immediate to level 2 and then level 3 verbally, by phone, email, whatever medium available.
Once escalated the rank/severity of the incident must be determined. Does it affect all customers? A single company? An individual? What type of data was affected if any? Was it encrypted? If so, how?
Analyze all elements of the incident in order to identify all the causes or where a failure occurred including the software, hardware, people, and internal processes.
Based on the result of the investigation, determine what could be done to prevent this attack and what defensive mechanisms failed and take immediate action to re-mediate the cause and improve the future process.