資訊安全事故管理

資訊安全事故是一些會影響營運衝擊的非預期事件，而此類事件足以讓組織的營運中斷或是服務量能下降。而資安事故管理就是要將此類事件的發生率降到最小，並且在真的事件發生時也能讓營運衝擊最小化及快速(組織認可的時間內)的將營運服務回到正常的量能。

而事故安全管理通常分為三個階段分別是事故的

1. 確認(identifies)
2. 準備(prepares)
3. 回應(responds)

以期能夠達成事故的控制與損害最小化( service的recovery/restore在組織規定的SLA內)，在事故過後還能夠針對事故進行採證與調查(就是資安鑑識)。而這一類事故事件定義是根據組織的數位資產/服務對組織的價值以及受影響的範圍而定，根據不同的價值與受影響的程度而有不一樣的回應。

第一步我們要做的就是要制定事故回應計畫(IRP)，這一種計畫有幾個目標

1. 要老闆(或高階主管)同意過的，不然沒人理你
2. 確認這個IRP的內容是可以讓你拿去跟組織內外的相關部門或partner溝通的，不然人家不知道怎麼配合你也不知道跟他自身部門有甚麼關係
3. 描述這個IRP的目標，這個內容是具有系統性與一致性的方法能夠及時的定義來解決事故與修復發生的原因以防下次再度發生，而這一切都必須要與組織的營運目標一致。

在事故管理中三階段第一階段是確認，而事故的確認流程中"即時性與正確性"是我們最大的考量，這樣才有辦法確認我們的事故確認是有效的。而且我們要避免一堆假警報的產生，因為假警報的產生會消耗組織的資源並且會讓我們對與真的影響我們的事故忽略掉(狼太來了太多次)。再者從事故發生到我們真的確認事故的時間中組織已經很可能遭受衝擊了另外若事故的正確性無法被確認我們也很可能將此事件分到不同的分類並使用錯誤的對應/修復方法。所以再一次"事故的確認需要有即時性與正確性"。

一旦確認事故接下來我們就要依照IRP的內容通知受影響的部門及相關人員(後面會提及可能會有的那些部門及人員)。另外一個重要的是"事件升級成程序"，當事故超過規定的時間與程度後我們就需要將事件升級到不同的程度。另外在事故管理組成中也包含了BCP(Business continuity plan)與DRP(Disaster recovery plan)後面我們會再提及這兩個部分。

事故管理概觀(Overview)

事故管理可以被視為是風險管理中緊急維運的組成。這一類未預期事故的發生是由於缺乏控制措施或是控制措施失效所導致的。事故管理是整個事故週期(事故發生前/中/後)的一連串行動，而這一串的行動的目標就是最小化對於組織的營運衝擊。要達成這一目標會有幾個特點:

1. 有效解決問題的方式(怎麼樣將衝擊最小化)
2. 有效及充足的資訊才能讓接下來的行動是正確的
3. 事故發生時能夠維持或回復組織的營運
4. 事故的防禦要能夠對應事故發生後的連續性事故，也就是是如果發生事故A哪個事故B一定或可能會發生。
5. 需要有額外的嚇阻方法(可能是透過IT技術/調查/司法官司)

總結事故管理就是確認與回應事故未預期的不好事件(一堆天災人禍)造成組織的營運中斷，將此類事件的衝擊控制在組織可以接受的範圍內。而是故管理中也包含了前期的事故預防，將事故的機率減到最小。
另外我們對於事故的優先順序通常會使用風險管理及BIA(business impact analysis)來決定。從結構上來看BCP中通常包含了以下三個部分

1. 事故管理
2. 問題管理
3. DRP災難回復計畫

這個三個部分有相輔相成的及有順序的。"資安事故管理是為了不讓事故(Incident)變成問題(Problem)再讓問題擴大成災難(Disaster)"。

但我們必須在事故管理中要做到兩方面的平衡，即組織的資安baseline與維運之間取的平衡。因為在事故發生有時可能為了能運作下去而在當下完全將組織的資安baseline拋在腦後。事故管理與回應活動的目標可以總結如下:

1. 快速的偵測事故
2. 能夠正確的診斷事故
3. 圍堵與最小化破壞
4. 回復受影響的服務
5. 能夠知道主要造成的原因
6. 有方法或對策可以防止再發
7. 有紀錄與回報

而整個事故管理的週期分為以下幾個階段

計畫與準備階段
這一階段是在準備相對應的資源(可能需要相關的軟硬體設備及工具)，並且能得到組織高層與相關部門的支持並對相關人員進行教育訓練，另外還需要有事故發生時針對組織內外部的聯絡計畫。

1. 偵測,分類與調查階段
   — 定義甚麼樣的事件對應到甚麼樣的事故與通知流程是甚麼。
   — 偵測並確認事故。
   — 事故的優先排序。
   — 需要建立防毒/IPS/IDS/SIEM/弱掃等等一堆資安方案或工具。
   — 建立事故回應團隊。
2. 圍堵，分析，追蹤與復原
   — 針對事故進行圍堵防止事故擴大。
   — 根據事件收集流程針對事故進行資安鑑識。
   — 根據BCP/DRP進行復原程序。
   — 確定事故來源。
3. 事後評估
   — 到底發生了甚麼時何時發生的?
   — 組織的內相關人員是否按照IRP內的內容來對應事故?對應的行動是合適嗎?
   — 我們有方案來對應下次同類的事故不會再發生了嗎?
   — 回報事故管理的各項指標，例如回應時間/解決花了多久/使用了那些資源等等。
   — 我們從這個事故學到了甚麼嗎?
4. 結案
   事故的回應分析報告，而此報告需要經過組織高層及相關受影響的單位認可。

事故回應程序

雖然我們在組織實行了很多控制措施但沒有人可以百分百保證這些控制措施能完全的消除風險(除非你有預知能力或可以觀落陰)，所以事故回應程序能讓我們將組織的運作能力保持在一定的程度(經過組織高層認可的)之內。以下將說明一個好的事故管理能力有哪些。

以下因素將會影響事故管理是否是有效的:

1. 資安事故導致資安事件的增加與相對損失增加的趨勢
2. 不斷增加的IT系統的軟硬體的漏洞/弱點將加大IT架構的衝擊
3. 控制措施的失效
4. 外部環境的法規法令要求
5. APT攻擊
6. zero-day攻擊

而一個好的事故管理將產生如下結果:

1. 能夠有效處理讓組織產生營運中斷的未預期事件
2. 事故能夠被有效與及時的偵測/監控並被確認
3. 好的事故分級/宣告事故與事故升級規則/通知程序
4. 良好的人員訓練以便辯識事故並定義回報制度
5. 根據組織的業務的重要性與敏感性給予相對應的保護
6. 有良好的事故管理監控與量測，這類的量測主要是監看事故回應的能力，並且能夠被定期測試是否符合組織目前的要求

上面提及良好的監控與量測是為了確認以下事項:

1. 資訊資產是被正確的保護(在可接受的風險程度內)
2. 事故回應小組所受的訓練是正確的
3. IRP是有效的而所有相關的利害關係人都有充分了解
4. 事故能夠被快速且正確地確認/分類/圍堵，以及主要原因分析

事故處理有以下功能:

1. 事故的偵測與告警
2. 事故的分類並且能夠分出優順序，並使用有限的資源處理事件
3. 事故分析，發生何事?造成甚麼損失/衝擊?
4. 事故回應，最主要有事前的計畫(如部門間的協同合作)並且執行事故的圍堵跟服務回復的行動。

而事故管理也具有主動性的特質，例如弱點/漏洞管理或資安教育訓練等等。

資安事故必須要有清楚的範圍/目標/實施策略，這個實施策略簡單的說就是我們事故管理的現況(能力)達到我們理想的事故管理能力。這就會產生一個事故管理計畫(IRP)，但產生IRP除了剛剛所提到的還需加上良好的資安政策/標準/程序，而我們也需要一個事故管理團隊(IRT)來執行這一個計劃。這個團隊需要了解以下概念:

1. Security Principle，例如 Confidentiality/Availability/Authentication/Integrity/Access control/Privacy/Nonrepudiation
2. Security vulnerabilities/weaknesses，這通常是特定的攻擊針對軟硬體特定的弱點但不只是邏輯上的實體上的也會有，攻擊可能有分內外部也有分有意於無意的。
3. Internet，一些網路概念如TCP/IP, IPv4/v6, ICMP, UDP, ARP, DNS,NFS等等。
4. 各類的作業系統，Windows/Linux/Mac/Android。像是設定/操作/可能的攻擊/活動的監控/回復等等。
5. 惡意的程式(病毒/木馬程式/勒索軟體/APT攻擊)。
6. 各類開發語言的概念，適合在甚麼作業系統運作/語言的優缺點是甚麼?/是否有特別需要在資安上注意的程式寫法或library等等。

而團隊要包含的不只是IT技術人員，而是在事故發生事會影響到的各單位都可能需要加入。例如若事故是因為惡意的員工哪麼HR與法務部門就會在此團隊中，若影響擴及外部消費者哪公關部門也會是成員之一。

事故管理的目標

通常有如下目標:

1. 當事故發生時能夠被快速的遏止或解決並在規定的RTO內回復服務
2. 將系統回復到正常運作
3. 防止之前的事故再度發生
4. 主動地尋找對策來防止或最小化事故發生的可能(這一點類似Google 的SRE概念)

為了達成以上的目標我們需要有一個良好的監控能力，來監控我們的控制措施是否失效。

制定事故管理程序

每個組織的事故管理程序可能都不盡相同，但大都有這五種基本程序並且是依循且循環進行的。分別是 準備/保護/偵測/分類/回應，最後再回到準備程序。

準備程序:
又可稱為"改進"或"支援"，這一流程是在準備事故管理所需要的事前準備工作及資源。另外還會因為回應程序的回饋會有事故的資訊調查讓事故的管理程序更完善。

保護程序(基礎設施保護):
此ㄧ程序是當事故發生時組織重要的資料及IT設施能夠被持續的保護。

偵測程序(事件的偵測):
偵測與辨識會使組織的重要業務功能中斷的不正常或可疑的活動。這裡我們有兩種偵測方式會同時進行，主動與被動。主動偵測可能像是滲透測試/弱掃/網路的監控等。被動偵測可能是組織一般的使用者給我們的不正常回報活外部廠商ㄧ些資安資訊等。

分類程序:
對事件的嚴重程度做分類，基本上判斷標準分為戰術面與戰略層面，戰術成面大都是以定義好的規則來分類，戰略層面就是組織受影響的業務。根據受影響的程度來判斷哪些可能可以等待那些需要馬上解決的。

回應程序:
這裡有三種回應型態，
1.技術層面: 大都是IT部門需要對事件進行遏止或圍堵後期可能要對相對應的IT設備進行log或資料的分析。
2. 管理階層: 事件的協調處理，事件通知/事件升級/或同意某種特別對應的方式。
3.法務層面: 此事件可能涉及組織內外部的人員有關犯罪的活動。

評估現有的事故回應能力

通常有三種方式來評估，第一種詢問公司高層/各BU主管/IT主管。第二種自我評估，組織內若有IMT團隊可以進行此種評估，但通常會容易跟組織的業務面脫節。第三種外部團隊評估，請外部的專家團隊來進行。
在執行此類評估時有一些資料或因素都需要列入考量中，像是過去的事故事件紀錄或是組織面對的威脅，而威脅大都分為此四類:
1.環境上的: 大都是自然災害，與組織的人員與設備所在地有關。
2.技術上的: 組織會用到的設備，IT/通信設備/空調等等。
3.人為的:惡意與非惡意的。
再來是漏洞/弱點，包含了系統面的/技術/流程/人員/控制措施等這些會讓組織有弱點產生的。

發展事故回應計畫(IRP)

事故回應計畫主要有六個部分組成，別分是:

1. 準備:可能是以下方式
   制定何種方式來處理事故
   制定政策與在IT系統中警告訊息
   制定事故發生時的聯絡計畫
   事故的回報規則與授權
   確保事故發生時有可用的設備或資源
2. 辨認:
   主要是要在時間的壓力下確認事故的真實程度(可能是警報)及影響範圍。也需要保存證據與事件升級的程度的必要性等。
3. 圍堵:
   一旦事件被確認就需要進行圍堵不讓事件繼續擴大。通知受影響的部門單位或人員，一同進行圍堵的行動並在事後進行紀錄。
4. 清除:
   一旦圍堵成功後就需要進行事件清除，需要知道主要發生的原因並從中消除此事件。例如系統中毒了，清除病毒可能無法完全清除我們可能需要進行系統重新安裝的程序。
5. 回復:
   在組織的BCP內規定的RTP將受影響的範圍回復回來
6. Lesson learned:
   這裡會產生一個事故報告給所有相關的部門與人員，主要是相同的事情不要再犯。

為了讓組織的業務與其他單位都了解IRP的重要性以及ㄧ同制定IRP我們需要進行BIA(Business impact analysis)，進行BIA是為了讓組織單位了解到事故會讓組織內重要的系統服務中斷或完全喪失可用性的後果。另外執行BIA後也會跟據時間的因素產生一個事件升級程序，也需要根據BIA讓使用者對系統的回復的重要性做出優先順序(用最少的資源回復)。BIA的報告可以是定性分析(使用排序的方式)或定量分析(跟錢比較相關)。BIA在事故管理中有三個目標:
1.重要業務的流程確認與依重要性分優先順序。對業務的衝擊越大重要性越高。
2.業務中斷時間的預估。大都使用MTD(maximum tolerable downtime)或是MTO(maximum tolerable outage)來評估。
3.資源需求預估。 恢復重要的業務流程縮需要的資源(時間/金錢/人力等等)。
而BIA的評估會包含以下的活動
1.資料的收集 — -大都是業務單位的面訪，了解他們的重要的業務流程/活動/工作等。
2.分析資訊 — -這裡有以下幾個子步驟
2.1 確認整個業務流程中的工作/步驟/活動/資源的相依性為何?
2.2 探索所有中斷業務中的工作/步驟/活動/資源可能。
2.3 接下來紀錄這一些可能中斷業務的威脅
2.4 根據這些紀錄做出定性或定量分析
2.5提出替代方案讓業務盡快回復
3. 紀錄評估結果並提出建議
BIA通常會指出組織在遭遇事故時可能是直接上的財務損失或者是無形上的損失(組織的名聲或是對於法規法令的不合規)。另外BIA必須經常更新(就是不斷的評估)，因為弱點/威脅/風險是不斷在變動的。

事件升級流程

主要是為了當事故在特定的時間內無法被解決時就要提升到下一個處理階段，可能是用更多的資源去處理或是採用替代方案來對應。最重要的是定義這個流程中誰可以宣告是事故需要處理由誰來處理，如果超過甚麼時間就必須進入下一階段或替代方案(哪又是誰有權定宣告)這一些都需要在此流程中被定義出來，千萬不要傻傻的等廠商修好。有興趣可以看這一個案例，這是小弟之前根據17直播在GCP在案例而寫的。

我們需要有一個IMT事故管理團隊來處理這一些事件，這個團隊是有組織內各部門的人員所組成。團隊內成員能夠知道他們的責任與義務是甚麼，組織需要提供這些成員在職訓練(組織內的資安政策/標準/程序/可用的工具/資安行為準則等)與正式的訓練(本身的專業技能)才有能力處理相對應的事故。

事故管理計畫的挑戰

通常有幾個具挑戰性的地方
1.老闆不買單或組織沒這個共識。
2.計畫與組織的業務目標脫鉤。
3.事故管理團隊的成員更換頻繁。
4.缺乏與各部門之間的溝通計畫。
5.計畫太複雜或範圍可能很大。

營運持續與災難回復程序

營運持續就是防止/減緩/回復組織的業務中斷。而營運持續中包含了災難回復，這是聚焦在回復某些特定的業務的持續性，這兩個名詞我們這邊簡稱BC/DRP。對組織在策略上來說就是在這三者中(風險管理/事故管理與回應/BC/DRP)達到三者的平衡並取得最具成本效益。事故管理就是要處理組織面對的威脅，而在處理威脅上事故管理的主動性可以達成
1.消除或中和威脅。
2.將威脅發生的可能性最小化。(通常是消除或減少弱點/漏洞/曝險程度)。
3. 當事故發生時將威脅的影響最小化。(減少衝擊並採取修正及補償性的控制措施)。在IT技術的部份Google的SRE對這一部分著墨很深。

通常BCP(營運持續計畫)中包含了DRP，BCP的目標是事故的預防與減緩而DRP在事故發生後將服務回復到正常的水準。BCP聚焦在組織業務面的持續營運而DRP聚焦在IT服務的回復。當我們在另一個地點執行DRP的活動時我們也需要另一個團隊在原來的地點盡快回復，因為當你在另一個地點啟用服務時你已經沒有backup site可以使用了(不過若你的IT服務是使用多雲架構就可以解決這個隱憂)。

從純IT的角度來說，我們在傳統機房會因為IT的管理量能與費用限制了我們的DRP的選擇。傳統機房的選擇(Duplicate/Mirror/Hot/Warm/Cold site)會因為設備的費用與地點讓我們的RTO也有所限制，但你的IT服務若全都在雲端並且你的架構/程式設計良好並符合雲端的特性。有時可以達到cold site價錢但卻又Hot site的量能。
我們選擇recovery site的形式(Duplicate/Mirror/Hot/Warm/Cold site)通常有幾種考量
1. AIW(acceptable interruption windows) —從宣告啟動BCP到回復組織可以接受的最小服務量能所要花費的時間。
2. RTO
3.RPO
4. SDO(Service Delivery Objective) — 組織可接受的最小服務量能
5. 地點-主機房與備用機房的距離。
6.相近因素 — 例如資訊機房的可能會淹水，淹水有沒有可能來自於機房的冷卻系統呢?
7.天然災害
上面的一到四點都跟備用機房的資源是有關的，但是雲端運算在這四點的限制都沒有傳統機房的限制來得高。另外我們經常要把BCP/DRP的文件放在傳統機房，但從存IT的角度來說在雲端的概念上則不需要這種東西，因為重建機房服務的一切工作你都可以自動化。

最後這一些計畫我們必須要來實作與驗證是否可行並驗證結果來調整計畫，且建立我們對這一個計劃的信心。測試與實作的形式分成以下幾種
1. checklist review — 這是最初步的驗證，基本上是紙上作業。檢查要回復的項目是不是都在計畫中。
2.Structure walkthrough — 這比上一個再多一點但ㄧ樣是紙上作業，依計畫步驟一個一個對應是否正確。
3. Simulation test — 一樣是紙上作業但團隊的成員都要參加並依據設想的災難狀況ㄧ步地來對應。
4. Parallel test — -真實的在backup site啟用服務但沒有轉移實際業務過來。
5. Full interruption test — 完全地將公司業務流程轉至backup site。

這些計畫有幾個量測指標我們需要注意
1.時間--整個程序/各項工作花費了多少時間，有沒有超過組織規定的RTO。
2. 花費的資源 — -使用了組織的人力/IT資源
3. 服務回復的百分比或數量。是不是回復的重要的服務?回復多少的程度?
4.正確性--在primary site的服務流程/資料流程等是不是如同在backup site一樣重現。