香港中小企 IT 事故應變第一小時:當機、勒索軟件疑似感染、資料外洩懷疑,頭 60 分鐘做咩同唔做咩
分類:網絡安全 | 日期:2026-10-24
一、引言:為何頭一小時最關鍵
對一間香港中小企嚟講,IT 事故最危險的時刻,往往唔係事故本身,而係發現事故之後的第一個鐘。呢個鐘入面,負責同事通常又驚又趕:想快啲令系統返工、想快啲畀客戶一個交代、想快啲「清一清先算」。但頭一個動作做錯,後果可能好難補救:重裝系統可以毀掉調查同還原所需的紀錄;喺受感染電腦上繼續操作可以令感染擴散;向外講一句未核實的結論,之後要花更多時間收回。
本文講三種情況:系統或者服務突然用唔到(當機)、疑似勒索軟件感染、疑似資料外洩。以下例子只用通用情境,例如一間十人公司早上返工發現共用磁碟檔案打唔開,唔涉及任何真實公司名、人名、日期或金額。本文只屬一般資訊,唔係法律意見;涉及法律判斷或者通報決定的部分,應諮詢專業意見。
先講明兩個研究限制。第一,沒有任何一個已核實來源訂明一套放諸四海皆準的「頭 60 分鐘」固定順序;本文的 60 分鐘框架,屬於按各來源步驟整理的通用做法,不可歸因於 HKCERT、香港政府資訊保安網站或者私隱專員公署。第二,私隱專員公署資料外洩指引原文在本批研究中未能直接開啟核實,本文有關公署指引的內容只寫律師行及法律資訊摘要層面,並加限定語,唔寫成已核實的公署原文逐字引文,亦唔編造條文號碼或者罰則數字。同樣,HKCERT 中小企事故應變指引 PDF 全文亦未經本批研究直接開啟核實,本文只寫 HKCERT 新聞稿層面的目的同涵蓋範圍。
點解要特別講頭一小時?香港政府資訊保安網站講公司事故處理時用六步模型:準備、偵測及識別、圍堵、清除、還原、事後;該頁強調,成功的關鍵係事前準備,事前規劃可確保應變程序為人所知、協調一致、有系統地執行(香港政府資訊保安網站〈Security Incident Handling for Companies〉)。頭一小時做嘅事,大部分屬於六步模型入面的偵測及識別同圍堵:分清楚係邊一類事故、停一停擴散、記低時間線、通知啱嘅人。清除同還原係之後的步驟,唔應該喺未分清楚之前就急住做。
HKCERT 在 2022 年 8 月 8 日公布《Incident Response Guideline for SMEs》,目的係幫資源有限的中小企維持及提升系統防禦、減低事故造成的業務及財務影響、防止同類攻擊再次發生;指引內容包括事故應變生命週期、事前、事中同事後要做的事、制定組織保安框架、界定角色與責任、常見事故情境的關鍵處理步驟、按情境制定的標準作業程序、事故處理檢查清單及應變程序範本;非技術讀者亦容易理解(HKCERT 新聞稿〈HKCERT Publishes Incident Response Guideline for SMEs〉)。本文的結構,正係跟住呢個方向:先分清楚類別,再講每類的做法,最後講事後跟進同簽約前問題。
二、共通頭 10 分鐘:先分清楚係邊一類,再停擴散、記時間線
不論係邊一種事故,頭 10 分鐘的共通做法都係同一套:停一停,先判斷,再行動。以下整理自香港政府資訊保安網站個人及公司事故處理步驟的通用方向,屬於通用做法整理,唔係某一機構訂明的頭 10 分鐘固定順序。
第一,先判斷係邊一類。純當機,係系統用唔到、無勒索訊息、無可疑外洩跡象;疑似勒索軟件,係檔案打唔開、副檔名變晒、出現勒索訊息、防毒被停用;疑似資料外洩,係收到可疑通知、發現資料被不當查閱或者傳送、帳戶出現異常登入。分錯類,之後每一步都可能做錯。舉一個通用情境:一間十人公司早上返工發現共用磁碟檔案打唔開,負責同事第一句應該問的唔係「邊個整壞咗」,而係「有無勒索訊息、有無副檔名變晒、有無人收到可疑通知」——答案唔同,去向完全唔同。
第二,指定一個負責人做單一聯絡點,其他人唔好各自對外講不同版本;用電話等網外渠道聯絡,唔好只靠可能已經受影響的內部即時通訊或者電郵。呢個方向來自公司事故處理步驟的原則:用聯絡清單通知管理層及其他合適人士,執行「按需知情」原則,必要時用安全的網外通訊渠道(香港政府資訊保安網站〈Security Incident Handling for Companies〉)。個人事故處理步驟亦有同一方向:用其他通訊渠道求助,例如打電話,唔好用互聯網,因為可能再次散播惡意軟件(香港政府資訊保安網站〈Security Incident Handling for Individuals〉)。
第三,即時開一張時間線紀錄:幾點幾分邊個發現、見到乜嘢畫面或者訊息、邊部機或者邊個系統、邊啲檔案或者服務受影響、之前做過乜嘢操作。之後每一個動作都記低時間同負責人。個人事故處理步驟要求清楚記低事件,包括日期、時間、實際發生了什麼、涉及什麼人等(香港政府資訊保安網站〈Security Incident Handling for Individuals〉);公司步驟亦要求用標準事故紀錄表格開始記錄,並擷取事故紀錄(香港政府資訊保安網站〈Security Incident Handling for Companies〉)。時間線唔係文書工作,而係之後調查、報告同向專業人士求助的基礎。
第四,通知管理層及內部合適人士,按公司既定的聯絡清單,只通知需要知的人,唔好喺公司大群組公開未核實的猜測。準備階段本身就包括界定事故應變小組及其他參與人員的角色與責任、制定報告程序、升級程序及事故應變程序並傳達給全體員工,以及制定及維持聯絡清單(香港政府資訊保安網站〈Security Incident Handling for Companies〉)。如果公司平時根本無聯絡清單、無負責人、無報告程序,呢個就係事後要補的第一課,見第七節。
頭 10 分鐘有幾樣嘢絕對唔做,詳見第六節共通誤區,呢度先講最關鍵的兩樣:唔好一發現問題就即刻重裝系統、格式化、刪除檔案或者「清一清先算」;唔好用受影響的電腦繼續寄電郵、打文件或者登入其他系統。個人事故處理步驟明言:保持冷靜,立即切斷電腦與互聯網的連接,停止在該機器上繼續工作(香港政府資訊保安網站〈Security Incident Handling for Individuals〉)。
三、情境一:當機——系統或者服務突然用唔到,未見勒索或者外洩跡象
當機係三種情境入面最常見、亦最容易被誤判的一種。已核實來源提供的是通用事故處理六步模型及個人事故處理步驟,並無針對伺服器或者系統當機首小時的專用官方清單;本節屬於通用步驟的情境應用,必須標明是通用做法整理。
10 至 60 分鐘的做法,可以按以下次序做。第一,界定影響範圍:邊個系統停、邊個部門或者服務受影響、係單一部機、成個辦公室網絡、定係雲端服務;記低停機開始時間。公司偵測及識別階段本身就要求判斷問題類型及影響範圍(香港政府資訊保安網站〈Security Incident Handling for Companies〉)。第二,檢查最基本的分層:電源、網絡連接、服務供應商狀態、最近有無變更,包括更新、設定改動、新裝置接入。先排除最簡單的原因,再決定係咪需要深入排查;每改一個設定都要記低改前改後,唔好逐部機逐個設定亂試。
第三,按既定優先次序處理:最關鍵或者服務最多人的服務先恢復,其他服務分階段恢復;恢復前通知相關人士,恢復後核實系統回復正常運作。呢個方向來自還原階段的要求:按需求次序、分階段、有控制地恢復功能或者服務,核實還原操作成功、系統回復正常運作,並事先通知全部相關人士恢復運作(香港政府資訊保安網站〈Security Incident Handling for Companies〉)。未核實恢復成功的系統,不可當作已經正常,唔好為求快而跳過核實步驟就宣布「修好晒」。
第四,檢查備份狀態,但唔好即刻用未確認乾淨的備份覆蓋現有資料。先確認備份時間點、備份是否離線及安全、還原會唔會覆蓋未受影響的較新資料。清除階段的要求亦提醒:確保備份本身乾淨,防止還原時再次感染(香港政府資訊保安網站〈Security Incident Handling for Companies〉)。第五,保留紀錄:停機時間、影響範圍、採取過的步驟、恢復時間,供事後檢討用。
當機有兩個判斷要特別小心。第一,唔好假設當機一定係攻擊,亦唔好假設一定唔係攻擊。未查清楚之前,兩種假設都唔好寫成結論;如過程中發現勒索訊息或者可疑活動,即刻轉去第四節的做法。第二,唔好將當機寫成任何服務級別承諾的違反或者符合——本站定價頁並無公佈當機處理時限,本文亦唔寫任何時限承諾,見第八節。
四、情境二:勒索軟件疑似感染——先隔離,再評估有無資料被盜走
疑似勒索軟件感染的頭一小時,核心只有兩個字:隔離同評估。隔離係阻止加密擴散;評估係搞清楚除咗檔案被鎖之外,有無資料被盜走。好多人只睇前者,漏咗後者,就係最危險的誤判。
即刻隔離方面,HKCERT 加密勒索軟件感染的處理指出:立即隔離並切斷受感染機器的連接,避免惡意軟件造成進一步影響;之後做全面掃描清除惡意軟件;如有備份,用備份還原檔案及資料;如之前完全無備份,建議不要還原系統,以免遺失解密所需的資料(HKCERT〈Beware of Crypto Ransomware〉)。香港政府資訊保安網站的勒索軟件即時應變步驟亦指出:切斷受感染裝置的網絡連接,並對有關裝置做全面掃描,核實有無安裝惡意軟件;切斷電源並隔離與受感染電腦共用同一網絡、但未被勒索軟件完全加密的電腦或者裝置;仔細檢查,確保備份資料處於離線及安全狀態;記低事故詳情,包括日期、時間、受影響檔案或者裝置、感染源頭等,以便準備事故報告及向專業人士求助;立即向合適人士,例如 IT 管理員,報告以作調查及清理(香港政府資訊保安網站〈InfoSec: Ransomware〉)。
停用受感染裝置上的進一步操作之後,要記低勒索訊息的完整內容,包括出現時間、訊息原文、聯絡方式、要求的付款方式,但唔好按訊息指示即刻付款或者聯絡攻擊者。將已加密檔案複製到空白儲存裝置作保留;檢查備份資料是否處於離線及安全狀態,確認備份時間點及版本紀錄,但唔好即刻將備份還原到未清理乾淨的裝置。HKCERT 另一篇文章亦指出:受感染後先將受感染電腦離線,避免惡意軟件進一步影響內聯網檔案;將已加密檔案複製到空白儲存裝置;用乾淨電腦下載合法解密工具解密,不可從不可信來源下載可疑解密器;如感染前已備份系統或者資料,可用備份還原;並參考 HKCERT 編製的《Ransomware Decryption Guideline》及聯絡 HKCERT 查詢或者求助;HKCERT 明確表示不保證解密工具有效還原檔案(HKCERT〈Ransomware Evolved: Double Extortion and Fake Decryptor〉)。解密工具的成功率、個別工具的現行支援狀況及操作步驟,在本批研究中未經核實,本文唔推薦個別工具,亦唔寫成功率。
點解一定要同時評估資料外洩可能?因為雙重勒索的攻擊者會先抽取大量敏感資料再加密受害者資料庫;如受害者不理會,攻擊者會威脅在網上公開被盜資料,或者拍賣資料;部分攻擊者亦會威脅聯絡受害者的客戶及合作夥伴,或者發動阻斷服務攻擊施壓。因此勒索軟件事故不只係「檔案被鎖」,必須同時評估資料有無被盜走或者外洩的可能(HKCERT〈Ransomware Evolved: Double Extortion and Fake Decryptor〉及香港政府資訊保安網站〈InfoSec: Ransomware〉)。換言之,勒索軟件疑似感染一出現,就要同時啟動第五節的評估步驟,唔好等到檔案還原完先至諗外洩。
付贖金的問題,必須寫清楚,而且唔可以寫成兩種絕對說法。香港政府資訊保安網站明言,付贖金無保證可以成功取回加密資料、被盜資料會按承諾銷毀、受感染系統會解鎖、未來攻擊會消除(香港政府資訊保安網站〈InfoSec: Ransomware〉)。HKCERT 亦表示,未曾收到付贖金並從攻擊者取得解密金鑰後成功還原資料的報告;而且即使付贖金,控制伺服器可能已被取締,解密金鑰未必取得得到;付贖金亦等於資助攻擊者開發更多勒索軟件攻擊(HKCERT〈Beware of Crypto Ransomware〉)。正確寫法係「不建議付贖金」,因為無上述保證;付贖金的決定涉及法律及執法考慮,唔可以寫成「付咗就一定攞唔返」或者「付咗就一定攞得返」。
報告途徑方面,向內部 IT 管理員及管理層報告之後,按需要向 HKCERT 報告:資訊保安事故可經 HKCERT 網上事故報告表格報告;其他查詢可電郵 hkcert@hkcert.org 或者致電熱線 8105 6060(HKCERT 新聞稿〈HKCERT Publishes Incident Response Guideline for SMEs〉)。HKCERT 網上事故報告表格的具體欄位、處理時間及回覆承諾,在本批研究中未經核實,本文唔寫任何處理時間承諾。如涉及刑事成分,緊急個案可致電 999 或者到最近的警署(香港政府資訊保安網站〈InfoSec: Miscellaneous〉)。本文只寫途徑,唔寫保證回應時間。
五、情境三:資料外洩懷疑個案——收集、圍堵、評估、考慮通報、記錄
資料外洩懷疑個案最難的地方,係「懷疑」兩個字。未確定係咪真係外洩之前,已經要即刻按內部程序上報,唔好等「證實晒先講」;但對外講法,又必須以已核實的事實為限,唔好在評估未完成之前就講「無風險」或者「資料無外洩」。呢個張力,正係本節五步的用意。
以下五步,來自私隱專員公署 2023 年 6 月 30 日發出的經修訂《Guidance on Data Breach Handling and Data Breach Notifications》的律師行及法律資訊摘要,只寫摘要層面,唔係公署原文逐字引文:第一,即時收集關鍵資料;第二,圍堵外洩;第三,評估對受影響人士造成傷害的風險;第四,考慮發出外洩通報;第五,記錄外洩事故。指引亦建議機構制定書面的資料外洩應變計劃(Sidley、CMS Law Now 及 Boase Cohen & Collins 對公署指引的摘要)。
第一步,收集關鍵資料:點樣發現、邊啲系統或者帳戶涉及、邊類個人資料可能涉及、大約涉及幾多人、資料可能經邊個途徑被不當查閱或者傳送、外洩可能由邊個源頭引起,例如可疑登入、錯寄電郵、裝置遺失、系統設定錯誤。第二步,圍堵:按情況切斷不當查閱的途徑,例如停用可疑帳戶或者存取權、收回不當分享的連結或者權限、隔離受影響系統,並防止同一途徑再次發生;圍堵時同樣要記低每個動作的時間同負責人。圍堵階段的通用方向亦包括:評估事故對系統資料及資訊的影響,確認有關資料有無已經損壞或者受感染;保護敏感或者關鍵資料及系統,例如將關鍵資料移到與受影響系統或者網絡分隔的其他媒體或者系統(香港政府資訊保安網站〈Security Incident Handling for Companies〉)。
第三步,初步評估傷害風險:資料敏感程度,例如身份證資料、財務資料、健康資料等敏感程度較高的資料,風險較高;受影響人數;資料有無可能被進一步傳播或者公開;受影響人士可能面對的風險,例如身份盜用、財務損失、名譽損害等摘要列出的風險類別。第四步,考慮通報:按公署指引摘要,資料使用者應在切實可行的情況下盡快考慮通知公署及受影響資料當事人,特別是當外洩可能造成真實傷害風險時,而且不應因為內部調查未完成而拖延考慮通報;同時考慮有無需要通知執法機關或者其他相關監管機構,視行業及事故性質而定,應諮詢專業意見(Sidley、FTI 及 Dataprotectionreport 對公署指引的摘要)。
第五步,完整記錄:由發現、圍堵、評估到通報考慮的每一步都要記錄在案,供事後檢討及向管理層匯報用。摘要層面的通報內容要素包括:外洩的日期、時間、持續期間及來源;涉及的個人資料種類;受影響資料當事人的類別及約數;傷害風險評估;已採取的緩解措施(HK Lawyer 及 ONC Lawyers 對公署指引的摘要)。通報方式方面,摘要指出建議使用公署的資料外洩通報表格;公署在 2023 年 6 月推出電子資料外洩通報表格,設引導問題及多項選擇答案;摘要指出,口頭通報不獲接受。受影響人士可直接以電話、書面、電郵或者親身方式通知;如直接通知在實際情況下不可行,公開公布、報章廣告或者在網站或者社交媒體公布可能更有效(HK Lawyer 及 ONC Lawyers 對公署指引的摘要)。
呢一節有三個香港制度的關鍵澄清,寫錯任何一點都會誤導讀者。第一,香港現行《個人資料(私隱)條例》下,資料外洩通報並非法定強制要求,屬於自願通報制度;與歐盟 GDPR 的強制通報制度不同。公署指引本身不具法律約束力,但公署在調查或者投訴時會檢視機構有無符合條例要求(Recording Law、Linklaters 及 FTI 對香港資料私隱法例的摘要)。第二,歐盟 GDPR 的 72 小時通報規定是歐盟法例,不是香港法例,絕不可寫成香港要求;香港現行指引的用語是「在切實可行的情況下盡快」,沒有訂明以小時計算的固定法定期限。第三,曾經有建議提出強制通報要在知悉後「在切實可行的情況下盡快」並在任何情況下於五個工作天內完成,但該建議屬於修例建議層面,摘要指出相關修例建議似乎已被擱置,現行法例下並無此強制時限——本文只寫「曾有建議提出五個工作天」並標明是建議、非現行法例,絕不可將五個工作天寫成現行香港法例要求(JD Supra、Linklaters 及立法會研究文件對強制通報修例建議的摘要)。修例建議的現況及生效日期在本批研究中未經核實,本文唔寫修例已生效、將於某日生效或者已被正式撤回等結論。
第四個澄清同樣重要:自願通報唔等於無責任。保障資料第 4 原則要求資料使用者採取所有切實可行的步驟,保護所持有的個人資料免受未經授權或者意外的查閱、處理、刪除、遺失或者使用,並要考慮資料性質、發生事故時的潛在傷害等因素;換言之,即使通報本身屬自願,保安措施不足本身仍可能構成條例下的問題,本文不可寫成「自願通報等於無責任」(Dataprotectionreport 及 Mondaq/Hill Dickinson 香港比較指南摘要)。個別公司的通報義務判斷,例如某公司是否同時受其他司法管轄區法例、行業監管要求或者合約通報條款約束,在本批研究中沒有核實,本文唔一概而論,必須寫明諮詢專業意見。
最後,報案及求助途徑要分清楚用途,唔好寫成一條熱線包晒所有事故。緊急個案:致電 999 或者到最近的警署(香港政府資訊保安網站〈InfoSec: Miscellaneous〉)。電腦緊急事故:HKCERT 負責處理保安事故報告、協調應變及復原行動、協助監察及發布保安相關資訊、就防範保安威脅提供建議;熱線 8105 6060(香港政府資訊保安網站〈InfoSec: Miscellaneous〉)。防騙求助:反詐騙協調中心防騙熱線 18222;注意適用範圍:該熱線針對詐騙或者騙案求助,不可寫成所有 IT 事故的通用報案熱線(香港政府資訊保安網站〈InfoSec: Miscellaneous〉)。個人資料私隱查詢:私隱專員公署電話 2827 2827,辦公時間內;注意:此為該頁列出的一般查詢電話,不等於資料外洩通報表格或者通報程序本身(香港政府資訊保安網站〈InfoSec: Miscellaneous〉)。本文只寫途徑,唔寫保證回應時間。香港警方科技罪案網上報案表格的具體流程及所需文件,在本批研究中未經核實,本文唔寫報案表格細節。
六、唔應該做的事:共通誤區
三種情境有各自的誤區,但以下幾樣係共通的,邊一類事故都適用。第一,唔好一發現問題就即刻重裝系統、格式化、刪除檔案或者「清一清先算」。公司圍堵階段本身就要求為調查及後續跟進製備受影響系統的映像作證據,並記錄圍堵階段採取的全部行動(香港政府資訊保安網站〈Security Incident Handling for Companies〉)。個人事故處理步驟亦要求盡可能收集事故紀錄,並在確認係真實事故之後,盡快為受影響電腦或者系統做完整備份並存放在安全地方(香港政府資訊保安網站〈Security Incident Handling for Individuals〉)。清走證據,先至諗起要調查,就已經太遲。
第二,唔好在未分清楚類別之前,就向客戶或者外間講「只係小問題」或者「資料已經外洩」一類未核實的結論;亦唔好向外間講「已經無事」或者「資料無外洩」,直至完成外洩評估。對外說法要由負責人統一,並以已核實的事實為限。第三,唔好由多個人同時在受影響系統上「試下修」,互相覆蓋操作紀錄;每一個動作都要記低時間同負責人。第四,唔好用受影響的電腦繼續寄電郵、打文件或者登入其他系統;唔好在未隔離之前就將 USB 手指、外置硬碟接駁到受感染電腦,或者將受感染電腦的檔案抄去其他電腦,因為可能將感染擴散。
第五,勒索軟件情境特有的誤區:唔好付贖金,理由見第四節;唔好在受感染電腦上直接下載解密工具或者繼續上網,要用乾淨電腦處理;唔好在無備份的情況下急住還原或者重裝系統,因為可能遺失解密所需的資料;唔好刪除勒索訊息、紀錄或者已加密檔案的原樣,呢啲可能係調查及解密所需的資料。第六,資料外洩情境特有的誤區:唔好隱瞞或者拖延內部上報;唔好為求「快啲了事」而刪除紀錄、清除登入紀錄或者改動系統設定來掩蓋痕跡;唔好在通報表格或者對外通知中寫入未經核實的數字,例如受影響人數、涉及資料種類,估算必須標明係估算,並在有更新時更正;唔好假設「通知咗公署就等於合規」或者「唔通知就一定無責任」。
第七,唔好將通用做法寫成法定義務,亦唔好將法定義務寫成通用做法。本文的 60 分鐘框架係通用做法整理,唔係法例;香港資料外洩通報現行制度屬自願,但保安措施要求獨立存在,兩者要分開理解。第八,唔好寫任何絕對承諾,例如話還原一定成功、資料一定救得返一類說法。備份還原的成功保證、還原所需時間及還原測試的具體安排,視備份是否乾淨、是否離線、時間點及系統狀況而定,本批研究沒有核實任何具體保證或者時間,本文唔寫保證或者時間承諾。
七、事後 24 小時跟進要點:清除、還原、檢討,回到準備
頭 60 分鐘之後,按公司六步模型,依次係徹底清除、分階段還原、事後檢討,最後回到準備階段,形成持續改善循環。以下只作方向,唔屬頭 60 分鐘清單本身。
清除階段包括:停止或者終止攻擊者的全部活躍程序;刪除攻擊者建立的假檔案,刪除前可能需要先存檔以協助調查;清除攻擊者安裝的全部後門及惡意程式;為全部作業系統、伺服器及網絡裝置的漏洞打補丁並在還原前徹底測試;修正系統及網絡的不當設定;按防毒軟件供應商建議為全部受感染系統及媒體清除惡意軟件;確保備份本身乾淨,防止還原時再次感染;更新可能已被攻擊者存取的全部登入帳戶密碼;如未能確定關鍵系統的損壞範圍,或者難以徹底清理系統,支援人員可能需要格式化全部受感染媒體並從備份重新安裝系統及資料(香港政府資訊保安網站〈Security Incident Handling for Companies〉)。個人事故處理的清除與還原方向亦包括:清除攻擊者安裝的後門及惡意程式、為作業系統或者軟件漏洞打補丁、修正不當設定、更新密碼;用受信任來源重新安裝被刪除或者損壞的檔案,並用事故前已確認乾淨及更新的備份還原;之後核實還原操作成功、電腦回復正常運作;再加強現有保護,例如更新防毒定義、安裝個人防火牆、刪除不想要的電郵(香港政府資訊保安網站〈Security Incident Handling for Individuals〉)。
還原階段包括:做損害評估;按需要用受信任來源重新安裝被刪除或者損壞的檔案或者整個系統;按需求次序、分階段、有控制地恢復功能或者服務;核實還原操作成功、系統回復正常運作;事先通知全部相關人士恢復運作;停用不必要的服務;記錄採取的全部行動(香港政府資訊保安網站〈Security Incident Handling for Companies〉)。勒索軟件還原方面,資訊保安網站指出:用乾淨電腦下載合法解密工具解密檔案,如適用,不可從不可信來源下載可疑解密器;將資料從備份還原到乾淨的運算裝置。機構預防方面亦包括:啟用多重認證及登入通知、最小權限、將備份資料分開存放,包括線上及離線,防止被勒索軟件加密的檔案覆蓋、制定並執行事故應變、備份運作及災難復原計劃、定期檢視系統紀錄找出異常活動(香港政府資訊保安網站〈InfoSec: Ransomware〉)。
事後階段要盡快開始,管理層、用戶及現場事故應變小組都要參與;做事後檢討,找出改善地方,例如現有設定及程序是否足夠、是否需要更多用戶教育、是否需要外部保安審計、是否需要採取法律行動;邀請全部參與者對檢討草稿發表意見;向管理層提交附改善建議的行政摘要;管理層評估報告並選定要執行的改善建議;之後回到準備階段,形成持續改善循環(香港政府資訊保安網站〈Security Incident Handling for Companies〉)。事後 24 小時內值得對照檢查的準備清單包括:公司有無既定的事故應變程序、角色與責任、聯絡清單、優先資產及可接受停機時間、備份策略及備份是否離線、監察及紀錄機制、員工是否知道緊急程序及報告聯絡人。以上全部只屬簽約前要問的問題,唔代表本站提供相關服務,見第九節。
一個補充背景方向,不帶數字:勒索軟件並非罕見概念,香港警方報告亦有相關分類。香港警方《Cybersecurity Report 2024》的具體數字在本批研究中只見搜尋結果摘要,未直接開啟原文核實,本文因此唔引用該組數字,只寫方向句(只見搜尋結果摘要,未直接開啟原文核實)。香港中小企事故發生率、勒索軟件個案數字、資料外洩個案數字及行業統計,除上述摘要外,本批研究沒有核實任何香港本地統計,本文一律唔寫具體個案數字及比例。
八、定價頁分界:本文做法唔係任何一級已包服務
呢節必須先講清楚,否則好容易把通用做法誤當成已包服務。以下六級價錢及原文形式,根據 2026-10-24 定價頁可見正文核實:
- 基礎遙距版 HK$600 — 包正版 Office 365 商業授權、送企業級 Router 連安裝、無限次遙距支援(週一至五 9am-6pm)
- 專業進階版 HK$1,200 — 基礎版全部功能+緊急事故優先響應、新員工電腦入職設置、數據備份建議及設定、單一聯絡窗口(週一至六 9am-6pm)
- 企業設備版 HK$2,200 — 專業進階版全部功能+包商務電腦設備、硬件全保養(壞機即換)、每 3 年免費升級換機
- 全方位無憂版 HK$2,950 — 企業設備版全部功能+包多功能商務打印機及維修保養
- 設計專用版 HK$4,950 — 全方位無憂版全部功能+包 AutoCAD 正版授權及 Adobe Creative Cloud 全套
- 旗艦網頁版 HK$5,950 — 設計專用版全部功能+包企業網站設計及開發、網站維護及伺服器託管
定價頁可見正文關鍵詞核查結果(2026-10-24 可見正文):「事故應變」0 命中、「勒索」0 命中、「外洩」0 命中、「事故」唯一命中是 HK$1,200 級「緊急事故優先響應」原句,屬於級別功能原句,唔係已定義的事故應變服務範圍,不可擴寫成勒索軟件清理、鑑證調查、資料外洩通報代辦或者還原測試等服務。還原測試方面,HK$1,200 級只包建議+設定,還原測試唔包。
所以,本文第二至第七節的全部做法,包括共通頭 10 分鐘、三種情境做法、共通誤區、事後跟進要點,全部只屬通用做法,絕不是任何一級已包的服務說明。本站並無公佈事故應變服務;讀者如果想知道某一級包唔包,必須用下一節的問題,向任何供應商取得書面確認。核查範圍限制:本次核查只針對定價頁一頁,沒有全面爬取本站所有頁面及文章;因此結論只限於「定價頁沒有公佈事故應變服務」,不能引申為全站結論。
九、簽約前要問的問題:向任何供應商問,唔好只信口頭承諾
以下問題全部只作問題,教讀者問任何供應商,絕不寫成 itsupportking 自己的服務範圍或者不包括事項清單。凡定價頁無寫的項目,均標明未證實、需用戶確認,並須以書面確認為準。查詢時要求對方以電郵或者服務協議書面確認,唔好只信口頭承諾:
- 公司現時有無既定的事故應變程序、負責人及聯絡清單?聯絡清單幾耐更新一次?定價頁無寫事故應變程序內容,未證實、需用戶確認,須以書面確認為準。
- 事故發生時,隔離、調查、清理及還原的分工係點?邊啲已包、邊啲另行收費、邊啲唔提供?定價頁「事故」唯一命中只係「緊急事故優先響應」原句,未證實、需用戶確認,須以書面確認為準。
- 備份策略係點?備份是否離線存放、有無版本歷史、還原用邊個時間點、還原前點樣確認備份乾淨?定價頁 HK$1,200 級只寫數據備份建議及設定,未證實、需用戶確認,須以書面確認為準。
- 還原測試如何安排?由邊個負責做、幾耐做一次、紀錄點保存?還原測試唔包在 HK$1,200 級的建議+設定入面,未證實、需用戶確認,須以書面確認為準。
- 勒索軟件疑似感染時,隔離、調查、清理及還原的分工係點?定價頁「勒索」0 命中,未證實、需用戶確認,須以書面確認為準。
- 資料外洩懷疑個案的評估及通報支援係點?邊個負責評估傷害風險、邊個負責草擬通報內容、通報決定由邊個拍板?定價頁「外洩」0 命中,未證實、需用戶確認,須以書面確認為準。
- 事故紀錄及證據保存如何安排?紀錄保存幾耐、由邊個保管?定價頁無寫,未證實、需用戶確認,須以書面確認為準。
- 監察及紀錄機制是否包括在內?系統及網絡審計紀錄保存幾耐?定價頁無寫,未證實、需用戶確認,須以書面確認為準。
- 服務終止或者換供應商時,事故紀錄、備份及系統設定如何交接?定價頁無寫,未證實、需用戶確認,須以書面確認為準。
- 優先資產及可接受停機時間點樣訂?最關鍵或者服務最多人的服務係邊啲?定價頁無寫,未證實、需用戶確認,須以書面確認為準。
- 員工是否知道緊急程序及報告聯絡人?報告程序、升級程序及事故應變程序有無傳達給全體員工,包括管理層?定價頁無寫,未證實、需用戶確認,須以書面確認為準。
- 資料外洩通報決定點樣處理?會唔會提醒客戶,香港現行制度下通報屬自願、指引用語係「在切實可行的情況下盡快」,而且保安措施要求獨立存在?通報決定應諮詢專業意見,定價頁無寫,未證實、需用戶確認,須以書面確認為準。
問問題的意義,唔係為咗問得多,而係為咗事後有據可查:邊個做、做到邊個程度、做完有咩紀錄、做唔到點跟進。凡是定價頁無寫明的事故應變、勒索軟件清理、鑑證調查、資料外洩通報代辦及還原測試安排,喺未有書面確認之前,都應視為未證實、需用戶確認,唔好假設已經包喺月費入面。
十、結語:先分清楚類別,再按步驟做,再留紀錄問清楚
頭一小時的重點,可以收成三句:先分清楚係當機、疑似勒索軟件,定係疑似資料外洩,因為分錯類之後每一步都可能做錯;再按步驟做——停擴散、記時間線、指定負責人、按既定聯絡清單通知啱嘅人,唔好急住重裝、刪除或者對外講未核實的結論;最後留紀錄、做事後檢討,回到準備階段,補返平時無聯絡清單、無負責人、無備份檢查的缺口。
對香港中小企嚟講,最穩妥的次序係:先對照本文第二至第七節做一次現況檢查,再用第九節的問題,向任何供應商取得書面確認,確認邊啲包、邊啲另行收費、邊啲由公司自己負責。凡是定價頁無寫明的事故應變安排,喺未有書面確認之前,都應視為未證實、需用戶確認。
免責聲明:本文只屬一般資訊,供香港中小企參考通用做法,唔係法律意見。涉及個人資料做法、通報決定或者刑事成分的具體安排,應以私隱專員公署指引、執法機關及專業意見為準。先分清楚、再按步驟做、再留紀錄問清楚。
十一、來源清單
- HKCERT 新聞稿〈HKCERT Publishes Incident Response Guideline for SMEs〉(頁面標示 2022-08-08) — https://www.hkcert.org/blog/hkcert-publishes-incident-response-guideline-for-smes-to-enhance-information-security-incident-handling-competence
- HKCERT 新聞稿〈HKCERT Publishes Incident Response Guideline for SMEs〉,事故報告途徑(網上表格、電郵 hkcert@hkcert.org、熱線 8105 6060)
- HKCERT〈Beware of Crypto Ransomware〉(頁面標示 2015-05-04) — https://www.hkcert.org/blog/beware-of-crypto-ransomware
- HKCERT〈Ransomware Evolved: Double Extortion and Fake Decryptor〉(頁面標示 2020-07-13) — https://www.hkcert.org/blog/ransomware-evolved-double-extortion-and-fake-decryptor
- HKCERT〈Ransomware Evolved: Double Extortion and Fake Decryptor〉,及香港政府資訊保安網站〈InfoSec: Ransomware〉,雙重勒索定義 — https://www.infosec.gov.hk/en/knowledge-centre/ransomware
- 香港政府資訊保安網站〈InfoSec: Ransomware〉「Response to ransomware attack」一節,付贖金無保證
- HKCERT〈Beware of Crypto Ransomware〉FAQ 2,未曾收到付贖金後成功還原報告
- 香港政府資訊保安網站〈Security Incident Handling for Individuals〉 — https://www.infosec.gov.hk/en/best-practices/person/security-incident-handling-for-individuals
- 香港政府資訊保安網站〈Security Incident Handling for Companies〉,公司六步模型及各階段步驟 — https://www.infosec.gov.hk/en/best-practices/business/security-incident-handling-for-companies
- 香港政府資訊保安網站〈InfoSec: Ransomware〉「Immediate Response」、「Notify and report」及還原與預防各節
- 香港政府資訊保安網站〈InfoSec: Miscellaneous〉「Reporting」一節,報案及求助途徑 — https://www.infosec.gov.hk/en/useful-resources/miscellaneous
- Recording Law、Linklaters 及 FTI 對香港資料私隱法例的摘要,自願通報制度,二手摘要層面 — https://www.recordinglaw.com/world-laws/world-data-privacy-laws/hong-kong-data-privacy-laws/ ;https://www.linklaters.com/insights/data-protected/data-protected---hong-kong ;https://www.fticonsulting.com/insights/articles/what-hong-kongs-pcpds-data-breach-guidance-means-impacted-organizations
- Sidley、CMS Law Now、Boase Cohen & Collins、FTI 及 Dataprotectionreport 對公署 2023 年 6 月 30 日經修訂指引的摘要,五步及通報時機,二手摘要層面 — https://www.sidley.com/ja/insights/newsupdates/2023/07/hong-kong-new-pcpd-guidance-on-handling-data-breaches ;https://cms.law/en/chn/blogs/law-now-blog/apac-tmc-update-summer-2023 ;https://www.boasecohencollins.com/blog/data-breaches-and-how-to-handle-them/
- HK Lawyer 及 ONC Lawyers 對公署指引的摘要,通報內容要素及通報方式,二手摘要層面 — http://www.hk-lawyer.org/content/pcpd%E2%80%99s-updated-guidance-data-breach ;https://www.onc.hk/en_US/publication/keep-calm-if-the-database-of-personal-data-is-being-hacked?category=29&page=109
- Dataprotectionreport 及 Mondaq/Hill Dickinson 香港比較指南摘要,保障資料第 4 原則,二手摘要層面 — https://www.dataprotectionreport.com/2023/08/hong-kong-revised-breach-handling-and-notifications-guidance-published-by-the-pcpd/
- JD Supra、Linklaters 及立法會研究文件對強制通報修例建議的摘要,歐盟 72 小時對比及五個工作天建議層面,二手摘要層面 — https://www.jdsupra.com/legalnews/important-changes-to-hk-data-protection-72883/ ;https://www.legco.gov.hk/research-publications/english/essentials-1920ise02-mandatory-personal-data-breach-notification.htm
- 香港警務處〈Cybersecurity Report 2024〉,只見搜尋結果摘要,未直接開啟原文;本文只寫方向句,唔引用該組數字 — https://www.police.gov.hk/ppp_en/04_crime_matters/tcd/cybersecurityreport2024.html
- 本站定價頁 — https://www.itsupportking.com/pricing(2026-10-24 可見正文核查,見第八節)
- 未經直接核實的事項:私隱專員公署指引原文、HKCERT 中小企指引 PDF 全文、HKCERT 表格欄位及處理承諾、警方網上報案表格細節、官方頭 60 分鐘固定順序、當機首小時專用官方清單、香港本地事故統計、修例建議現況及生效日期、解密工具成功率及現行支援狀況、本站定價頁以外頁面的服務範圍、個別公司通報義務判斷、備份還原保證及時間——本文一律只寫二手摘要層面或者標示未證實,唔寫成事實。