Security Incident Management Policy

Incident Management Policy

Incident Management processes shall be developed and implemented to ensure timely and appropriate response to actual, attempted, or potential security incidents and privacy breaches, as well as reported product vulnerabilities.

This policy covers security incident management for KX’s computing infrastructure and business systems, as well as product security vulnerabilities not resolved within the controls defined.

Security Incident Management

KX defines a “Cybersecurity Incident” as any actual or suspected event that is reasonably likely to result in:

• Violations to governing policies or regulatory compliance policies that could result in monetary damages / fines, litigation, or noncompliance with governmental mandates laws.
• Significant damage to KX assets, management or business activities.
• Damage to KX reputation or decreased confidence in the KX brand.
• Significant operational disruption for any KX user or customer.

A product security incident is essentially the discovery of a security vulnerability within the product code which an attacker could exploit.  Product security incidents are managed under this policy when they affect product code that has been released to customers and pose a risk to the customers business processes or data and cannot be resolved within guidelines.

1. Security incidents can generally be categorized into five types:
2. Unauthorized access
3. Disclosure of information
4. Corruption of information
5. Denial of service
6. Theft of resources

The purpose of security incident response management is risk mitigation intended to minimize damage and exposure, as well as facilitate an effective recovery.  Within the risk mitigation goal, incident response has a hierarchy of priorities which are as follows:

• Human life and safety
• Sensitive or mission critical systems and data
• Damage to systems or data
• Disruption of access or services

Potential incidents can include, but are not limited to, the examples listed below:

• Deliberate violation of Information System Security Policy or other related Security Policy or Standard
• Any violation which has impact on customer service
• Any violation which results in the accidental sharing of customer or employee data
• Violations by a third party or insider threat / employee
• Violations resulting in financial loss
• Violations which have resulted in the loss of reputation, or have the potential for reputation loss
• Violations having legal or regulatory implication
• Violations affecting critical assets
• Not reporting an incident
• Violations in the standalone systems

All incidents will be responded to in a timely manner, as defined in the appropriate standard (see links above).

Security Incident Handling and Incident Response Process

Any employee who has found or suspects a security incident must report it to the appropriate Security and Compliance leads, depending on the type of incident (for additional information see the Security Incident Reporting Standard).  For guidance on reporting an incident, please see the Reporting an Incident page on the ISMS wiki.  All reported incidents will be reviewed by the appropriate Incident Response Team (IRT), depending on the type of incident.  The IRT will be assembled by the Security and Compliance lead who oversees that type of incident.

The employee must report the incident in detail.  The Security team shall analyze the impact of the incident and forward the incident report to the Security Lead as required and take immediate and appropriate steps as detailed in the Incident Response procedure, including reporting to appropriate authorities or notifying customers through appropriate channels if needed.

Collection of Evidence

For security incidents potentially involving follow-up legal or disciplinary action against a person or organization, evidence shall be collected, retained and presented to conform to the rules for evidence laid down in relevant jurisdiction(s).

Evidence collected must be kept secured from any kind of destruction either accidental or intentional.  In case of documented evidence, the document must be kept in a secure repository where it cannot be altered or deleted.  All evidence locations must be recorded and attached in the incident tracking system.

Learning from Security Incidents

Incidents will be tracked in Jira, with evidence to be stored in restricted access areas. Follow-up activity must be done for any incident deemed Critical or High, per the standards.

The lessons learned from the Security Incident will be shared with the respective departments.  Information Security Policies will be updated as part of the learning if required based on the Security Incident.

The “Don’ts” of Incident Management

• Do Not attempt to perform the investigation on your own.  You could unintentionally compromise the investigation or contaminate evidence.
• Do Not contact individuals or organization that you suspect of being the source of the incident, unless directed to do so by the Incident Response Team (IRT).
• Do Not try to reverse penetrate the origin of a system penetration attack.  Attempting to do so could be illegal.
• Do Not attempt to “clean up” the system until directed to do so by the Incident Response Team (IRT).  A key aspect of incident investigation is preservation of evidence.

Product Security Vulnerability Incident Management

Security vulnerabilities within product code provide opportunities for attackers to gain unauthorized access to the product, steal or corrupt data, or interrupt product functions.  According to the Open Web Security Project (OWASP), the top 10 most common web application security vulnerabilities can be found on the OWASP Top 10 page.

At KX, a Product Security Incident Response Team (PSIRT) will manage product security vulnerabilities found in products which have been released to market.  The PSIRT Program Manager shall be responsible for ensuring that product security vulnerabilities are analyzed, remediated, and communicated appropriately.  All product security vulnerabilities which have been confirmed to affect the product will be addressed in a timely manner based on the severity of the incident. A PSIRT issue becomes a security incident when, the vulnerability is being actively exploited in the wild, has led to unauthorized access, data leak, system compromise or has a widespread threat.