Taranis Security and Privacy Incident Response Policy

Taranis Security And Privacy Incident Response Policy

Taranis Security And Privacy Incident Response Policy


Purpose and Scope

The purpose of this policy is to ensure that Taranis reacts appropriately to any actual or suspected security or privacy event regarding Taranis systems and/or data and that all activities are documented for future reference. This policy establishes responsibility and accountability and defines the steps required to ensure that security incidents are identified, contained, investigated, remedied, communicated, and documented.

This policy applies to all systems, personnel, and data at Taranis. 


Policy Statement

Management responsibilities and processes will be established to ensure a quick, effective, and orderly response to information security and/or privacy incidents. All activities pertaining to the incident will be documented in a Google Docs document.


Definitions

Security Incident: A security incident is any real or suspected event that may adversely affect the security of Taranis cloud information or the systems that process, store, or transmit that information.  Security Incident includes, but is not restricted to, the following:

  • Attempts (either failed or successful) to gain unauthorized access to a system or its data

  • A system infected with malware, such as a worm, virus, or Trojan horse

  • Theft, loss, or unauthorized transfer of data to those who are not entitled to receive that data

  • Unwanted disruption or denial-of-service (DoS) attack

  • Changes to data or system hardware, firmware, or software without Taranis’’ knowledge, instruction, or consent

SIRT: Security Incident Response Team


Responsibilities

Security Incident Response Team (SIRT)

The SIRT consists of:

  • VP R&D - Team Lead

  • Chief Technology Officer

  • Chief Technology Innovation Officer

  • Chief Product Officer

  • Chief Operating Officer

  • VP Operations

  • Support Team Leader

  • R&D Team Lead

  • CEO


Responsibilities of the SIRT include:

  • Coordinating and overseeing the response to incidents in accordance with the requirements of Taranis’ security policy and regulatory laws

  • Minimizing the potential negative impact on Taranis and Taranis customers resulting from such incidents

  • Determining what type of incident has occurred: security, privacy or both security and privacy

  • Repairing, or coordinating the repair of, damage caused by the incident

  • Restoring services to a normalized and a secure state of operation

  • Preserving evidence of the incident, as appropriate

  • Providing clear and timely communication to all interested parties

  • Taking proactive steps to prevent future incidents


Policy Review and Update

This policy and its supporting procedures will be reviewed at least annually and updated as required.


Security and Privacy Incident Response Procedure

Security and privacy incident response includes:

  • Reporting the initial information regarding how the incident was identified.

  • Collecting the information around the event to understand what has happened and the impact.

  • Assessing the event to understand the severity. 

  • Communicating about the event, which includes:

    • Communication within the immediate event team.

    • Communication within the company, as appropriate.

    • Communication with customers, as appropriate.

  • Containing/limiting the current event

  • Taking corrective action

  • Ensuring that complete documentation is available during and after the event.

  • Documenting the Root Cause of the event

  • Incident closure

  • Lessons learned review


Incident Identification

A privacy or security incident is initiated when:

  • An employee contacts VP R&D or Support Team Leader

  • A customer notifies Taranis of a security issue

  • An alert is created from the PageDuty system

An incident begins when a security or privacy incident is reported to the VP R&D, Support Team Leader, or any other member of the SIRT. This report could come from an Taranis employee, an automated system diagnostic, a customer, or other means.

Customers usually contact the Taranis through the Support Hub, but can also contact their Customer Success representative directly. When the customer contacts Taranis regarding a system disruption, the incident will be escalated to the VP R&D immediately and will include information regarding the disruption.


Documenting the Incident Initially

Based on the information collected below, an immediate determination will be made by the VP R&D or appointed event manager.

Once an incident is identified, document the following information in an information system.


Information

Description

Customer data affected?

Yes/No (required)

Source

Source of the complaint/issue (e.g., Support Hub ticket, email, individual).

Include the following information:

Contact information for the incident reporter: Full name, affiliation, organization, e-mail address, phone number and location.

If an automated system reported the event: Name of software/product, where the software is installed, physical location of the host, host/CPU ID of the host, network address of the host.

Incident contact information

List contact information for all parties involved in the incident.

Incident timeline

Date/time that the incident was discovered

Date/time that the incident was reported

Date/time that the incident occurred (if known)

Type of incident

Examples:

  • Compromised system

  • Compromised user credentials

  • Network attacks (DOS, scanning, sniffing)

  • Malware (viruses, worms, trojans)

  • Lost equipment/theft

  • Physical break-in

  • Social engineering

  • Policy violation

  • Unauthorized access to customer data

Detailed description of the incident

  • System(s) or product(s) affected

  • Description of incident

  • Affected resources and organizations

  • Estimated technical impact of the incident (i.e., data deleted, system crashed, application unavailable)

  • Initial actions taken

  • Cause of incident if known

  • List of evidence gathered

  • Official Common Vulnerabilities (CVE)

  • Individuals contacted

Identification of the host(s)

  • Source of the incident: List of sources' host names/IP addresses

  • Target of the attack: Host name/IP address (Note: the target of the attack should not be listed for the incidents involving personal data)

Communication

  • Internal – Taranis only

  • External – customers or other parties


Severity Assessment

An incident must be assessed to understand the severity and impact of the event. The following factors should be considered:

  • Personal information: was personal information affected? This can be customer or employee information.

  • Service disruption: did the event disrupt service, and if so, who/what was affected?

  • Has the event been stopped or contained, or is it still on-going?

  • What is the urgency?

Incident severity will be determined as either high, medium or low. In general, use the following:


Severity

Symptoms

High

Requires immediate remedial action to prevent further compromise of data and adverse impact on network or other systems.

  1. Network of system outage with significant impact on the user population or operation of Taranis cloud services.

  2. High probability of propagation.

  3. Probable or actual release or compromise of personal data.

  4. Requires immediate remedial action to prevent further compromise of data and adverse impact on network or other systems.

Medium

Some adverse impact on the operation of Taranis.

  1. Adverse effects are localized or contained, or minimal risk of propagation.

  2. No apparent release or compromise of personal data.

  3. Remedial but not immediate action is required.

Low

Localized with little or no risk to other systems.

  1. Minimal impact on small segment of user population or operation of Taranis cloud services.

  2. Completely localized with few individuals affected and presenting little or no risk to other system.

  3. No loss or compromise of personal data.

  4. Remedial action is required.


Notification/Communication

SIRT Lead will take action to notify the appropriate internal and external parties, as necessary.

Internal Notification (within Taranis) 

  • SIRT Lead will issue or direct all internal communications.

  • SIRT Lead will notify Taranis senior management, support team, and customer success team of the incident and provide ongoing status reports.

  • Where applicable, SIRT Lead will notify Taranis employees and provide on-going status reports.


External Notification

In the case of a personal data breach, the affected customer(s) will be notified as soon as is reasonably practicable, but no later than forty-eight (48) hours after Taranis becomes aware of the breach.

For all incidents where external notification is necessary, the notification will include:

  • Incident Description (i.e., how it was detected, what occurred, type of security incident(e.g, network attack, worm, phishing) )

  • Event Timeline / Chain of Events (e.g, date and time that the problem occurred, that the incident was discovered, that the problem was corrected, etc.)

  • Root Cause Analysis

  • Identified Gaps

  • Action Performed and Preventative Measures

  • Lessons Learned

For incidents caused by a Taranis product or a third-party product a Security Advisory must be written and published to the Customer Knowledge Center.

Once the incident is resolved and documented, if appropriate, a report will be sent to the affected external party describing the root cause analysis results, corrective measures implemented, and any additional pertinent information.


Containment

The objective is to prevent the incident from continuing. This is accomplished by:

  • Isolating the incident to prevent it from spreading further.

  • Putting measures in place to stop the immediate threat.

  • Preventing further damage to the compromised system and/or data.


Incident containment activities in a case of unauthorized access include, but are not restricted to, the following:

  • Disconnect the system or hosts from the network or access other systems.

  • Isolate the affected IP address from the network.

  • Where possible, capture and preserve system, host, and application logs, network flows for review.

  • Disable the affected application(s).

  • Discontinue or disable remote access.

  • Stop services or close ports that are contributing to the incident.

  • Notify SIRT of statues and any action taken.

Note: Information pertaining to the incident should be kept confidential until the incident is resolved, at which point the classification of the information will be reconsidered.


Corrective Measures

After the incident is contained, a plan should be developed and implemented to correct the cause of the incident. This is accomplished by:

  • Identifying the root cause of the incident

  • Taking the necessary actions to prevent the incident from recurring

  • Securing the Taranis cloud environment

  • Restoring the Taranis cloud environment to its normal state


Corrective activities in a case of unauthorized access include, but are not restricted to, the following:

  • Require change passwords/passphrases on all local user and administrator accounts or otherwise disable the accounts as appropriate.

  • Require change passwords/passphrases for all administrator accounts where the account uses the same password/passphrase across multiple appliances or systems (servers, firewalls, routers).

  • Rebuild systems to a secure state.

  • Restore systems with data known to be of high integrity.

  • Modify access control lists as deemed appropriate.

  • Implement IP-range filtering as deemed appropriate.

  • Modify/implement firewall rule sets as deemed appropriate.

  • Make all personnel “security aware”.

  • Monitor/scan systems to ensure problems have been resolved.

  • Notify SIRT of status and any action taken.


Lessons Learned Review

After the incident has been managed and corrective actions have been implemented, a review of lessons learned will be performed within a one week period.


Incident Closure

All incident activities, from receipt of the initial report through Lessons Learned Review, will be documented in a Google Docs document. The SIRT Lead will ensure that all the activities regarding the incident are recorded and will organize the lessons learned review.

Compliance

Failure to comply with this policy will result in disciplinary action up to and including termination of employment.


    • Related Articles

    • Taranis Data Security and Retention

      Data Security Introduction Taranis is committed to providing its customers with a highly secure and reliable environment for our data operations and cloud-based applications. We have therefore developed a multi-tiered security model that covers all ...

    • Taranis Business Continuity Planning (BCP)

      Business Continuity Plan Overview Taranis systems Business Continuity Plan is a comprehensive statement of actions to be taken before, during and after a disaster. This plan is designed to reduce the risk to an acceptable level by ensuring the ...