企業面對資安事故，需要龐大的專業人力與經驗才有辦法妥善處理，單就事前準備和日常運作，所須投入的人力、物力或許就已經超出不少企業所能承受的範圍。但保有正確的資安觀念，做好事前準備與事後處理步驟，仍然可以讓資安事故的傷害降到最低。
在網管人雜誌158期「發生資安事故先別慌 分析紀錄通報SOP有撇步」一文提到，事故回應的流程有多個步驟，包含了事前準備、偵測與分析、封鎖、排除、復原、善後等，並闡述了分析步驟的部分，針對資安事故分析、記錄、排定順序與通報進行闡述。而本文可以算是先前文章的二部曲，將要回頭定義一下事件和事故的差異、討論事前準備、日常作業偵測，並且談談在東窗事發之後應該如何封鎖、排除、復原和善後。同樣地，適合的讀者群有資安事故回應團隊、系統管理者、網路管理者、技術支援人員、資安長、資訊長，以及負責處理資安事故的相關人員。
事前準備
事件與事故的差異在於，事件是任何可以觀察得到的事實。事件包含了使用者連線去檔案伺服器、伺服器接收一個網頁請求、使用者發送電子郵件、防火牆封鎖了某個連線。負面的事件就是那些伴隨著負面結果的事件，例如系統掛了、封包洪水攻擊、未經授權使用系統的高階權限、未經授權就存取敏感資料，以及執行惡意軟體去刪除資料。本文件只說明與電腦安全相關的負面事件，並非由天然災害、不可抗的電力中斷所引起的負面的事件。電腦安全事故是對於電腦安全政策或相關標準的違反行為，或者即將發生的違反行為。
事故回應的方法論通常會強調「事前準備」，這不僅要打造組織本身足以回應事故的能力，還要透過確保系統、網路和應用系統有足夠安全來預防事故。雖然事故回應團隊並非本來就負責事故預防，但事故預防就是讓事故回應方案得以成功的其中一個基礎。
接下來，提供一些對於處理事故和預防事故的準備基準。下面的清單提供一些在事故處理過程中可能值得使用的資源。列出這份清單是要當作討論的切入點，到底哪一個工具和資源是組織的事故處理者所需要的。舉例來說，智慧手機只是打造眾多緊急溝通和協調機制方法的其中一種。組織應該要有多重溝通和協調機制，以防其中一種機制不通的時候還能有順暢的溝通方式。
資源一：事故處理者的溝通和相關設施
事故處理者的溝通和相關設施，分成以下幾種：
‧給予組織內和組織外的團隊成員和其他人的聯絡資訊，例如執法單位、其他事故回應團隊；該資訊可能包含電話號碼、E-mail、公開加密金鑰等。
‧24小時待命人員的聯絡方式，包含事故升級的資訊。
‧事故報告機制。例如電話號碼、E-mail、線上表格、安全的即時通訊系統；至少應該要有一種機制，讓人們能夠匿名通報事故。
‧議題追蹤系統，用來追蹤議題資訊、狀態等等。
‧智慧手機，非上班時間的支援，以及現場溝通。
‧被用來在組織內與外部團隊成員之間溝通的加密軟體；舉例而言，如果要提供給美國聯邦政府部門，軟體就必須採用FIPS認可的加密演算法。
‧為了中央溝通和協調的戰情室。如果永久的戰情室並非必要，那麼團隊應該創建一份程序以利爭取臨時的戰情室。
‧安全儲存設施，以利保全證據和其他敏感素材。
資源二：事故分析的硬體及軟體
針對事故分析的硬體及軟體，說明如下：
‧數位鑑識工作站以及備份設備，以創建硬碟映像檔、保存Log檔案，以及儲存其他相關事故資料。
‧筆記型電腦，可以用來分析資料、側錄封包、編撰報告等等。
‧空閒的工作站、伺服器和網路設備，或者相對等的虛擬環境，可能被用在多種目的，例如將備份檔案復原和測試惡意軟體。
‧空白的可移除式媒體。
‧可攜式印表機，可以列印Log檔案的複本和其他證據。
‧封包側錄和通訊協定分析器以擷取和分析網路流量。
‧數位鑑識軟體以分析硬碟映像檔。
‧可移除式的媒體。
‧證據收集的相關配件，可能是紙本筆記本、數位相機、錄音筆、證據鏈表格、證據袋和標籤、錄音帶等。
資源三：事故分析資源
關於事故分析資源，包括以下幾項：
‧Port清單：包含常被使用的Port和木馬Port。
‧作業系統、應用系統、通訊協定和IDS和防毒軟體的相關文件。
‧網路圖和重要資產清單，例如資料庫伺服器。
‧對於網路、系統和應用系統活動的可忍受基準線。
‧重要檔案的加密雜湊，以加速事故分析和根除。
資源四：事故緩解軟體
針對事故緩解軟體，說明如下：
‧存取乾淨的作業系統映像檔和應用系統的安裝檔案，以達成復原目的。
許多事故回應團隊會準備一種「帶著就走工具箱」，這是一種可攜式的箱子，裡面包含了在調查過程中可能需要的材料。「帶著就走工具箱」應該要被準備好，隨時可以出發。
「帶著就走工具箱」包含許多上面羅列的清單項目。舉例來說，各個「帶著就走工具箱」通常至少包含一台筆電、裡面安裝的軟體（封包側錄、數位鑑識軟體等）。其他重要的材料包含備份設備、空白媒體、基本的網路設備和電纜網路線等。因為準備好「帶著就走工具箱」的目的是為了更快速地回應，所以團隊應該要有自己獨立的一個「帶著就走工具箱」，而應避免採用租賃的方式。
各個事故處理者應該要可以存取至少兩個運算設備（例如筆電）。其一，其中一個從「帶著就走工具箱」而來，應該被用在執行封包側錄、惡意軟體分析，以及所有其他可能會污染它們的筆記本電腦操作的東西。而且在拿它用在其他事故處理之前，這台筆電應該被洗乾淨，所有軟體都要重新安裝。除了一台調查用的筆電，各個事故處理者應該也要有標準的筆電、智慧型手機或其他運算設備來撰寫報告、讀取E-mail以及執行其他事務。
附帶一提，關於模擬演練事故這檔事，如果組織有認真走完一整套的事故模擬演練，演練本身會帶來不錯的經驗值。
預防事故
前面談論在日常作業中應該準備的基本功，接著來聊聊如何有效預防事故。平心而論，任何組織或企業，沒人敢也不可能宣稱自己從未遭受任何資安事故（甚至在那些有被發現的資安事故之外，尚有許多神不知鬼不覺的事故是組織本身從來就不知道的）。
換另一個角度來說，每家組織都會有資安事故。既然無法完全避免，那麼將事故數量維持在一個合理程度的數量，就是一門大家都要面對的課題。如果安全控管措施不足，可能就會發生大量的事故、會把事故反應團隊給壓垮。這可能導致緩慢而且不完整的回應，甚至會對企業造成負面衝擊，例如更長時間的服務無法取得。
關於如何保全網路、系統和應用系統，已經超過本文件所要討論的範圍。雖然事故回應團隊通常不負責保全組織的這些資源，但他們可以是觀念的推廣者，安全實務的推廣者。關於一般的安全概念和作業系統和應用系統的安全概念，在其他文件會提供相關建議。接著，談一下關於保全網路、系統、應用系統的某些主要被推薦的概念性實務作為。
風險評估
定期對系統和應用系統做風險評估，應該要判斷有甚麼樣的威脅、弱點和風險。這應該包含了去了解適用的威脅，包含組織特定的威脅、產業特定的威脅。各個風險應該被排定優先序，而且風險可以被減緩、移轉或接受。執行風險評估的另一個好處通常是重要資源被識別出來，讓同仁們多花點心思在這上面去監控和回應。
主機安全
所有主機皆應該被適度強化。除了維持各台主機適當的上Patch以外，主機應該要遵循最小授權的原則：只有因為被授權的任務所需要而授權給使用者。主機應該要將稽核功能打開，並且應該記錄重要的安全事件。主機的安全和他們的組態設定應該要持續地被監控。有些組織會採用SCAP（Security Content Automation Protocol）來描述作業系統和應用系統組態設定的檢核清單，以協助一致化且有效地保全主機。
網路安全
如果沒有明講要允許通過的話，網路邊界應該要被設定成拒絕所有活動，這包含了保全所有連接點，例如VPN、專線連接等等。
惡意軟體預防
偵測並且停止惡意軟體的工具，應該被部署到組織內，而且應該要將它部署在主機層級（例如伺服器和工作站的作業系統）、應用系統伺服器層級（例如E-mail伺服器、Web Proxies），以及應用系統用戶端層級（例如E-mail用戶端、即時通訊的用戶端）。
使用者意識和教育訓練
使用者應該要知曉政策和程序，關於恰當地使用網路、系統。從先前的事件當中適用的經驗學習，也應該被分享給各個使用者，這樣他們才能知道自己的任何行動是如何地影響組織。增進使用者對於事故的意識，某種程度上可以減緩事故發生的頻率。當然，IT人員也要被訓練成專業人士、熟悉組織內部的規範，以利維護網路、系統、應用系統。
攻擊入口
發生事故的來源有太多種可能，所以如果要發展每一個步驟的教戰手則並不切實際。組織應該要準備好處理任何事故，至少，對於那些常見的攻擊來源或攻擊手法，不能一無所知，不同種類的事故會對應不同的回應策略。下面列出來的攻擊入口，並非要提供事故的分級，而是羅列出常見的攻擊方法，可以被用來當作定義更明確之處理步驟的基礎。
‧外部／可移除式媒體：從可移除式媒體或周邊設備執行的攻擊，例如惡意程式碼從一個被感染的USB拇指碟散播到系統上。
‧耗損：利用暴力破解的方法去滲透、降級、破壞系統、網路或服務。例如，DDoS企圖削弱或拒絕存取到某服務或應用系統；對於身分驗證機制的暴力破解攻擊力，如密碼、CAPTCHAS或數位簽章。
‧Web：從網站或網頁應用程式執行的攻擊，例如發起Cross-site Scripting攻擊以竊取帳號密碼，或者是重新導向至一個利用瀏覽器弱點，並且安裝惡意軟體的網站。
‧E-mail：透過E-mail本身或附件所執行的攻擊，例如利用程式碼偽裝成附件檔案或E-mail內文連結到惡意網站。
‧擬人化：涉及把某些無害的東西替換成有害的，例如中間人攻擊、偽裝的無線AP、SQL injection攻擊，這些都涉及擬人化。
‧不恰當的使用：被授權的使用者任何由於違反組織可接受的使用規則導致的事故；不包含上述種類。例如，使用者安裝檔案分享軟體，導致敏感資料遺失，或者使用者在系統上做了違法行為。
‧設備遺失或遭竊：運算設備或媒體的遺失或遭竊。
‧其他：無法歸納於上述攻擊種類者。
上述段落著重在關於處理事故種類的實務。至於，根據特定攻擊入口給予特定建議，已經超過本文章範圍。
事故的記號
古諺有云：「事必有因」。任何事故也都會有一些蛛絲馬跡或先期的一些線索。對許多組織而言，事故回應流程最挑戰的地方在於精確偵測並評估可能事故：判斷是否事故已經發生、並且如果已經發生的話是什麼種類、範圍、問題的強度。之所以這麼挑戰是，因為以下三個因素：
1. 有很多種方式可以去偵測事故，當然也有很多不同等級的細緻度、精確度。自動化偵測能力，包含NIDS、NIPS、HIDS、HIPS、防毒軟體、Log Analyzer。事故也可能因為人工方式而被偵測到，例如由使用者通報。某些事故會有很明顯的記號，所以很容易被偵測到，但也是有幾乎不容易偵測到的記號。
2. 事故的潛在記號之數量通常都很多，舉例來說，比較常見的是組織接收到數以千計或百萬計的入侵偵測發出警告。
3. 為了妥適並且有效地分析事故相關資料，深入且專業的技術人員和豐富的經驗是必要的。
事故的記號有徵兆和跡象兩種。徵兆是一種記號，代表事故可能在未來即將發生。而跡象是一種記號，代表事故可能已經發生或者正在發生當中。
從被攻擊方來看，大部分的攻擊並沒有任何可識別或可偵測到的徵兆。如果徵兆被偵測到的話，組織透過發布警報，那就可能有機會去預防該事故。最起碼，組織可以更密切地監控被攻擊方的活動。徵兆的例子如下：
‧網頁伺服器軌跡紀錄顯示有人執行弱掃
‧新公布出來的弱點有打中組織的郵件伺服器
‧駭客團體聲明該團體將會攻擊貴公司
雖然徵兆相當稀少，但跡象卻非常多。因為跡象的種類太多，所以以下僅舉其中一些例子：
‧NIDS發出的警告，當DB被Buffer Overflow。
‧防毒軟體偵測到主機被惡意軟體感染
‧檔案名稱有不正常的字元
‧軌跡稽核的組態設定被變更
‧來自於未知的遠端系統，多次登入皆失敗。
‧比起一般的網路流量，網路流量有不尋常偏離。
徵兆和跡象來源
可以從許多不同的來源來識別徵兆和跡象，下面就來看看有那些比較常見的徵兆和跡象。
IDS及IPS
IDS和IPS產品識別出可疑的事件並且記錄適當的相關資料，包含偵測到攻擊的日期和時間、攻擊種類、來源IP和目的IP，以及使用者名稱。大部分IDS與IPS產品使用攻擊特徵去識別惡意活動；特徵值必須被維持在最新狀態，以利於最新的攻擊可以被偵測到。IDS和IPS軟體也會有誤判的時候，把對的判成錯的。分析人員應該人工去核實IDS和IPS警告，看是要仔細檢查IDS與IPS裡面的相關資料，或者另外從其他資料來源去互相佐證。
安全資訊事件管理系統（SIEMs）
安全資訊事件管理系統類似IDS和IPS產品，但是安全資訊事件管理系統產生的警告是曾把資料分析過之後才發出警告。
防毒軟體和防垃圾郵件軟體
防毒軟體偵測到不同型態的惡意軟體、產生警告，並且預防惡意軟體去感染主機。現在的防毒軟體產品，如果特徵值都有被更新的話，在阻止許多惡意軟體時都已經蠻有效的。防垃圾郵件的軟體，被用來偵測垃圾郵件並且預防它進到使用者的信箱。垃圾郵件可能包含惡意軟體、釣魚攻擊、其他惡意內容，所以從防垃圾郵件軟體而來的警告，可能就意味著有人企圖要攻擊你。
檔案完整性檢核軟體
檔案完整性檢核軟體，可以偵測到有檔案被變更。採用的是雜湊演算法，讓每個指定的檔案取得一組加密Checksum。如果檔案有被更改，而且Checksum有被重新計算過，那麼就有很高的可能性意味著有新的Checksum無法和舊的相匹配。透過經常性的重新計算和比對，就可以偵測到檔案有改變。
第三方監控服務
第三方提供多種的訂閱服務可以用來監控。舉例來說，詐欺偵測服務，將會通知組織，如果對方的IP、DN等等和當下的事故活動有相關的話。另外，也有免費的即時黑名單。另一個例子是CSIRC通知清單，這些清單通常都只能從不同的事故回應團隊去取得。
作業系統、服務和應用系統軌跡紀錄
作業系統、服務、應用系統的軌跡紀錄，在發生事故的時候常常有很大的價值，例如記錄哪一個帳號被存取、被做了什麼動作。組織應該要求所有的系統紀錄的基準水平、對重要系統要有較高的基準水平。軌跡紀錄可以被用來分析相關的事件資訊。根據事件資訊，警告可以被產生，用來顯示有事故發生。
網路設備軌跡紀錄
從網路設備而來的軌跡紀錄，例如防火牆和路由器，通常並非徵兆或跡象的主要來源。雖然這些設備通常被設定來記錄封鎖起來的連線，關於活動的本質，它們卻提供很少資訊。然而，它們在識別網路趨勢和把其他設備偵測到的事件關聯化，是蠻有價值的。
網路流量
網路流量是發生在主機之間。路由器和其他網路設備可以提供網路流量的資訊，這可以被用來找出惡意軟體、資料外流、其他惡意行為等異常的網路行為。現在也有許多的網路流量格式，例如NetFlow、sFlow以及IPFIX。
新的弱點資訊
維持新的弱點和漏洞，可以預防某些事故發生，並且協助偵測和分析新的攻擊。NVD包含了弱點資訊，像CERT這些組織都會定期提供威脅更新資訊。
組織內的同仁
每個人通報上來的不見得都真的是資安事故，所以記得去檢查核對這些通報是否真的是資安事故。其中一個方法是要去詢問這些提供通報的人，問他們對於該資訊有多少信心。
選擇封鎖策略
在網管人雜誌158期「發生資安事故先別慌 分析紀錄通報SOP有撇步」一文以事故通報作為結尾，雖然在資安事故發生後，接著會進行分析，但同時也要特別留意，在事故把資源全部湮滅或者增加破壞之前，封鎖是很重要的。換句話說，實務上，事故分析和事故封鎖、事故根除、事故復原之間會反覆來回。
事故封鎖在處理各個事故都是重要的，而且在處理事故的一開始就要執行。事故封鎖替我們爭取時間，以利有較充裕的時間來想緩解策略以爭取時間。重要的是封鎖的決策為何，打算關閉系統、從網路上斷線、關閉特定功能或採取何種行動。如果有一些已經預先決定的策略或程序的話，將會發現比較容易下這樣的決策，而不會手忙腳亂或坐以待斃。
封鎖策略會因為事故種類而不同。舉例來說，封鎖一個從E-mail而來的惡意軟體感染和一個網路DDoS攻擊的策略是很不同的。組織應該要對各種主要的事故種類打造個別的封鎖策略，包含協助決策的明確準則。決定適當的策略的準則包含了：
‧對於資源的潛在破壞、對資源的潛在偷竊。
‧證據保存的需要性
‧服務可用性（例如網路連接的可用性、由外部方提供的服務的可用性）
‧實施策略所需的時間和資源
‧策略的有效性（例如部分封鎖、全部封鎖）
‧解決方案持續期間（例如四小時內移除緊急的變通方法；兩周內移除暫時性的變通方法；或者，永久性的解決方案）
在某些情況下，某些組織會把攻擊方引導去沙箱，如此一來，他們就可以監控攻擊者的行為，通常是用來收集額外的證據。事故回應團隊應該連同法務部門一起討論這個策略，以判斷該策略是否可行。做沙箱以外的監控方式，不應該被採用。如果組織知道有系統已經被滲透並且允許讓滲透繼續進行，那麼駭客用這個被滲透的系統再繼續攻擊其他系統的話，駭客可能就要負起法律責任。如果你的封鎖策略拖延了時間，就危險了，因為你的無知同時也替駭客爭取了提升權限或者滲透其他系統的時間。
其他關於封鎖的潛在議題是，某些攻擊在被封鎖的時候可能導致額外破壞。舉例來說，被滲透的主機可能正在執行一個惡意程序定期地Ping其他主機。當事故處理者透過把被滲透的主機從網路上斷網來企圖封鎖事故，理所當然地，Ping就會失敗。因為這個Ping的失敗，所以惡意程序可能會複寫硬碟、加密主機硬碟內的所有資料，或者把一個已經長久注意的重要備份資料夾刪除。所以看到這裡，如果以往遇到資安事故的時候很多次都是直接斷網但卻沒發生後續的滾雪球效應，或許應該要謝天謝地才對。
證據收集及處理
雖然蒐集證據的主要原因是要解決資安事故，但有時候也可能是因為法律訴訟而需要蒐集證據。不管如何，清楚且詳實記載並保存所有證據就是很重要的一門課題。根據符合所有適用法律法規的程序，證據應該被收集。而且，記得找法遵部門同仁一起討論的適用的執法單位或法律，這樣證據到了法庭上才有證據力。
此外，每當證據從某一人傳送到另一某人，都應該要簽署。詳細的紀錄應該包含以下幾項：
‧相關的識別性資訊，例如地點、序列號、主機名稱、MAC位址、IP位址。
‧雙方的姓名、頭銜、電話號碼。
‧處理證據的日期和時間（包含時區）
‧存放證據的地點
從電腦資源收集證據，會有一些挑戰。一旦有可疑的事故可能已經發生的時候，通常都想要從系統取得證據。比起其他行為來說，最初簡單的系統快照可能是比較好的方式。從證據的角度而言，在系統未被改變的時候就快照，比起在事故處理者、系統管理者，或其他人在調查期間做了一些不可逆的動作或已經修改機器狀態之後才系統快照來得好。使用者和系統管理者應該要知曉各自應該採取的步驟，來保存證據。
識別發起攻擊的主機
在事故處理期間，系統擁有者和其他人有時候想要或需要識別發起攻擊的主機為何。雖然這個資訊可能有時候是蠻重要的，但事故處理者通常應該保持專注在封鎖、根除和復原。識別攻擊主機其實蠻耗時、沒甚麼績效的過程，甚至阻礙了團隊達成主要目標：也就是將該事故對企業造成的衝擊最小化。下列事項描述了識別攻擊主機時較常執行的活動：
新手事故處理者通常會聚焦在攻擊主機的IP位址
處理者可能企圖用Ping來證明該位址並非偽造。但其實應該要清楚，主機對Ping的回應不過就是個回應，不回應並不意味著該位址並非真實，因為主機被設定成忽略Ping和Traceroute是如此容易的事情。
用搜尋引擎研究攻擊主機
去做一些網路搜尋，可能也會有意想不到的發現。
使用事故資料庫
許多團體從不同組織收集並合併事故資料變成一個事故資料庫。這個資訊共享可能用多種形式發生，例如即時黑名單。該組織也可以檢查自己的知識庫，或發布到追蹤系統上。
隨時注意那些可能的駭客溝通管道
事故處理者可以監控攻擊主機的溝通管道。舉例來說，許多肉雞採用IRC來當作他們主要的溝通方式。而且，駭客可以聚集在特定IRC管道來吹噓他們的傑作。然而，事故處理者對待這種資訊應該要秉持著它只是其中一種可能的線索，而不見得值得當作事實來看待。
根除與復原
封鎖之後，接著要來消除事故，例如刪除惡意軟體並且把那些被外洩的使用者帳號給關閉，識別出並減緩所有已經被利用的弱點。在根除過程中，識別出所有受影響的主機很重要，這樣它們才能夠被診斷和治療。某些事故中，根除這檔事要嘛就是不被需要，要嘛就是要在復原過程中去執行。
在復原過程中，管理者將系統復原到正常運作，確認系統正常運作而且補救相關弱點來預防類似事故再發。復原可能涉及從乾淨的備份檔案當中來復原系統，從暫存重新建立系統，用乾淨的版本來取代被滲透的檔案，安裝Patch，變更密碼並且強化網路邊界安全，例如防火牆政策、邊界路由器的ACL。較高等級的系統Log或網路監控，通常都是復原過程的一部分。一旦資源被成功駭入，通常就會被再次攻擊，或者組織內的其他資源會被用類似手法再度攻擊。
根除和復原，應該還要再切割成小階段的方式，這樣個個步驟才能被排定優先順序。對大規模事故而言，復原可能需要好幾個月；早期的步驟的目的應該是要用來增加整體性的安全，伴隨著相對快速（幾天或幾個星期）的高價值變更以預防未來的事故。比較後面的步驟應該專注在長期的變更（例如資訊基礎建設變更），以及持續工作來維持組織儘可能的安全。
事後活動
事故回應的其中一個最重要的部分、也最容易被忽略的部分：學習和精進。各個事故回應團隊應該也要學著進化，以反映新的威脅、持續變化的科技，以及經驗學習。在重大事故之後、並且不定期舉辦經驗學習會議，把所有涉入方都拉進來，對於提升安全措施以及事故處理流程本身都是有幫助的。許多事故可以被涵蓋到單一經驗學習會議裡面。這個會議提供一個機會來揭露關於事故的相關議題，透過檢視發生甚麼事情、可以做甚麼去介入、採取的介入又會有何功效。這個會議應該要在事故結束後幾天之內就舉辦。會議裡面要回答的問題包含以下：
1. 實際上發生甚麼事、甚麼時間點？
2. 處理事故過程中，員工和管理階層的表現如何？文件化程序是否有照著走？文件化程序是否恰當？
3. 有甚麼樣的資訊需要更快地被知道？
4. 有任何採取的步驟或行動反而限制約束了事故復原嗎？
5. 如果之後還有類似的事故再度發生，那麼員工和管理階層的行為有需要調整或改變嗎？
6. 與其他組織的資訊共享可以怎麼被改進？
7. 有甚麼矯正行動可以預防類似的事故再度發生？ 8. 有甚麼徵兆和跡象應該要被看管，以便偵測類似的事故發生？
9. 為了偵測、分析、減輕未來事故發生，是否需要額外的工具或資源？
小型事故需要較小型的事後分析。但如果發生嚴重的攻擊後，就有必要舉行跨部門的事後會議，因為這提供了一個資訊共享的機制。舉辦這樣的會議，主要考量是要確保正確的人都有被拉進來。不只有邀請那些涉入的人來出席會議是重要的，還有把那些為了促進未來合作目的的相關人物都拉進來也是重要的。
經驗學習會議也會提供其他好處。這些會議的報告都是好的教材，可以拿來訓練新進的團隊成員，讓他們知道有經驗的同仁們是如何回應事故的。更新事故回應政策和程序，是經驗學習流程的另一個重要部分。事後分析通常會揭露事故處理過程中遺漏的步驟或不正確的步驟，這可以當作改變的動力。因為資訊科技和人事本身就是不斷在變動，事故回應團隊應該要定期檢視所有相關文件和程序。
另一個重要的事後活動是，替各個事故打造追蹤報告，這會是很有價值的。報告提供一個參考，可以被用來幫助處理類似的事故。至於追蹤報告應該被維持多長的時間，可參考組織內的紀錄保存政策來看要保存多久。
結語
本文章及網管人雜誌158期「發生資安事故先別慌 分析紀錄通報SOP有撇步」一文說明了資安事故處理在概念上的一系列步驟，讀者不難發現，組織要想妥善處理資安事故，其實需要相當多的人力、經驗、專業、資源。
如果組織連最基本的安全周邊、網路設備、防護體系都沒有，那這兩篇文章對你來說也只是一個太遙遠又綺麗的幻想而已。單就事前準備和日常運作而言，組織所要投入的人力、心力和物力，或許就已經超過不少企業在認知上所能承受的範圍。各項步驟裡面所提到的領域或事項，其實都需要再另外花時間去研究了解，並非花錢買來放著就可以抵擋網路攻擊。藉由這兩篇文章的分享，讓讀者在資安事故處理的架構上，有較清晰的認識。
＜本文作者：黃信智，目前為久揚科技服務有限公司營運總監，提供資安管理、隱私保護、營運持續管理等顧問諮詢服務，以及滲透測試、源碼檢測等資安服務。擁有CEH、ECIH、CISSP、ISO 27001 LA等資安證照。＞