Intrrol utilizes industry-standard cloud infrastructure vendors to provide the Intrro service. Intrro's infrastructure is primarily managed through Amazon Web Services, and is complemented by additional secondary infrastructure vendors to provide specific features within the Intrro web application, like machine learning and natural language processing.

Primary infrastructure

Principally, the Intrro web application leverages Amazon Web Services for infrastructure hosting.

The  web application is hosted in the Amazon Web Services eu-west-2 region located in London, United Kingdom.

Amazon Web Services has been granted formal certification, attestation, and audit reports for ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2, SOC 3, and more – the full list of compliance resources is available on the Amazon Web Services Security page.

Feature-specific infrastructure

Intrro also makes use of secondary cloud infrastructure providers to process data for specific features of the web application. The use of these features is optional within the web application.

Data is sent to these providers temporarily and stored for a brief period of time in order to perform the functionality of the feature, and is subsequently permanently deleted after the functionality has been performed. No data is permanently stored or hosted within these infrastructure providers.

Machine Learning and Natural language processing

Intrro utilizes Google Cloud Platform for machine learning and natural language processing. Upon use of the Intrro web application’s network analysis feature, the text content to be  analyzed is sent to Google Cloud Platform. All communication with Google Cloud Platform is encrypted in transit using HTTPS and Transport Layer Security 1.2.

Google Cloud Platform stores the text sent to the Cloud Natural Language API for a short period of time in order to perform text analysis and then returns the results to the Intrro web application.

Google warrants that the stored text is typically deleted within a few hours. Google asserts that they do not use the content they process to train and improve their Cloud Natural Language features or machine analysis model.

The Intrro web application utilizes Google Cloud Platform computation located in South Carolina, United States in the us-east1 region.

Google Cloud Platform has been granted formal certification, attestation, and audit reports for ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2, SOC 3, and more – the full list of compliance resources is available on the Google Cloud Platform Security page.

Intrro has vulnerability management policies and procedures in place to describe how we monitor for new vulnerabilities, enforce timelines and processes for remediation.

Scanning and detection

Intrro utilizes a number of services to perform internal vulnerability scanning and package monitoring on a continuous basis.

Netsparker

Intrro employs automated and integrated security scans of the web application through Netsparker. Automated scans occur at least daily and any detected vulnerabilities immediately notify the engineering team.

Security advisories

Intrro subscribes to GitHub's security alerts program. If GitHub detects a vulnerability from the GitHub Advisory Database or WhiteSource in one of the web application's dependencies, the engineering team is notified.

AWS Systems Manager

Intrro utilizes AWS Systems Manager for fleet management and endpoint security. AWS Systems Manager automatically scans and detects vulnerabilities on employee hardware and alerts the user on known vulnerabilities and provides guidance on remediation.

Image scanning

Intrro utilizes Amazon ECR image scanning to identify vulnerabilities in container images. Amazon ECR image scanning uses the Common Vulnerabilities and Exposures (CVEs) from the open-source Clair project to scan and alert on known container vulnerabilities.

Vanta

Intrro utilizes Vanta to scan and monitor for package vulnerabilities. Vanta enforces compliance with vulnerability SLAs based on severity.

Severity and timing

Intrro defines the severity of an issue via industry-recognized Common Vulnerability Scoring System (CVSS) scores, which all modern scanning and continuous monitoring systems utilize. The CVSS provides a way to capture the characteristics of a vulnerability and produce a numerical score reflecting its severity. The numerical score can then be translated into a qualitative representation (such as low, medium, high, and critical) to help organizations properly assess and prioritize their vulnerability management processes.

Low Severity - 0.1 - 3.9

Low severity vulnerabilities are likely to have very little impact on the business, perhaps because they require local system access.

Medium Severity - 4.0 - 6.9

Medium severity vulnerabilities usually require the same local network or user privileges to be exploited.

High Severity - 7.0 - 8.9

High severity vulnerabilities are typically difficult to exploit but could result in escalated privileges, significant data loss, and/or downtime.

Critical Severity - 9.0 - 10.0

Critical severity vulnerabilities likely lead to root level compromise of servers, applications, and other infrastructure components. If a critical vulnerability cannot be addressed within timelines as defined, an incident response ticket will be opened, documenting what interim remediation has been made.

Remediation process

When a vulnerability is detected and verified, the engineering team will remediate vulnerabilities within the SLA depending on the severity. Compliance of vulnerability SLAs is enforced via Vanta and tracked using JIRA {Atlassian product},

Intrro employs industry-standard techniques for detecting and preventing possible intrusions. Detected intrusions can result in escalation through incident response procedures.

IDS & IPS

Intrro utilizes Amazon GuardDuty as an Intrusion Detection System (IDS) and as an Intrusion Prevention System (IPS).

GuardDuty continuously monitors for malicious activity and unauthorized behavior to protect Amazon Web Services accounts, workloads, and data stored in Amazon S3. GuardDuty employs machine learning, anomaly detection, and integrated threat intelligence to identify and prioritize potential threats.

Firewall

Intrro is protected by Amazon's web application firewall (WAF) and assists in blocking common web exploits and attack patterns. Intrro manages a number of firewall rules, including rules that address issues like the OWASP Top 10 security risks.

Brute force prevention

The Intrro web application employs log in attempt rate limited with automated account lockout and secure password reset practices to prevent against brute force attacks. We also maintain a large email domain blacklist to prevent malicious actors and spam.

Logging and monitoring

Intrro has implemented multiple layers of logging with the application and infrastructure and uses industry-standard tooling to monitor application health and alert the engineering team when the application is not optimally operating.

Application logging

Intrro utilizes Sentry and Amazon CloudWatch Logs for application logging and monitoring to help diagnose and fix issues within the Intrro web application. Application error logs are stored in Sentry for 30 days and are used to help investigate issues raised from automatic alarms raised via Sentry and Cloudwatch. 

Infrastructure logging

Intrro utilizes Amazon CloudWatch to log, monitor and alert on resource allocation and operational performance of the infrastructure of the Intrro web application. Infrastructure logs are stored for 365 days.

Audit logging

Intrro utilizes Amazon CloudTrail to enable governance, compliance, and operational risk auditing of operations and actions taken on Amazon infrastructure and services. Audit logs are stored indefinitely. 

Intrro also utilizes Vanta to help monitor security related events and misconfigurations. Examples include, new user accounts in our IdP, employee account permission changes, publicly accessible infrastructure, IP based rate limits and logging not enabled on relevant resources.

Intrro utilizes a multi-tenant architecture where all customers share the same computing resources.

Logical separation of data between customers and correct access is enforced through PostgreSQL Row Level Security (RLS). Transaction-scoped configuration variables are leveraged in RLS policies to ensure the correct access permissions.

Incident response plan

Intrro has a documented incident response plan that establishes the procedures to be undertaken in response to information security incidents.

This incident response plan includes:

• Escalation procedures
• Incident severity identification and classification
• Roles, responsibilities, and communication strategies in the event of a compromise
• Containment and remediation strategies
• Communication protocols, both internally and externally
• A retrospective analysis to determine the root cause and implement improvements to incident response procedures

Monitoring and alerting

Intrro has continuous monitoring, logging, and alerting in place that will automatically escalate any issues. Depending on severity, these incidents may trigger an incident to dedicated on-call engineering 24 hours a day, 7 days a week, 365 days a year. Potential catalysts that may trigger an incident include:

• severe vulnerabilities
• vulnerabilities disclosed by a security researcher
• intrusion detections
• elevated errors, operational performance, and suspicious operations
• data breach discovery

This policy governs how security researchers should raise security concerns with us, and how we will respond.

Data security is a top priority for Intrro, and we believe that working with skilled security researchers can identify weaknesses in any technology.

If you believe you’ve found a security vulnerability in our service, please notify us; we will work with you to resolve the issue promptly.

Disclosing a weakness

• If you believe you’ve discovered a potential vulnerability, please let us know by emailing us at security@intrro.com. We will acknowledge your email within ten business days.
• Provide us with a reasonable amount of time to resolve the issue before disclosing it to the public or a third party. We aim to resolve critical issues within one week of disclosure.
• Make a good faith effort to avoid violating privacy, destroying data, or interrupting or degrading the Intrro service. Please only interact with accounts you own or for which you have explicit permission from the account holder.

Exclusions

While researching, we’d like you to refrain from:

• Distributed Denial of Service (DDoS).
• Spamming.
• Automated penetration tests or vulnerability scans.
• Social engineering or phishing of Intrro employees or contractors.
• Any attacks against Intrro’s physical property or data centers.

Intrro maintains documented Software Development Life Cycle (SDLC) policies and procedures to guide developers in implementing and documenting application and infrastructure changes.

Development environments

All code is deploy and tested in a staging (development) environment that is functionality equivalent to production environments. Intrro performs testing and quality assurance procedures in this staging environment before releasing to the production environment that is used by customers. No customer data is ever used or accessible from staging or local development environments.

Version control

Intrro employs Git version control to maintain source code versions and manage the migration of source code through the development process through to release. Using a decentralized version control allows multiple developers to work simultaneously on features, bug fixes, and new releases; it also allows each developer to work on their own local code branches in a local environment. Git maintains a history of code changes, supports rollback capabilities and tracks changes to individually identifiable developers.

All code is written, tested, and saved in a local repository before being synced to the origin repository. Writing code locally decouples the developer from the production version of the Intrro code base and insulates Intrro from accidental code changes that could affect users. Any changes involving the persistence layer (database) are performed locally when developing new code, where errors or bugs can be spotted before the change is deployed to users.

Code review

Code changes are managed and reviewed through Git pull requests. Every pull request is manually reviewed and approved by two developers before it can be merged. Automatic and integrated testing is also performed with each pull request, and all tests must pass before a code change can be merged.

Developers are trained in evaluating code for security defects as part of code review, and automatic testing is employed to test against common security defects.

Security bugs

Security bugs represent key issues and should be resolved quickly to maintain the security, confidentiality, privacy, processing integrity, and availability of the Intrro service. Intrro has SLAs in place to enforce compliance with resolving security bugs within reasonable timelines.