Security - Trust Center

• We use Guidelines documented in corporate Confluence pages.
• We use brakeman, Bundler and RuboCop run manually and by Circle CI.
• We engage security experts to do white box testing such as fault injection (manual), penetration testing (manual) and vulnerabilities testing (both automatic, and manual)

Ethicontrol also has a responsible disclosure program.

Ethicontrol has a formal change management process where all changes are tracked and are approved. A change is reviewed before being moved into a staging environment where it is further tested before finally being deployed to production
Defined in-house security requirements and policies, and well-known security best practices applied in every stage of the lifecycle.
Security review of architectures, design of features, and solutions.
Iterative manual and automated (using static code analyzers) source code review for security weaknesses, vulnerabilities, and code quality, and providing of sufficient advice and guidance to the development team.
Regular manual assessment and dynamic scanning of pre-production environment.
Security trainings conducted for IT teams according to their respective job roles.
Continuously running bug bounty program
Continuously running internal and external security tests

The publicly accessible part of Ethicontrol system - Ethicontrol intake and web-feedback application is separated from Ethicontrol incident & case management application which is for client internal use only.

The data assembled during investigations is isolated in such a way that there is no possibility of receiving access to investigation data once the intake system is compromised.

In case of ddos or other attacks against Ethicontrol intake application, the case management application will remain fully operational and protected by more conservative tools and methods which cannot be used for public portals & applications.

All cloud assets must have a defined owner, security classification, and purpose.
To better protect the data in our care, Ethicontrol classifies data into different levels and species the labeling and handling requirements for each of those classes.
Customer data is classified at the highest level.
Data classifications are maintained as part of the asset management process. Ethicontrol inventories hardware, software and data assets at least annually to maintain correct data classification.

User data (data of each company/customer) is separated at the database and cloud storage levels. The data of different companies is isolated in such a way that there is no possibility of receiving access to access of another user by accident.

Ethicontrol's production environment, where all customer data and customer-facing applications sit, is a logically isolated Virtual Private Cloud (VPC). Production and non-production networks are segregated. All network access between production hosts is restricted using firewalls to only allow authorized services to interact in the production network.

Network access to Ethicontrol's production environment from open, public networks (the internet) is restricted. Only a small number of production servers are accessible from the internet

Every action within the system is logged.
Ethicontrol offers the possibility to get a report with up-to-date account activity information, including authentication events, changes in the authorization and access controls, sharing folders and tasks, and other security activities.

Each user in Ethicontrol has a unique account with a verified email address, and protected with a password, which are validated against password policies and stored securely using a strong hashing algorithm with unique salt for every password.
Administrative access to systems within the production network is limited to CTO only.


Customer data, including tasks and folders, can only be accessed by other users within your Ethicontrol account if those items were specifically shared with them. Otherwise, your cases and tasks are not accessible by other Ethicontrol users.

At the level of the operating system, the Ethicontrol's web server is behind a firewall where all ports are closed with the exception of those which are used for system purposes. Technical access to the server is carried out exclusively through Ethicontrol subnets.

A specialized server environment which does not allow write access to the local file
system is used along with a customized PHP module which ensures isolation among
users and security of user data.

Authentication data sent by a client machine can be encrypted using JavaScript and
and RSA key. Additionally, OTP (one-time password) technology can be engaged in
conjunction with an eToken.

Ethicontrol's proactive protection blocks 100% of web attacks attempting to use application vulnerabilities. Malicious users do not have any opportunity to load malicious code via PHP.
The web application conforms to WAFEC 1.0 standards.
Access to Ethicontrol is provided to users (companies) in complete isolation from other users with passwords encrypted via double md5.
Limitation to specific subnets and logging of potentially threatening activity is also possible.

Proactive Web Application Firewall, which categorically blocks the vast majority of
attacks on web applications.

The Etihcontrol OTP app provides one-time password codes for two-step
authorization in Ethicontrol and other Ethicontrol products. Even if your password is
stolen, your account will not be accessible to a would-be hacker.

Ethicontrol hosts their servers in locked cages within data centers located in the U.S and
EU: Trusted Data Center in the U.S is compliant with SSAE 16 Type II and ISO 27001
standard, and is located in San Jose, California.
Ethicontrol's European Data Center is hosted in Frankfurt, Germany and is also
compliant with ISO 27001 and ISAE 3402 standards (equivalent to SSAE 16). This
data center is isolated and retains customer and sensitive data within EU only.

All data centers used by Ethicontrol are protected in compliance with SAS 70 Type II
(which includes access to the physical storage media based on biometric data and
maximum protection against intrusion) and conform to the Safe Harbor standard.

Etihcontrol is running real-time database replication, to ensure that customer data is
both backed up and available on redundant and geographically dispersed servers,
physically separated from the primary Ethicontrol application servers, aiming to
ensure fault tolerance.
All backups are encrypted in transit and at rest using strong encryption. Backup files
are stored redundantly across multiple availability zones and are encrypted.

We track the uptime by several services. E.g. UptimeRobot. Access to uptime.ethicontrol.com page can be provided by request.

Do you maintain a quality management system (QMS) approved by management? In lieu of a formal and static QMS, Ethicontrol has a dynamic and responsive approach to quality management. Does your quality management system (QMS) include coverage for software application security principles?
YES

Is quality management system (QMS) content published and communicated to all relevant employees?
YES.

Is quality management system (QMS) content reviewed and updated (if appropriate) at least once per year?
It is considered a constant Work In Progress; and updated almost daily in small increments.

Is there defined management oversight who is responsible for application quality and security reporting & signoff?
YES.

Is access to and maintenance of applications, systems, network components (including routers, databases, firewalls, voice communications servers, voice recording servers, etc), operating systems, virtualization components, hypervisors, or other information objects restricted to authorized personnel only?
YES

Is access to and maintenance of applications, systems, network components (including routers, firewalls, voice communications servers, voice recording servers, voice response units (VRU) etc), operating systems, virtualization components, hypervisors, or other information objects granted based upon need-to-know job function?
YES

For all IT systems including but not limited to servers, routers, switches, firewalls, databases, and external social spaces, is management approval required prior to creating all user and privileged accounts (e.g., system or security administrator)?
YES

For all IT systems including but not limited to servers, routers, switches, firewalls, databases are privileged accounts (e.g., system or security administrator) logged at all times and reviewed on at least a quarterly basis?
YES

Are all user accounts (including, but not limited to, standard user, system administrator, security administrator, internal social spaces, etc) assigned to an individual employee and not shared?
YES

Are all user accounts disabled after no more than ten unsuccessful logon attempts?
YES

For all IT systems (including but not limited to servers, routers, database, switches, firewalls, external social spaces), are inactive user and privileged accounts (e.g., system administrator or security administrator) disabled after 90 days or more?
YES

Is a user's identity verified before communicating an initial/temporary password or initiating a password reset by an automated or manual process?
YES

Do application, system, and device passwords (including routers, firewalls, databases, and external social spaces) require passwords to have the following characteristics: 1. minimum length of 8 characters, 2. chosen from any acceptable character sets available on the target system, 3. includes at least one alphabetic and one numeric character.)
YES

Are passwords prevented from being displayed in clear text during user authentication or in electronic/printed reports?
YES

Are passwords/PINs sent to users utilizing a secure method (e.g. secure e-mail) and sent separately from other authentication information such as the user account?
YES

For all IT systems (including but not limited to servers, routers, databases, switches, firewalls), are user and privileged account (e.g., system or security administrator) passwords changed at least every 90 days?
YES

Are users required to authenticate prior to changing their password?
YES

Are all system, application and device password files encrypted using an industry standard encryption algorithm where technically feasible?
YES

In instances where a software token is used to access an application or system, is a password or PIN required?
YES

In instances where a software token is used to access an application or system, are stored keys and software token files encrypted using an industry standard algorithm and smartcards compliant to FIPS level 2 or above?
YES

For externally hosted environment, is there separation of administrative access between the hosting infrastructure/platform and the hosted platform and data?
YES

If user accounts are assigned to non-permanent personnel (e.g., contractors, consultants) for troubleshooting purposes, are the accounts disabled or removed after each use?
YES

Is the retirement or replacement of encryption keys included in key management procedures when the integrity of the key has been weakened (such as departure of an employee with key knowledge) or keys are suspected of being compromised?
YES

If you use cloud services, do you ensure that confidential data or an aggregation of proprietary information that can reveal confidential information is encrypted to ensure confidentiality at rest and in transit?
YES

If you use cloud services, do you have key management procedures to manage and maintain encryption keys?
YES

Are there documented processes, procedures, standards and templates used in your SDLC process?
YES.

Do the materials above include references to application security best-practices and principles being followed?
YES.

Are design and code reviews performed as part of your SDLC processes?
YES.

Are security considerations (checklists, standards and policies) referenced in the design and code review?
YES.

Is app security threat modeling performed when deemed appropriate (i.e. new or changed architectures and approaches)?
NO.

Is application code managed in a secure configuration management system with access controls?
YES.

Is there a configuration management plan and are release artifacts maintained in a configuration management system?
YES.

Are test plans and records kept that reflects the tests performed and results observed for each release?
YES.

Is security testing defined and included in the test plan for each release?
YES.

Is a release criteria defined, measured and reported on to confirm targeted release quality is achieved?
YES. We do manual QA testing for each monthly release and deploy all new versions on Ethicontrol.com to be our own test subjects.

Are specific application security characteristics and measures part of the defined release criteria?
NO.

Is Internal company training available & performed commensurate with personnel roles and responsibilities?
YES; peer-to-peer training is commonplace.

Does training include security awareness?
YES; as applicable for the role.

Does training include education on policies, standards, procedures and updates when needed?
YES; as applicable.

Are personnel training plans and records kept for internal company compliance purposes?
Tasks and training completed during onboarding are recorded.

Is antivirus protection enabled on endpoints?

• NO. Antivirus solution will be dependent on management decision on device management strategy. We use Apple Macbook Pro's and Linux laptops. Mac's provide application sandboxing which will require the malware to escape; requires by default all applications installed are signed. Linux laptops are operating with user trust. Ethicontrol hosts are monitored utilizing Uptycs.
• Yes. For PC's we use Windows Defender. PC are used by marketing team only which is isolated/restricted by default from development and production processes or client's systems or data.

Are results from the execution of test plans reported and used to track and justify release readiness?
YES. We require all automated tests to pass before any official release (monthly and patch versions), and perform manual QA testing for each monthly release.

Does the quality assurance organization have authority to delay shipment of releases due to non-conformance reasons?
YES.
Is some form of static code scanning performed as part of the release acceptance? What tools are used?
YES. For example, brakeman and bundler-audit are part of our test suite to be alerted to any security issues in our dependent Ruby libraries.

Is some form of dynamic code scanning performed as part of the release acceptance? What tools are used?
YES. We use Circle CI for this purpose.

Do you have a documented company security incident response process?
YES. See security documentation as well as details on service level response times and priorities.

Do your maintenance releases include fixes for both quality and security related issues?
YES.

Do you provide dedicated security patches for software versions that are released and supported in the field? How?
YES, for the latest release and the two prior monthly releases, when applicable.

Is there proactive notification provided to customers and software partners (PTC)? How?
YES. Notifications in the "version check" image, blog posts, tweets, and a mailing list just for security fixes.

Do you have a formal risk severity classification assessment approach?
NO.

Is there a specified response policy that includes the timeframe issues are to be addressed?
YES. See security documentation as well as details on service level response times and priorities.