INCIDENT MANAGEMENT HANDLING AND RESPONSE POLICY OF ARBOR GARDEN SOLUTIONS LTD

 

1. GENERAL PROVISIONS
1.1. This incident management handling and response policy (“the Policy”) ensures that a consistent, methodical, and timely incident response process is completed by the designated response personnel after a security incident is believed to have taken place involving Arbor Garden Solutions Ltd (“the Company”) information and information systems. The Policy will help identify if a systems resource has been compromised, limit the exposure of sensitive data, clean the resource(s), and determine if breach notification is required.
1.2. The Policy applies to all employees, contractors and vendors, or other persons that have, or may require, access to information and information technology resources at the Company.

2. DEFINITIONS
2.1. Incident – an actual or potential event involving loss or compromise of data or the loss of functionality of an information system or network. Examples include unauthorized access to a PC, data theft, unauthorized data modification, a computer virus, unauthorized network probing, denial of service attacks, and violations of Information Security Policy, lost or stolen computer equipment and /or intelligent devices.
2.2. Event of Interest – any information system, application or other event data that relates to an incident.
2.3. Compromise – a confirmed security incident resulting in harm to the businesses reputation, assets, information or ability to operate.
2.4. Breach – a security incident that may result in the acquisition or disclosure of personal data to unauthorized parties as defined in section 8 of the Policy.

3. ROLES AND RESPONSIBILITIES
3.1. Incident Reporter – all persons with access to the Company’s information resources or sensitive information are responsible for prompt and accurate notification to the Company of all suspected incidents. The Incident Reporter is responsible for providing complete and accurate detail as possible regarding a suspected incident as well as contact information for use by the Incident Handler and Computer Emergency Response Team.
3.2. Incident Handler – members of the Company’s information technology or information security teams, physical security or third-party Incident Handlers as required that are responsible for implementing incident response procedures, recovery, notification and reporting as detailed within this Policy. The Incident Handler may operate alone in confirmation of a suspected incident or as a member of the Computer Emergency Response Team as required.
3.3. Computer Emergency Response Team (CERT) – mitigate and recover compromised systems and data in adherence to response procedures and implement any required incident handling tasks appropriate to their operational role within the CERT.
3.4. Computer Emergency Response Team Leader – CTO of the Company is responsible for formation and coordination of the Computer Emergency Response Team. The incident team leader is responsible for notifying the Breach Communication Team of breaches and coordination of other communications and resources required by the Computer Emergency Response Team.
3.5. Breach Communication Team – the breach communication team consists of CTO, CEO and legal counsel and is responsible for appropriate breach notification as required by state or regulatory laws in response to a confirmed breach.

4. INCIDENT NOTIFICATION
4.1. Reporting an Incident:
   4.1.1. all persons accessing and using the Company’s information technology resources have a responsibility to immediately report any suspected security incidents to the CTO, IT Specialist or to the IT department via email [email protected].
   4.1.2. Incident reporters are responsible for providing as much detail as possible regarding the suspected incident when reporting or working with the Incident Handler or Computer Emergency Response Team in response to an Incident report. Contact details for the individual reporting the Incident must be included in the Incident report.
4.2. Third-Party Incidents:
   4.2.1. all third-parties, contractors and vendors in possession of or with access to the Company’s information or information technology systems must immediately report all security incidents or Breaches affecting the Company’s information or information systems.
4.3. Contact of Authorities:
   4.3.1. Ambulance should be contacted immediately for any incident that appears an immediate threat to the health, safety or life of an individual.
   4.3.2. The Computer Emergency Response Team Leader will work with the Computer Emergency Response Team to liaise with external law enforcement when, and where, necessary. The Breach Communication Team will be responsible for notifying the appropriate state agencies including law enforcement upon determination of confirmed Breach.

5. INCIDENT LEVEL DEFINITIONS
5.1. Incident level definitions provide a clear standard of definition to assist with communication and reporting of Incidents within the Company as well as supporting the required decision making needed by response actions during Incident handling.
5.2. An Incident level is defined by the confidence in validity of the suspected Incident, potential severity of impact and indicators as to a risk of Breach.
5.3. Incident handling phases, participants and decision-making scopes of authority may be in part dictated by the Incident Level definition.

6. INCIDENT CONFIDENCE LEVELS
6.1. Incident confidence levels provide differentiation between suspected, confirmed and false Incidents.
6.2. Incident confidence levels:
   6.2.1. Suspected. Suspected Incidents have not been confirmed to be valid and are comprised of the Incident notification reports, events of interest, monitoring alerts, log files and all other investigation artifacts related to the associated Incident.
   6.2.2. Confirmed. Confirmed Incidents are suspected Incidents which have been confirmed to involve a loss or Compromise of data or the loss of functionality of information system(s), application(s) or business operations.
   6.2.3. False. False Incidents are suspected Incidents which do not involve a loss or Compromise of data or the loss of functionality of information system(s), application(s) or business operations.

7. INCIDENT IMPACT SEVERITY LEVELS
7.1. Incident impact severity levels help communicate the amount of potential damage to the Company’s financial and/or operational statuses because of the Incident.
7.2. Incident impact severity levels:
   7.2.1. Minor. Minor Incidents potentially affect a small portion of employees, information systems, access accounts or data within a subset of the Company’s business operation processes and does not greatly impact or impede normal operations of any whole the Company’s business operation processes. Personal data impacted by the Breach if indicated, must not exceed 300 records.
   7.2.2. Major. Major Incidents affect employees, information systems, access accounts or data of an entire the Company’s business operations process, or subsets of multiple operational processes such that a portion of the Company’s business operations processes cannot operate within normal functions. Personal data impacted by the Breach if indicated, must not exceed 1500 records.
   7.2.3. Severe. Severe Incidents affect most employees, information systems, access accounts or data of the Company’s business operations processes and impacts normal operation for a majority of business processes. Personal data impacted by the Breach if indicated, exceeds 1500 records.

8. BREACH INDICATOR
8.1. A Breach indicator is added to the Incident level if the Compromised applications or information systems are suspected to hold personal data in accordance with Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC.
8.2. Breach status indication may only be removed if it can be adequately determined and proven that no “personal data” was acquired by or disclosed to unauthorized parties because of the Incident.

9. DETECTION AND NOTIFICATION
9.1. Detection details technologies and methodologies for the collection, review, normalization and alerting required for the effective monitoring of event and system data for indicators of Compromise which are indicative of suspected Incidents.
9.2. Notification of a suspected Incident can come from any persons, software monitoring and alerts, anomalous activity or other technical indicators of Compromise. Upon notification of a suspected Incident an Incident Handler must be assigned to begin investigation into the Incident. Notification steps also apply to communication between Incident Handlers, the CERT, and within the Company. Notification messages during Incident handling should maintain a current and accurate Incident definition.

10. INVESTIGATION
10.1. Incident investigation is the responsibility of the Incident Handlers operating alone or in conjunction with the CERT. Investigation uses correlation between Incident reports, events of interest from log sources or other indicators of Compromise along with other available tools to determine an accurate Incident definition and aide in determining appropriate actions for mitigation, recovery and reporting.
10.2. Incident definition. The Incident definition is comprised of the Incident level as defined in section 6 of this Policy, the scope of the Incident and type. Incident definition may be subject to change during the course of Incident handling as investigation may uncover more components of the Incident which extends or reduces the scope, level or involved Incident types, and it is the job of the Incident Handlers to maintain and communicate appropriate Incident definition within all Incident handling communication including notifications and reports.
10.3. Scope. The scope of the Incident must be determined by the Incident Handlers and is an inventory of the affected accounts, applications, and information systems, operational processes along with potentially affected data definitions.
10.4. Type. Incident types are defined by the Company and specific handling procedures related to the defined Incident types developed. The general incident handling procedure provides general guidance for all Incidents including matched and unmatched Incident types. A specific Incident type handling procedure takes precedence when it conflicts with requirements of the general Incident handling procedure. Conflicts and deviations are to be clearly noted in type procedures. Some actions may only apply to a specific Incident definition such as “Confirmed” or “Severe”, actions within the procedure will be noted to be applicable only within those definitions where required.

11. MITIGATION
11.1. Mitigation actions are the responsibility of the Incident Handlers and CERT and are actions taken to:
   11.1.1. Contain the definition of the Incident while investigating Incident details;
   11.1.2. Remove active threats from the environment as it pertains to the Incident following adequate investigation;
   11.1.3. Prevent future recurrence of the Incident by controlling, removing or remediating used attack vectors.

12. RECOVERY AND MONITORING
12.1. Some Incident types may leave information systems or data in non-operable or untrusted states. Recovery tasks are the responsibility of the Incident Handlers and CERT to:
   12.1.1. Restore normal business operations from a failed state;
   12.1.2. Restore business data or information systems from an untrusted to trusted state.
12.2. Additional monitoring actions may be required to be put temporarily into place following the Incident to continue monitoring the environment for ongoing indicators of Compromise or to confirm that Incident has been successfully contained and mitigated.

13. REPORTING
13.1. Incidents and handling actions must be internally tracked and reported to assist in improving Incident handling procedures and information security controls.
13.2. Additionally, there are situations requiring external reporting to entities such as Law Enforcement, in cases where criminal activity is suspected or determined.
13.3. Reporting also pertains to reports required by authorities (e.g. state data protection inspectorate, cyber security center) and persons whose information has been breached in accordance to relevant laws.
13.4. All Incidents along with their definition, investigation actions, mitigation actions and recovery actions should be reviewed at the end of the Incident with the intent to create and improve documented Incident response procedures. Output should also consider required improvements to policy, training, implemented controls or other relevant security planning.

14. COMPUTER EMERGENCY RESPONSE TEAM (CERT)
14.1. At any time, the Incident Handler may determine the Incident definition requires additional response resources to effectively mitigate and recover from the Incident and must escalate the request to the Computer Emergency Response Team Leader to form a Computer Emergency Response Team (CERT) to assist in Incident handling. The CERT will be comprised of all appropriate personnel required to effectively respond to and handle the defined Incident. Personnel may be added or removed from the CERT as required during the course of Incident handling by the CERT Leader. CERT members may also include third parties aiding in response activities. A CERT must be established along with formation of a Breach Notification Team when the Incident definition indicates a Breach.

15. INCIDENT TYPE HANDLING PROCEDURES
15.1. CTO must be notified as the CERT leader of any Incident definition when it reaches a Breach indicator.
15.2. The CERT leader must notify appropriate personnel on the Breach Communication Team of Incident definitions with a Breach indicator.
15.3. Notification of any mitigation actions that could impact the service availability of information systems which would have an impact to business operation processes must be made to the owner of the business operation and information.
15.4. File integrity monitoring for all system files and sensitive data locations, anti-malware systems will send alerts to [email protected] which will be investigated as suspected indicators of Compromise.

16. INVESTIGATION AND MITIGATION
16.1. Alerts from all sources will be investigated and coordinated to determine:
   16.1.1. Incident confidence levels:  Suspected, Confirmed or False;
   16.1.2. Incident impact severity levels:  Minor, Major or Severe;
   16.1.3. Whether a Breach of personal data has occurred;
   16.1.4. The scope of the Incident – to determine specific targets for detailed further investigation, such as forensic examination or personnel interviews;
   16.1.5. The possible sources of the Incident – to help determine the direction of mitigation.
16.2. Based on the findings of the investigation, mitigations will require the following:
   16.2.1. The specific targets that require remediation, for example:
      16.2.1.1. Physical controls around sensitive areas housing personnel, computing devices, physical or electronic data, or other valuable company assets. These may involve security systems, environmental controls, or the business procedures relating to them.
      16.2.1.2. Logical controls around operating systems, software platforms or applications that may require updates, repairs or replacement.
      16.2.1.3. Procedural controls related to all the above such as building access, application access, software change management, security awareness training, etc.
  16.2.2. The sources of the Incident. These may include:
      16.2.2.1. Burglars or other types of thieves;
      16.2.2.2. Known malicious websites or attack vectors such as vulnerable system ports, spam, or other methods of malware infection;
      16.2.2.3. Malicious or accidental actions by personnel.
16.3. In all cases immediate action must be taken to eliminate identified active threats to business operations.  These actions may include suspension of processing, physical or logical access, evacuation of staff, confiscation of computer equipment, disconnection of computer equipment from Company networks, or other actions necessary to ensure the safety of Company personnel, assets and business processes.
16.4. All activities in mitigation must be communicated to the CERT Team Leader and documented in the Incident report.

17. RECOVERY AND MONITORING
17.1 The Incident Handler, in coordination with the CERT team where necessary, will work to restore normal business operations from a failed state, and to restore business data or information systems from an untrusted to a trusted state. This may involve actions such as the following:
   17.1.1. Recovering data from local or offsite backups;
   17.1.2. Restoring or rebuilding workstations or servers from saved images;
   17.1.3. Installing security updates or patches;
   17.1.4. Re-installing application platforms or other types of software;
   17.1.5. Run anti-malware software on system to ensure they clean and can be reconnected to the Company’s network.
17.2. In addition, any affected systems (or personnel) may require heightened monitoring to ensure the completion of recovery efforts.

18. REPORTING
18.1. All Incident details will be reviewed annually during the Company at risk assessment to identify improvements to handling procedures or control requirements.
18.2. Response handling procedures will be updated within this document following each review process that results in requirements to update and improve content of this document.

19. MALWARE. DETECTION AND NOTIFICATION
19.1. Managed anti-virus infection reports and alerts will be reviewed daily by Incident Handlers for indicators of persistent Compromise such as large infection thresholds, recurring infections on the same machines and recurring infections on multiple machines.
19.2. Out of date definitions will be reviewed daily by Incident Handlers to ensure anti-virus software is working as effectively as possible.
19.3. Where possible additional alerting mechanisms for malware activity will be established for the following events and thresholds:
   19.3.1. System infected;
   19.3.2. Greater than 1% of systems experiencing infection within a 24-hour period;
   19.3.3. Greater than 1% of systems experiencing infection within a 72-hour period;
   19.3.4. Greater than 3% of managed systems experiencing infection within a 30-day period;
   19.3.5. Same infection on same machine within a 24-hour period;
   19.3.6. Same infection on same machine within a 7-day period;
   19.3.7. Same infection on same machine within a 30-day period;
   19.3.8. Same infection on multiple machines within a 72-hour period;
   19.3.9. Same infection on multiple machines within a 30-day period;
   19.3.10. Virus definitions out of date;
   19.3.11. Outbound connections to known command and control sites;
   19.3.12. Inbound connections from known command and control sites;
   19.3.13. Web access filters malicious executable content or malware sites;
   19.3.14. DNS queries to known malware domains and botnets;
   19.3.15. Malformed/Non-DNS traffic over DNS.

20. MALWARE. INVESTIGATION
20.1. Execute full anti-virus scans against information systems.
20.2. Execute a malware policy scan against all information systems. Create and include a custom md5 hash of discovered malware files if available. Review output for untrusted and never before seen processes to determine a trust level for processes executing on information systems.
20.3. Scan suspected malware executable and files with https://www.virustotal.com/ or similar multi-vendor signature checker.
20.4. Check outbound connections for the system and investigate IP address communications and DNS queries for any unknown host communication. Check IP’s being communicated with against known command and control and malware sites.
20.5. Infected files on file shares or shared storage locations should be reviewed for user owner and access properties to determine a source of infection.
20.6. Inspect file share connections and turn on access auditing for file shares as required to determine source and scope of potential infection.
20.7. Confirmed major malware Incident on the file server or other shared storage locations will result in the storage location being taken offline to prevent further spread or infection of crypto virus or other virus types until the infection has been resolved.

21. MALWARE. MITIGATION
21.1. Confirmed or suspected major malware Incidents on the Company’s workstations and laptops will result in the reinstallation and imaging of the Company workstations and laptops.

22. MALWARE. RECOVERY AND MONITORING
22.1. Malware events will be actively monitored for previously confirmed or suspected infected systems for a period of:
   22.1.1. Minor Incident: 7 days;
   22.1.2. Major Incident: 30 days;
   22.1.3. Severe Incident: 90 days.

23. MALWARE. REPORTING
23.1. Minor malware Incidents not involving the Compromise of personal data will be documented in the Company’s cyber security incident report (Appendix A.). Major and Severe malware events, or those involving the Breach of personal data, must also be reported to the CTO. As CERT Team leader, the CTO may convene the CERT team for more comprehensive Incident Response, as well as initiate Breach Handling procedures where necessary.

24. SOCIAL ENGINEERING
24.1. Detection and notification. CTO must be notified of social engineering attacks and is responsible for delegation of company-wide notification regarding social engineering attack details.
24.2. Suspected malicious email is to be forwarded by the Incident reporter as an attachment to email [email protected]
24.3. Investigation:
   24.3.1. Review email headers and email content in attached email;
   24.3.2. Review destinations of links and content present within the email;
   24.3.3. Scan suspected malicious attachments through VirusTotal.com or other resources;
   23.3.4. If interaction with infected content is suspected, review workstation for any unknown active processes and connections to external IP addresses, and treat as potential malware type response.
24.4. Mitigation:
   24.4.1. Company-wide notification will be made to all employees regarding details of the attempted social engineering attack;
   24.4.2. Suspected or confirmed account or malware Compromises should be treated by the appropriate Incident type;
   24.4.3. Awareness training and social engineering exercises to maintain awareness will be performed periodically against internal personnel.
24.5. Recovery and monitoring. This should follow requirements of the appropriate Incident type(s).
24.6. Reporting. In addition to the company-wide notification cited above, the Incident will be documented in the Company’s cyber security incident report (Appendix A.). Other reporting requirements should follow the requirements of the appropriate Incident type(s).

25. ACCESS ACCOUNT COMPROMISE. DETECTION AND NOTIFICATION
25.1. Notification by the Incident Handler must be made to employees whose accounts have been reset while mitigating the Incident. Notification should first be attempted but may be made after the account has been reset, such that notification does not impede the need to contain the Incident definition.
25.2. Event alerts will be created for the following events and Indicated thresholds and sent to email [email protected]  where they will be investigated as appropriate to the level of indicator of Compromise:
   25.2.1. Threshold for failed login attempts within a set time period;
   25.2.2. Login attempts to remotely accessible services from known malicious IP;
   25.2.3. Login attempts to remotely accessible services from foreign countries;
   25.2.4. Login attempts to remotely accessible services outside of normal business hours;
   25.2.5. Failed login attempts to internal information systems by invalid accounts;
   25.2.6. Failed login attempts to internal information systems by valid accounts;
   25.2.7. Successful and failed logins for administrative and privileged users;
   25.2.8. Successful and failed logins for all third-party service provider access accounts.
25.3. Investigation. Determine if any active source of Compromised connections made by suspected Compromised accounts by reviewing access to public facing and internal information systems.
25.4. Mitigation. An Incident Handler may revoke access to the network for suspected accounts. Any accounts affected by the Incident must have their passwords changed immediately by the Incident Handler.
25.5. Recovery and monitoring. Access to VPN and other available access logs will monitor and alert on failed or successful thresholds or suspicious access attempts made by suspected and confirmed Compromised accounts for a period of 30 days post Incident mitigation.
25.6. Reporting. In addition to the notification to individuals cited above, the Incident will be documented in the Company’s cyber security incident report (Appendix A.). Other reporting requirements should follow the requirements of the appropriate incident type(s).

26. LOST OR STOLEN DEVICE
26.1. Detection and notification. The IT department must be notified of any planned device upgrade or change.
26.2. Investigation. Incident handlers will assist personnel in attempting to locate the device through the appropriate mobile device utilities.
26.3. Physical surveillance cameras will be reviewed where possible for identification of perpetrators of physical theft from the Company locations.
26.4. If the device is believed to contain personal data, the CTO must be notified and, if necessary, Breach Handling procedures must be initiated.
26.5. Mitigation. If a device is suspected or confirmed to be lost or stolen and reasonable measure has been taken to locate the device, Incident Handlers will remote wipe the device and remove the device association from ActiveSync or other software.
26.6. Phones with the Company’s data must be factory defaulted before trade in.
26.7. Suspected and confirmed stolen devices are to have an appropriate police report filed with authorities.
26.8. Accounts associated to the device are to be treated as suspected account Compromise Incident type and response plans for the account(s) followed accordingly.
26.9. Recovery and monitoring. A list of ActiveSync or other software connected devices will be generated and reviewed by Incident Handlers periodically and inactive or multiple mobile devices beyond three devices will be disassociated from ActiveSync and other resources.
26.10. Reporting. The Incident will be documented in the Company’s cyber security incident report (Appendix A.)
26.11. If the device appears to have contained personal data, the CTO must initiate Breach Handling procedures, which have additional reporting requirements. In the case of a personal data Breach, the Company shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data Breach to the supervisory authority, unless the personal data Breach is unlikely to result in a risk to the rights and freedoms of natural persons. When the personal data Breach is likely to result in a high risk to the rights and freedoms of natural persons, the Company shall communicate the personal data Breach to the data subject without undue delay.

27. POLICY VIOLATION
27.1. Detection and notification. As with all Incidents, any user of the Company’s systems should report suspicion or discovery of the Policy violation to their manager, the IT department, or HR. Ultimately, the Policy violations, if confirmed, are disciplinary issues that should involve HR.
27.2. Investigation. The investigation will still involve the assignment of an IT Incident Handler. If the matter involves HR, then the Incident Handler will work with the department to perform a forensic investigation to help gather evidence to confirm the Incident, and aid in the determination of appropriate disciplinary action.  It is likely creation of a forensic image of the suspected violators hard drive will need to be created to ensure no actual files on the hard drive are modified during the investigation. Each step of the forensic investigation must be carefully documented to properly support any disciplinary proceeding that may arise from the investigation results.
27.3. Mitigation. If there is suspicion or confirmation of a malware infection on the device or devices involved (e.g. due to an acceptable use violation,) then the related devices must be removed from the network until the investigation is concluded. At that time, the normal mitigation steps for a malware infection Incident type should be followed before the device(s) returns to use. Accounts associated to the device are to be treated as suspected account Compromise Incident type and response plans for the account(s) followed accordingly.
27.4. Recovery and monitoring. Depending on the outcome of the investigation, HR may require close monitoring of the computer activity of the individual(s) involved.
27.5. Reporting. The Incident report for this type of investigation must very thoroughly document all the steps taken. This report must be delivered to HR, and their procedures will govern the confidentiality of the information, and any further distribution of the report.

28. VIOLATIONS AND SANCTIONS
28.1. The CTO will administer this Policy, including the review of reported violations and the recommendation of appropriate actions.
28.2. Violation of the Policy could result in disciplinary actions up to and including termination with legal prosecution.

29. DOCUMENT CONTROL
29.1. Version history:

Version	Date
1.0	[01-08-2022]

 

APPENDIX A: SECURITY INCIDENT REPORT FORM

SECURITY INCIDENT REPORT

Date:

Time:

Reported by:

Description:

Suspected  ☐                                                  Confirmed  ☐                                                 False  ☐

Minor  ☐                                                           Major  ☐                                                         Severe  ☐

Breach Indicator:

Incident Handler(s):

CERT Convened:              Yes ☐        No ☐

CERT Members:

INCIDENT RESPONSE

Investigation:

Mitigation:

Recovery and Monitoring:

Reporting: