This privacy statement applies to Ethicontrol client related services provided via websites as subdomains of ethicontrol.com, services and products that collect data and display these terms. It does not apply to any Ethicontrol site, service or product that does not display or link to this statement or that contains its own privacy statement.



Ethicontrol, LLC. ("Ethicontrol") is committed to protecting your privacy in a variety of ways including using industry accepted security measures to protect against loss, misuse and alteration of data contained in our systems. This Privacy Policy is designed to describe how we secure and maintain our customers' and visitors' personal information when collected on sites which link to this Privacy Policy. This includes subdomains on ethicontrol.com or ethicontrol.ru or ethicontrol.com.ua. Any information given to us will never be sold, rented, traded, shared or leased other than as outlined in this Policy.



Ethicontrol does not publish text, images, or multimedia content that portray nudity, foul language, violence or other information not suitable for children. Web sites maintained by Ethicontrol are not directed to children under the age of 13. Ethicontrol will not knowingly collect or maintain personally identifiable information from or about anyone under 13. Ethicontrol is committed to complying with privacy laws to which it is subject and adhering to the highest industry standards for privacy.



Ethicontrol is not responsible for content saved to any Ethicontrol's system by Hotline/Ethicsline/Trustline/Trustbot/Trustchat reporters or client company representatives.

Ethicontrol gathers information about how you use our services in a limited ways:

• Web forms, such as when you type information into a registration form.
• Web logging, which enables us to collect the standard information your browser sends to every web site you visit such as your IP address.

Other information is not collected.

Licensed Users of Products and Services:

Personally identifiable information such as name, contact information, username and password is stored in our database for access to and use of certain software applications. This information is kept secure on our private servers and is only used to assist you in accessing your account. No information is released outside of the Ethicontrol system unless specifically authorized.

Hotline/EthicsLine Reporters:

No personally identifiable information is automatically collected from reporters submitting a case. Personally identifying information, such as name and e-mail address, is collected and stored only when a reporter voluntarily gives this information.

No use of Cookies, Clear Gifs and Log File Technology:

We DO NOT use technologies such as cookies, beacons, tags, and scripts the services used by reporters.

Upon request, Ethicontrol will provide you with information about whether we hold, or process on behalf of a third party, any of your personal information. To make a request please contact us at privacy@ethicontrol.com with "Personal Information Request" in the subject line, and provide us with full details in relation to your request, including your contact information, your company's name and any other detail you feel is relevant.

Upon request by mail or e-mail (to the addresses noted below in the Contact Information section), Ethicontrol will grant individuals reasonable access to personal information that it holds about them, unless otherwise legally unable to do so. In addition, Ethicontrol will take reasonable steps to permit individuals to correct, amend, or delete information that is demonstrated to be inaccurate or incomplete. Ethicontrol shall provide a response to an access request within 30 days of receiving such request.

We will retain your information for as long as your account is active or as needed to provide services to your organization. We will retain and use your information as necessary to comply with our legal obligations, resolve disputes, and enforce our agreements.

Our web-intake portals are cookie-free and script-free.
We provided such an opportunity to guarantee additional anonymity protection.
Log Files
As true of most web sites, we gather certain information automatically and store it in log files. This information may include internet protocol (IP) addresses, date/time stamp.
We do not link this automatically-collected log information with other information we collect about you.
Local Storage Objects (Flash/HTML 5)
We use Local Storage Objects (LSOs) such as HTML 5 to store content and preferences. Third parties with whom we partner to provide certain features on our site to display advertising based upon your web browsing activity use LSOs such as HTML 5 to collect and store information. Various browsers may offer their own management tools for removing HTML 5 LSOs.

Ethicontrol will take reasonable precautions to protect personal information in its possession from loss, misuse and unauthorized access, disclosure, alteration and destruction.
For licensed users and reporters, communications between the Ethicontrol site and a user's web browser are accomplished using, at a minimum, 128 bit SSL encryption and various third party security certificates to protect confidential data. Ethicontrol does not allow users to transfer or receive confidential information unless they are using a validated 128 bit (or greater) encrypted session.
We follow generally accepted industry standards to protect the personal information submitted to us, both during transmission and once we receive it. However, no method of transmission over the Internet, or method of electronic storage, is 100% secure. Therefore, while we strive to use commercially acceptable means to protect your personal information, we cannot guarantee its absolute security.
If you have any questions about security on our Web site, you can e-mail us at itsecurity@ethicontrol.com with "Questions about Security" in the subject line. We do not link this automatically-collected data to personally identifiable information.
Automatic Information Storage
Session Variables may be used temporarily in your system cache to create ease-of-use during your transaction. Examples of such information are automatically-produced alphanumeric numbers held during your session on our site to facilitate page-to-page transactions. We only store name, e-mail, phone, address, company name or any other identifying information for licensed users; no information is stored for others unless otherwise stated in this policy.

Ethicontrol contracts with select third parties for Web-based services that include e-mail delivery and content streaming, that may collect non-personally identifiable visitor data including IP address and pages visited. These third parties may only use personally identifiable information, for example, e-mail addresses, for the service requested and not for their own marketing purposes.
Ethicontrol also contracts with select third parties in connection with the delivery of services to our clients. These third parties may not use any personally identifiable information other than to provide the specific contracted services.

No company other than Ethicontrol is allowed to access information stored on our servers unless expressly authorized by Ethicontrol. Unauthorized access to this information is a violation of the law. Ethicontrol has placed security measures and firewalls on all network servers in an attempt to prevent outside parties from accessing private information. In the event of a breach of security, Ethicontrol will press charges to the fullest extent possible against those parties illegally accessing the information on our servers.

Upon request, Ethicontrol will provide you with information about whether we hold, or process on behalf of a third party, any of your personal information. To make a request please contact us at privacy@ethicontrol.com with “Personal Information Request" in the subject line, and provide us with full details in relation to your request, including your contact information, your company's name and any other detail you feel is relevant.
Upon request by mail or e-mail (to the addresses noted below in the Contact Information section), Ethicontrol will grant individuals reasonable access to personal information that it holds about them, unless otherwise legally unable to do so. In addition, Ethicontrol will take reasonable steps to permit individuals to correct, amend, or delete information that is demonstrated to be inaccurate or incomplete. Ethicontrol shall provide a response to an access request within 30 days of receiving such request.
We will retain your information for as long as your account is active or as needed to provide services to your organization. We will retain and use your information as necessary to comply with our legal obligations, resolve disputes, and enforce our agreements.

If you have received unwanted, unsolicited e-mail sent by Ethicontrol or from any Ethicontrol system or purporting to be sent via Ethicontrol, please forward a copy of that e-mail with your comments to info@ethicontrol.com for review.
If you have questions or complaints regarding our privacy policy or practices, please contact us at privacy@ethicontrol.com with “Privacy Enquiry" in the subject line and provide detail on your question or complaint so that we may adequately respond.

Ethicontrol is implementing Zero Trust as inspired by Gitlab's security policies and Google BeyondCorp.
We are shifting access control from the perimeter of the org to the individuals, the assets and the endpoints. You can learn more about this strategy from the Google BeyondCorp whitepaper: A New Approach to Enterprise Security.

High-level components of BeyondCorp
Single sign-on, access proxy, access control engine, user inventory, device inventory, security policy, and trust repository.

BeyondCorp principles

• Connecting from a particular network must not determine which services you can access
• Access to services is granted based on what we know about you and your device
• All access to services must be authenticated, authorized, and encrypted

In our case, Zero Trust means that all devices trying to access an endpoint or asset within our Ethicontrol environment will need to authenticate and be authorized. Because Zero Trust relies on dynamic, risk-based decisions, this also means that users must be authorized and validated: what department are they in, what role do they have, how sensitive is the data and the host that they are trying to access?

Identity is a critical element of the implementation of a ZTN framework.
Ethicontrol is moving forward with an implementation of instruments to allow users to standardise authentication for Cloud Application access and implement user-friendly SSO.

In many enterprise environments, virtual private networks (VPN) are used to allow access to less secured resources, typically also protected by an enterprise firewall.

At Ethicontrol, as an all remote company, we do most of our work using other Software-as-a-Service (SaaS) providers that we rely on to maintain confidentiality of communication and data. Additionally adding VPN connectivity only marginally improves the security of using those systems.

For the use case of laptop usage in untrusted environments, such as coffee shops and coworking spaces, a baseline of always-on host protections, such as up-to-date security patching, host firewalls, and antivirus, should be prioritized.
Team members should follow the system configuration guidelines at a minimum to secure their workstations.
In relation to Zero Trust, a corporate VPN is a perimeter, which ZTN architecture deemphasizes as a basis for making authorization decisions. Current access to critical systems is managed through alternative controls.
While a corporate VPN is not implemented at this time, there are other valid use cases for which individual team members may still wish to use a personal VPN, such as privacy or preventing traffic aggregation. Team members that wish to use a personal VPN service for any reason may still expense one.

We have tried to take a comprehensive approach to our immediate and future security compliance needs. Older and larger companies tend to treat each security compliance requirement individually which results in independent security compliance teams going out to internal teams with multiple overlapping requests. For example, at such a company you might have one database engineer that is asked to provide evidence of how a particular database is encrypted based on SOC2 requirements, then again for ISO requirements, then again for PCI requirements.

Given our efficiency value here at Ethicontrol we wanted to create a set of security controls that would address multiple underlying requirements with a single security control which would allow us to make fewer requests of our internal teams and efficiently collect all evidence we would need for a variety of audits at once.

Adobe's open source compliance framework and Gitlab's GCF served as the starting point for this efficient method of collecting security control evidence. It has been adapted and expanded as needed and the result is the below list of controls grouped by families and sub-families.

Clicking a control below that has a link will take you to a page with a variety of information about that control.

Control Owner - Ensures that the design of the control and the control activities operate effectively and is responsible for remediation of any control activities that are required to bring that control into a state of audit-readiness.

Process Owner - Supports the operation of the control and carries out the process designed by the control owner. The process owner is most likely to be interviewed by an auditor to determine whether or not the process is operating as intended.

The purpose of a gap analysis is to identify gaps between CF controls and documented Ethicontrol process. Gap analysis project work is done in a private project due to the sensitive nature of the assessment findings. The project will have an issue for every CF control in scope for the gap analysis. Ethicontrol's first gap analysis can serve as an example for how future gap analyses can be organized and executed.

The remediation phase fills the gaps identified during the gap analysis and get each in-scope control into a state of audit readiness.

Definition of Done

A control is considered to be remediated if:

1. The process addressing the requirements of the control (as defined by the security compliance team) is documented in the Ethicontrol handbook
2. The process documented above is the same process being used by all Ethicontrol team-member involved in operation of the security control
3. The collection of testing evidence that will prove the above 2 points can begin
   • Testing encompasses both "test of design" (sample of 1) and then if that passes, a test of "operating effectiveness" (random sampling)

Controls which have been remediated should be tested to see whether the process documented in the Ethicontrol handbook, runbooks, and other sources are followed.

The Security Compliance team will occassionally perform group peer reviews on one or more controls per review. The purpose of these reviews is to leverage the experience and perspective of the entire team to dig deep into past, current, and future work on or operation of a given control. The date of a control's most recent review is documented in the CF Remediation Status sheet.

The Security Compliance team is responsible for completing the activities which continually assess the design and operating effectiveness of the controls established by the CF.

The Ethicontrol compliance team is responsible for ensuring the consistency of the documentation of the security controls listed below. While normally we welcome any Ethicontrol team-member to make edits to handbook pages, please be aware that even small changes to the wording of any of these controls impacts how they satisfy the requirements for the security frameworks they map to. Because of this, we ask any changes that need to be made to this page and the underlying guidance pages to start with a comment in this issue. The compliance team will then engage with you and make any appropriate changes to these handbook pages.

• 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.

A SOC 2 (Service and Organization Controls) examination with a third party assessor is on Ethicontrol's 2020 security compliance roadmap.

Whereas we currently do not maintain an independently certified security controls certification, we do operate within an information security control framework.

We are also self certified under CSA Star Certification and Cyber Essentials scheme.

Ethicontrol's on-premises product as well as Ethicontrol.com SaaS is subjected to security tests regularly through a combination of:

Bug reporting program through direct email, or HackerOne. For more details on this, please see the page on responsible disclosure.
A combination of third party white box, grey box, and pen testing.

(Undisclosed name) carries out a black box assessment of Ethicontrol and Ethicontrol.com annually and the last assessment was performed in Q3 of 2019. Their report is available for (prospective) enterprise customers by emailing security(at)ethicontrol.com.

Given that penetration testing and other simulated events are frequently indistinguishable from real life attack activities and have the potential to impact performance and site reliability, we do not permit customers, prospective customers, to conduct penetration tests and vulnerability scans to or originating from the Ethicontrol.com environment.

This policy defines what qualifies as a breach of user data, what actions will be taken in the event of user data exposure or compromise, and the timeline for action.
This policy applies to user data stored on Ethicontrol.com. It does not apply to self-hosted / on-premises EthiBox instances or instances hosted with other providers than Ethicontrol.com

This policy covers "private user data" stored by Ethicontrol.com, and includes:

• Client's database
• Client's files
• Encrypted Passwords
• Private Email Addresses

Note: Ethicontrol.com does not store any "personally identifiable information" (PII) such as (i) Private Addresses, (ii) Credit Card Numbers, (iii) Bank Account Information, (iv) ID numbers (e.g. passport, driver's license, social security, national identification, etc.). Ethicontrol.com also does not store any "personal health information" (PHI). Therefore, laws and regulations relating to PII and PHI do not apply.

A breach of user data is the unintended or accidental exposure of private user data. This can be caused by accidents, misconfigurations, or malicious actions performed by an external attacker or team member.

An event is considered a data breach when there is evidence that private user data has been exposed to the public or to an untrusted third party.

Trusted third parties may have authorized access to user data under a signed Non-Disclosure Agreement (NDA). Such trusted third parties include but are not limited to:

• Cloud service providers
• Database consultants
• Security auditors
• Financial auditors

Some examples of a user data breach would include:

• Compromise of a database server that contains private user data with evidence that an attacker may have had access to or copied the data off-site.
• Compromise of an application server account that has access to private user data and evidence that the attacker has downloaded or accessed private data.
• Theft of a device known to contain private user data.
• Web application attack used to download a list of all user emails and encrypted passwords.

Examples of security incidents that would not be considered a breach of private user data:

• Compromise of an application server that does not contain or have access to private user data.
• Compromise of a team member application account that does not have access to private user data.
• Malware infection on a server or team member computer system that does not contain private user data.
• Compromise of non-sensitive user data such as login IP addresses, login history, project permissions.
• Unintentional disclosure of project names, group names, issue titles, or project or user metadata unless this data can cause damage to the user or their business.
• Discovery of a vulnerability that could have been used to compromise private data, but for which there is no evidence of exploitation.
• Theft of a team member's mobile device that does not contain private user data.
• Theft of a team member's private keys, tokens, or other credentials provided there is no evidence they were used to access private user data.

You can check out these common non-vulnerabilities that will not be considered as a breach.

If Ethicontrol has detected evidence of a breach of Ethicontrol.com or Ethicontrol Hosted private user data, all affected users will be notified via the configured email address for their accounts. Emails will contain information on what data was exposed or compromised, when, and for how long (to the extent this information is available).

For a breach that exposes private data for a large number of users, the public will also be informed via the configured email addresses for their accounts, and additional means of communication will be considered (e.g. press release, the blog, etc.) on a case by case basis.

Ethicontrol will endeavor to notify users within 24 hours of breach discovery. This may be delayed when necessary to comply with requests by law enforcement.

We know how much work goes in to pen testing!
To avoid frustration, you can check out these common non-vulnerabilities that don't qualify for rewards.
Got a valid issue? Awesome! Please include:

• A summary of the problem
• A severity rating of 1 — 5 (1 being least severe, 5 being most ie. you can easily hijack, impersonate or access any other account or data)
• A PoC or breakdown of how to replicate the issue
• The operating system name and version as well as the web browsers name and version that you used to replicate the issue

Send to security (at) ethicontrol.com

If you plan to provide access tokens, secure cookies or sensitive data as an example, we kindly ask you GPG encrypt your email. Here is our public GPG key.

Download
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBFvaxloBEAC88nEMGv8ZlZ0EfFiSuJBlNaVzKf2XVGfz7FFY9Z1q2mHABzuL
weNy9P52VlFl7b5cmmMvCmyOQ0TJJMVGSJInG2UW4XV10ZFYppqipS3q4Dn8rXHH
CSgTISSff+GV6Ksfcw0+JEKG65vRW4AcC5gAkIgfEYM0ASAYx8JyhQQgAtlZ62q+
PjkTt48T17q+ZQ3tUF+EtvE8RStWz7DL6ONpvgP88QvLM2ejE7mCDENgshjkcJOT
kgih7oZWMiBuAexrgeYAtJwOO1NP5Ltv4sBs2kdogwUtQac5839SbgnMej1niWEL
+8aZ+WIBl44Q38okjPM9EHpVB0fub9ujtn/hp5WE4EsGeM/ivjKTl3CoNfWJhGED
ZM/0Yq1hTyZOE4oIMdlaHoCQKAYC/2VCcpwerljNnWMv27cVEIca1aNeVzU6kQCF
/1LHd3qp0H6w8GqqobIta/zaZzZ/fDtPbZgoDEvOLAxy0q2ADV1U+M9e7djWhjZ4
uHx3PyvT58ROBMXnhPV6hyB5LKEtVUWAx2O8YJTClg5QXZxKS70dncHPkMgFcVp7
duWY7NWrV8mVYjfQw22tPl+OXGFD9zzzZoHd8do9qCYvrTjBzo8tQrw4IWK/oqwT
Wcv4UTLRUqOLSF5GmnUgy0o+lbIsPg7xLHBnWnFpmufZ2X8xTAupm3C4HQARAQAB
tCtPbGVnIExhZ29kaXllbmtvIDxzZWN1cml0eUBldGhpY29udHJvbC5jb20+iQJU
BBMBCAA+FiEE2g4mqS9MF/18A+3NCGf4JnXRz+sFAlvaxloCGwMFCQeGH4AFCwkI
BwIGFQoJCAsCBBYCAwECHgECF4AACgkQCGf4JnXRz+tWxRAAqh09eA4EgmjVTFuv
Bmjk1H4DFWoBFq5gTRXgpibSfD3Qh1dkiLqrN9P28JCiG+OmaizfJS6X5BcBPO/S
AkTSjphe5zgnIpBsASc73SOGtsjocLiul/Odq6NqP3u0zbRt7155GqhVhODbGT0B
A2ydWlzRd9TwGuHNL1aCUF5r3QemsiV0kMVW9e/2PAqn6CKF64FJb3zG4gj6WTKA
xPhLNHFzwE+J2c3iAjtLKm4uGznnjxFIOhfaaWJMIORS9rMMj+c+uyp7r/xBxO+T
pTUEvRz6eFO9VIT9OmnozorXXeZXHNz2CEhfG/NcqLxwO9COkd570RPvUo/i6m4l
wwH49aZq0rqz5i7wHAY4JrkIAz8ZeTc+OwEqTLdUXbDqN+xP4kIixliASQ3Eqx65
9EZcvc0zenVE7s6K8XKMGf4bkAu0cXDd29fe4wLgi6CrMgm+WG8MddgNDE6dQl0Y
liM+Cnile9iCM6zMqg9bVRCGU9sxuMYrq1L0ZvKArH+uqXnrenK3x7wmkqSMyTVU
le4S00z3LT/GHVUzoK3TBVbf2mLhtPifRxY6wjwA+kZTFsNz4U+t4f6qkcJETcN7
1YbARrKP3zcRU1uB3LDplRJcJ7FmBsijUau62vwLFAbCP+ac0uxdV4ts+ynpX44e
HL8ZjHIHqV0WGFNPc6BAHP8oTce5Ag0EW9rGWgEQAOoCu86qsSajwt0xLlvpYDKQ
xozrYryj4bF9n9YWEU/wHtFE/3A425+VIHRcTr5DuI9nf/TV5PzrxsOetV1uFSzw
sauIQ+fjY1XOfTOVi4Cfe/CuZqmRe0aniQClsknjJdnbroUwZr5f73EPXAxTTUDV
Axgr2XRY8nVDns5ehz2/xzPbNP+ZVVBksE4K0nCS2mdYIvBrPGxLqqjsIX3p0PFa
K7vQu3JZNdjlBr2bse9Hv6zu3twnIXY5gl6zdR6blp18dPj/Qv04zV0m1SKmnB5l
IakagKJClYBzj4hFGgcwp5+H2S0kQ8mEgED9mNODC2IFFNK8ptKUSKDraKnXqoBC
h9Owm46VgeabWeW5lYJDXELZ8iyGMA9bqqcH5DsjOdieUescVYdvDySeM6KyzyI1
BFbgnkpUmE44rQwjuBZR+kcgNwBUmS01/TUAL0wzV15hwxfALPBNZR26wWVa80rv
ky1Dfy+PCvFhReeJ7bsiL8U8KiZ9Is6ujQir884sDh+x6qbhoRFPArbfEoV5+uCR
1eMxPxtgmZ4oJ+58EzFANCCjK4Mld081YQQCNhzL8sisiti16kOjR8qWiBuoVlmb
y4RaYBEB8u8AzVD+187i0IIIUXI+MaGefmIgmM1DhL1qM20Bpp8K2hXs127OersQ
jmDXZGOhEdqlee1VKjbTABEBAAGJAjwEGAEIACYWIQTaDiapL0wX/XwD7c0IZ/gm
ddHP6wUCW9rGWgIbDAUJB4YfgAAKCRAIZ/gmddHP6waRD/0bj/rbMhG+i6iW8Nmn
NP+DPfUHWKEuUXwJjpo6eFwNGYoQEiMrMMQ/6kGMpRGXqS1jCBoZEvtoYg655dIj
sHariZnXMTfAKCDRIhVbAzWcpejSCFTQ+Ysv7//ZQr2/RMSZBQhg8MNFVm/MRbw9
vtnxJ1GQ4d10S6kBQmZrit4tieLerhMJ4Zju8Lq+XFh8uiLtYGbIJfwBOqcF02ar
WZUiUolZa8UDZH4tQb7XkTOsXACsekZxplTYyUTEdboXEo3+nihwFRr6tES4+t6D
jk27ldzmkCzZCmV4NFE76Lgvsy0kBijvp7/WmacvBJVaP0YQCFkcyM46Tya/K9/x
fb+k70imH/U9CsqEOKjohTd6Y5Fu6SRrfj+Libit5Rn35AIytkdCNgnHYsUNE8/w
CW+83u/JZ6ia0GDNgg8ZLXYd34e4ve6vBHJgH+c+p94mQ2PkRVlzMlHi9CQU860V
/H6uImcdTGSYP3/KM9Gpkb/1e4vrzD4tEkbCmeYNeMVkVbua1KSR2/9Bqk45ufvr
dEVLKz+dE/t5mVThcm7QBLIYpZS7l7VoTNqtovVXBsP1EQC1LF0f9VIAOwYa82jG
CVICeQWIjTbH6O3och46R+eKhp7ilyzn6cC4U9A/cOhbztCp7W/Ax/BAqyb4M2SP
Xmpem1wxkG1QZf3IMPmLl3+sSg==
=GHMz
-----END PGP PUBLIC KEY BLOCK-----

We're eternally grateful for all of those who put in hard work to identify weaknesses within Ethicontrol.
For reports that are not common non-vulnerabilities, we like to reward those who responsibly disclose vulnerabilities with an acknowledgement, swag or bounty money.
Whisky and biscuits can be also provided during one to one meeting.

We appreciate the work that goes into finding and disclosing security flaws in Ethicontrol and would like to thank the following individuals and organisations:

• Alexey Yankovsky, ISACA
• We've been working closely with Alexey and his team at ISACA Kyiv Chapter to identify key weaknesses within our app. They've continuously proven to be experts in identifying weaknesses. They have helped us identify and resolve potential security holes such as account hijacking, access token leaks, XSS and CSRF exploits.

We know about your company nothing except for info you allowed us to know. The
main principle – restriction of access to client's data.

All sensitive case related data are isolated from the applications so that those who have the application admin access rights could not access case data without permission.

We do not know who whistleblowers or managers are, what client communications are or who you a client talking to. We do not collect any of the client's data, statistics or content such as your email content, message content, cloud content etc. We do not record calls and have a strict policy of cache clearing on a weekly basis.

After the system is rolled out - we do not have access to it. If negotiated, the transfer of full control over the client’s server to the client is possible, including SSH access.
Ethicontrol's engineers have temporary access to the system during initial setup
only.

The system captures any requests for access to data allowing to monitor any
unauthorised read-write operation.
Security logs are retained for 180 days. Access to these security logs is limited.

Most systems only encrypt clients data during transmission or/and operating system of the server. We also do that, but this means that anyone with access to the servers on which a client data is stored (such as the company’s staff) could have access to it (database). So, our system can be encrypted from a client-side.
The one-way encoding process we use is comprehensive – even with physical access to the servers, third-parties and even Ethicontrol cannot read client’s data. All they can see are sequentially numbered rows of encoded undecipherable data.

Our third-party service provider (data centre) or and even Ethicontrol team will not be able to decrypt and read client content. Only the client will have the ability to decrypt and read its data.
Zero-knowledge policy in terms of client-side encryption is a feature and subject to additional charges. Traditionally, we can sign a non-disclosure agreement with a client’s wordings.
Needless to say about certified data centres according to the most stringent international standards.

Access credential and encryption keys to servers and applications are transferred to
an authorised customer representative after the system setup.


The credential and the key are then stored by the customer and to be changed as a
guarantee of access restriction.


Updates of the software may be restricted without customer's permission and to be
supervised by the representative of the company.

Ethicontrol uses Transport Layer Security (TLS) TLS 1.2 with a preferred AES 256 bit algorithm in CBC mode and 2048-bit server key length with most modern browsers.
When you access Ethicontrol via a web browser TLS technology protects your information using both server authentication and data encryption. This is equivalent to network security methods
used in banking and leading e-commerce sites.
User files uploaded to Ethicontrol servers are automatically encrypted with AES 256 using
per file keys. If someone were to gain physical access to the file storage, this data would be encrypted and impossible to read directly. These encryption keys are stored in a secure key vault, which is a separate database decoupled from the file storage layer.


Data at rest in Ethicontrol's production is encrypted using FIPS 140-2 compliant encryption standards.
Ethicontrol stores encryption keys in a secure server on a segregated network with very limited access. Keys are never stored on the local system, but are delivered at process start time and retained only in memory while in use.

Data transfer for all users is carried out via an SSL-encrypted connection (with a 256-bit key). Users can confidently open Ethicontrol in public places through WiFi or mobile network connections.
Ethicontrol is accessed exclusively through an SSL connection, from intital authorization to the downloading and uploading of company data.

Our corporate clients can store case files at corporate cloud facilities from Box.com,
Dropbox.com or Google drive. This option will make the system compliant with
existing corporate policies

Scope
The Ethicontrol Data Classification Policy applies to all data handled, managed, stored, or transmitted by Ethicontrol and our team members, including that which is submitted to Ethicontrol Support as part of a support request.
Roles and Responsibilities
Everyone at Ethicontrol is responsible to review, adhere to and handle data according to the classification levels below. The Data Classification Index (internal only) provides a list of various types of data and their classification level. If you cannot identify the data element or are uncertain of the risk associated with the data and how it should be classified and handled, please contact The CTO.
Definitions

• Personally Identifiable Information (PII) has been defined per GDPR Requirements

Data Classification levels

RED
Restricted and must remain confidential. This is our most sensitive data and access to it should be considered privileged. Exposure of this data to unauthorized parties could cause extreme loss to Ethicontrol and/or its customers. In the gravest scenario, exposure of this data could trigger or cause a business extinction event.
Examples: See Data Classification Index
Access: Requests should be reviewed based on the principle of "need-to-know" and approved by the appropriate data owner. Once approved, access should be logged and monitored. Additional security measures should be put in place to ensure immediate response to access that seems unexpected or inappropriate. These measures should include a formalized and documented review of access on a recurring basis, during which appropriateness of access and access entitlements are recertified. Strong access controls should be put in place to ensure that this type of data is not publicly exposed.
Vendor and/or contractor access is not permitted without formal approval and verification that they have signed an approved confidentiality agreement or non-disclosure agreement.
Systems, applications and/or integrations containing Red information must have a DPIA on file.
Reproduction: Do not reproduce or share Red information in an application lacking the appropriate level of security. Never share in a public forum.

ORANGE
Data and information that should not be made generally available. Unauthorized access or disclosure could cause significant or financial material loss, risk of harm to Ethicontrol if exposed to unauthorized parties, break contractual obligations, and/or adversely impact Ethicontrol, its partners, employees, and customers.
Examples: See Data Classification Index
Access Access to this data must be approved by the appropriate owner prior to being granted, and once provisioned, access should be logged and monitored. Strong access controls should be put in place to ensure that this type of data is not publicly exposed.
Access to ORANGE data is limited to those with a business need-to-know, including third parties and customers, as defined by Ethicontrol Security.
Third party access to confidential information is granted only on a need to know basis and providing appropriate confidentiality agreement or non-disclosure agreement is in place.
Reproduction: May be reproduced for Internal Use only.
Distribution/Disclosure: May be sent internally on a need to know basis, but discretion should be used. May not be sent over a public network unless encrypted. Must use the standard Ethicontrol email statement regarding sensitive information. Information must be encrypted or otherwise electronically protected when sent to a recipient outside the company. Must be encrypted or otherwise protected when stored and not in use on a laptop or portable device. Documents and computer screens should be positioned to prevent inadvertent disclosure of information. “Orange” markings should be applied to all presentation materials to identify sensitive information.
Storage/Disposal: Electronic storage requires access controls, access control lists, and directory as well as file permissions, and other protection mechanisms. Information must be encrypted if necessary to store on publicly accessible systems. Electronic storage media must be irretrievably erased, degaussed and/or disposed of in a secure fashion. When information is no longer valid or necessary, it should be completely and permanently destroyed.

YELLOW
Non-public data that is not classified as ORANGE or RED. Disclosure of this data could violate privacy policies, minimal risk of harm and/or adversely impact Ethicontrol, its partners, employees, and customers.
Examples: See Data Classification Index
Access: Access to this data should be approved prior to being provisioned and should be logged. Strong access controls should be put in place to ensure that this type of data is not publicly exposed.
Access to YELLOW data is limited to those with a business need-to-know, including third parties and customers, as defined by Ethicontrol Security.
Reproduction: May be reproduced for internal use only. May be distributed to vendors and contractors on a need-to-know basis.
Distribution/Disclosure: Whenever possible, do not leave screens unattended or unsecured in public locations. Conversations must be limited to other Ethicontrol employees or individuals covered by a non-disclosure agreement. Appropriate care must be taken to prevent disclosure or theft.
Storage/Disposal: Normal deletion commands or utilities with operating systems are sufficient for online files. When information is no longer valid or necessary, it should be completely and permanently destroyed. Basic access controls must be configured on the device(s) storing such information

GREEN
Data and information that are publicly shareable, and do not expose Ethicontrol or its partners to any harm are classified as Green.
Public Information requires no special handling.
Credentials and access tokens are classified at the same level as the data they protect
Credentials such as passwords, encryption keys, and session cookies derive their importance from the data they protect. For example, authentication cookies for domain.ethicontrol.com super users are classified as RED because anyone who gains access to them will have access to customer content, which is RED data.
Systems must be protected at a level appropriate for the volume of data they process.
A system that processes a single data element at a time still processes many over time and must therefore be protected at a level appropriate for systems processing bulk data.
Typically only client applications are considered to be handling "A single customer's" data. Data on hosts/services is typically always "more than one customer". (example of hosts running "client applications" would likely be runner hosts)
Combinations of data types may result in a higher classification level
An example of this would be a single customer's encrypted content (ORANGE) that is stored on the same system as a Ethicontrol employee's credentials (ORANGE). If this user has permission to access to secrets that decrypt the customer's encrypted content, this elevates the classification (to RED).

Labeling
There is currently no requirement to label data according to this policy however labels are encouraged. By labeling data according to classification level.

Ethicontrol, by its remote-only nature, is not easily affected by typical causes of business disruption, such as local failures of equipment, power supplies, telecommunications, social unrest, terrorist attacks, fire, or natural disasters.

In case of an all-remote company like Ethicontrol, it is sufficient to have simple contingency plans in the form of service-level agreements with companies that host our data and services. The advantage of an all-remote workforce like Ethicontrol is that if there are clusters of people or systems that are unavailable, the rest of the company will continue to operate normally.

The exception to this would be a scenario of a single point of failure, (for example, if one of the Engineering heads who should sign off on triggering the plan is unavailable due to a disaster). In this case we would need an alternate plan in place that covers how to get in contact with the person or people affected by the disaster and trigger this business continuity plan.

RTO and RPO are two of the most important parameters of a Business Continuity Plan. These are objectives to guide GitLab Infrastructure team in choosing the optimal data backup plan. The RTO/RPO provides the basis for identifying and analyzing viable strategies for inclusion in the business continuity plan. Viable strategy options include any which would enable resumption of a business process in a time frame within the RPO/RTO.

What is a Recovery Point Objective?
Recovery Point Objective (RPO) is the interval of time that might pass during a disruption before the quantity of data lost during that period exceeds the Business Continuity Plan’s maximum allowable threshold.

What is a Recovery Time Objective?
The Recovery Time Objective (RTO) is the duration of time a service level or business process must be restored after a disaster, in order to avoid risks associated with a break in continuity.

For a business continuity plan to be effective, it needs to be triggered as soon as possible; too early or late can reduce its efficacy.

Key decision points to consider when a BCP has to be triggered or invoked are given below:

• When an incident turns into an event like a disaster, breach, or something which classifies is as a Severity 1
• When the estimated time of resolution for a potential breach is greater than the normal estimated time for regular security incidents
• When the recovery of an incident is uncertain, a decision must be made to invoke the business continuity plan if the disruption cannot be resolved within the specified incident recovery timelines
• When resolution of an incident with critical customers, depending on their service-level agreements is delayed, then the BC plan must be triggered

This section provides details about the Production environment that must be available for domain.ethicontrol.com to run effectively:
Customer domains are mostly hosted on Linode cloud platform.

P1: Outage would have immediate impact on Ethicontrol customer/user operations
1 Disruption of service of Linode Cloud Platform, specifically the region in which Ethicontrol.com and domain.ethicontrol.com are hosted.

• Effect: a loss or degradation of service, of the Linode Cloud Platform means that Ethicontrol platform is not available. This affects client who uses the selected locations to host their system and may prevent Ethicontrol team members from completing their work.
• Solution(s): There are many other servers across the globe where Ethicontrol is readily available.
• Effect: Security releases are developed and staged before being brought to production; these may be lost or unavailable for the duration of the disruption.
• Solution(s): Depending on the duration and nature of the disruption, the solution is to wait for service to be restored (minimal duration), or build a new staging server. Using VM snapshots, recovery from backup is relatively quick.

2 Unavailability of support staff in case of a customer emergency.

• Effect: emergency response times are greater than intended.
• Solution(s): The team is distributed geographically (except during team get-togethers). Customer emergencies are handled by any person who is in the on-call rotation. Emergencies also trigger automatic notifications on our internal chat system, alerting the entire company. There is also an ongoing effort to publish our runbooks, explaining how we manage our infrastructure and how we deal with outage cases.

3 Disruption of service of Freshdesk.

• Effect: support workflows are disrupted. New tickets cannot be created, existing tickets cannot be responded to.
• Solution(s): For the duration of the outage (if more than e.g. 4 hours) temporarily re-route incoming support requests to individual email accounts of members of the support team. Customers with premium support also have access to a direct chat channel.

P2: Outage would have immediate impact on Ethicontrol ability to continue business Malicious Software attack and hacking or other Internet attacks.

• Effect: depends on attack.
• Solution(s): We log and track any access that happens on any server in the fleet using Rollbar, Errbit and Bugsnag.

P3: Outage greater than 72 hours would have impact on Ethicontrol ability to continue to do business Disruption of service from Hubspot.com, Zadarma, G-suite

• Solution: create redundancy solutions to Zoho, Binotel or Datagroup VoiP.

P4: Non critical system Disruption of service from Jira or internal chat tool (Slack).

• When Jira is down, team members can use a Redmine instance to track tasks
• When Slack is down, team members can use Google hangouts.

When it comes to a disaster, communication is of the essence. A plan is essential because it puts all team-members on the same page and clearly outlines all communication. Documents should all have updated team-member contact information and team-members should understand exactly what their role is, in the days following the triggering of the BC plan. Assignments like setting up workstations, assessing damage, redirecting phones and other tasks will need assignments if you don’t have some sort of technical resource to help you sort through everything.

Each Ethicontrol team should be trained and ready to deploy in the event of a disruptive situation requiring plan activation. The plan of action steps, procedures, and guidelines will be documented in their team runbooks page (currently under development) and should be available offline. This should have detailed steps on recovery capabilities, and instructions on how to return the system to normal operations.

Make sure that backups are performed daily, and include running an additional full local backup on all servers and data in the Business Continuity preparation plan.
Run them as far in advance as possible to ensure that they’re backed up to a location that will not be impacted by the disaster.

Ethicontrol documentation related to all procedure and guidelines detailing the Business Continuity and Disaster Recovery must be reviewed, updated, and formally approved by Ethicontrol leadership

After developing basic guidelines, this plan will be distributed as a work in progress to the core team The core team will review to verify that all technical details are covered and deficiencies exist

The core team will review and add guidelines so that all related DRIs are clear on what is required in all situations

Ethicontrol team members must be asked to confirm their current details, such as phone numbers and emergency contacts on an annual basis

Managers or team leads will share the relevant parts of the plan to all Ethicontrol team members based on their role and department, and verify that they know what to do in the event of an emergency

A plan cannot be successful without restoring customer confidence. As a final step, ensure that there is a detailed vendor communication plan as part of the Business continuity preparation plan. This plan will check for all the systems and services to ensure normal operations have resumed as intended once the damage is repaired in the area. Also, include the section to check with the main service providers on restoration and access.

There are several types of tests, such as a plan review, a tabletop test, or a simulation test, which was detailed in the previous section. Some testing scenarios that can be performed, are given below:

Data Loss/Breach

• One of the most prevalent workplace disasters today. Cause of data loss or breach could be due to any of the following:
• Ransomware and cyberattacks
• Unintentionally erased files or folders
• Server/drive crash
• Datacenter outage * Data is mission-critical and losing it can have many serious consequences, such as significantly impacting sales and logistics applications. * The goal is to regain access to that data as soon as possible. Restoring backup is the solution. However, who’s responsible for that? What’s the communication plan in this case? What are the priorities? Who needs to be contacted right away? Are there any vendors involved? These and many other questions will be answered during this test.

Data Recovery Testing

• This testing scenario, is used to make sure that the backup and recovery systems work as intended. To prove that, run a test that involves losing a bulk of data, and then try to recover it.
• Some of the elements to be evaluated include the RTO, and whether the team met its objectives.
• Also make note of, if there were any damage to the files during recovery? Was the backup stored in the cloud, recovered successfully and on time.

Emergency Communication

• Being able to communicate during a disaster or an emergency is crucial. Yet, the most disruptive events can leave with no traditional means of staying in contact.
• For these scenarios, the BC plan needs to outline the actions to be taken. An alternate mode of communication should be tested for its reliability and efficiency, for a company like Ethicontrol which has team members all around the globe.
• Regular updates to all Ethicontrol team members contact information, so that all of them can receive timely notifications thus streamlining the disaster scenario process.

Purpose
The purpose of the BIA is to identify and prioritize system components by correlating them to mission critical processes that support the functioning of Ethicontro.


The Business Impact Analysis is composed of the following:
Determine data classification and approved operating System usage: Ethicontrol data and system resources can more clearly be linked to mission critical business processes by way of classifying them based on sensitivity. These priority levels can be established for sequencing recovery activities and resources. Additionally, the existence of an approved set of operating systems platforms will facilitate ease of management and quick turnaround and repair when they are non-functional. Ethicontrol's Data Classification policy covers all aspects of this requirement: Approved Operating Systems

Determine mission critical business processes and recovery criticality: In this step, Ethicontrol's mission critical business processes / systems are identified and the impact of a system disruption to those processes is determined along with outage impacts and estimated downtime. The downtime reflects the maximum, that an organization can tolerate while still maintaining the mission. This is covered in the P1, P2, P3: Outages and their immediate impact on Ethicontrol customer/user operations

Identify resource requirements: Realistic recovery efforts require a thorough evaluation of the resources required to resume business processes and related interdependencies as quickly as possible. Examples of resources that should be identified include software, data files, system components, and vital records. The Backup and Recovery process in Ethicontrol is robust enough to satisfy the above requirement as it relates to Ethicontrol.com.

Determine alternate storage and strategies: Identify any alternate strategies in place to meet expected RTOs. This includes backup or spare equipment and vendor support contracts. Ethicontrol alternate storage process, serves to securely store data in an alternate location from source data

Identify recovery priorities for system resources based on standards: Adherence to Ethicontrol's agreed upon RTO/ RPO: Apart from determining the RTO and RPO, BIA also defines Maximum Tolerable Downtime (MTD)

The Maximum Tolerable Downtime (MTD) - represents the total amount of time senior management are willing to accept for a mission/business process outage or disruption and includes all impact considerations. Determining MTD is important because it could leave continuity planners with imprecise direction on (1) selection of an appropriate recovery method, and (2) the depth of detail which will be required when developing recovery procedures, including their scope and content.

Delegation and defining the process: Designate each incident as critical or non-critical based on the business priority. Compile a list of personnel who must be in place to perform these functions. In times of an occurence of an incident, a detailed step-by-step approach about how to communicate it to the group, how it is performed, who performs it, and the operational mode of action taken.

Security vulnerabilities in Ethicontrol and its dependencies are to be addressed with the highest priority.
Security releases are naturally very similar to patch releases, but on a much shorter timeline. The goal is to make a security release available as soon as possible, while ensuring that the security issue is properly addressed and that the fix does not introduce regressions.

General process overview
The release manager also makes sure that all the deadlines (described below) are respected. Any delay needs to be escalated to CEO.
Security engineers need to follow the process defined in respective Confluence Wiki page.
Developers need to follow the process defined in respective Confluence Wiki page.
Quality engineers need to follow the process defined in respective Confluence Wiki page.

Terminology
Security vulnerability issue - A confidential issue in a Ethicontrol Jira project, detailing a security vulnerability and steps to reproduce. Usually created via HackerOne.
Security release tracking issue - A confidential issue in Ethicontrol Jira which is the high-level overview of an entire security release (critical or otherwise).
Security implementation issue - An issue in a Ethicontrol Jira, outlining the versions affected, detailing the steps a developer needs to take to remediate the vulnerability, and associating backports.
Security merge request (MR) - A merge request in a Ethicontrol Jira, resolving a vulnerability in a specific branch.
Release task issue - Used by release managers as a checklist of steps to complete the release.

Non-critical Security Releases
Every 28th of the month, we are releasing patch versions of Ethicontrol containing non-critical security fixes. This date has been chosen as it gives enough time to release regular patch releases after standard release on the 22nd of the month. This date also allows us to create and test fixes internally as the next development cycle (starting on the 8th) starts.

Release deadlines
Anything that can be carried out before the deadline, should be done. Anything that is not done by the deadline requires immediate escalation to people responsible of security release process. Dates in this section can be considered as non-negotiable deadlines.
Non-critical security release contains security fixes that are ready for merge by 23:59 EEST time on the 23rd of the month. Both the fixes for the current release and all of the backports need to be ready for merge and have green tests.
If fixes and backports are not ready by that date, they will have to go into the next security release. Exceptions can't be made because verifying and creating security releases are time consuming and any delay puts regular releases in danger.
Current release and all backports need to be tagged and packages created by 23:59 EEST on the 24th. This is also the deadline for creating the initial blog post.
Once the packages are ready and up until 23:59 EEST time on the 26th of the month, Quality Assurance tasks need to be carried out on all created releases to verify that the fixes are indeed working as intended. During this period, the tests should be executed on separate infrastructure created to carry out these tests. Staging/canary/production are should remain open for regular releases.
Deploy to staging and canary environments should be carried out by 23:59 EEST time on the 27th the latest. Deploy to production has to be completed by 07:00 EEST time on the 28th. Package promotion has to be coordinated with the blog post release. 1 hour before the scheduled blog post announcement, package promotion should be done. This is required because package promotion takes time to propagate.
Blog post, tweet and the email announcement should be complete by 10:00 EEST time on the 28th.

Critical Security Releases
Depending on the severity and impact of the vulnerability, an immediate patch release consisting of just the security fix may be warranted.
The critical release process is a superset of a non-critical release, and for completeness the process is written here:

1. The vulnerability has been reported and discussed between a Security Engineer and a Developer. When the timeline of a possible fix is established, the Security Engineer informs a Release Manager of a need for the critical security release.
2. A release manager proposes a timeline for the critical security release based on the other release tasks, and informs a security engineer and a Quality Engineer in the designated release issue.
3. Depending on the nature of the issue, a security engineer may decide that a temporary mitigation strategy is required. If a patch is required, the security engineer works with the developer and infrastructure engineer following the post-deployment patch process. In other cases, the security engineer will work with infrastructure engineers on remediations.
4. The security engineer creates a security operations issue using the "User Impact Investigation Template" for the security operations team to track further investigations and other post-remediation activities, such as determining and notifying affected users.
5. A security engineer works on a blog post to pre-announce the critical security release. They also work with the marketing team to inform the customers of an upcoming release. The security engineer also prepares the second blog post which will be published at release time.
6. The developer follows the Developer process to create the artifacts necessary for a release. When complete, the developer assigns merge requests to the release managers.
7. A release manager prepares the release with all backports, and deploys to staging (if applicable). If there are any non security releases pending, such as a release candidate, release managers may decide to release those first.
8. If any post-deployment patches were applied, an on-call Security engineer should verify that the applied patches are still working; unless the newly deployed version removes the need for these patches.
9. A quality engineer prepares environments and executes QA tasks together with the security engineer to verify that all released versions have successfully resolved the vulnerability.
10. When the QA is completed, release manager deploys to the other environments.
11. When all environments contain the fix, any temporary mitigation strategy is reverted.
12. Following deployment, a release manager coordinates with a security engineer on the exact timing of a release.
13. A release manager will promote the packages at the designated time, and merge the release blog post.
14. A security engineer works with the marketing team to send notification emails to any affected users.
15. A release manager closes all release issues.
16. A security engineer keeps the issues where the vulnerabilities were reported open for the next 30 days.
17. A security engineer prepares a blog post that explains the vulnerability in detail and releases it approximately 30 days after the original release.
18. Once the final blog post is released, a security engineer removes the confidentiality from the issues and closes them.

Each involved role should follow their own guide, and create separate issues linking to the main release issue.

Where possible we use of Secure Boot, vTPM-enabled Measured Boot, and integrity monitoring for our VPS instances.
Additionally, per request we can deploy specialized agents to produce telemetry about user and host activity in cloud-based virtual machines (VMs).
This provides the Security Operations Center (SOC) with visibility into activities within and around the frequently-morphing security boundary.

We monitor the volume and frequency of data transmission by our users over email and other organizational messaging tools.
If the average user sends X megabytes of data on average per day, a user sending 10X megabytes will trigger an alert.
We retain a log of addresses used to send email, what devices emails are sent from, and the addresses of recipients.
We also use tagging sensitive content with markers, like keywords or hashes.
Our mail provider will prevent sending messages over insecure channels, such as using http instead of https, and alert our IT security staff of attempts.

We prohibit downloads of any data to local terminals or desktop.
Our users never need to download it to local hardware since we use cloud based document systems.
All of the data is in the cloud.
We maintain a policy that prohibits downloads, we classify and label sensitive data, and keep access logs of data that is requested and served via secured interactions and API calls.

We prohibit any data from being downloaded and keep all data in the cloud
We prevent installation of insecure third party software, such as social media apps or unauthorized browser plugins, on devices with access to sensitive data.
We use G Suite policies and account management for Chrome browsers.

We set company wide security policies within our cloud solution providers, e.g. G Suite.

There is a paid option for additional masking and client database encryption.

We log all the actions of administrators in a place they cannot access.
We use a separate security team to manage monitoring and logging services.

In addition to zero-knowledge and zero-trust policies, we adhere to single date kick off policy.