今天延續昨天的資安事件流程再造，簡單來說，資安過去不是最被重視的一環，也常常被當作理所，自然而然就是好的。
但是資安沒有在管理層面、流程層面下手，累積起組織的資安韌性，它只是沒發生事情，不代表就是ok...

以下是團隊血與淚的寶貴的經驗，無論如何真的不容易。

Action

• 以下是事件處理的概略方向說明，非全部細節，一個為單系統事件，一個為入侵後已橫向擴散的事件，僅供操考

1. 勒索病毒事件
   1. 確認是否為 Incident（不是所有的 Bug，都是 Incident）
      1. （事故處理相關）
         • 因為系統都掛了，所以確認是 Incident。
   2. 確認 incident 對服務的影響範圍
      1. （事故處理相關）
         • 整個服務矩陣都陣亡了，需要逐步收斂看斷點在哪。
   3. 確認 incident severity and priority，事件分級歸類，需要溝通的範圍（escalation process）
      1. （事故處理相關）
         • Critical service failure, Severity 1, Priority 1, 需要立即回報執行長辦公室。
         • Mitigate Incident impact，想辦法對事故進行收斂。
   4. 對應程序啟動
      1. 確認異常
         1. War Room setup（ex. Teams、Slack），stakeholder engagement（當責的 Engineer，Engineering Manager, CIO）
         2. 有 Tier 2 support 跟 CyberSec incident support contract 的就啟動（當時該單位沒有）
         3. Incident timeline, recording and reporting
         4. （事故處理相關）
            • 有 War Room，有 stakeholder engagement, incident timeline, recording and reporting, 開始必要的回報跟溝通。
            • 定義異常事件處理基調，駭客要比特幣，先不說真的貴，該單位連比特幣是什麼都不知道，駭客找錯人了，所以基調是不付錢，那口水戰給一堆官腔就交給CEO跟他所轄的業務單位，工程專心處理異常事件，把服務帶回來就好。
      2. 釐清異常的肇因及範圍（上面是服務面向，現在討論的是工程面向）
         1. 入侵受影響的範圍，攻擊的路徑（查閱防火牆、網路、系統、應用程式相關的日誌 log，嘗試收斂）
         2. User, Device, Network, System, Application, Data 存取的紀錄、存取的時間、各種非正常紀錄（這時候就要看之前工程定錨時，有沒有確認過什麼叫正常），尤其是進一步確認數據受應想的可能性。
         3. 該事故系統可連結存取的範圍釐清（事故橫向擴散的可能範圍）
         4. （事故處理相關）
            • 該事故系統為外部廠商提供服務的系統，是數轉團隊入駐後的廠商，基本上跟資安相關的要求有幾項相關已開始落實
              • 服務應依其服務的範圍，存取的數據，配合甲方環境拆分（ex. 不是全部都在一台，一定要放在權限最大的網段），此事件因有落實這點，所以受影響的只有是因為系統設計因素，需要暴露在網際網路上的服務主機，該主機沒有照要求定時定期 patch system and app，所以被網路上攻擊程序掃到，自動被打包帶走。
              • 服務應依其數據必要性及敏感性，配合甲方拆分儲存的標的跟媒介（ex. 不是通通丟在一台資料庫跟目錄），此事件被勒索軟體鎖住的資料，因當初其架構的關係，在廠商解決方案遴選時，該廠商有將數據資料照甲方要求進行分級分段處理，所以因風險性，該事故主機上只有使用者上傳的暫存資料（可揮發），所以無敏感性資料，可以直接用系統重建恢復服務。
              • 該廠商有配合甲方要求，進行服務的版本控制，對應的系統、應用程式、設定檔（configuration management），數據（資料庫、檔案）皆有備份，可以確保在事故發生時，可以照程序恢復服務（這點一半以上的廠商都做不到，大部分的廠商都是提供服務時可以，經過半年一年，各個甲方環境異動時，就散掉了，事故發生，都是人工進入看狀況 debug，廠商也忘記自己上次改了什麼（東西都在原先負責工程師的電腦裡，他離職後就不知道了之類的，上市櫃的系統廠也是一樣，甲方自己不懂不要求，就是被當提款機）。
            • 廠商有配合甲方建立聯繫群組（ex. Line），甲方平時就有照內部程序，定期『聯絡』，確認都會回應，需要的 key resource 會在（我們有遇過工程師說他要睡覺不理人，老闆說了也沒用，不是小公司喔），有離職時要確認接手的知道狀況（要有簡單的測試程序），還有不要以為有總經理在就沒問題，筆者團隊也遇過整組工程跑掉（不是小公司，交易額也是幾百億的公司），也有總經理自己壓力太大跑掉了的極端情況，千萬不要只聽廠商業務一張嘴，出事業務都只會矮呀矮呀、這裡哥那裡哥的叫..，就算服務外包，甲方還是要知道狀況，不然到時哭的都是自己。
            • 因為平時廠商要對服務異動時，需要跟甲方申請（除非是 pre-defined 的自動化程序），每次異動甲方也會跟乙方確認異動的細節（知道很瑣碎，但是不這麼做沒辦法應對異常風險），所以出問題時就算乙方作業不落實，還是有線索可以追朔，有機會將服務帶回來。
            • 以上資料有，廠商跑掉了，起碼還有自己救的機會，不然可能不只是服務的問題，還有法律的責任會發生（知道合約要訂，但處理都是麻煩）。
            • 經事故研判，最大可能是因為系統版本太舊（查詢過去備份的紀錄，系統跟程式版本太舊），所以請乙方在系統重建時要同步處理。
            • 經過確認，因該網段是獨立網段，跟主系統是透過 API 存取，查閱 Application log 無發現異常，初步判定是單一服務主機的獨立事件，並基於此推論進行後續處理。
            • （外包商）負責的外包商除了在上述的異常事故處理時，要一起討論處理外，要在最短時間先出一份異常事故處理報告（version one），甲方這邊的討論要包含乙方處理相關的資訊，乙方拿錢了該做的該扛的要先扛起來，你等後面事後乙方再出報告，真的有辦法照合約要求就見鬼了。
      3. 異常事故現場隔離
         1. 受影響服務應該如何提供 workaround (downgrade, fallback, etc.)
         2. 現場存證
         3. （事故處理相關）
            • 受影響系統、服務、及數據資料皆為 Level 3（L1 核心，L2 關鍵，L3 可揮發），乙方（外包商）照程序改設定，預設提供 workaround 的方案是
              Service downgrade, 子功能暫時關掉，無特殊考量，就依循程序逐步恢復服務。
            • 因該主機有獨立硬體設備，事故主機先離線離網，等待後續處理。
      4. Service recovery
         1. （事故處理相關）
            • 該事故主機為實體機，甲方提供備品，乙方（外包商）照程序重建恢復服務（以這個案例，乙方同時要將系統升級到最新版本，該上的 patch 都要到位）。
            • 乙方先照預設的異常場景處理方案進行 Workaround，Service downgrade, 子功能暫時關掉，（當初在廠商遴選時，架構討論時，有假設幾個異常場景，設定相關的預設處理程序），讓服務不會因為異常事故卡住，讓對外服務先恢復正常，並通知相關部門各階段恢復的計劃跟時程。
            • 乙方系統重建後，進行數據資料核對，當初設計時，在進行數據分級討論時，有相關的設計將必要的數據跟檔案進行分散分級儲存，要將缺失的數據連結重建，完成數據資料完整性查核後，準備子系統服務上線。
            • 通知相關業務部門，系統重整上線需要進行測試，服務會短暫暫停。
            • 工程在子系統重新上線前，對現行 downgrade service version 進行一次版控備份（因為有異動到程式，這也是目前大家可以接受的暫時版本，再來到100%回覆，服務品質不可以低於這個版本）。
            • Release the regular version to the production environment.
            • 確認所有配套監控、備份等相關程序，因事故（Incident）進行的調整都回復到原狀。
            • 跟業務單位確認服務都恢復正常。
      5. Incident close
         1. （事故處理相關）
            • 此事件有造成部分服務影響，無證據說明可能有敏感性數據外洩風險，（看起來是自動攻擊程序，被掃到直接打包），既然沒有直接民事或刑事風險，第一階段處理只上報到CEO辦公室，後續的處理請CEO辦公室自行判斷（因該單位無既有流程可依循）。
            • 系統服務恢復正常，後續轉 Incident postmortem、final report（結案歸檔用），在轉到 Problem Management 處理改善優化部分。
      6. Incident postmortem
         1. 照 Incident timeline and all the actions we did during the incident handling，進行發現事項及改善建議的討論。
         2. 釐清 Incident 各階段處理的細節，將改善事項分成即期跟後續轉 Problem Management 處理的部分，轉 Report processing。
      7. Incident report
         1. 照 Postmortem 的討論，照內部格式及程序產生報告結案。
      8. Problem Management
         1. 系統應定期更新，可以請外包商在定期的報告中增列這方面的紀錄，另一方面也可以討論是否需要加上內部自動化查核程序，確認外包系統有定期更新。
         2. 網路層在新架構中會有 ingress layer，進一步改善資安及監控，同時改善個系統自己暴露在網際網路上提供服務的風險。
         3. 服務中的 Error handling 需要進一步改善，不能因為一個非核心服務子系統出問題就拖垮整個服務矩陣。
2. 資料外洩事件
   1. 確認是否為 Incident
      1. （事故處理相關）
         • 客服接獲多件詐騙電話課訴。
         • 服務異常，話務進化量比過去平均值異常高。
   2. 確認 incident 對服務的影響範圍
      1. （事故處理相關）
         • 根據收集到的資訊，跟舊系統架構的理解，判斷可能的攻擊路徑跟影響範圍。
   3. 確認 incident severity and priority，事件分級歸類，需要溝通的範圍（escalation process）
      1. （事故處理相關）
         • Critical service failure, Severity 1, Priority 1, 需要立即回報執行長辦公室，建立專案，統籌公關、客服、業務、法務等部門，準備進行必要的內外部溝通（因為有潛在的民事跟刑事風險，也可能會需要面對主管機關查核）。
         • Mitigate Incident impact，想辦法對事故進行收斂。
   4. 對應程序啟動
      1. 確認異常
         1. War Room setup（ex. Teams、Slack），stakeholder engagement（當責的 Engineer，Engineering Manager, CIO）
         2. 有 Tier 2 support 跟 CyberSec incident support contract 的就啟動（當時該單位沒有）
         3. Incident timeline, recording and reporting
         4. （事故處理相關）
            • 有 War Room，有 stakeholder engagement, incident timeline, recording and reporting, 開始必要的回報跟溝通。
            • 定義異常事件處理基調，確認有資料外洩風險，想辦法釐清攻擊路徑，外洩弱點在哪，如何止血，如何堵漏。
      2. 釐清異常的肇因及範圍（上面是服務面向，現在討論的是工程面向）
         1. 入侵受影響的範圍，攻擊的路徑（查閱防火牆、網路、系統、應用程式相關的日誌 log，嘗試收斂）
         2. User, Device, Network, System, Application, Data 存取的紀錄、存取的時間、各種非正常紀錄。
         3. 該事故系統可連結存取的範圍釐清（事故橫向擴散的可能範圍）
         4. （事故處理相關）
            • 照客服回報的資訊組合，倒回去查詢可能從哪些地方外洩，（這邊要再次說明，一般公司對資安不上心是因為過去沒發現問題，不是沒有問題，但是通常也是因為這樣，所以就算要投入資安，也會想說放在新架構，不會在舊有架構進行改善，此例也是如此）。
            • （背景說明）
              • 原先老闆態度就是工程是來服務我的，任何對我的電腦管理限制都是不對的，還有上述的文化，不與惡人作對，佛系管理，so...
            • 事故分段診斷
              • User：帳密外洩一堆（從暗暗的渠道驗證），一堆使用者把幾乎全部使用者資料下載在個人電腦作業，so...
              • Device：個人終端沒有控管，所以大部分同仁都是當自己電腦，四處下載西台灣應用程式，so...
              • Network：
                • 為原生資訊同仁作業方便（其實是不會管理跟設定），所有的服務都是放在一起，那橫向攻擊的風險，so...
                • 內外網環境沒有妥善切分，so...
                • VPN 存取控管，恩，只能說有做，so...
              • System：微軟大家族系列，市面上通用的都有，市面上已經找不到的也有，而且幾乎都是剛出廠那版喔，原汁原味沒更新的喔，加上本機相關資安設定，無，so...
              • Application：
                • 應用程式多年沒更新，同因專業知識不足，為求方便，所有的系統跟資料庫都是以最方便的權限通通打通，要改一時間也不知道怎麼改起，so...
                • 後台管理系統帳號權限控管因使用者方便需求，so...
                • 離職的員工帳號還是與你同在，倍感溫暖，so...
                • 前後台沒拆分，為方便在家作業，所以應該是內網的功能，外網也可以讓有興趣的使用者踹踹看喔，so...
                • Log，無，卒，so...
              • Data
                • 同樣因為方便，資料都是大鍋炒的，沒有正規，只有正龜，so...
                • 數據資料的加密跟遮罩，這個可能要科普後才有辦法溝通，so...
              • 資安相關需要的設備
                • 無，卒
            • 緊急處置
              • 以上可以看出佛系管理強大之處，用『你看不到我這招』可以支撐這麼多年，但神也會累，該是凡人自己努力點的時候了。
              • 還是那句，雖說老闆（通常都是業務單位出身），已經決定不在舊架構上花會痛痛的錢，但是團隊內部經評估風險實在太大，心臟受不了，所以還是有做了些事。
                • 風險評鑒釐清服務主次要流程（ex. 主商品銷售到金流這段最重要，是說哪家不是？）
                • 真的要 Downgrade service and only keep core，可以做到什麼程度，有計劃雛形。
                • 萬一的萬一，『你看不到我』這個神技失效時，我們需要有備案，所以新官網有在規劃進行，（各位看官，你要這樣做的話請審慎評估，因為大部分老闆會生氣，會不會被生魚片刀追殺，你要自己評估），我只能說筆者團隊的做法，是風險太大的還是要有備案，不然吃虧的還是自己）。
                • 工程本來就有在規劃新的資安管理架構，大部分模組都已經定義，只是提早上線，工程會需要多工，粉累。
              • 跟需要溝通的一堆人溝通後
                • 存取管理收斂（帳號，授權）
                • 網路層（防火牆）進行緊急的存取管控拆分
                • 非必要功能關閉（為使用者方便出現的詭異功能）
                • 內外部功能存取拆分
                • 因為不乾淨了，要重灌系統再上線（需要免戰）
                • (太多了，要 donate 解鎖)
      3. 異常事故現場隔離
         1. 受影響服務應該如何提供 workaround (downgrade, fallback, etc.)
         2. 現場存證
         3. （事故處理相關）
            • 受影響系統、服務、及數據資料皆為 Level 1（L1 核心，L2 關鍵，L3 可揮發），乙方（外包商）無能力配合處理，甲方是利用離峰時間，將服務下線，照預設程序進行 Service downgrade support，換一套上線，待進一步釐清後，依循程序逐步恢復服務。
            • 這個 case，是在虛擬機上，保留事故系統，供後續分析。
      4. Service recovery
         1. （事故處理相關）
            • 該事故主機為虛擬機，因乙方無力處理，甲方另開虛擬環境（僅限內網，另外暫時設定的獨立網段），照備份的資料，用乾淨的作業系統開始逐步重新建立系統，並進行相對應的 patch，程式修正（如 php 更新後需要調整的功能），並觀察所有必要的連線，防火牆規則同步收斂，（防火牆不是只是管進來的，出去的也要管），完成後，逐步開放存取，同步測試觀察。
            • 帳號清查，外洩帳號都強制更改密碼，非必要存取的都關掉，可以刪的幽靈帳號都刪掉（不可以刪的幽靈帳號還真多，為什麼系統要用個人帳號串服務呀，簽名的概念嗎？）。
            • 受影響 Device 都重灌。
            • 服務主機可以配合未來網路微分段架構的，就先異動，減少風險。
            • (後面比較瑣碎了，有緣再見)
      5. Incident close
         1. （事故處理相關）
            • 此事件影響範圍很大，所以不是該單位可以自行評估結案就結案了，需要主管機關復合才可結案。
      6. Incident postmortem
         1. 因後續檢討，需要改進的東西很多，有先出第一階段判斷受影響的系統的檢討報告，但有說明，風險仍在，後續轉到 Problem Management 處理。
      7. Incident report
         1. 同上。
      8. Problem Management （當初討論的幾個面向供大家參考）
         1. User, Device, Network, System, Application, Data，照各個層級擬定改善計劃。
         2. 去董事會給幾個董事『強烈關心』後，幸好有英明的董事長幫忙，有提供實質的資源跟支持，讓後續計劃（原先的資安改善計劃提前一年上線)。
         3. 後續細節有緣再見。

Result

• 技術日新月異，資安風險永遠都在，該單位已認知『你看不見我』的無敵星星秘技已失效。
• 新架構含常規資安維運框架設計，從日常到異常處理，從 Tier One 到 Tier Two，都有涵蓋。
• 資安現狀已納入常規治理及管理面報告事項。