Security is one of the most vital parts in offering a cloud software solution to our clients. Securing sensitive data is central to our values at Accept Mission. This is why we have implemented rigorous security policies that we continue review, update and build upon. As organization and in the software solutions we deliver.
“We are Committed to Information Security and Privacy”
Accept Mission 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.
We isolate customers from each other
All Enterprise customers are isolated with their own database with unique and randomly generated credentials, secured and encrypted using Azure Kubernetes Service. 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.
We provide SSO access to the platform
Workspace Admins have the option to enable secure Single Sign-On access to the platform. We provide many different ways to achieve this: SAML, Azure B2B, OpenID and build integrations with third party SSO providers.
We proactively monitor the service
We regularly check our service monitoring dashboards and have alerts set up to notify our team if anything ever looks out of place.
We keep the software up to date
We use fast Patching timeframes for critical and high vulnerabilities. Every two weeks new software updates are installed when they are available and secure and stable for our SaaS solution.
We monitor and act on suspicious behavior
Unusual network patterns or suspicious behavior is monitored. Microsoft Azure Infrastructure 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.
Accept Mission 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.
We audit continuously during the development proces
Accept Mission audits changes to our application throughout the development lifecycle via architecture reviews and stringent automated and manual code review processes.
We’ve Built In Security Controls
We’ve taken significant measures to ensure that Accept Mission 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 Accept Mission 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.
We use the latest versions of Encryption TLS v1.3
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 (version 1.3). Accept Mission nodes run in isolated containers, configured according to the principle of least privilege, and with restrictions on system calls and allowed root operations. Accept Mission nodes communicate using TLS. Cluster data is encrypted at rest. API access is limited to Accept Mission 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 Accept Mission offerings, however, we do use third parties to perform application security assessments against the Accept Mission software components used to deliver these services.
We Practice Responsible Vulnerability Management
Accept Mission recognizes that software development inherently includes the possibility of introducing vulnerabilities. We accept and disclose vulnerabilities discovered in our software in a transparent manner.
We Operate in Compliance with the Principles of GDPR
Accept Mission is operating in compliance with the principles of GDPR. Accept Mission customers are covered via the Accept Mission Data Processing Addendum (DPA).
Protecting your account
At Accept Mission, 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 Accept Mission Cloud. The security and privacy of your Accept Mission Cloud SaaS data also relies on you maintaining the confidentiality of your Accept Mission Cloud login credentials.
Here’s a quick checklist:
- Don’t share your credentials with others.
- Update your account profile to make sure information is correct and current.
- Ensure that you’ve set secure passwords.
- If you believe an account has been compromised, please contact us.
- If you need to make an erasure request, please contact us.
Our Privacy Statement is Transparent and Clear
We Operate on a Modern Cloud SaaS Platform
We use Microsoft Azure Infrastructure for our Cloud datacenter, which means our customers benefit from GCP’s comprehensive security practices and compliance certifications. Standard all of our servers are located in West Europe. Enterprise customers can choose to place their database server at another location worldwide. 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.
Accept Mission Cloud is hosted on infrastructure that we control via Microsoft Azure Kubernetes. 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.
Physical Access Control
Accept Mission is hosted on the Microsoft Azure Cloud infrastructure. Azure data centers feature a layered security model, including extensive safeguards such as:
- Custom-designed electronic access cards
- Vehicle access barriers
- Perimeter fencing
- Metal detectors
According to the Microsoft 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.”
Accept Mission employees do not have physical access to Microsoft Azure data centers, servers, network equipment, or storage.
Network Access Control
Accept Mission is the assigned administrator of its infrastructure on Microsoft Azure Cloud infrastructure, and only designated authorized Accept Mission 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.
Accept Mission 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.
Microsoft Azure Cloud infrastructure 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.
Business Continuity and Disaster Recovery
Every part of the Accept Mission 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.
Accept Mission keeps continuous encrypted backups of data on the Microsoft Azure Cloud infrastructure. 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, Accept Mission will bring up a duplicate environment in a different Microsoft Azure Cloud infrastructure. We always respect the location of the data based on the agreement of the customers.
Recovery Point Objective (RPO)
The maximum acceptable age of the data that can be restored (or recovery point) and the version of data lost. RPO: ’24 hours’.
Recovery Time Objective (RTO)
The maximum acceptable length of time required for an organization to recover lost data and get back up and running. RTO: ’72 hours’.
Data into servers
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.
Data between our servers
Connections between our servers (i.e. web servers <-> databases) are encrypted via TLS v1.3 with a AES-256bit encryption method. Secrets such as database password, API secrets are encrypted using the same AES-256bit method.
Data out of our servers
Once the request is processed, the response is sent back using the same HTTPs SSL encrypted connection.
Data Security and Privacy
All data in Accept Mission servers is automatically encrypted at rest. Microsoft Azure Cloud infrastructurestores 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 Accept Mission 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. Accept Mission exclusively sends data over HTTPS transport layer security (TLS) encrypted connections for additional security as data transits to and from the application.
Data Retention & Removal
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.
Accept Mission follows the incident handling and response process recommended by SANS, which includes identifying, containing, eradicating, recovering from, communicating, and documenting security events. Accept Mission notifies customers of any data breaches within 2 business days via email or phone call, followed by periodic updates throughout, addressing progress and impact.
Systems status live report
Accept Mission maintains a live report of operational uptime and issues on our status page.
Incident response plan
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 Accept Mission 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.
Contacting Accept Mission
If you have any questions about the Security Policy, please contact us.
3016 BC, Rotterdam
This Security Policy is effective as of January 01, .