ISMS Security Incident Management Process

1. Purpose, Scope and User

This document defines the process how VSHN handles security events and vulnerabilities.

Further it defines the objectives and processes to for threat intelligence.

2. Definition of a Security Incident

An information security incident is "a single or a series of unwanted or unexpected information security events that have a significant probability of compromising business processes and threatening information security" (ISO/IEC 27000:2016, translated from German).

3. Triggers of a Security Incident

The following events can trigger a security incident and should be handled according to this document.

  • Loss or theft of information

  • Data loss on VSHN systems

  • Loss or theft of equipment

  • Unauthorized access to customer data and other sensitive data (for example customer names passed on to other customers, access by customers to data of other customers, etc.)

  • Protected data (for example passwords, confidential documents, etc.) that were viewed or sent via insecure channels

  • Violation of the Acceptable Use Policy (AUP)

  • Openly accessible sensitive papers (confidentiality level "Authorized"/"Berechtigt" or higher)

  • Indications that passwords, sensitive data or the system may have been compromised

  • Targeted attempts by third parties to gain unauthorized access to VSHN systems

  • Large-scale and noticeable attacks on VSHN systems (DDoS, viruses, etc.)

  • Long unresolved security vulnerabilities in software, packages, etc. used by VSHN (for example no updates on important servers)

  • Phishing mails whose links have been clicked on by employees or subsequently user entries have been made.

  • Targeted Phishing mail attack with APT tactics. In other words, if a targeted phishing e-mail is sent to a person in VSHN using publicly accessible data from VSHN or internal information obtained through social engineering in order to damage VSHN

  • Attempted or successful social engineering

  • Longer backup failures of VSHN systems

  • Longer failures of system-relevant VSHN systems

  • Physical access of unauthorized persons to the offices of VSHN

  • Possible violations of regulations or laws by VSHN or its employees

  • Other triggers where there is a suspicion that confidentiality, integrity or availability is at risk. The principle is to report one incident too many rather than too few.

4. Report Security Incident

Each employee or third party who is in contact with information or systems of VSHN AG must report any system vulnerabilities, incidents or events that could lead to a possible security incident as follows:

  1. All incidents must be reported to the CISO or the ISM Governance Role.

  2. The observer creates a security incident ticket according to How to Create Security Incident Tickets.

  3. The observer ensures that the CISO or the ISM Governance Role is aware of the ticket and that immediate measures are applied if needed.

5. Treatment

First an initial assessment must be done, then work through bullet points according to classification.

5.1. Initial Assessment

The CISO ensures:

  1. Assessment of the incident and whether immediate measures are needed:

    1. Organize immediate measures in coordination with the Operations engineers of the team responsible for the affected service.

    2. Define a ticket owner.

  2. Classification of the incident in four categories:

    1. Security vulnerability or event - no incident has occurred, but the event related to a system, process or organization could result in an incident in future.

    2. Minor Incident - an incident that doesn’t have a significant impact on the confidentiality or integrity of information and can’t cause a longer-term loss of availability.

    3. Major Incident - an incident that could cause significant damage through the loss of confidentiality or integrity of information, or that could cause an interruption in the availability of information or processes for an unacceptable period of time.

    4. Incident endangering the business continuity - a serious incident that could endanger the existence of VSHN.

5.2. Security Vulnerabilities or Events

The CISO analyzes the information, determines the cause and, if necessary, proposes preventive and corrective measures.

All actions must be recorded in the ticket system.

5.3. Minor and Major Incidents

If a minor incident is reported, following steps must be done:

  1. Take measures to isolate the incident.

  2. Analysis of the causes of the incident.

  3. Take corrective action to eliminate the cause of the incident.

  4. Informing those affected by the incident and the ISM Governance Role about the procedure for handling the incident.

  5. If customers are involved then Customer Account Manager must be involved and must assess whether they should inform the customer.

  6. If there is a bigger incident with involving customer, Customer Account Manager, CISO, and ISM Governance Role should find out whether a communication on C-level to C-level is needed and find a person that could represent VSHN’s C-level.

The assignee of the ticket must document taken actions in the ticket system.

5.4. Incidents that Endanger the Progress of Business

In the event of incidents that endanger the progress of business, an BCM Plan comes into effect.

The assignee of the ticket must document taken actions in the ticket system.

6. Learning from Incidents

The CISO ensures each incident is analyzed and documented in the incident ticket according to the following points:

  • identification of the type

  • origin / root cause of an incident

  • and cost of an incident

The CISO must review all incidents on a quarterly basis and propose appropriate preventive or corrective measures for those that recur (or those that could become significant incidents the next time they recur). The verification is ensured by the recurring ticket ISMS-181 and documented in the VSHN’s wiki.

6.1. Post-mortem

A post mortem must be created according to the post mortem template if the incident is major or more severe. If customers are involved Customer Account Manager and CISO will decide whether a post-mortem should be created for minor or less severe incidents. Involved customers must receive the post-mortem

7. Threat Intelligence

The objective of VSHN’s threat intelligence is to ensure that VSHN remains updated on potential threats and can effectively communicate this information to employees working on the front line.

The CISO is responsible for analyzing new potential threats during the quarterly review required in Learning from Incidents section. The following three layers of threats should be analyzed:

  • Strategic threat intelligence (high-level information about the changing threat landscape)

  • Tactical threat intelligence (information about attacker methodologies, tools and technologies)

  • Operational threat intelligence

For strategic and tactical intelligence analysis, the CISO utilizes sources documented in Security and Vulnerability Handling Process; this list may be expanded or modified during the analysis process. Operational intelligence is gained from the incidents documented by VSHN and other relevant sources. A summary is quarterly documented in Annex - Quarterly Review of Security Incidents with the ticket ISMS-181. The CISO is responsible for deciding whom to communicate the findings to and to define follow-up tickets to be looked at by VSHN’s teams.

8. Disciplinary Measures

The People Role may initiate disciplinary processes for any violation of security rules.

9. Collection of Evidence

If there is a suspicion that an incident occurred due to criminal activities, evidence must be secured immediately. For this purpose, external partners such as Swiss FTS are called in who have the necessary expertise in handling evidence. The CISO is responsible for the coordination.

10. Reference Documents

ISO 27001:2022 ISO 27001:2013 Control

A.5.7

N/A

Threat intelligence

A.5.24

A.16.1.1

Information security incident management planning and preparation

A.5.25

A.16.1.4

Assessment and decision on information security events

A.5.26

A.16.1.5

Response to information security incidents

A.5.27

A.16.1.6

Learning from information security incidents

A.5.28

A.16.1.7

Collection of evidence

A.6.4

A.7.2.3

Disciplinary Process

A.6.8

A.16.1.2, A.16.1.3

Information security event reporting

11. Appendix


This policy is tracked and approved by the CISO with ticket ISMS-180

Approval date

2024-10-31 with ISMS-1698

Approved with

ISMS-1698 in MR 1111

Last reviewed

2024-10-31 with MR 1111

Classification

Public