事件回應模式
儘管採取了預防措施,仍會發生安全性事件。Trust 結構需要針對可偵測性、快速回應、鑑識調查和寬鬆復原而設計。此頁面合併來自 Trust 支柱「事件回應」區段的事件回應模式,涵蓋偵測結構、回應程序、鑑識功能和事件後學習。
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 事件監視 | ✅ 啟用「事件監視」,以透過路由至 SIEM 平台,以便保留超過原生保留限制的登入模式、大量資料匯出、權限變更和 API 活動 |
| 交易安全性原則 | ✅ 設定即時評估事件的原則,以封鎖可疑動作、要求逐步驗證,或根據行為基準觸發通知 |
| 設定稽核追蹤 | ✅ 監視管理組態變更,啟用 180 天保留的偵測未經授權的修改 |
| 自訂應用程式記錄 | ✅ 在 Apex 中實作與安全性相關的事件記錄,以捕捉驗證失敗、授權拒絕和可疑的輸入模式 |
| 健康檢查監視 | ✅ 設定可能表示未經授權變更的安全性基準中組態漂移的自動偵測 |
| SIEM 整合 | ✅ 將「事件監視」記錄路由至企業 SIEM 平台,以與企業安全性距離測量和行為分析相關聯 |
| 警示規則 | ✅ 設計警示規則以偵測可疑模式 (營業時間外大量存取、從新地理位置登入、快速權限升級),並使用行為基準來儘量減少假陽性 |
| 行為分析 | ✅ 建立行為基準,以針對異常資料存取量、暫時管理活動和 API 耗用模式啟用異常偵測 |
| 多管道偵測 | ✅ 透過「事件監視」、「交易安全性」、「設定稽核追蹤」、自訂記錄和「健康檢查」實作偵測,提供多個獨立偵測訊號 |
| 固定的記錄儲存空間 | ✅ 將記錄路由至攻擊者即使透過管理 Salesforce 存取權也無法修改的固定的外部儲存空間,以確保鑑識證據完整性 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 僅限原生記錄保留 | ⚡️ 僅依賴原生 Salesforce 稽核追蹤保留視窗 (「事件監視」原生限制、180 天「設定稽核追蹤」),而不需外部歸檔,在調查需要歷程記錄分析時發現記錄已過期 |
| 無行為基準 | ⚡️ 沒有異常偵測的行為基準,產生過多的假陽性警示,以訓練安全性小組忽略通知 |
| 無 SIEM 整合 | ⚡️ 缺少企業 SIEM 整合,缺少與其他系統安全性遠距測量相關聯的機會,這會顯示更廣泛的妥協模式 |
| 手動記錄檢閱 | ⚡️ 視定期手動記錄檢閱而非自動警示而定,在發生重大損毀的週或數月後發現事件 |
| 無交易安全性原則 | ⚡️ 沒有即時交易安全性原則,無法在發生損害之前封鎖可疑動作 |
| 不完整的涵蓋範圍 | ⚡️ 僅監視與安全性相關事件 (登入但無法存取資料、組態變更但無法修改權限) 的子集,以建立盲點 |
| 警示疲勞 | ⚡️ 無須調整即可產生過多假陽性警示,訓練小組忽略包括合法安全性事件在內的通知 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 隔離邊界 | ✅ 設計結構,讓入侵的元件可以透過權限集撤銷、IP 限制變更或工作階段終止來隔離,而不會中斷重要業務功能 |
| 工作階段管理 | ✅ 針對入侵的帳戶實作快速工作階段終止功能,包括強制登出和在所有啟用的工作階段中工作階段無效 |
| 權限撤銷 | ✅ 透過權限集授與權限,而非基準設定檔,以快速撤銷:移除權限集指派會在沒有設定檔或其他指派獨立授與相同權限時撤銷存取權 |
| IP 限制 | ✅ 針對特權帳戶設定設定檔層級登入 IP 範圍,以完全拒絕從其他地址登入,以便快速與已知管理位置隔離網路層級 |
| 使用者帳戶凍結 | ✅ 實作阻止驗證的帳戶凍結程序,同時保留資料以供調查,而不刪除入侵的帳戶 |
| API 存取控制 | ✅ 使用權杖撤銷功能設計 API 驗證,以快速隔離入侵的整合帳戶 |
| 多組織隔離 | ✅ 針對高價值的資產,評估多組織結構,以提供最強大的關鍵元件隔離,而造成作業複雜度增加 |
| 緊急休息玻璃程序 | ✅ 透過使用後稽核和驗證,維護緊急管理存取的已記錄斷玻璃存取程序 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 沒有隔離邊界 | ⚡️ 缺少結構隔離邊界,需要完整的系統關機才能包含任何妥協,進而中斷所有業務功能 |
| 過度允許的存取權 | ⚡️ 授與廣泛的「修改所有資料」權限,以防止細微權限撤銷,而不會中斷多個業務流程 |
| 共用服務帳戶 | ⚡️ 在多個系統之間使用單一共用的「API 使用者」或「整合使用者」帳戶,避免特定入侵整合的隔離,而不會中斷所有整合 |
| 沒有 IP 限制 | ⚡️ 沒有特權帳戶的 IP 允許清單,且在帳戶遭到入侵時缺乏網路層級容納功能 |
| 無工作階段管理 | ⚡️ 缺少需要重設密碼的工作階段終止功能,這是強制登出唯一的方法,進而在重要回應期間導致延遲 |
| 無緊急程序 | ⚡️ 沒有記錄的中斷玻璃或緊急存取程序,在啟用事件期間在壓力下 improvise 重要決策 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 事件監視記錄 | ✅ 使用足夠的詳細資料以用於鑑識分析,來捕捉詳細的活動記錄,包括使用者動作、API 呼叫、驗證事件和資料存取模式 |
| 欄位稽核追蹤 | ✅ 啟用「欄位稽核追蹤」,以保留符合法規需求的「受限制」和「機密」欄位資料變更歷程記錄 (支援無限保留;根據法規確認必要期間) |
| 固定的儲存空間 | ✅ 將記錄路由至攻擊者無法修改的外部固定的儲存空間,以確保整個調查的鑑識證據完整性 |
| 設定稽核追蹤 | ✅ 保留管理組態變更歷程記錄,啟用 180 天保留的未經授權系統修改調查 |
| 範疇評估 | ✅ 設計權限模型和資料存取控制,以根據入侵的帳戶權限快速評估資料曝光範圍 |
| 變更關聯性 | ✅ 維護「設定稽核追蹤」組態變更與「事件監視」活動模式之間的關聯,以啟用攻擊者技術的調查 |
| 資料存取記錄 | ✅ 記錄「受限制」與「機密」資料的所有存取權,以便調查在認可期間公開的資料 |
| 整合稽核追蹤 | ✅ 瞭解整合系統的 API 驗證、授權和資料交換模式,以便調查跨系統入侵 |
| 證據保留 | ✅ 持續將記錄與稽核追蹤路由至固定的外部儲存空間,以便在調查事件時保留與使用鑑識證據 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 可變動記錄儲存空間 | ⚡️ 僅在 Salesforce 中儲存記錄,其中具有管理存取權的攻擊者可以刪除或修改鑑識證據 |
| 記錄詳細資料不足 | ⚡️ 在沒有足夠詳細資料以供調查的情況下捕捉高層級事件 (已記錄登入但未記錄 IP 位址、已記錄資料存取但未記錄特定記錄) |
| 無資料存取記錄 | ⚡️ 缺少對「受限制」與「機密」資料的存取權詳細記錄,無法在缺口通知期間評估資料曝光範圍 |
| 遺失欄位稽核追蹤 | ⚡️ 未針對敏感欄位啟用「欄位稽核追蹤」,無法判斷入侵期間顯示的資料值 |
| 無變更關聯性 | ⚡️「設定稽核追蹤」組態變更與後續「事件監視」活動模式之間沒有關聯功能 |
| 已刪除稽核歷程記錄 | ⚡️ 允許稽核歷程記錄在法規保留最短的部署規範集前到期,進而造成規範違規 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 復原時間目標 | ✅ 針對安全性事件案例 (而不只是災害復原案例),定義並測試復原時間目標 (RTO) 和復原點目標 (RPO) |
| 已測試的復原程序 | ✅ 已入侵帳戶、大量資料洩漏、未經授權的部署、權限升級和每季測試封裝的文件復原流程 |
| 備份驗證 | ✅ 定期驗證備份完整性,確保還原功能在安全性事件期間運作,而不只是營運失敗 |
| 回復功能 | ✅ 針對未經授權的程式碼部署或惡意組態變更,使用經測試的回復程序設計部署管道 |
| 認證輪替 | ✅ 針對入侵的整合帳戶、API 使用者和已命名認證實作快速認證輪換程序 |
| 權限還原 | ✅ 在事件回應期間,記錄在過寬隔離動作後還原適當存取權的程序 |
| 資料還原 | ✅ 設計資料復原功能以解決安全性事件造成的資料損毀或刪除,而非災害復原 |
| 服務持續性 | ✅ 架構解決方案,讓安全性事件回應程序在調查和補救期間維持重要業務功能的連續性 |
| 還原驗證 | ✅ 每季測試復原程序,驗證還原的系統是否正常運作,且在還原過程中未經妥協 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 未經測試的程序 | ⚡️ 從未透過演練測試過已記錄的復原程序,在實際事件中發現程序不完整或不正確 |
| 無安全性的 RTO/RPO | ⚡️ 僅針對災害復原定義復原時間目標,而不考慮需要不同的復原程序的安全性事件情況 |
| 無回復功能 | ⚡️ 缺少未經授權程式碼部署的部署回復程序,需要完整重新開發才能移除惡意變更 |
| 未驗證的備份 | ⚡️ 切勿測試備份還原,在事件期間發現備份損毀或不完整 |
| 無認證輪替程序 | ⚡️ 沒有入侵整合帳戶的快速認證輪換程序,在調查期間將入侵認證保持啟用 |
| 手動復原流程 | ⚡️ 完全依據事件期間的手動復原程序,在速度非常重要時導入錯誤和延遲 |
| 無還原測試 | ⚡️ 永不驗證還原的系統在復原後是否正常運作,可能會重新導致入侵或資料損毀 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 入侵的使用者帳戶回應 | ✅ 文件程序:凍結使用者、強制重設認證、檢閱「設定稽核追蹤」與資料存取記錄以瞭解入侵期間、評估資料曝光範圍、如果已存取「受限制」資料,則執行缺口通知 |
| 大量資料外洩回應 | ✅ 文件程序:立即撤銷工作階段、限制權限、識別受影響的記錄和分類層級,在部署的時間表內執行法規違規通知 |
| 未授權的程式碼部署回應 | ✅ 文件程序:立即回復部署、稽核已入侵認證中的所有變更、檢閱授權略過的管道安全性、掃描已部署程式碼以找出永久的後端 |
| 權限升級回應 | ✅ 文件程序:立即撤銷升級權限、稽核以升級存取權執行的活動、調查升級如何略過批准控制,實作補償控制 |
| AppExchange 封裝配套回應 | ✅ 文件程序:區隔封裝權限、評估封裝存取的資料、評估封裝取代選項,以及記錄針對封裝評估條件學習的經驗 |
| 偵測訊號 | ✅ 設定監視以偵測每個案例:已入侵帳戶的登入異常、用於外洩的報告匯出量、未經授權程式碼的部署監視、用於升級的權限變更監視 |
| 桌上型電腦演練 | ✅ 針對驗證小組整備與程序完整性的平台特定案例,執行桌上型演練測試回應程序 |
| 回應自動化 | ✅ 即時交易安全性原則會自動封鎖可疑的動作、需要逐步驗證,或通知回應者高度信賴的偵測訊號,以提供自動控制以減少回應時間 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 僅限一般回應計畫 | ⚡️ 僅擁有不含 Salesforce 特定指引的一般事件回應程序,在啟用事件期間 improvising 平台特定動作 |
| 無偵測組態 | ⚡️ 未設定監視以偵測平台特定的案例 (大量匯出、權限升級、未經授權的部署),透過使用者報告或稽核探索事件 |
| 無桌上型電腦演練 | ⚡️ 永不執行桌上演練,驗證小組熟悉平台特定回應程序,探索實際事件期間的 Knowledge 缺口 |
| 無自動化 | ⚡️ 針對沒有即時交易安全性原則的所有事件,自動控制的完整手動回應,當立即封鎖可能減少損害時導入延遲 |
| 缺少回應手冊 | ⚡️ 缺少常見情況 (入侵的使用者帳戶、資料外洩、未經授權的程式碼部署) 的已記錄回應播放簿 |
| 無違規通知程序 | ⚡️ 沒有法規違規通知需求的程序,在時間表緊湊時,在實際事件期間忙於瞭解義務 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 頻外通訊 | ✅ 建立不依賴潛在入侵系統 (電話樹狀結構、外部傳訊平台) 的通訊管道,以協調回應 |
| 升級程序 | ✅ 使用連絡人資訊和升級條件記錄從初始偵測到執行通知的升級路徑 |
| 通知範本 | ✅ 針對常見事件類型維護預先草稿的通知範本,以便快速與利害關係人、客戶和監管機構通訊 |
| 利害關係人識別 | ✅ 識別需要不同事件類型通知的利害關係人,包括主管、法律、合規性、受影響的使用者和監管機關 |
| 法規通知時間表 | ✅ 記錄每個管轄區的法規通知需求,並根據部署的規範法規確認,並使用確保及時合規性的程序 |
| 內部協調 | ✅ 設計事件協調程序,指定角色和責任 (事件指揮官、技術負責人、通訊負責人、法律聯繫人) |
| 外部協調 | ✅ 建立適當與 Salesforce 支援、外部鑑識調查人員、法律顧問和執法機構的協調程序 |
| 狀態通訊 | ✅ 在啟用事件期間實作一般狀態通訊步調,讓利害關係人取得通知,而無須讓調查小組壓倒性 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 無頻外通訊 | ⚡️ 完全依據潛在入侵的電子郵件或內部傳訊進行事件協調,在主要管道遭到入侵時會失去通訊功能 |
| 不明確的升級路徑 | ⚡️ 沒有記錄的升級程序,導致延遲並混淆應通知的人員和時間 |
| 無通知範本 | ⚡️ 在時間壓力下改善啟用事件期間的事件通知,導致通訊不完整或不正確 |
| 缺少利害關係人清單 | ⚡️ 沒有預先識別的利害關係人清單,在事件期間發現重要對象 (法律、合規性、主管) 未收到通知 |
| 無法規時程表認知 | ⚡️ 未瞭解事件回應期間套用至您部署的法規通知時間表、缺少期限並建立其他違規 |
| 不明確的角色 | ⚡️ 具有不明確的事件回應角色和責任,導致混淆誰有權決定限制 |
| 無外部協調程序 | ⚡️ 沒有已建立的關係或程序可在需要時與 Salesforce 支援、鑑識調查人員或執法人員互動 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 無罪的文化 | ✅ 將事件後審查專注於系統改善,而非個人指責,讓組織學習不必擔心後果 |
| 事件時程表文件 | ✅ 使用精確的時間戳記記記錄完整事件時程表,包括初始認可、偵測、回應動作和解決方案 |
| 控制失敗分析 | ✅ 識別哪些預防和偵測控制無法防止或偵測事件,進而通知結構改善 |
| 結構劣勢文件 | ✅ 文件結構弱點,由安全性變更的架構決策記錄 (ADR) 事件所顯示 |
| 補救措施優先順序 | ✅ 根據風險減少潛力排定補救優先順序,解決根本原因而非症狀 |
| 學習共用 | ✅ 跨小組和業務單位共用學習的經驗,避免組織其他部分發生類似事件 |
| 偵測規則更新 | ✅ 根據調查期間觀察的攻擊技術更新偵測規則和行為基準 |
| 回應程序精簡 | ✅ 根據實際事件回應期間運作的項目與未運作的項目更新事件回應程序 |
| 度量追蹤 | ✅ 追蹤平均偵測時間 (MTTD)、平均回應時間 (MTTR),以及隨時間的影響範圍,以識別需要結構投資的趨勢 |
| 檢閱步調 | ✅ 及時執行事件後審查,同時詳細資料保持最新狀態且有改善的動力 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 略過的評論 | ⚡️ 略過事件後審查,直接移至下一個事件,而無須獲取學習的經驗或結構改善 |
| 責責文化 | ⚡️ 將事件後審查專注於個人責任,而非系統改善,導致事件隱藏並防止組織學習 |
| 無結構文件 | ⚡️ 無法記錄由「結構決策記錄」(ADR) 中事件學習所驅動的安全性結構變更 |
| 症狀治療 | ⚡️ 僅處理事件的症狀 (密碼已入侵),而不修正根本原因 (缺乏 MFA),讓類似攻擊成功 |
| 無訓練共用 | ⚡️ 在回應小組內保留事件學習,而非跨組織共用,允許在其他業務單位中發生類似事件 |
| 無偵測更新 | ⚡️ 無法根據觀察的攻擊技術更新偵測規則或行為基準,且仍容易受到類似攻擊 |
| 無度量追蹤 | ⚡️ 未追蹤平均偵測時間 (MTTD)、平均回應時間 (MTTR) 或範圍趨勢、缺少機會以識別系統弱點 |
| 延遲審查 | ⚡️ 當遺忘詳細資料且失去改善動力時,在事件解決後幾個月執行事件後審查 |
| 無補救措施後續追蹤 | ⚡️ 在事件後審查期間識別改善方式,但無法實作,讓類似事件循環發生 |