What is the Cortex Security Policy?

This document governs the security practices at Cortex. This is a public document, open to
review by Cortex customers. New employees will review this policy with their hiring managers, and all employees will review this policy on at least an annual basis.

Updates to the Cortex Security Policy

Cortex will follow generally accepted security best practices. Cortex will also implement new
compliance measures and certifications. This means the policy will update over time. Updates to this document will be timely and transparent available on getcortexapp.com.

What is Production and Customer Data?

Customer Data is data input into the Cortex API, and only includes Cortex user data such as
names and emails. Production Data includes analytics and dashboard configuration data on top of Customer Data and Additional Data. Application logs are also production data. Cortex does not access, store, or require any data from the Customer’s own users.

Tracking Customer Data

Each customer will have access to Cortex services such that their data is identified and
separate from other customers. Cortex will restrict access such that only a customer who input customer data has access to retrieve that data.

Additional Data

Cortex may enrich Customer Data with data from other publicly available websites or third party services. This data is acquired by Cortex for the purpose of providing its service and may be subject to the policies of the corresponding service provider.

Data Storage

Securing data in transit

When Production Data is in transit, communication should be secured using industry standard methods such as SSH Client/Server, SSL, VPN and SSL/VPN. This includes all communication between clients and servers, such as API clients & SDK to production application servers. This also includes database clients in application servers connecting to databases. Web console access to any production system management tools must be over HTTPS.

Securing data at rest

Production data will be stored on encrypted disks when at rest. This includes both development machines and hosted database services. Database backups should be encrypted. Software security patches must be implemented upon discovery including database updates, operating system updates, and other application updates.

Securing data in use

Cortex systems require active processing of data. This includes things like in memory data
stores, in memory processing, and actively changing database tables. Data in use will not be
encrypted. All access to systems processing data in use will be limited and any transfer of this data is covered by the data in transit policy above.

Third Party Management

When feasible, Cortex will leverage managed solutions for hosting and data storage. This
ensures high reliability, performance, and adherence to the goals of our security policy. Current providers include Google Cloud Platform. Hosted systems provide immediate software library and operating system security patches and updates.

Development

Local devices including desktops, laptops, cell phones and tablets will be used to access Cortex email and other services for Cortex for development and testing. Development and testing will occur on Cortex hardware, with exceptions requiring direct approval. Two factor authentication should be used when available. All devices should have a password or lock code, and should use two factor authentication when available on third party services. Cortex approved hardware should have encrypted hard drives. In the event that a Cortex device is lost or stolen, it should be remotely wiped if possible.

Employee and New Hire Responsibility

New Hires

New employee hires will be trained in the Cortex Security Policy. Training involves reviewing the policy with the employee's hiring manager. New hires must sign a confidentiality and invention assignment agreement. Consultants and contractors will be treated like full time employees. Employee candidates who will be responsible for production systems will have an assessment of security knowledge and experience as part of their interview process.

Provisioning Access to Production Systems

New hires who require access to production data will have access provisioned as part of onboarding by the CTO, Ganesh Datta. Only this provisioning process will allow people access to production systems. In the interests of business continuity, other administrators may be designated to complete this process. We follow the principle of least privileges on production systems, only granting access to the specific roles that an employee requires to operate production systems.

Shared Secrets

Cortex will deploy a shared secret management system to secure access to system tokens and passwords. The current management system is 1Password. Where possible, systems that support two factor authentication will be used.

Termination and Revoking Access

Upon termination, any employee with access to production systems and data will have that access revoked. Access to Cortex email and other communications channels will also be revoked. Machines (desktops, laptops, smart phones, etc) which have connected to Cortex email or services must be cleared of Cortex data and code.

Failure to Comply

Employees who knowingly violate this policy will face disciplinary action including termination of his or her employment.

Incident Reporting

Failure to Comply

If a security breach occurs, report the incident immediately to Ganesh Datta. Determine the severity of the breach. Notify affected customers of the breach within a timely manner, in at most 48 hours. Notification should include description of the incident, whose data was affected, and the status of remedies.

Production Systems Management During Incidents

Immediately shut down access and revoke tokens and passwords that have been compromised. If necessary, shut down the live application until the breach has been contained and a security patch has been implemented. Verify customer identity before restoring access to customers.

Evidence Handling

When we have confirmed or reasonably believe that an Incident was caused by a malicious attack, evidence must be properly collected and maintained. No log files should be deleted and no data backups should be deleted. The current state of the application code must be identified with the ability to rollback to the state of the application code at the time of the incident.

Regulatory Compliance

Cortex will implement regulatory and legal security requirements. Such requirements change over time and across different geographies. Cortex will routinely review and update the security policy based upon these changes.

Acceptable Use

Acceptable Use of Customer Data

Cortex is built upon the trust our customers have in our systems. The only acceptable use of processing customer data is to improve quality, reliability, and performance of the Cortex service. Cortex is not a data broker: Cortex may not sell or license customer data. Only third parties required to provide Cortex services will access customer data; notable examples include third party servers and database hosts such as GCP.

Securing User Passwords

Cortex uses SSO to provide login for all users and does not store user passwords. Users are responsible for managing passwords for their own login provider.

API Secret Keys

Customers are required to use a secret key to access their data via APIs. The secret key is shared with the customers only on the user settings. The customer is responsible for sharing access to secret keys during their product development and should never embed the secret keys in insecure clients. Cortex documentation should include clear instructions about management of secret keys. Nikhil Unni (Chief Architect) and Ganesh Datta (CTO) are the only engineers that have access to these keys.

Testing Environment

Cortex production access tokens must be stored as environment variables in the secured servers. Access to third party services for testing should use specific passwords and access tokens that do not have access to production services or data. Test tokens may be embedded in code, such as production testing infrastructure without access to production systems.

Physical Security

Remote Access

All production systems are hosted off site, and so all production system access is remote access. Data centers are managed by hosting service providers such as GCP, and other providers. They are housed in nondescript facilities, and critical facilities have extensive setback and military grade perimeter control berms as well as other natural boundary protection. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, state of the art intrusion detection systems, and other electronic means. Authorized staff must pass two factor authentication no fewer than three times to access data center floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff.

Office Access

Physical access to the Cortex office will be restricted to authorized personnel. Office access is locked during non business hours including nights and weekends.

Change Management

Process Changes

Changes to the process must be reviewed and approved by Ganesh Datta, or an employee designated by Ganesh Datta. This document will be reviewed annually, and may be updated. Customers should be notified of updates to this document.

Infrastructure Changes

New services and tools that are used must comply with the terms of this document. Any new services or applications that violate this document must be reported and reviewed by Ganesh Datta.