There are several things that may be of interest for you. First of all, our General Terms and Conditions offer a lot of information about our service level and related issues. An up-to-date version can be found by going to our homepage, scrolling all the way down and clicking the ‘GTC’ link in the footer. Second, below is a lot of extra information about how we manage our Triggre Cloud taken from this document, Triggre – Security, Development and Hosting, with even more information. Feel free to share it with your customers if they need it.
Triggre runs completely on Microsoft Azure and is hosted in the Microsoft Western-Europe data center in Amsterdam. The datacenters in which Triggre is hosted are amongst the best compliant in the world. Amongst these are ISO 27001, SOC 1 and SOC2. For a complete list of certifications, please check the Microsoft Azure Certification website.
In case of a catastrophic failure of the Western-Europe datacenter, the fallback location will immediately become active. This fallback location is the Microsoft Northern Europe datacenter, which is located in Ireland (and therefore, is still part of the European Union). This provides the best possible physical protection, while also providing strong legal protection.
Physical access to the servers is strictly reserved for Microsoft Azure engineers. Remote access to the Triggre servers is only possible from the Triggre corporate network. Connecting to the Triggre corporate network requires valid credentials, as well as a device that has a valid certificate as issued by Triggre. The Triggre corporate network and Triggre production network are two
completely separated networks, using different Access Control Lists on different domains.
Applications do their own monitoring and log events such as user log-ins, user actions and changes to data. Anomalies are automatically detected and reported.
Intrusion and anomaly detection
Unexpected behavior in the application is automatically detected and reported by the Triggre Platform. These reports are evaluated and based on that evaluation appropriate actions are taken immediately. All application processes in Triggre have an expected way of executing them (as specified in the Designer). Any deviation from the expected execution (such as errors) cannot be executed because of this and is automatically reported by the Triggre Platform. This also, for example, reports URL manipulation (or URL injection) and the loading of external resources.
Other attempts at code injections are not reported, but instead are sanitized so the code isn’t executed. Because of the nature of Triggre, where you can create a wide range of applications, saving a bit of text that looks like a script might be valid for certain applications. So instead of forbidding that or raising alarms, Triggre properly encodes during transport so the code is never executed within the application.
On a platform level, monitoring is done by Windows’ built-in monitoring, extended with Triggre’s own resource monitoring system. It tracks events on a platform level, such as user log ins, whether processes are running as they should and it reports when resource consumption get to high, which might negatively influence application performance.
Currently event monitoring is decentralized. An implementation of ELK stack for the monitoring of events is currently being researched.