安全性網域：作業安全性
作業安全性網域可確保ISV針對威脅執行者所面臨的各種威脅，實作一組強大的安全性風險降低技術。 這是設計來保護作業環境和軟體開發程式，以建置安全的環境。
認知訓練
安全性意識訓練對組織而言很重要，因為它有助於將人為錯誤所造成的風險降到最低，而此錯誤牽涉到超過90%的安全性缺口。 它可協助員工瞭解安全性措施和程式的重要性。 提供安全性認知訓練時，它會強化安全性感知文化的重要性，讓使用者知道如何辨識和回應潛在威脅。 有效的安全性認知訓練計劃應包含內容，涵蓋使用者可能面臨的各種主題和威脅，例如社交工程、密碼管理、隱私權和實體安全性。
控制節點 1
請提供證據：
組織會為資訊系統使用者提供已建立的安全性意識訓練， (包括經理、資深主管和約聘人員) ：
作為新使用者初始訓練的一部分。
信息系統需要變更時。
組織定義的認知訓練頻率。
檔和監視個別資訊系統安全性感知活動，並以組織定義的頻率保留個別的訓練記錄。
意圖：為新用戶進行訓練
此子點著重於建立針對所有員工以及加入組織的新員工所設計的強制安全性認知訓練計劃，而不論其角色為何。 這包括經理、資深主管和約聘人員。 安全性意識計劃應該包含一套完整的課程，旨在提供組織資訊安全性通訊協議、原則和最佳做法的基礎知識，以確保組織的所有成員都符合一組統一的安全性標準，從而建立具復原性的信息安全性環境。
指導方針：為新用戶進行訓練
大部分的組織都會利用平臺型安全性認知訓練與系統管理文件的組合，例如原則檔和記錄，來追蹤整個組織所有員工的訓練完成。 提供的辨識項必須顯示員工已完成訓練，而且應該使用概述安全性認知需求的支持原則/程序來備份。
範例辨識項：為新用戶進行訓練
下列螢幕快照顯示用來追蹤新員工上線的 Confluence 平臺。 已為新員工提出 JIRA 票證，包括其指派、角色、部門等。在新的入門程式中，已選取安全性意識訓練並指派給員工，該員工必須在 2023 年 2 月 28 日的到期日 之前完成。
此螢幕快照顯示 Knowb4 在員工成功完成安全性認知訓練時所產生的完成憑證。 完成日期是 2023 年 2 月 21日 ，在指派的期間內。
意圖：資訊系統變更。
此子點的目標是確保每當組織資訊系統有重大變更時，就會起始自適性安全性感知訓練。 修改的原因可能是軟體更新、架構變更或新的法規需求。 更新的訓練會話可確保所有員工都收到新變更的相關通知，以及對安全性措施產生的影響，讓他們能夠據此調整其動作和決策。 這種主動式方法對於保護組織的數位資產免於可能因系統變更而產生的弱點至關重要。
指導方針：信息系統變更。
大部分的組織都會利用平臺型安全性認知訓練和系統管理文件的組合，例如原則文件和記錄，來追蹤所有員工的訓練完成。 提供的辨識項必須示範各種員工已根據組織系統的不同變更完成訓練。
範例辨識項：信息系統變更。
下一個螢幕快照顯示將安全性感知訓練指派給各種員工，並示範網路釣魚模擬發生。
每當發生系統變更或測試失敗時，平臺會用來指派新的定型。
意圖：認知訓練的頻率。
此子點的目標是要定義定期安全性認知訓練的組織特定頻率。 這可以每年、每半年或組織決定的不同間隔來排程。 藉由設定頻率，組織可確保使用者會定期更新威脅的演進環境，以及新的保護措施和原則。 這種方法有助於在所有使用者之間維持高階的安全性意識，並強化先前的訓練元件。
指導方針：認知訓練的頻率。
大部分的組織都有系統管理檔和/或技術解決方案，可概述/實作安全性認知訓練的需求和程式，以及定義訓練的頻率。 提供的辨識項應該會示範在定義的期間內完成各種認知訓練，而且貴組織有一個定義的期間存在。
範例辨識項：認知訓練的頻率。
下列螢幕快照顯示安全性感知原則檔的快照集，以及該檔存在並進行維護。 此原則要求組織的所有員工都接受安全性感知訓練，如原則的範圍一節中所述。 訓練必須由相關部門每年指派並完成。
根據原則檔，組織的所有員工都必須完成三個課程 (一個訓練和兩個評定，) 每年和在指派后的二十天內完成。 課程必須透過電子郵件傳送，並透過 KnowBe4 指派。
提供的範例只會顯示原則的快照集，請注意，預期會提交完整的原則檔。
第二個螢幕快照是原則的接續，它會顯示檔中規定年度訓練需求的區段，並示範組織定義的認知訓練頻率設定為每年。
接下來的兩個螢幕快照示範如何成功完成先前所述的訓練評定。 螢幕快照取自兩位不同員工。
意圖：檔和監視。
此子點的目標是建立、維護及監視每位用戶參與安全性認知訓練的記錄。 這些記錄應該保留在組織定義的期間內。 本文件可作為符合法規和內部原則的可稽核線索。 監視元件可讓組織評估的有效性
訓練、識別改善的領域，以及瞭解用戶參與程度。 藉由在定義的期間內保留這些記錄，組織就可以追蹤長期有效性和合規性。
指導方針：文件和監視。
可為安全性認知訓練提供的辨識項，將取決於如何在組織層級實作訓練。 這可能包括訓練是透過平臺進行，還是根據內部程式在內部執行。 提供的辨識項必須顯示在一段時間內為所有使用者完成訓練的歷程記錄，以及如何追蹤。
範例辨識項：文件和監視。
下一個螢幕快照顯示每個用戶的歷程訓練記錄，包括其加入日期、訓練完成，以及下一次訓練排程的時間。 本文件的評量會定期執行，每年至少執行一次，以確保每位員工的安全性意識訓練記錄保持在最新狀態。
惡意代碼保護/反惡意代碼
惡意代碼會對組織造成重大風險，視惡意代碼特性而定，這可能會對作業環境造成的安全性影響有所不同。 威脅執行者已發現惡意代碼可以成功獲利，這已透過勒索軟體樣式惡意代碼攻擊的成長來實現。 惡意代碼也可以用來提供輸入點，讓威脅執行者入侵環境以竊取敏感數據，也就是遠端訪問特洛伊木馬程式/Rootkits。 因此，組織必須實作適當的機制來防範這些威脅。 可用的防禦是防病毒軟體 (AV) /Endpoint Detection and Response (EDR) /Endpoint Detection and Protection Response (EDPR) /啟發式掃描使用人工智慧 (AI) 。 如果您已部署不同的技術來降低惡意代碼的風險，請讓認證分析師知道誰會樂於探索這是否符合意圖。
控制節點 2
請提供證據，證明您的反惡意代碼解決方案已在所有取樣的系統元件中啟用，並已設定為符合下列準則：
如果已開啟存取掃描的防病毒軟體，且簽章在 1 天內為最新狀態，則為 。
適用於在偵測到惡意代碼時自動封鎖惡意代碼或警示和隔離的防病毒軟體
或者，如果是 EDR/EDPR/NGAV：
正在執行該定期掃描。
正在產生稽核記錄。
會持續保持在最新狀態，並具有自我學習功能。
它會封鎖已知的惡意代碼，並根據宏行為以及具有完整額度功能來識別和封鎖新的惡意代碼變體。
意圖：存取時掃描
此子點的設計目的是要確認已在所有取樣的系統元件上安裝反惡意代碼軟體，並且正在主動執行存取掃描。 控件也規定反惡意代碼解決方案的簽章資料庫在一天的時間範圍內是最新的。 最新的簽章資料庫對於識別和減輕最新的惡意代碼威脅非常重要，因此可確保系統元件受到充分保護。
指導方針：存取時掃描**.**
若要示範 AV 的作用中實例正在評估的環境中執行，請為範例集中支援使用反惡意代碼的分析師所同意的每個裝置提供螢幕快照。 螢幕快照應該會顯示反惡意代碼正在執行，而且反惡意代碼軟體正在使用中。 如果有反惡意代碼的集中式管理控制台，則可能會提供來自管理控制台的辨識項。 此外，請務必提供螢幕快照，顯示已取樣的裝置已連線並正常運作。
範例辨識項：存取時掃描**.**
下列螢幕快照取自 Windows Server 裝置，其中顯示已針對主機名 「IaaS-Web-app」 啟用 「Microsoft Defender」。
下一個螢幕快照是從 Windows Server 裝置擷取，其中顯示 Microsoft Defender Antimalware 安全性情報版本已從 Windows 事件查看器更新記錄檔。 這會示範主機名 「IaaS-Web-app」 的最新簽章。
此螢幕快照取自 Windows Server 裝置，其中顯示Microsoft Defender 反惡意代碼防護更新。 這清楚地顯示威脅定義版本、建立的版本，以及最後一次更新，以示範主機名 「IaaS-Web- app」 的惡意代碼定義是最新的。
意圖：反惡意代碼封鎖。
此子點的目的是要確認反惡意代碼軟體已設定為在偵測時自動封鎖惡意代碼，或產生警示，並將偵測到的惡意代碼移至安全的隔離區域。 這可確保在偵測到威脅時立即採取動作、減少弱點的視窗，以及維護系統的強式安全性狀態。
指導方針：反惡意代碼區塊。
提供範例中支援使用反惡意代碼之每個裝置的螢幕快照。 螢幕快照應該會顯示反惡意代碼正在執行，並設定為自動封鎖惡意代碼、警示或隔離和警示。
範例辨識項：反惡意代碼區塊。
下一個螢幕快照顯示主機 「IaaS-Web-app」 已針對 Microsoft Defender Antimalware 設定為開啟實時保護。 如設定所示，這會找出並阻止惡意代碼在裝置上安裝或執行。
意圖：EDR/NGAV
此子點的目的是要確認端點偵測和回應 (EDR) 或新一代防病毒軟體 (NGAV) 正在所有取樣的系統元件上主動執行定期掃描;稽核記錄是針對追蹤掃描活動和結果而產生的;掃描解決方案會持續更新，並擁有自我學習功能以適應新的威脅環境。
指導方針：EDR/NGAV
提供EDR/NGAV解決方案的螢幕快照，示範取樣系統中的所有代理程式都在報告中，並顯示其狀態為作用中。
範例辨識項：EDR/NGAV
OpenEDR 解決方案的下一個螢幕快照顯示主機 「IaaS-Web-app」 的代理程式正在使用中並回報。
OpenEDR 解決方案的下一個螢幕快照顯示已啟用實時掃描。
下一個螢幕快照顯示警示是根據已從系統層級安裝的代理程式即時取得的行為計量來產生。
OpenEDR 解決方案的下一個螢幕快照示範稽核記錄和警示的設定和產生。 第二個影像顯示已啟用原則，並已設定事件。
OpenEDR 解決方案的下一個螢幕快照示範解決方案會持續保持在最新狀態。
意圖：EDR/NGAV
此子點的重點在於確保 EDR/NGAV 能夠自動封鎖已知的惡意代碼，並根據宏行為識別和封鎖新的惡意代碼變體。 它也可確保解決方案具有完整的核准功能，讓組織允許受信任的軟體，同時封鎖所有其他軟體，進而增加額外的安全性層級。
指導方針：EDR/NGAV
根據所使用的解決方案類型，可以提供辨識項來顯示解決方案的組態設定，以及解決方案具有機器學習/啟發學習法功能，以及設定為在偵測時封鎖惡意代碼。 如果在解決方案上預設會實作設定，則廠商文件必須驗證此設定。
範例辨識項：EDR/NGAV
OpenEDR 解決方案的下一個螢幕快照示範安全配置檔 v7.4 已設定為強制執行即時掃描、封鎖惡意代碼和隔離。
來自 Secure Profile v7.4 組態的下一個螢幕快照示範解決方案會根據較傳統的反惡意代碼方法來實作「即時」掃描，該方法會掃描已知的惡意代碼簽章，以及將「啟發學習法」掃描設定為中層級。 此解決方案會檢查檔案和以可疑/非預期或惡意方式運作的檔案和程序代碼，以偵測並移除惡意代碼。
掃描器已設定為解壓縮封存，並掃描內部的檔案，以偵測可能在封存下遮罩本身的潛在惡意代碼。此外，掃描儀會設定為封鎖Microsoft Office 檔案內的微腳本。
下一個螢幕快照示範安全配置檔 v.7.4 已指派至我們的 Windows Server 裝置 'IaaS-Web-app' 主機。
下一個螢幕快照取自 Windows Server 裝置 'IaaS-Web-app'，其示範 OpenEDR 代理程式已在主機上啟用並執行。
惡意代碼保護/應用程控
應用程控是一種安全性做法，可封鎖或限制未經授權的應用程式以讓數據面臨風險的方式執行。 應用程控是公司安全性計劃的重要部分，可協助防止惡意執行者惡意探索應用程式弱點，並降低缺口的風險。 藉由實作應用程控，企業和組織可以大幅降低與應用程式使用量相關聯的風險和威脅，因為如果應用程式將網路或敏感數據置於風險中，就無法執行應用程式。 應用程控可為作業和安全性小組提供可靠、標準化且系統化的方法，以降低網路風險。 它們也可讓組織更完整地瞭解其環境中的應用程式，這可協助IT和安全性組織有效地管理網路風險。
控制節點 3
請提供證明，示範：
您有一份核准的軟體/應用程式清單，其中包含業務理由：
存在且保持在最新狀態，而且
每個應用程式都會經過核准程式，並在部署之前先註銷。
該應用程控技術已在所有取樣的系統元件上啟用、啟用及設定，如所述。
意圖：軟體清單
此子點旨在確保已核准的軟體和應用程式清單存在於組織內，並持續保持在最新狀態。 請確定清單上的每個軟體或應用程式都有記載的商業理由，以驗證其必要性。 此清單可作為規範軟體和應用程式部署的權威參考，因此有助於消除可能會造成安全性風險的未經授權或備援軟體。
指導方針：軟體清單
包含已核准軟體和應用程式清單的檔，如果是以數位檔 (Word、PDF 等 ) 。 如果透過平臺維護核准的軟體和應用程式清單，則必須提供來自平臺的清單螢幕快照。
範例辨識項：軟體清單
下一個螢幕快照示範 Confluence Cloud 平臺中已核准的軟體和應用程式清單。
下一個螢幕快照示範已核准的軟體和應用程式清單，包括要求者、要求日期、核准者、核准日期、控制機制、JIRA 票證、系統/資產。
意圖：軟體核准
此子點的目的是要確認每個軟體/應用程式在組織內部署之前都經過正式核准程式。 核准程式應包含技術評估和主管註銷，以確保已考慮操作和策略性觀點。 藉由建立這個嚴格的程式，組織可確保只部署經過審查且必要的軟體，藉此將安全性弱點降至最低，並確保與商務目標保持一致。
指導方針
您可以提供辨識項，以顯示正在遵循核准程式。 這可以透過已簽署的檔、在變更控制系統內追蹤，或使用 Azure DevOps/JIRA 之類的專案來追蹤變更要求和授權來提供。
範例辨識項
下一個螢幕快照示範 JIRA Software 中的完整核准程式。 使用者 'Jane Doe' 已提出「允許 Qualys 雲端代理程式」安裝在 'IaaS-Web-app' 和 'IaaS-VM- Backend' 伺服器的要求。 'Andrew Smith' 已檢閱要求，並以「根據反惡意代碼的商務需求核准」批注加以核准。 Qualys 提供的更新和修補程式。 要核准的軟體。
下一個螢幕快照顯示在允許應用程式在生產伺服器上執行之前，透過 Confluence 平臺上引發的票證授與核准。
意圖：應用程控技術
此子點著重於確認所有取樣系統元件的應用程控技術為作用中、已啟用且設定正確。 請確定技術會根據記載的原則和程序運作，以作為其實作和維護的指導方針。 透過使用中、啟用及妥善設定的應用程控技術，組織可協助防止執行未經授權或惡意軟體，並增強系統的整體安全性狀態。
指導方針：應用程控技術
提供檔，詳細說明應用程控的設定方式，以及示範如何設定每個應用程式/進程的適用技術辨識項。
範例辨識項：應用程控技術
下一個螢幕快照示範 Windows 組策略 (GPO) 設定為僅強制執行已核准的軟體和應用程式。
下一個螢幕快照顯示允許透過路徑控制執行的軟體/應用程式。
注意：在這些範例中，未使用全螢幕快照，不過所有ISV提交的辨識項螢幕快照必須是顯示任何URL、登入使用者以及系統時間和日期的全螢幕快照。
修補程式管理/修補和風險排名
修補程式管理通常稱為修補，是任何強固網路安全性策略的重要元件。 它牽涉到系統化程式來識別、測試，以及將修補程式或更新套用至軟體、作業系統和應用程式。 修補程式管理的主要目標是降低安全性弱點，確保系統和軟體能夠持續抵禦潛在威脅。 此外，修補程式管理包含風險排名在排定修補程序優先順序中的重要元素。 這牽涉到根據弱點的嚴重性和對組織安全性狀態的潛在影響來評估弱點。 藉由將風險分數指派給弱點，組織可以有效率地配置資源，專注於立即解決重大和高風險的弱點，同時維持主動對抗新興威脅。 有效的修補程式管理和風險排名策略不僅可增強安全性，也有助於IT基礎結構的整體穩定性和效能，協助組織在不斷演進的網路安全性威脅環境中保持復原能力。
若要維護安全的操作環境，必須適當地修補應用程式/附加元件和支持系統。 必須管理識別 (或公開發行) 與修補之間的適當時間範圍，以減少威脅執行者利用弱點的機會範圍。 Microsoft 365 認證不規定「修補視窗」;不過，認證分析師會拒絕不合理或符合業界最佳做法的時間範圍。 此安全性控制群組也位於平臺即服務 (PaaS) 裝載環境的範圍內，因為應用程式/載入宏第三方軟體連結庫和程式代碼基底必須根據風險排名進行修補。
控制節點 4
提供辨識項，讓修補程式管理原則和程式文件定義下列所有專案：
適合用於嚴重/高和中風險弱點的最小修補視窗。
解除委任不支援的操作系統和軟體。
如何識別新的安全性弱點並指派風險分數。
意圖：修補程式管理
許多安全性合規性架構都需要修補程式管理，例如PCI-DSS、ISO 27001、NIST (SP) 800-53、FedRAMP 和SOC 2。 良好修補程式管理的重要性不能過度強調
因為它可以更正軟體、韌體中的安全性和功能問題，並減輕弱點，這有助於減少惡意探索的機會。 此控件的目的是要將威脅執行者的機會範圍降到最低，以利用可能存在於範圍內環境中的弱點。
提供完整涵蓋下列層面的修補程式管理原則和程序檔：
適合用於嚴重/高和中風險弱點的最小修補視窗。
組織的修補程式管理原則和程式文件必須針對分類為重大/高和中風險的弱點，明確地定義適當的最小修補視窗。 這類布建會根據弱點的風險層級，建立在識別弱點之後必須套用修補程式的最大允許時間。 藉由明確陳述這些時間範圍，組織將修補程式管理的方法標準化，將與未修補弱點相關的風險降至最低。
解除委任不支援的操作系統和軟體。
修補程式管理原則包含解除委任不支援之操作系統和軟體的布建。 不再接收安全性更新的操作系統和軟體會對組織的安全性狀態造成重大風險。 因此，此控件可確保及時識別並移除或取代這類系統，如原則檔中所定義。
- 概述如何識別新的安全性弱點並指派風險分數的文件程式。
修補作業必須以風險為基礎、弱點的風險也比較高，需要更快速地補救。 已識別弱點的風險排名是此程式不可或缺的一部分。 此控件的目的是要確保已記載的風險排名程式已遵循，以確保所有已識別的弱點都會根據風險適當地排名。 組織通常會利用一般弱點評分系統 (CVSS) 廠商或安全性研究人員所提供的評等。 如果組織依賴 CVSS，建議在程式中包含重新排名機制，以允許組織根據內部風險評估來變更排名。 有時候，此弱點可能不適用，因為應用程式在環境中的部署方式。 例如，可能會釋放 Java 弱點，這會影響組織未使用的特定連結庫。
注意：即使您是在單純的平臺即服務 『PaaS/無伺服器』環境中執行，您仍須負責識別程式代碼基底內的弱點：也就是第三方連結庫。
指導方針：修補程式管理
提供原則檔。 必須提供系統管理證據，例如原則和程式檔，詳細說明組織定義的程式，其中涵蓋指定控件的所有元素。
注意：邏輯辨識項可以提供為支持辨識項，以進一步深入瞭解貴組織的弱點管理計劃 (VMP) ，但不會自行符合此控件。
範例辨識項：修補程式管理
下一個螢幕快照顯示修補程式管理/風險排名原則的代碼段，以及不同層級的風險類別。 後面接著分類和補救時間範圍。 請注意：預期ISV會共用實際的支持原則/程序檔，而不只是提供螢幕快照。
(選擇性) 支援原則檔的其他技術辨識項範例
邏輯辨識項，例如弱點追蹤電子表格、弱點技術評估報告，或透過在線管理平臺引發的票證螢幕快照，以追蹤用來支持原則檔中所述之程式實作的弱點狀態和進度。 下一個螢幕快照示範 Snyk 是軟體組合分析 (SCA) 工具，可用來掃描程式代碼基底是否有弱點。 後面接著透過電子郵件的通知。
請注意：在這些範例中，未使用全螢幕快照，不過所有ISV提交的辨識項螢幕快照必須是顯示任何URL的全螢幕快照，並登入使用者和系統時間和日期。
接下來的兩個螢幕快照顯示 Snyk 標幟新弱點時所收到的電子郵件通知範例。 我們可以看到電子郵件包含受影響的專案，以及接收警示的指派使用者。
下列螢幕快照顯示已識別的弱點。
請注意：在先前的範例中，未使用全螢幕快照，不過所有ISV提交的辨識項螢幕快照必須是顯示URL的全螢幕快照，任何已登入的使用者和系統時間和日期。
範例辨識項
下一個螢幕快照顯示已設定並啟用 GitHub 安全性工具，以掃描程式代碼基底內的弱點，並透過電子郵件傳送警示。
接下來顯示的電子郵件通知是確認已標幟的問題將會透過提取要求自動解決。
範例辨識項
下一個螢幕快照顯示透過電子錶格的內部技術評估和弱點排名。
範例辨識項
下一個螢幕快照顯示在 DevOps 中針對每個探索到的弱點所引發的票證。
個別員工在實作變更之前，會先進行評量、排名和檢閱。
控制節點 5
提供可示範的辨識項：：
正在修補所有取樣的系統元件。
提供不支援的作業系統和軟體元件不在使用中的可辨識證據。
意圖：取樣的系統元件
此子點旨在確保提供可驗證的辨識項，以確認組織內所有取樣的系統元件正在主動修補。 辨識項可能包含但不限於修補程式管理記錄、系統稽核報告，或顯示已套用修補程式的文件程式。 在使用無伺服器技術或平臺即服務 (PaaS) 時，這應該延伸為包含程式代碼基底，以確認正在使用最新且安全的連結庫和相依性版本。
指導方針：取樣的系統元件
提供範例中每個裝置的螢幕快照，並支援軟體元件，其中顯示修補程式已與記載的修補程式一起安裝。 此外，提供示範程式代碼基底修補的螢幕快照。
範例辨識項：取樣的系統元件
下一個螢幕快照示範 Linux 操作系統虛擬機 'IaaS- VM-Backend' 的修補。
範例辨識項
下一個螢幕快照示範 Windows 操作系統虛擬機 『IaaS-Web-app』 的修補。
範例辨識項
如果您要維護任何其他工具的修補，例如 Microsoft Intune、適用於雲端的 Defender 等，則可以從這些工具提供螢幕快照。 OpenEDR 解決方案的下一個螢幕快照示範修補程式管理是透過 OpenEDR 入口網站執行。
下一個螢幕快照示範範圍內伺服器的修補程式管理是透過OpenEDR平臺來完成。 下方會顯示分類和狀態，以示範進行修補。
下一個螢幕快照顯示已針對伺服器上成功安裝的修補程式產生記錄。
範例辨識項
下一個螢幕快照示範如何透過 Azure DevOps 修補程式代碼基底/第三方連結庫相依性。
下一個螢幕快照顯示 Snyk 所探索到弱點的修正程式正在認可至分支，以解決過時的連結庫。
下一個螢幕快照示範連結庫已升級至支援的版本。
範例辨識項
下一個螢幕快照示範透過 GitHub Dependabot 維護程式代碼基底修補。 已關閉的專案會示範修補已發生，且弱點已解決。
意圖：不支援的OS
不由廠商維護的軟體會因已知的弱點而無法修正，而加班時會受到影響。 因此，不支援操作系統和軟體元件的使用不得在生產環境中使用。 部署基礎結構即服務 (IaaS) 時，此子點的需求會擴展為同時包含基礎結構和程式代碼基底，以確保技術堆疊的每一層都符合組織使用支援軟體的原則。
指導方針：不支援的OS
提供分析人員所選取範例集中每個裝置的螢幕快照，以收集辨識項，以針對顯示執行中的操作系統版本 (在螢幕快照) 中包含裝置/伺服器的名稱。 此外，提供證明在環境中執行的軟體元件正在執行支持的軟體版本。 這可以藉由提供內部弱點掃描報告的輸出來完成， (提供已驗證的掃描包含) 和/或檢查第三方連結庫的工具輸出，例如 Snyk、Trivy 或 NPM 稽核。 如果在 PaaS 中執行，則只需要涵蓋第三方連結庫修補。
範例辨識項：不支援的OS
下一個來自 Azure DevOps NPM 稽核的螢幕快照示範 Web 應用程式內沒有使用不支援的連結庫/相依性。
注意：在下一個範例中，未使用全螢幕快照，不過所有ISV提交的辨識項螢幕快照必須是顯示URL的全螢幕快照，任何已登入的使用者和系統時間和日期。
範例辨識項
來自 GitHub Dependabot 的下一個螢幕快照示範 Web 應用程式內沒有使用連結庫/相依性。
範例辨識項
下一個透過OpenEDR的Windows作業系統軟體清查螢幕快照示範找不到不支援或過時的作業系統和軟體版本。
範例辨識項
下一個螢幕快照來自OS 摘要底下的OpenEDR，其中顯示Windows Server 2019 Datacenter (x64) 和OS完整版本歷程記錄，包括 Service Pack、組建版本等等... 驗證找不到不支援的作業系統。
範例辨識項
來自 Linux 作業系統伺服器的下一個螢幕快照示範所有版本詳細數據，包括散發者標識碼、描述、版本和代碼名，驗證找不到不支援的 Linux 作業系統。
範例辨識項：
Nessus 弱點掃描報告的下一個螢幕快照示範目標計算機上找不到不支援的作業系統 (OS) 和軟體。
請注意：在先前的範例中，未使用全螢幕快照，不過所有ISV提交的辨識項螢幕快照必須是顯示URL的全螢幕快照，任何已登入的使用者和系統時間和日期。
弱點掃描
弱點掃描會尋找組織計算機系統、網路和 Web 應用程式中可能的弱點，以找出可能導致安全性缺口和敏感數據暴露的漏洞。 產業標準與政府法規通常需要弱點掃描，例如PCI DSS (支付卡產業數據安全標準) 。
名為「2020 PCI DSS 合規性的安全性計量指南」的安全性計量報告指出，「從組織看到攻擊者入侵系統時，平均需要166天的時間。 一旦遭到入侵，攻擊者平均可以存取敏感數據 127 天，因此此控件旨在識別範圍內環境內的潛在安全性弱點。
藉由引進一般弱點評估，組織可以偵測其環境中的弱點和不安全性，而這些弱點和不安全性可能會為惡意執行者提供危害環境的進入點。 弱點掃描有助於識別環境中遺失的修補程式或設定錯誤。 藉由定期進行這些掃描，組織可以提供適當的補救措施，以將由於這些弱點掃描工具經常挑選的問題而導致的危害風險降到最低。
控制節點 6
請提供證明，示範：
每季會執行基礎結構和 Web 應用程式弱點掃描。
如果環境是 IaaS、混合式或內部部署，則必須針對整個公用使用量 (IP/URL) 和內部 IP 範圍執行掃描。
注意：這必須包含環境的完整範圍。
意圖：弱點掃描
此控制項旨在確保組織每季進行弱點掃描，同時以其基礎結構和 Web 應用程式為目標。 掃描必須完整，涵蓋公用IP和URL等公用使用量，以及內部IP範圍。 掃描的範圍會根據組織基礎結構的本質而有所不同：
如果組織實作混合式、內部部署或基礎結構即服務 (IaaS) 模型，則掃描必須同時包含外部公用 IP/URL 和內部 IP 範圍。
如果組織實作平臺即服務 (PaaS) ，則掃描只能包含外部公用 IP/URL。
此控制項也要求掃描應包含環境的完整範圍，因此不會取消核取任何元件。 目標是要識別和評估組織技術堆疊所有部分的弱點，以確保全面的安全性。
指導方針：弱點掃描
針對過去 12 個月執行的每季弱點掃描，提供完整掃描報告 (的) 。 報告應該清楚陳述目標，以驗證是否包含完整的公用使用量，以及在適用的情況下，每個內部子網。 提供每季的所有掃描報告。
範例辨識項：弱點掃描
下一個螢幕快照顯示網路探索，以及透過外部基礎結構上的Nmap執行的埠掃描，以識別任何不安全的開放埠。
注意：無法自行使用Nmap來符合此控件，因為預期必須提供完整的弱點掃描。 Nmap 埠探索是以下所示弱點管理程式的一部分，並由針對外部基礎結構的 OpenVAS 和 OWASP ZAP 掃描來補充。
此螢幕快照顯示透過OpenVAS針對外部基礎結構進行弱點掃描，以識別任何設定錯誤和未處理的弱點。
下一個螢幕快照顯示來自 OWASP ZAP 的弱點掃描報告，其中示範動態應用程式安全性測試。
範例辨識項：弱點掃描
下列來自可租用 Nessus Essentials 弱點掃描報告的螢幕快照顯示已執行內部基礎結構掃描。
先前的螢幕快照示範針對主機 VM 進行每季掃描的資料夾設定。
上述和以下的螢幕快照顯示弱點掃描報告的輸出。
下一個螢幕快照顯示報告的接續，其中涵蓋找到的所有問題。
控制節點 7
請提供示範下列專案的重新掃描辨識項：
- 控件 6 中所識別之所有弱點的補救，會依照您原則中定義的最小修補視窗進行修補。
意圖：修補
無法快速識別、管理和補救弱點和設定錯誤，可能會增加組織遭到入侵而導致潛在數據外泄的風險。 正確識別和補救問題對於組織的整體安全性狀態和環境而言很重要，這符合各種安全性架構的最佳做法，例如 ISO 27001 和 PCI DSS。
此控件的目的是要確保組織提供重新掃描的可靠辨識項，並示範控件 6 中識別的所有弱點都已修復。 補救必須與組織修補程式管理原則中定義的最小修補視窗一致。
指導方針：修補
提供重新掃描報告，確認控件 6 中識別的任何弱點都已依照控件 4 中定義的修補視窗進行補救。
範例辨識項：修補
下一個螢幕快照顯示在 2023 年 8 月 2日，名為 Thor 的單一電腦 (範圍內環境的 Nessus 掃描，) 顯示弱點。
下一個螢幕快照顯示問題已解決，2 天后會在修補原則內定義的修補視窗內。
注意：在先前的範例中，未使用全螢幕快照，但已提交所有ISV
辨識項螢幕快照必須是顯示任何 URL、登入使用者以及系統時間和日期的全螢幕快照。
網路安全性控制 (NSC)
網路安全性控制是網路安全性架構的基本元件，例如 ISO 27001、CIS 控件和 NIST 網路安全性架構。 它們可協助組織管理與網路威脅相關聯的風險、保護敏感數據免於未經授權的存取、遵守法規需求、及時偵測和響應網路威脅，以及確保商務持續性。 有效的網路安全性可保護組織資產免於遭受來自組織內部或外部的各種威脅。
控制節點 8
提供可辨識的辨識項：：
- 網路安全性控制 (NSC) 會安裝在範圍內環境的界限上，並安裝在周邊網路和內部網路之間。
AND 如果混合式、內部部署，IaaS 也會提供證據：
- 所有公用存取都會在周邊網路終止。
意圖：NSC
此控制已確認 NSC) (網路安全性控制已安裝在組織網路拓撲內的主要位置。 具體而言，NSC 必須放在範圍內環境的界限上，以及周邊網路與內部網路之間的界限。 此控件的目的是要確認這些安全性機制正確定位，以最大化其保護組織數字資產的有效性。
指導方針：NSC
應該提供辨識項，以證明 NSC) (網路安全性控制已安裝在界限上，並在周邊和內部網路之間設定。 透過提供來自網路安全性控制 (NSC) 組態設定的螢幕快照，以及套用至範圍的螢幕快照，例如防火牆或對等技術，例如 Azure 網路安全組 (NSG) 、Azure Front Door 等。
範例辨識項：NSC
下一個螢幕快照來自 Web 應用程式 'PaaS-web-app';[網络] 刀鋒視窗示範所有輸入流量都會通過 Azure Front Door，而從應用程式到其他 Azure 資源的所有流量都會透過 VNET 整合透過 Azure NSG 路由傳送和篩選。
「存取限制」內的拒絕規則會防止來自 Front Door (FD) 以外的任何輸入，流量會在到達應用程式之前透過 FD 路由傳送。
範例辨識項：NSC
下列螢幕快照顯示 Azure Front Door 的預設路由，而且流量會在到達應用程式之前透過 Front Door 路由傳送。 也已套用 WAF 原則。
範例辨識項：NSC
第一個螢幕快照顯示在 VNET 層級套用的 Azure 網路安全組，以篩選輸入和輸出流量。 第二個螢幕快照示範 SQL Server 無法透過因特網路由傳送，並透過 VNET 和私人鏈接進行整合。
這可確保 NSG 會先篩選內部流量和通訊，再到達 SQL Server。
意圖**:** 混合式、內部部署、IaaS
對於操作混合式、內部部署或基礎結構即服務 (IaaS) 模型的組織而言，此子點是不可或缺的。 它試圖確保所有公用存取都會在周邊網路終止，這對控制進入內部網路的進入點，並降低可能暴露於外部威脅的可能性非常重要。 合規性的辨識項可能包括防火牆設定、網路訪問控制清單，或其他類似的檔，可證明公用存取不會延伸到周邊網路以外的宣告。
範例辨識項：混合式、內部部署、IaaS
此螢幕快照示範 SQL Server 無法透過因特網路由傳送，且已透過 VNET 和私人鏈接進行整合。 這可確保只允許內部流量。
範例辨識項：混合式、內部部署、IaaS
下一個螢幕快照示範網路分割已在範圍內的虛擬網路內就緒。 如下所示的 VNET 分成三個子網，每個子網都已套用 NSG。
公用子網會作為周邊網路。 所有公用流量都會透過此子網路由傳送，並透過具有特定規則的NSG進行篩選，而且只允許明確定義的流量。 後端是由沒有公用存取權的私人子網所組成。 所有 VM 存取僅允許透過 Bastion 主機存取，該主機已在子網層級套用自己的 NSG。
下一個螢幕快照顯示流量只能從因特網流向埠 443 上的特定IP位址。 此外，RDP 只允許從 Bastion IP 範圍到虛擬網路。
下一個螢幕快照示範後端無法透過因特網路由傳送 (這是因為 NIC) 沒有公用 IP，而且只允許流量來自虛擬網路和 Bastion。
此螢幕快照示範 Azure Bastion 主機僅用於存取虛擬機以進行維護。
控件 No. 9
NSC) (所有網路安全性控件都設定為卸除規則基底內未明確定義的流量。
網路安全性控制 (NSC) 規則檢閱至少每 6 個月執行一次。
意圖：NSC
此子點可確保組織中所有網路安全性控制 (NSC) 都設定為卸除規則基底內未明確定義的任何網路流量。 目標是在網路層強制執行最低許可權原則，方法是只允許授權的流量，同時封鎖所有未指定或可能的惡意流量。
指導方針：NSC
為此提供的辨識項可能是顯示輸入規則的規則組態，以及這些規則的終止位置;藉由將公用IP位址路由傳送至資源，或提供輸入流量的NAT (網路位址轉換) 。
範例辨識項：NSC
此螢幕快照顯示 NSG 組態，包括預設規則集和自定義 Deny：All 規則，以重設所有 NSG 的預設規則，並確保禁止所有流量。 在其他自定義規則中， Deny：All 規則會明確定義允許的流量。
範例辨識項：NSC
下列螢幕快照顯示已部署 Azure Front Door，所有流量都會透過 Front Door 路由傳送。 套用「預防模式」中的 WAF 原則，以篩選潛在惡意承載的輸入流量並加以封鎖。
意圖：NSC
如果沒有定期檢閱，網路安全性控制 (NSC) 可能會過時且無效，讓組織容易遭受網路攻擊。 這可能會導致數據外洩、敏感性資訊遭竊，以及其他網路安全性事件。 定期 NSC 檢閱對於管理風險、保護敏感數據、遵守法規需求、及時偵測和響應網路威脅，以及確保商務持續性至關重要。 此子點要求網路安全性控制 (NSC) 至少每六個月進行一次規則基底檢閱。 定期檢閱對於維護 NSC 設定的有效性和相關性非常重要，特別是在動態變更的網路環境中。
指導方針：NSC
提供的任何辨識項都必須能夠證明規則檢閱會議已發生。 這可以藉由共用 NSC 檢閱的會議分鐘數，以及顯示從檢閱中採取之任何動作的任何其他變更控制辨識項來完成。 請確定檢閱您提交的認證分析師必須查看至少兩個會議檢閱檔的日期， (也就是每隔六個月) 一次。
範例辨識項：NSC
這些螢幕快照示範有六個月的防火牆檢閱存在，而且詳細數據會保留在 Confluence Cloud 平臺中。
下一個螢幕快照示範每個規則檢閱都有在 Confluence 中建立的頁面。 規則檢閱包含已核准的規則集清單，其中概述允許的流量、埠號碼、通訊協定等，以及業務理由。
範例辨識項：NSC
下一個螢幕快照示範在DevOps中維護六個月規則檢閱的替代範例。
範例辨識項：NSC
此螢幕快照示範在 DevOps 中執行並記錄為票證的規則檢閱範例。
上一個螢幕快照顯示已建立的已記載規則清單以及商業理由，而下一個影像則示範來自實際系統之票證內規則的快照集。
變更控制件
建立且了解的變更控制程式對於確保所有變更都經過可重複的結構化程式而言非常重要。 藉由確保所有變更都經過結構化程式，組織可以確保變更在註銷之前會受到有效管理、對等檢閱及適當測試。 這不僅有助於將系統中斷的風險降到最低，也有助於透過引進的不當變更，將潛在安全性事件的風險降到最低。
控件 No. 10
請提供證明，示範：
引進生產環境的任何變更都會透過包含下列專案的文件變更要求來實作：
變更的影響。
備註程式的詳細數據。
要執行的測試。
由授權的人員檢閱和核准。
意圖：變更控件
此控件的目的是要確保已仔細考慮並記載任何要求的變更。 這包括評估變更對系統/環境安全性的影響、記錄在發生錯誤時協助復原的任何備份程式，以及詳細說明驗證變更成功所需的測試。
必須實作程式，這會禁止在未經適當授權的情況下執行變更並註銷。 在實作變更之前，必須先授權變更，而且變更必須在完成後註銷。 這可確保已正確檢閱變更要求，且授權單位中的人員已簽署變更。
指導方針：變更控件
您可以藉由共用變更要求範例的螢幕快照來提供辨識項，示範變更影響的詳細數據、備份程式、測試會保留在變更要求內。
範例辨識項：變更控件
下一個螢幕快照顯示已指派 XSS) 的新跨網站腳本弱點 (，以及變更要求的檔。 下列票證示範已設定或新增至要解決之票證的資訊。
下列兩張票證顯示系統變更的影響，以及發生問題時可能需要的退回程式。 變更和退回程式的影響已通過核准程式，並已核准進行測試。
在下列螢幕快照中，已核准變更的測試，而您會在右側看到變更現在已核准並進行測試。
在整個程式中，請注意，執行此作業的人員、報告該工作的人員，以及核准要完成工作的人員都是不同的人員。
下列票證顯示變更現在已核准，可實作至生產環境。 右方方塊顯示測試已運作且成功，且變更現在已實作至 Prod 環境。
範例辨識項
下一個螢幕快照顯示範例 Jira 票證，其中顯示變更必須先獲得授權，才能由開發人員/要求者以外的人實作和核准。 這些變更會由具有授權的人員核准。 螢幕快照右側顯示變更完成後已由 DP 簽署。
在下列票證中，變更已在完成後註銷，並顯示作業已完成並關閉。
請注意：在這些範例中，未使用全螢幕快照，不過所有ISV提交的辨識項螢幕快照必須是顯示任何URL、登入使用者以及系統時間和日期的全螢幕快照。
控制節點 11
請提供證據：
有個別的環境存在，如此一來：
開發和測試/預備環境會強制將職責與生產環境分開。
職責區隔是透過訪問控制來強制執行。
敏感性生產數據不在開發或測試/預備環境中使用。
意圖：個別的環境
大部分組織的開發/測試環境未設定為與生產環境相同的震動，因此較不安全。 此外，測試不應該在生產環境中執行，因為這可能會造成安全性問題，或對客戶的服務傳遞造成損害。 藉由維護會強制區分職責的個別環境，組織可以確保變更會套用至正確的環境，藉由在開發/測試環境時實作生產環境的變更來降低錯誤的風險。
應設定訪問控制，讓負責開發和測試的人員不需要存取生產環境，反之亦然。 這可將未經授權的變更或數據暴露的可能性降到最低。
在開發/測試環境中使用生產數據可能會增加遭到入侵的風險，並讓組織暴露於數據外泄或未經授權的存取。 此意圖要求任何用於開發或測試的數據都應針對該目的進行清理、匿名或產生。
指導方針：個別的環境
您可以提供螢幕快照，示範用於開發/測試環境和生產環境的不同環境。 一般而言，您會有不同的人員/小組可以存取每個環境，或在無法存取的情況下，環境會利用不同的授權服務來確保使用者無法誤入錯誤的環境來套用變更。
範例辨識項：個別的環境
下一個螢幕快照示範開發/測試的環境與生產環境是分開的，這是透過 Azure 中的資源群組來達成，這是將資源邏輯分組到容器的方式。 達成分隔的其他方式可能是不同的 Azure 訂用帳戶、網路和子網等。
下列螢幕快照顯示此資源群組內的開發環境和資源。
下一個螢幕快照顯示生產環境和此資源群組內的資源。
範例辨識項：
下一個螢幕快照示範開發/測試的環境與生產環境不同。 透過具有與每個環境相關聯之不同許可權的不同使用者/群組，即可充分區分環境。
下一個螢幕快照顯示開發環境和可存取此資源群組的使用者。
下一個螢幕快照顯示生產環境和使用者 (與可存取此資源群組的開發環境) 不同。
指導方針：
您可以針對生產資料庫共用相同 SQL 查詢輸出的螢幕快照來提供辨識項， (修訂任何敏感性資訊) 和開發/測試資料庫。 相同命令的輸出應該會產生不同的數據集。 儲存盤案的位置，檢視這兩個環境內的資料夾內容也應該示範不同的數據集。
範例辨識項
此螢幕快照顯示 (辨識項提交的前 3 筆記錄，請從生產資料庫提供前 20 個) 。
下一個螢幕快照顯示來自開發資料庫的相同查詢，其中顯示不同的記錄。
注意：在此範例中，未使用全螢幕快照，不過所有ISV提交的辨識項螢幕快照必須是顯示URL的全螢幕快照，任何已登入的使用者和系統時間和日期。
安全軟體開發/部署
涉及軟體開發活動的組織通常會面臨安全性與 TTM 之間的競爭優先順序， (上市時間) 壓力，不過，在整個軟體開發生命週期中實作安全性相關活動 (SDLC) 不僅可以節省成本，還可以節省時間。 當安全性保留為事後考慮時，通常只會在 (DSLC) 的測試階段識別出問題，這通常會更耗時且更耗費成本來修正。 本安全性區段的目的是要確保遵循安全的軟體開發做法，以降低將程式代碼錯誤引入開發的軟體中的風險。 此外，本節會尋找包含一些控件，以協助安全部署軟體。
控制節點 12
請提供證明，證明檔存在，並維護：
支援安全軟體的開發，並包含安全編碼的業界標準和/或最佳做法，例如 OWASP 前 10 名或 SANS 前 25 名 CWE。
開發人員每年會進行相關的安全程式碼撰寫和安全軟體開發訓練。
意圖：安全開發
組織必須盡自己的能力來確保軟體安全地開發，並不受弱點影響。 為了達到此目的，應該建立健全的安全軟體開發生命週期 (SDLC) 和安全的程式代碼撰寫最佳做法，以在整個軟體開發程式中推廣安全的程式代碼撰寫技術和安全開發。 其目的是要減少軟體中弱點的數目和嚴重性。
所有程式設計語言都有程式代碼撰寫最佳做法和技術，以確保程式代碼安全地開發。 有一些外部訓練課程旨在教導開發人員不同類型的軟體弱點類別，以及可用來停止將這些弱點引入軟體的程式碼技術。 此控制項的目的是要向所有開發人員教授這些技術，並確保不會忘記這些技術，或是每年執行這項作業來學習較新的技術。
指導方針：安全開發
提供記載的 SDLC 和/或支援檔，其中示範安全開發生命週期正在使用中，並提供指引給所有開發人員，以提升安全的程式代碼撰寫最佳做法。 請參閱 SDLC 中的 OWASP 和 SAMM) (OWASP 軟體保證成熟度模型 。
範例辨識項：安全開發
安全軟體開發原則檔的范例如下所示。 以下是從 Contoso 的安全軟體開發程式擷取，其中示範安全開發和程式代碼撰寫做法。
注意：在先前的範例中，未使用全螢幕快照，不過所有ISV提交的辨識項螢幕快照必須是顯示任何URL、登入使用者以及系統時間和日期的全螢幕快照。
指導方針：安全開發訓練
如果訓練是由外部訓練公司執行，或提供訓練字典或其他成品的螢幕快照，以證明開發人員已參加訓練，請透過憑證提供辨識項。 如果這項訓練是透過內部資源執行，也請提供訓練數據的辨識項。
範例辨識項：安全開發訓練
下一個螢幕快照是要求DevOps小組中的員工註冊 OWASP 十大訓練年度訓練的電子郵件。
下一個螢幕快照顯示已要求具有業務理由和核准的訓練。 接著會接著從訓練中擷取的螢幕快照，以及顯示人員已完成年度訓練的完成記錄。
注意：在此範例中，未使用全螢幕快照，不過所有ISV提交的辨識項螢幕快照必須是顯示URL的全螢幕快照，任何已登入的使用者和系統時間和日期。
控制節點 13
請提供程式代碼存放庫受到保護的辨識項，以便：
所有程式代碼變更都會先由第二位檢閱者進行檢閱和核准程式，再與 main 分支合併。
適當的訪問控制已就緒。
所有存取都會透過多重要素驗證 (MFA) 來強制執行。
針對生產環境 () 的所有發行，都會在部署之前進行檢閱和核准。
意圖：程式代碼檢閱
此子點的目的是要由另一個開發人員執行程式代碼檢閱，以協助識別可能在軟體中造成弱點的任何程式碼撰寫錯誤。 應建立授權以確保執行程式碼檢閱、完成測試等。 部署之前。 授權步驟會驗證已遵循正確的程式，以支援控件 12 中定義的 SDLC。
目標是確保所有程式代碼變更都經過第二個檢閱者的嚴格審查和核准程式，然後再合併到主要分支。 此雙重核准程式可作為品質控制措施，以攔截任何可能危害應用程式完整性的程式碼錯誤、安全性弱點或其他問題。
指導方針：程式代碼檢閱
提供證據，證明程式代碼會進行對等檢閱，而且必須先獲得授權，才能套用至生產環境。 此辨識項可能是透過變更票證的導出，示範程式代碼檢閱已執行且變更已獲授權，或是透過程式代碼檢閱軟體，例如 Crucible
範例辨識項：程式代碼檢閱
下列票證顯示程式代碼變更由原始開發人員以外的人員進行檢閱和授權程式。 它顯示受指派者已要求程式代碼檢閱，並會指派給其他人進行程式代碼檢閱。
下圖顯示程式代碼檢閱已指派給原始開發人員以外的其他人，如影像右側反白顯示的區段所示。 在左側，程式代碼檢閱者已檢閱程式代碼，並給予「已通過的程式代碼檢閱」狀態。 票證現在必須經過經理核准，才能將變更放入實時生產系統。
下圖顯示已核准將檢閱過的程式代碼實作至即時生產系統。 完成程式代碼變更之後，最終作業就會註銷。 請注意，整個程式有三個相關人員，即程式代碼的原始開發人員、程式代碼檢閱者，以及要核准和註銷的經理。 若要符合此控件的準則，預期您的票證會遵循此程式。
注意：在此範例中，未使用全螢幕快照，不過所有ISV提交的辨識項螢幕快照必須是顯示URL的全螢幕快照，任何已登入的使用者和系統時間和日期。
範例辨識項：程式代碼檢閱
除了上述程式的管理部分之外，還可實作新式程式代碼存放庫和平臺等其他控制措施，例如強制執行檢閱的分支原則，以確保在完成這類檢閱之前，無法進行合併。 下列範例顯示在 DevOps 中達成此目的。
下一個螢幕快照顯示已指派預設檢閱者，且自動需要檢閱。
範例辨識項：程式代碼檢閱
您也可以在 Bitbucket 中達成強制執行檢閱的分支原則。
在下一個已設定預設檢閱者的螢幕快照中。 這可確保在變更傳播至主要分支之前，任何合併都需要指派的人員進行檢閱。
後續的兩個螢幕快照會示範所套用組態設定的範例。 以及已完成的提取要求，此要求是由使用者 Silvester 起始，且需要預設檢閱者 Andrew 核准，才能與 main 分支合併。
請注意，提供辨識項時，預期會示範端對端程式。 注意：如果分支原則已就位 (或其他程序設計方法/控制) ，以及核准的票證/記錄，則應提供螢幕快照，以顯示組態設定。
意圖：受限制的存取
從上一個控件開始，應該實作訪問控制，以限制只能存取正在處理特定專案的個別使用者。 藉由限制存取權，您可以限制未經授權變更執行的風險，進而引入不安全的程式碼變更。 應採用最低許可權的方法來保護程式代碼存放庫。
指導方針：受限制的存取
透過程式代碼存放庫的螢幕快照提供辨識項，這些螢幕快照僅限個人所需的存取權，包括不同的許可權。
範例辨識項：受限制的存取
下一個螢幕快照顯示已在 Azure DevOps 中實作的訪問控制。 「CloudDemo 小組」顯示為有兩個成員，且每個成員有不同的許可權。
注意：下一個螢幕快照顯示預期符合此控件的辨識項和格式類型範例。 這不一定很廣泛，而且實際案例在實作訪問控制的方式上可能會有所不同。
如果許可權是在群組層級設定，則必須提供每個群組和該群組使用者的辨識項，如 Bitbucket 的第二個範例所示。
下列螢幕快照顯示 「CloudDemo 小組」 的成員。
上圖顯示 Andrew Smith 具有比下方 Silvester 更高的項目擁有者許可權。
範例辨識項
在下一個螢幕快照中，在 Bitbucket 中實作的訪問控制是透過在群組層級設定的許可權來達成。 針對存放庫存取層級，有一個「系統管理員」群組，其中一位使用者和一個「開發人員」群組與另一位使用者。
下一個螢幕快照顯示每個用戶都屬於不同的群組，而且本身具有不同層級的許可權。 Andrew Smith 是系統管理員，而 Silvester 是開發人員群組的一部分，該群組只會授與開發人員許可權。
意圖：MFA
如果威脅執行者可以存取和修改軟體的程式代碼基底，它們可能會在程式代碼基底中引進弱點、後門程式代碼或惡意代碼，因而進入應用程式。 已經有數個實例，其中最公開的可能是 2020 年 SolarWinds 攻擊，攻擊者將惡意代碼插入到稍後包含在 SolarWinds Orion 軟體更新中的檔案中。 超過 18,000 名 SolarWinds 客戶安裝了惡意更新，且惡意代碼散佈未偵測到。
此子點的目的是要確認所有對程式代碼存放庫的存取都是透過多重要素驗證 (MFA) 來強制執行。
指導方針：MFA
透過程式代碼存放庫中所有使用者都已啟用 MFA 的螢幕快照來提供辨識項。
範例辨識項：MFA
如果在 Azure DevOps 中儲存和維護程式代碼存放庫，則根據在租用戶層級設定 MFA 的方式而定，可以從 AAD 提供辨識項，例如「每位使用者 MFA」。 下一個螢幕快照顯示已針對 AAD 中的所有用戶強制執行 MFA，這也適用於 Azure DevOps。
範例辨識項：MFA
如果組織使用 GitHub 之類的平臺，您可以透過從「組織」帳戶共用辨識項來示範已啟用 2FA，如下一個螢幕快照所示。
若要檢視是否在 GitHub 上針對組織的所有成員強制執行 2FA，您可以瀏覽至組織的 [設定] 索引卷標，如下一個螢幕快照所示。
流覽至 GitHub 中的 [人員] 索引標籤，可以確定已為組織內的所有使用者啟用 “2FA”，如下一個螢幕快照所示。
意圖：檢閱
此控件的目的是要由另一位開發人員在開發環境中執行發行檢閱，以協助識別任何程式代碼撰寫錯誤，以及可能造成弱點的設定錯誤。 應建立授權以確保執行發行檢閱、完成測試等。 在生產環境中部署之前。 授權。 步驟可以驗證是否已遵循支援 SDLC 原則的正確程式。
指導方針
提供辨識項，證明從測試/開發環境到生產環境的所有發行，都會由與啟動器不同的人員/開發人員進行檢閱。 如果是透過持續整合/持續部署管線來達成此目的，則提供的辨識項必須顯示 (與強制執行檢閱 ) 程式代碼檢閱相同。
範例辨識項
在下一個螢幕快照中，我們可以看到 CI/CD 管線正在 Azure DevOps 中使用中，管線包含兩個階段：開發和生產。 發行已觸發並成功部署至開發環境，但尚未傳播到生產) 的第二個階段 (，且正等待 Andrew Smith 核准。
預期一旦部署至開發，安全性測試會由相關小組進行，而且只有當具有正確授權檢閱部署的指派人員已執行次要檢閱，且符合所有條件時，才會授與核准，以允許發行進入生產環境。
通常會由指派的檢閱者收到的電子郵件警示，告知已觸發預先部署條件，且正在擱置檢閱和核准。
檢閱者可以使用電子郵件通知流覽至 DevOps 中的發行管線，並授與核准。 如下所示，已新增批注來證明核准的合理性。
在第二個螢幕快照中，會顯示核准已授與，且發行進入生產環境已成功。
接下來的兩個螢幕快照會顯示預期的辨識項範例。
辨識項會顯示歷程記錄版本，而且會強制執行部署前的條件，而且必須先進行檢閱和核准，才能部署至生產環境。
下一個螢幕快照顯示版本的歷程記錄，包括我們可以看到已在開發和生產環境中成功部署的最近版本。
注意：在先前的範例中，未使用全螢幕快照，不過所有ISV提交的辨識項螢幕快照必須是顯示URL、任何已登入使用者和系統時間和日期的全螢幕快照。
Account management
安全帳戶管理做法很重要，因為用戶帳戶是允許存取資訊系統、系統環境和數據的基礎。 用戶帳戶必須受到適當保護，因為使用者認證遭到入侵，不僅可以提供環境的據點和敏感數據的存取權，也可以在使用者的認證具有系統管理許可權時，為整個環境或密鑰系統提供系統管理控制。
控制節點 14
提供辨識項：
默認認證會在取樣的系統元件上停用、移除或變更。
已備妥保護 (強化服務帳戶) 程式，且已遵循此程式。
意圖：預設認證
雖然這會變得較不受歡迎，但仍有威脅執行者可以利用預設且記載完善的使用者認證來危害生產系統元件的實例。 其中一個常用的範例是使用 Dell iDRAC (整合式 Dell 遠端存取控制器) 。 此系統可用來從遠端管理 Dell Server，威脅執行者可以利用它來控制伺服器的作業系統。 root：：calvin 的預設認證已記載，而且通常可由威脅執行者利用來存取組織所使用的系統。 此控件的目的是要確保預設認證已停用或移除，以增強安全性。
指導方針：默認認證
有各種方式可以收集辨識項以支援此控件。 所有系統元件上已設定使用者的螢幕快照都可提供協助，也就是透過命令提示字元 (CMD) 以及 Linux /etc/shadow 和 /etc/passwd 檔案的 Windows 默認帳戶螢幕快照，有助於示範帳戶是否已停用。
範例辨識項：預設認證
下一個螢幕快照顯示 /etc/shadow 檔案，以示範默認帳戶有鎖定的密碼，而新的建立/使用中帳戶具有可用的密碼。
請注意，若要示範帳戶確實已停用，需要 /etc/shadow 檔案，方法是觀察密碼哈希開頭的字元無效，例如 '！'，表示密碼無法使用。 在下一個螢幕快照中，“L” 表示鎖定具名帳戶的密碼。 這個選項會停用密碼，方法是將密碼變更為不符合任何可能加密值的值， (加入 ！在密碼開頭) 。 “P” 表示它是可用的密碼。
第二個螢幕快照示範 Windows 伺服器上已停用所有預設帳戶。 藉由在 CMD) (終端機上使用 『net user』 命令，您可以列出每個現有帳戶的詳細數據，並觀察所有這些帳戶都不在使用中。
藉由在 CMD 中使用 net user 命令，您可以顯示所有帳戶，並觀察所有預設帳戶都不在作用中。
意圖：預設認證
服務帳戶通常會以威脅執行者為目標，因為它們通常會以較高的許可權進行設定。 這些帳戶可能不會遵循標準密碼原則，因為服務帳戶密碼的到期通常會中斷功能。 因此，它們可能會設定為弱式密碼或在組織內重複使用的密碼。 另一個可能的問題，特別是在 Windows 環境中，可能是操作系統快取密碼哈希。 如果是下列任一項，這可能是大問題：
服務帳戶是在目錄服務內設定的，因為此帳戶可以跨已設定許可權等級的多個系統使用存取權，或
服務帳戶是本機帳戶，其可能性是相同的帳戶/密碼會在環境中的多個系統中使用。
先前的問題可能會導致威脅執行者取得環境內更多系統的存取權，並可能導致進一步提高許可權和/或橫向移動。 因此，目的是要確保服務帳戶已正確強化並受到保護，以協助保護它們不受威脅執行者接管，或藉由限制其中一個服務帳戶遭到入侵時的風險。 控件需要有正式程式來強化這些帳戶，其中可能包括限制許可權、使用複雜密碼，以及定期認證輪替。
指導方針
因特網上有許多指南可協助強化服務帳戶。 辨識項可以是螢幕快照的形式，示範組織如何實作帳戶的安全強化。 一些 (預期的範例是會使用多種技術) 包括：
將帳戶限制為 Active Directory 內的一組電腦，
將帳戶設定為不允許互動式登入，
設定極複雜的密碼
針對 Active Directory，啟用 [帳戶敏感且無法委派] 旗標。
範例辨識項
有多種方式可強化將相依於每個個別環境的服務帳戶。 以下是一些可能採用的機制：
下一個螢幕快照顯示服務帳戶 [_Prod SQL 服務帳戶] 上已選取 [帳戶敏感且已委派連線] 選項。
第二個螢幕快照顯示服務帳戶「_Prod SQL 服務帳戶」已鎖定至 SQL Server，且只能登入該伺服器。
下一個螢幕快照顯示服務帳戶「_Prod SQL 服務帳戶」只允許以服務身分登入。
注意：在先前的範例中，未使用全螢幕快照，不過所有ISV提交的辨識項螢幕快照必須是顯示URL、任何已登入使用者和系統時間和日期的全螢幕快照。
控制節點 15
提供辨識項：
唯一的用戶帳戶會簽發給所有使用者。
環境中會遵循使用者最低許可權原則。
已備妥強密碼/複雜密碼原則或其他適當的緩和措施。
程式已就緒，且至少每三個月會遵循一次，以停用或刪除 3 個月內未使用的帳戶。
意圖：保護服務帳戶
此控件的目的是責任。 藉由使用自己的唯一使用者帳戶發行使用者，用戶將負責其動作，因為用戶活動可以追蹤至個別使用者。
指導方針：保護服務帳戶
辨識項是透過螢幕快照顯示跨範圍系統元件設定的用戶帳戶，其中可能包含伺服器、程序代碼存放庫、雲端管理平臺、Active Directory、防火牆等。
範例辨識項：保護服務帳戶
下一個螢幕快照顯示針對範圍內 Azure 環境設定的用戶帳戶，且所有帳戶都是唯一的。
意圖：許可權
用戶應該只獲得履行其工作功能所需的許可權。 這是為了限制使用者刻意或無意中存取不應存取數據或執行 數據的風險
惡意行為。藉由遵循此原則，它也會減少潛在攻擊面 (也就是特殊許可權帳戶) ，這些帳戶可能會成為惡意威脅執行者的目標。
指導方針：許可權
大部分的組織都會利用群組，根據組織內的小組來指派許可權。 辨識項可能是螢幕快照，其中顯示各種特殊許可權群組，且僅顯示需要這些許可權之小組的用戶帳戶。 通常，這會備份支持的原則/程式，以定義具有必要許可權和業務理由的每個已定義群組，以及驗證群組成員資格的小組成員階層已正確設定。
例如：在 Azure 中，「擁有者」群組應該非常有限，因此這應該會記載，而且應該有有限數目的人員指派給該群組。 另一個範例可能是能夠進行程式碼變更的人員人數有限，群組可能會以此許可權設定，且員工成員視為需要設定此許可權。 這應該會記載，讓認證分析師可以與已設定的群組交互參照檔等等。
範例辨識項：許可權
下一個螢幕快照示範 Azure 環境中最低許可權的原則。
下一個螢幕快照醒目提示在 Azure Active Directory 中使用各種群組 (AAD) /Microsoft Entra。 請注意，有三個安全組：開發人員、首席工程師、安全性作業。
在群組層級流覽至「開發人員」群組時，唯一指派的角色是「應用程式開發人員」和「目錄讀取器」。
下一個螢幕快照顯示「開發人員」群組的成員。
最後，下一個螢幕快照顯示群組的擁有者。
相對於「開發人員」群組，「安全性作業」具有指派的不同角色，也就是「安全性操作員」，這符合作業需求。
下一個螢幕快照顯示有不同成員屬於「安全性作業」群組。
最後，群組有不同的擁有者。
全域系統管理員是高度特殊許可權的角色，組織必須在提供這種類型的存取權時，決定他們想要接受的風險層級。 在提供的範例中，只有兩位使用者具有此角色。 這是為了確保受攻擊面和影響降低。
意圖：密碼原則
用戶認證通常是威脅執行者嘗試取得組織環境存取權的攻擊目標。 強密碼原則的目的是要嘗試並強制使用者挑選強密碼，以降低威脅執行者暴力密碼破解他們的機會。 新增「或其他適當的風險降低」的目的是要辨識組織可能會實作其他安全性措施，以根據 NIST特殊發行集 800-63B 等產業發展來協助保護用戶認證。
指導方針：密碼原則
示範強密碼原則的辨識項可能是組織組策略物件或本機安全策略「帳戶原則→密碼原則」和「帳戶原則→帳戶鎖定原則」設定的螢幕快照。 辨識項取決於所使用的技術，也就是針對Linux，它可以是 /etc/pam.d/common-password 組態檔，適用於管理入口網站 [管理您的密碼原則 ] 中 Bitbucket 的 [驗證原則] 區段 | Atlassian支援等等 。
範例辨識項：密碼原則
下列證據顯示在範圍內系統元件 「CONTOSO-SRV1」 的「本機安全策略」內設定的密碼原則。
下一個螢幕快照顯示 WatchGuard 防火牆的帳戶鎖定設定。
以下是 WatchGuard 防火牆的最小複雜密碼長度範例。
請注意：在先前的範例中，未使用全螢幕快照，不過所有ISV提交的辨識項螢幕快照必須是顯示URL的全螢幕快照，任何已登入的使用者和系統時間和日期。
意圖：非使用中的帳戶
非使用中帳戶有時可能會遭到入侵，因為這些帳戶是暴力密碼破解攻擊的目標，可能未標示為使用者不會嘗試登入帳戶，或是因密碼資料庫外泄而導致使用者密碼重複使用，且可在因特網上的使用者名稱/密碼傾印中使用。 應該停用/移除未使用的帳戶，以減少威脅執行者必須執行帳戶入侵活動的攻擊面。 這些帳戶可能是因為離職者程式未正確執行、員工成員長期打勾，或員工成員正在休假/同父期。 藉由實作每季程式來識別這些帳戶，組織可以將受攻擊面降至最低。
此控件會要求至少每三個月執行一次程式，以停用或刪除過去三個月內未使用的帳戶，以確保定期的帳戶檢閱和及時停用未使用的帳戶，以降低風險。
指導方針：非使用中的帳戶
辨識項應該是兩個折疊：
首先，螢幕快照或檔案匯出顯示範圍內環境中所有用戶帳戶的「上次登入」。 這可能是本機帳戶以及集中式目錄服務內的帳戶，例如 AAD (Azure Active Directory) 。 這會示範未啟用超過 3 個月的帳戶。
其次，每季檢閱程式的辨識項，可能是在 ADO (Azure DevOps) 或 JIRA 票證內完成工作的證明，或是透過應該註銷的紙張記錄。
範例辨識項：非使用中的帳戶
下一個螢幕快照示範已使用雲端平台來執行存取權檢閱。 這已使用 Azure 中的身分識別控管功能來完成。
下一個螢幕快照示範檢閱歷程記錄、檢閱期間和狀態。
檢閱形式的儀錶板和計量會提供其他詳細數據，例如組織的所有使用者範圍和檢閱結果，以及每季的頻率。
評估檢閱結果時，影像會指出已提供建議的動作，這是以預先設定的條件為基礎。 此外，還需要指派的人員手動套用檢閱的決策。
您可以在下列內容中觀察到，每個員工都有提供建議和理由。 如前所述，指派的人員必須先決定接受或忽略該建議，才能套用檢閱。 如果最終決定是針對建議，則預期會提供辨識項來說明原因。
控制節點 16
驗證已針對所有遠端訪問連線和所有非控制台系統管理介面設定多重要素驗證 (MFA) ，包括存取任何程式代碼存放庫和雲端管理介面。
這些詞彙的意義
遠端存取 – 這指的是用來存取支援環境的技術。 例如，遠端訪問IPSec VPN、SSL VPN或 Jumpbox/Bastian 主機。
非控制台系統管理介面 – 這指的是系統元件的網路系統管理連線。 這可能是透過遠端桌面、SSH 或 Web 介面。
程式代碼存放庫 – 應用程式的程式代碼基底必須受到保護，以防止惡意修改，而這些修改可能會在應用程式中引入惡意代碼。 必須在程式代碼存放庫上設定 MFA。
雲端管理介面 – 雲端服務提供者 (CSP) 內託管部分或所有環境的位置。 此處包含雲端管理的系統管理介面。
意圖：MFA
此控件的目的是藉由實作 多重要素驗證 (MFA) ，在具有安全存取權的特殊許可權帳戶上提供暴力密碼破解攻擊的風險降低。 即使密碼遭到入侵，MFA 機制仍應受到保護，以確保所有存取和系統管理動作只由授權和信任的員工成員執行。
若要增強安全性，請務必使用 MFA 為遠端存取連線和非控制台系統管理介面新增額外的安全性層級。 遠端訪問連線特別容易受到未經授權的輸入，而系統管理介面會控制高許可權功能，使得這兩個重要區域都需要加強的安全性措施。 此外，程式代碼存放庫包含敏感性開發工作，而雲端管理介面可讓您廣泛存取組織的雲端資源，使其成為應使用 MFA 保護的其他重要點。
指導方針：MFA
辨識項必須顯示已在符合先前類別的所有技術上啟用 MFA。 這可能是透過螢幕快照顯示已在系統層級啟用 MFA。 根據系統層級，我們需要辨識它已針對所有用戶啟用，而不只是已啟用 MFA 的帳戶範例。 在將技術備份至 MFA 解決方案時，我們需要證據來證明它已啟用且正在使用中。 這是什麼意思;其中，技術已針對指向 MFA 提供者的 Radius 驗證進行設定，您也需要辨識其所指向的 Radius 伺服器是 MFA 解決方案，且帳戶已設定為使用它。
範例辨識項：MFA
下一個螢幕快照示範如何在 AAD/Entra 中實作 MFA 條件式原則，以在整個組織中強制執行雙因素驗證需求。 我們可以在下列內容中看到原則為「開啟」。
下一個螢幕快照顯示 MFA 原則會套用至組織內的所有使用者，而且已啟用此功能。
下一個螢幕快照示範在符合 MFA 條件時授與存取權。 在螢幕快照右側，我們可以看到只有在實作 MFA 之後，才會將存取權授與使用者。
範例辨識項：MFA
您可以實作其他控件，例如 MFA 註冊需求，以確保在註冊時，用戶必須先設定 MFA，才能存取其新帳戶。 您可以觀察套用至所有使用者的 MFA 註冊原則設定下方。
在先前顯示要套用而不排除原則的螢幕快照接續中，下一個螢幕快照會示範所有使用者都包含在原則中。
範例辨識項：MFA
下一個螢幕快照顯示[每位使用者 MFA] 頁面正在示範已針對所有用戶強制執行 MFA。
範例辨識項：MFA
下一個螢幕快照顯示在 Pulse Secure 上設定的驗證領域，用於遠端存取環境。 驗證是由適用於 MFA 支援的 Duo SaaS 服務所關閉。
此螢幕快照示範已啟用其他驗證伺服器，指向 『Duo - 預設路由』 驗證領域的 「Duo-LDAP」。
最後一個螢幕快照顯示 Duo-LDAP 驗證伺服器的組態，其示範這是指向 MFA 的 Duo SaaS 服務。
注意：在先前的範例中，未使用全螢幕快照，不過所有ISV提交的辨識項螢幕快照必須是顯示URL、任何已登入使用者和系統時間和日期的全螢幕快照。
安全性事件記錄、檢閱和警示
安全性事件記錄是組織安全性計劃不可或缺的一部分。 足夠的安全性事件記錄，加上已調整的警示和檢閱程式，可協助組織識別組織可用來增強安全性和防禦性安全性策略的缺口或嘗試入侵。 此外，適當的記錄將會受到組織事件回應功能的危害，而這些功能可以饋送至其他活動，例如能夠精確地識別哪些數據和誰的數據遭到入侵、入侵期間、提供詳細的分析報告給政府機關等等。
檢閱安全性記錄是協助組織識別安全性事件的重要功能，這些事件可能表示安全性缺口或偵察活動可能表示即將發生的事件。 這可以透過每日手動程式來完成，或是使用 SIEM (安全性資訊和事件管理) 解決方案來協助分析稽核記錄，尋找可標示為手動檢查的相互關聯和異常。
必須立即調查重大安全性事件，以將對數據和作業環境的影響降到最低。 警示有助於立即向員工強調潛在的安全性缺口，以確保及時回應，讓組織可以儘快包含安全性事件。 藉由確保警示能夠有效運作，組織可以將安全性缺口的影響降到最低，因而降低嚴重外泄的機會，而嚴重缺口可能會損害組織品牌，並因罰款和信譽損害而造成財務損失。
控制節點 17
請提供安全性事件記錄已在範圍內環境中設定的辨識項，以記錄適用的事件，例如：
系統元件和應用程式的使用者/秒存取權。
高許可權用戶所採取的所有動作。
無效的邏輯存取嘗試。
特殊許可權帳戶建立/修改。
事件記錄檔竄改。
停用安全性工具;例如，事件記錄。
反惡意代碼記錄;例如，更新、惡意代碼偵測、掃描失敗。
意圖：事件記錄
若要識別嘗試和實際的缺口，請務必由組成環境的所有系統收集足夠的安全性事件記錄檔。 此控件的目的是要確保擷取正確的安全性事件類型，然後再饋送至檢閱和警示程式，以協助識別和回應這些事件。
此子點需要ISV設定安全性事件記錄，以擷取所有使用者存取系統元件和應用程式的實例。 這對於監視誰正在存取組織內的系統元件和應用程式非常重要，而且對於安全性和稽核用途都很重要。
此子點需要記錄具有高階許可權的用戶所採取的所有動作。 高許可權的使用者可以進行重大變更，這可能會影響組織的安全性狀態。 因此，請務必維護其動作的記錄。
此子點需要記錄任何無效的嘗試，以取得系統元件或應用程式的邏輯存取權。 這類記錄是偵測未經授權存取嘗試和潛在安全性威脅的主要方式。
此子點需要記錄任何建立或修改具有特殊許可權存取權的帳戶。 這種類型的記錄對於追蹤具有高層級系統存取權且可能成為攻擊者目標之帳戶的變更非常重要。
此子點需要記錄任何竄改事件記錄檔的嘗試。 竄改記錄可以是隱藏未經授權活動的方式，因此，記錄和處理這類動作至關重要。
此子點需要記錄停用安全性工具的任何動作，包括事件記錄本身。 停用安全性工具可能是表示攻擊或內部威脅的紅色旗標。
此子點需要記錄與反惡意代碼工具相關的活動，包括更新、惡意代碼偵測和掃描失敗。 適當運作和更新反惡意代碼工具，對於組織的安全性和與這些活動相關的記錄有助於監視至關重要。
指導方針：事件記錄
透過螢幕快照或組態設定的辨識項，應該跨所有取樣的裝置和任何相關性的系統元件提供，以示範如何設定記錄，以保證擷取這些類型的安全性事件。
範例辨識項
下一個螢幕快照顯示 Azure 中不同資源所產生的記錄和計量組態，然後將這些設定擷取到集中式 Log Analytic 工作區。
我們可以在第一個螢幕快照中看到記錄記憶體位置是 「PaaS-web-app-log-analytics」。。
在 Azure 中，您可以在 Azure 資源上啟用診斷設定，以存取稽核、安全性和診斷記錄，如下所示。 自動可用的活動記錄包括事件來源、日期、用戶、時間戳、來源位址、目的地位址和其他實用元素。
請注意：下列範例顯示可提供以符合此控件的辨識項類型。 這取決於您的組織如何跨範圍內環境設定安全性事件記錄。 其他範例包括 Azure Sentinel、Datadog 等。
針對載入於 Azure App Services 上的 Web 應用程式使用 [診斷設定] 選項，您可以設定要產生哪些記錄，以及這些記錄的傳送位置以進行儲存和分析。
在下列螢幕快照中，[存取稽核記錄] 和 [IPSecurity Audit Logs] 已設定為產生並擷取至 Log Analytic 工作區。
另一個範例是 Azure Front Door，其設定為將產生的記錄傳送至相同的集中式 Log Analytic 工作區。
如同使用 [診斷設定] 選項之前，請設定要產生哪些記錄，以及這些記錄的傳送位置以進行儲存和分析。 下一個螢幕快照示範已設定「存取記錄」和「WAF 記錄」。
同樣地，針對 Azure SQL Server，「診斷設定」可以設定要產生哪些記錄，以及要在何處傳送記錄以進行儲存和分析。
下列螢幕快照示範 SQL Server 的「稽核」記錄會產生並傳送至 Log Analytics 工作區。
範例辨識項
下列來自 AAD/Entra 的螢幕快照示範為特殊許可權角色和系統管理員產生稽核記錄。 資訊包括狀態、活動、服務、目標和啟動器。
![Microsoft角色和系統管理員] 頁面。](media/ops/image249.jpg)
下列螢幕快照顯示登入記錄。 記錄資訊包括IP位址、狀態、位置和日期。
![Microsoft使用者] 頁面。](media/ops/image251.jpg)
範例辨識項
下一個範例著重於針對計算實例產生的記錄，例如虛擬機 (VM) 。 已實作數據收集規則，並擷取 Windows 事件記錄檔，包括安全性稽核記錄。
下列螢幕快照顯示另一個來自名為 「Galaxy-Compliance」 之取樣裝置的組態設定範例。 這些設定示範在「本機安全策略」內啟用的各種稽核設定。
下一個螢幕快照顯示使用者已從取樣裝置 「Galaxy-Compliance」 清除事件記錄檔的事件。
請注意：先前的範例不是全螢幕螢幕快照，您必須提交具有任何 URL、登入使用者以及時間和日期戳記的全螢幕螢幕快照，以供辨識項檢閱。 如果您是Linux使用者，可以透過命令提示字元來完成此動作。
控制節點 18
提供至少 30 天的安全性事件記錄數據可立即取得的辨識項，並保留 90 天的安全性事件記錄。
意圖：事件記錄
有時候，入侵或安全性事件與識別事件的組織之間會有時間間隔。 此控件的目的是要確保組織能夠存取歷史事件數據，以協助處理事件回應和可能需要的任何鑑識調查工作。 確保組織至少保留 30 天的安全性事件記錄數據，可立即供分析，以利快速調查及回應安全性事件。 此外，總共會保留 90 天的安全性事件記錄，以允許深入分析。
指導方針：事件記錄
辨識項通常是透過顯示集中式記錄解決方案的組態設定，顯示數據的保留時間。 解決方案內必須立即提供 30 天的安全性事件記錄數據。 不過，封存數據的位置必須證明有90天的可用時間。 這可能是透過顯示具有匯出數據日期的封存資料夾。
範例辨識項：事件記錄
遵循控件 17 中先前的範例，其中集中式 Log Analytic 工作區正在用來儲存雲端資源所產生的所有記錄，您可以觀察下方的記錄會儲存在每個記錄類別的個別數據表中。 此外，所有數據表的互動式保留期為90天。
下一個螢幕快照提供其他辨識項，示範 Log Analytic 工作區保留期間的組態設定。
範例辨識項
下列螢幕快照示範有 30 天的記錄可在一起，以在一起。
![將記錄檔報表傳送至[擴充日誌]。](media/ops/image260.jpg)
注意：由於這是公開的檔，因此已修訂防火牆序號，不過，ISV 必須提交此資訊而不進行修訂，除非其中包含個人標識資訊 (必須向其分析師揭露的 PII) 。
下一個螢幕快照顯示記錄檔擷取回五個月，即可使用記錄。
注意：由於這是公開的檔，因此公用IP位址已經過修訂，不過，除非ISV包含個人標識資訊 (PII) ，否則必須提交此資訊，而不需進行任何修訂。
注意：上述範例不是全螢幕螢幕快照，您必須提交具有任何 URL、登入使用者以及時間和日期戳記的全螢幕螢幕快照，以供辨識項檢閱。 如果您是Linux使用者，可以透過命令提示字元來完成此動作。
範例辨識項
下一個螢幕快照顯示記錄事件會即時保留 30 天，並在 Azure 內的冷記憶體中保留 90 天。
請注意：預期除了示範已設定保留的任何組態設定之外，還會提供90天期間的記錄範例，以驗證記錄會保留90天。
請注意：這些範例不是全螢幕螢幕快照，您必須提交具有任何 URL、登入使用者以及時間和日期戳記的全螢幕螢幕快照，以供辨識項檢閱。 如果您是Linux使用者，可以透過命令提示字元來完成此動作。
控件 No. 19
請提供證明，示範：
系統會定期檢閱記錄，並調查並解決在檢閱程式期間識別的任何潛在安全性事件/異常。
意圖：事件記錄
此控件的目的是要確保定期執行記錄檢閱。這對於識別設定為提供安全性事件警示的警示腳本/查詢可能無法挑選的任何異常狀況非常重要。 此外，也會調查記錄檢閱期間所識別的任何異常狀況，並執行適當的補救或動作。這通常牽涉到分級程式，以識別異常是否需要採取動作，然後可能需要叫用事件回應程式。
指導方針：事件記錄
螢幕快照會提供辨識項，示範正在進行記錄檢閱。 這可能是透過每天完成的表單，或透過 JIRA 或 DevOps 票證的方式
已張貼相關批注，以顯示此動作已執行。如果標幟了任何異常，這可以記載在此相同的票證中，以示範在記錄檢閱中識別為異常狀況的後續追蹤，然後詳細說明之後執行的活動。 這可能會提示引發特定的 JIRA 票證，以追蹤正在執行的所有活動，或者可能只是記錄檢閱票證中記載。 如果需要事件回應動作，則應該將此記錄為事件回應程式的一部分，並提供辨識項來證明這一點。
範例辨識項：事件記錄
第一個螢幕快照會識別使用者已新增至「網域系統管理員」群組的位置。
下一個螢幕快照會識別多個失敗的登入嘗試之後，接著成功登入，這可能會醒目提示成功的暴力密碼破解攻擊。
此最終螢幕快照會識別密碼原則變更發生的位置，以設定原則，讓帳戶密碼不會過期。
下一個螢幕快照顯示SOC的ServiceNow工具內會自動引發票證，並觸發上述規則。
請注意：這些範例不是全螢幕螢幕快照，您必須提交具有任何 URL、登入使用者以及時間和日期戳記的全螢幕螢幕快照，以供辨識項檢閱。 如果您是Linux使用者，可以透過命令提示字元來完成此動作。
控制節點 20
請提供證明，示範：
已設定警示規則，以便在適用的情況下觸發警示以調查下列安全性事件：
特殊許可權帳戶建立/修改。
特殊許可權/高風險活動或作業。
惡意代碼事件。
事件記錄檔竄改。
如果) 設定，則會 (IDPS/WAF 事件。
意圖：警示
這些是一些安全性事件類型，可能會醒目提示已發生的安全性事件，而這些事件可能指向環境缺口和/或數據外洩。
此子點是為了確保特別設定警示規則，以便在建立或修改特殊許可權帳戶時觸發調查。 在特殊許可權帳戶建立或修改的情況下，應該產生記錄檔，而且每當建立新的特殊許可權帳戶或變更現有的特殊許可權帳戶許可權時，都應該觸發警示。 這有助於追蹤任何未經授權或可疑的活動。
此子點的目標是要設定警示規則，以在進行特殊許可權或高風險活動或作業時通知適當的人員。 對於特殊許可權或高風險的活動或作業，必須在起始這類活動時設定警示，以通知適當的人員。 這可能包括變更防火牆規則、數據傳輸或敏感性檔案的存取權。
此子點的目的是要強制設定由惡意代碼相關事件觸發的警示規則。 不只應該記錄惡意代碼事件，也應該觸發立即警示以進行調查。 這些警示應該設計成包含來源、惡意代碼本質和受影響的系統元件等詳細數據，以加速回應時間。
此子點的設計目的是要確保任何竄改事件記錄檔會觸發立即警示以進行調查。 關於事件記錄檔竄改，系統應該設定為在偵測到未經授權的記錄存取或記錄修改時觸發警示。 這可確保事件記錄檔的完整性，這對鑑識分析和合規性稽核而言非常重要。
此子點想要確保，如果已設定入侵偵測和預防系統 (IDPS) 或 Web 應用程式防火牆 (WAF) ，它們會設定為觸發警示以進行調查。 如果已設定入侵偵測和預防系統 (IDPS) 或 Web 應用程式防火牆 (WAF) ，則也應該設定它們來觸發可疑活動的警示，例如重複登入失敗、SQL 插入嘗試或建議阻斷服務攻擊的模式。
指導方針：警示
辨識項應該透過警示設定的螢幕快照和所收到警示的辨識項來提供。 組態螢幕快照應該會顯示觸發警示的邏輯，以及警示的傳送方式。 警示可以透過簡訊、電子郵件、Teams 頻道、Slack 頻道等來傳送...
範例辨識項：警示
下一個螢幕快照顯示在 Azure 中設定警示的範例。 我們可以在第一個螢幕快照中觀察到當 VM 停止並解除分配時，已引發警示。 請注意，這會描述在 Azure 中設定警示的範例，而且預期會提供辨識項來證明針對控件描述中指定的所有事件產生警示。
下列螢幕快照顯示針對在 Azure App Service 層級以及 Azure 資源群組層級所採取之任何系統管理動作所設定的警示。
範例辨識項
Contoso 會利用 Contoso Security 所提供的第三方資訊安全 (SOC) 。 此範例顯示 SOC 所使用之致變值內的警示，已設定為將警示傳送給 SOC 小組成員 Sally Gold at Contoso Security。
下一個螢幕快照顯示 Sally 正在接收的警示。
請注意：這些範例不是全螢幕螢幕快照，您必須提交具有任何 URL、登入使用者以及時間和日期戳記的全螢幕螢幕快照，以供辨識項檢閱。 如果您是Linux使用者，可以透過命令提示字元來完成此動作。
資訊安全性風險管理
資訊安全性風險管理是所有組織至少每年應執行的重要活動。 組織必須瞭解其風險，才能有效降低威脅。 如果沒有有效的風險管理，組織可能會在認為重要的區域中實作安全性資源，因為其他威脅可能比較可能。 有效的風險管理可協助組織專注於對企業造成最大威脅的風險。 這應該每年執行一次，因為安全性環境不斷改變，因此威脅和風險可能會隨著加班而改變。 例如，在近期的 COVID-19 鎖定期間，隨著移至遠端工作，網路釣魚攻擊會大幅增加。
控制節點 21
提供已記載並建立正式資訊安全性風險管理原則/程序的辨識項。
意圖：風險管理
健全的資訊安全性風險管理程序對於協助組織有效地管理風險非常重要。 這可協助組織針對環境的威脅規劃有效的風險降低措施。 此控件的目的是要確認組織具有正式記錄的資訊安全性風險管理原則或程式。 此原則應概述組織如何識別、評估及管理資訊安全性風險。 其中應包含角色和責任、風險評估的方法、接受風險的準則，以及風險降低的程式。
注意：風險評估必須著重於資訊安全性風險，而不只是一般商務風險。
指導方針：風險管理
應提供正式記載的風險評估管理程式。
範例辨識項：風險管理
下列辨識項是 Contoso 風險評估程式的螢幕快照。
注意：預期ISV會共用實際的支持原則/程序檔，而不只是提供螢幕快照。
注意：預期ISV會共用實際的支持原則/程序檔，而不只是提供螢幕快照。
控制節點 22
請提供證明，示範：
- 正式的全公司資訊安全性風險評估至少每年執行一次。
或針對目標風險分析：
系統會記錄並執行目標風險分析：
對於傳統控件或產業最佳做法不存在的每個實例，至少每12個月一次。
其中的設計/技術限制會造成將弱點引入環境的風險/讓使用者和數據面臨風險。
在懷疑或確認入侵時。
意圖：年度評量
安全性威脅會根據環境的變更、所提供服務的變更、外部影響、安全性威脅環境的演進等而不斷變更。組織至少每年都需要經歷風險評估程式。 建議也會在重大變更時執行此程式，因為威脅可能會變更。
此控件的目的是要確定組織每年至少執行一次正式的全公司資訊安全性風險評估，以及/或在系統變更期間或事件、弱點探索、基礎結構變更等時進行目標風險分析。這項評估應該包含所有組織資產、程序和數據，並致力於識別和評估潛在的弱點和威脅。
針對目標風險分析，此控件強調在特定案例上執行風險分析的需求，這著重於較窄的範圍，例如資產、威脅、系統或控件。 這樣做的目的是要確保組織持續評估並識別因偏離安全性最佳做法或系統設計限制而帶來的風險。 至少每年執行目標風險分析，其中缺少控制措施、技術限制造成弱點，以及回應可疑或已確認的安全性事件，組織可以找出弱點和暴露。 這可讓您做出以風險為基礎的明智決策，以排定補救工作的優先順序，並實作補償控件，以將惡意探索的可能性和影響降到最低。 目標是提供持續的盡責調查、指引和辨識項，指出已知的差距是以風險感知方式解決，而不是無限期地被忽略。 執行這些目標風險評估示範組織承諾在一段時間內主動改善安全性狀態。
指導方針：年度評量
辨識項可能是透過版本追蹤或過時的辨識項。 應該提供辨識項，以顯示資訊安全性風險評估的輸出，以及資訊安全性風險評估程式本身的 NOT 日期。
範例辨識項：年度評量
下一個螢幕快照顯示每六個月排程一次的風險評估會議。
接下來的兩個螢幕快照顯示來自兩個風險評估的會議分鐘數範例。 預期會提供風險評估的報告/會議分鐘數或報告。
注意：此螢幕快照顯示原則/程序檔。 預期ISV會共用實際的支持原則/程序檔，而不只是提供螢幕快照。
注意：此螢幕快照顯示原則/程式檔，預期ISV會共用實際的支持原則/程序檔，而不只是提供螢幕快照。
控制節點 23
驗證資訊安全性風險評估包含：
受影響的系統元件或資源。
威脅和弱點，或等價。
影響和可能性矩陣或對等專案。
建立風險快取器/風險處理計劃。
意圖：風險評估
其目的是風險評估包含系統元件和資源，因為它有助於識別最重要的IT資產及其價值。 藉由識別和分析企業的潛在威脅，組織可以先將焦點放在潛在影響最高和機率最高的風險。 藉由瞭解 IT 基礎結構的潛在影響和相關成本，可協助管理對預算、原則、程式等做出明智的決策。 可包含在安全性風險評估中的系統元件或資源清單如下：
伺服器
資料庫
應用程式
網路
數據儲存裝置
People
為了有效管理資訊安全性風險，組織應該針對環境和數據的威脅，以及針對可能存在的弱點進行風險評估。 這可協助組織識別可能造成重大風險的眾多威脅和弱點。 風險評估應該記載影響和可能性分級，可用來識別風險值。 這可用來排定風險處理的優先順序，並協助降低整體風險值。 必須正確追蹤風險評估，以提供所套用的四種風險風險其中之一的記錄。 這些風險解決方式如下：
避免/終止：企業可能會判斷處理風險的成本大於從服務產生的營收。 因此，企業可能會選擇停止執行服務。
轉移/共用：企業可以選擇將處理移至第三方，以將風險轉移給第三方。
接受/容許/保留：企業可能會決定可接受的風險。 這非常取決於企業的風險偏好，而且可能會因組織而異。
處理/緩和/修改：企業決定實作風險降低控制措施，以將風險降低到可接受的層級。
指導方針：風險評估
辨識項不僅應透過已提供的資訊安全性風險評估程式提供，也應透過風險緩存器/風險處理計劃) 來提供風險評估 (輸出，以證明風險評估程式正在正確執行。 風險緩存器應包含風險、弱點、影響和可能性分級。
範例辨識項：風險評估
下一個螢幕快照顯示風險緩存器，其中顯示包含的威脅和弱點。 它也會示範包含影響和可能性。
注意：應該提供完整的風險評估檔，而不是螢幕快照。 下一個螢幕快照示範風險處理計劃。
控制節點 24
請提供證據：
您 (ISV) 已備妥風險管理程式，可評估和管理與廠商和商務合作夥伴相關聯的風險。
您 (ISV) 可以識別及評估可能會影響內部控制系統的變更和風險。
意圖：廠商和合作夥伴
廠商風險管理是在建立業務關係之前，以及在關聯性期間內評估商務夥伴、供應商或第三方廠商風險狀態的作法。 藉由管理廠商風險，組織可以避免業務持續性中斷、防止財務影響、保護其信譽、遵守法規，以及找出與廠商共同作業相關的風險並將其降至最低。 若要有效地管理廠商風險，請務必備妥包含盡責評估、與安全性相關的合約義務，以及持續監視廠商合規性的程式。
指導方針：廠商和合作夥伴
您可以提供辨識項來示範廠商風險評估程式，例如採購和審查所建立的檔、檢查清單和問卷，以讓新廠商和承包商上線、執行的評量、合規性檢查等。
範例辨識項：廠商和合作夥伴
下一個螢幕快照示範廠商上線和審查程式是在 Confluence 中維護為 JIRA 工作。 針對每個新廠商，會進行初始風險評估，以檢閱合規性狀態。 在採購過程中，會填入風險評估問卷，並根據提供給廠商的系統和數據存取層級來決定整體風險。
下列螢幕快照示範評估的結果，以及根據初始檢閱所識別的整體風險。
意圖：內部控件
此子點的重點在於辨識及評估可能會影響組織內部控制系統的變更和風險，以確保內部控制在一段時間內保持有效。 隨著商務營運變更，您的內部控制可能不再有效。 風險會隨著時間而演進，而且可能會出現先前未考慮的新風險。 藉由識別和評估這些風險，您可以確保您的內部控件是設計來解決這些風險。 這有助於防止詐騙和錯誤、維護商務持續性，並確保法規合規性。
指導方針：內部控件
您可以提供辨識項，例如檢閱會議分鐘數和報告，以示範廠商風險評估程式已在定義的期間重新整理，以確保可能的廠商變更已列入考慮並評估。
範例辨識項：內部控件
下列螢幕快照示範已核准廠商和承包商清單的三個月檢閱，以確保其合規性標準和合規性層級與上線期間的初始評估一致。
第一個螢幕快照顯示執行評量的已建立指導方針和風險問卷。
下列螢幕快照顯示實際廠商核准的清單及其合規性層級、執行的評定、評估者、核准者等。請注意，這隻是基本廠商風險評估的範例，其設計目的是為了瞭解控件需求及顯示預期辨識項的格式提供基準案例。 身為ISV，您應該提供自己已建立的廠商風險評估，以適用於您的組織。
安全性事件回應
安全性事件回應對所有組織都很重要，因為這可以減少包含安全性事件的組織所花費的時間，並限制組織暴露於數據外洩的程度。 藉由開發完整且詳細的安全性事件回應計劃，可以將此暴露程度從識別時間縮短為內含項目的時間。
IBM 的「數據外泄成本報告 2020」報告強調，平均而言，包含缺口所花費的時間為 73 天。 此外，相同的報告會識別組織發生缺口的最大成本節省措施，也就是事件響應準備，提供的平均值
節省 $2,000,000 美元成本。 組織應該遵循使用業界標準架構的安全性合規性最佳做法，例如 ISO 27001、NIST、SOC 2、PCI DSS 等...
控制節點 25
請提供您的安全性事件回應計畫/程式 (IRP) 概述貴組織如何回應事件、顯示其維護方式，以及包含：
事件回應小組的詳細數據，包括連絡資訊、
事件期間的內部通訊計劃，以及與相關方的外部通訊，例如重要項目關係人、付款品牌和取得者、監管機構 (，例如 GDPR) 、監管機關、主管、客戶的 72 小時
事件分類、內含專案、風險降低、復原和返回正常商務作業等活動的步驟，視事件類型而定。
意圖：IRP) (內嵌響應計劃
此控件的目的是要確保有正式記載的事件回應計劃 (IRP) ，其中包含具有清楚記載角色、責任和連絡資訊的指定事件回應小組。 IRP 應該提供結構化方法來管理從偵測到解決的安全性事件，包括分類事件的本質、包含立即的影響、降低風險、從事件復原，以及還原正常的商務作業。 每個步驟都應該妥善定義，並使用清楚的通訊協定，以確保所採取的動作符合組織的風險管理策略和合規性義務。
事件回應小組在 IRP 內的詳細規格可確保每個小組成員都瞭解其在管理事件方面所扮演的角色，以啟用協調且有效率的回應。 藉由備妥 IRP，組織可以更有效率地管理安全性事件回應，這最終可能會限制組織的數據遺失暴露，並降低危害的成本。
組織可能根據其在 (中運作的國家/國家/地區，例如一般數據保護法規GDPR) ，或根據 (提供的功能，例如，如果付款數據) 處理，則組織可能會違反通知義務。 及時通知失敗可能會造成嚴重的後果;因此，為了確保符合通知義務，事件回應計劃應包含通訊程式，包括與所有專案關係人通訊、媒體通訊程式，以及誰可以和誰無法與媒體交談。
指導方針：內部控件
提供事件回應計劃/程式的完整版本。 事件回應計劃應包含一個區段，其中涵蓋處理從識別到解決事件的程式，以及記載的通訊程式。
範例辨識項：內部控件
下一個螢幕快照顯示 Contoso 事件回應計劃的開頭。
注意：在提交辨識項時，您必須提供整個事件響應計劃。
範例辨識項：內部控件
下一個螢幕快照顯示事件回應計劃的擷取，其中顯示通訊程式。
控制節點 26
請提供辨識項，以顯示：
事件回應小組的所有成員都已收到年度訓練，讓他們能夠回應事件。
意圖：訓練
組織包含入侵所需的時間越長，數據外泄的風險就越大，可能會導致大量外泄的數據，以及入侵的整體成本愈高。 組織的事件回應小組必須具備及時回應安全性事件的能力。 藉由定期訓練並執行桌面練習，小組已準備好快速且有效率地處理安全性事件。 此訓練應涵蓋各種層面，例如識別潛在威脅、初始響應動作、呈報程式，以及長期風險降低策略。
建議為事件回應小組執行兩個內部事件響應訓練，並執行定期的桌面練習，這應該連結到資訊安全性風險
評估以識別最有可能發生的安全性事件。 桌面練習應該模擬真實世界案例，以測試和提升小組在壓力下做出反應的能力。 藉由這樣做，組織可以確保其員工知道如何正確地處理安全性缺口或網路攻擊。 而且小組將會知道要採取哪些步驟，快速包含和調查最有可能的安全性事件。
指導方針：訓練
應該提供辨識項，以分享訓練內容來示範訓練，以及顯示誰參與 (應包含所有事件回應小組) 的記錄。 或者，或也顯示已執行表格式練習的記錄。這一切必須在提交辨識項的 12 個月期間內完成。
範例辨識項：訓練
Contoso 使用外部安全性公司執行事件回應桌面練習。 以下是當做顧問一部分產生的報表範例。
注意：必須共用完整報表。 此練習也可以在內部執行，因為第三方公司不需要Microsoft 365 需求。
注意：必須共用完整報表。 此練習也可以在內部執行，因為第三方公司不需要Microsoft 365 需求。
控制節點 27
請提供證據：
事件回應策略和支援檔會根據下列其中一項進行檢閱和更新：
從表格式練習中學習到的課程
從回應事件中學到的課程
組織變更
意圖：計劃檢閱
經過一段時間后，事件回應計劃應該根據組織變更或根據制定計劃時所學到的經驗而演進。 作業環境的變更可能需要變更事件回應計劃，因為威脅可能會變更，或法規需求可能會變更。 此外，當執行桌面練習和實際的安全性事件回應時，這通常可以識別可改善的計劃區域。 這必須內建在計劃中，而此控件的目的是要確保包含此程式。 此控件的目標是要根據三個不同的觸發程式，強制檢閱和更新組織的事件回應策略和支持檔：
在執行測試其事件回應策略有效性的模擬練習之後，應立即將任何已識別的差距或改善區域併入現有的事件回應計劃中。
實際事件提供目前回應策略的優點和缺點的寶貴深入解析。 如果發生事件，應該執行事件后檢閱來擷取這些課程，然後應該使用這些課程來更新回應策略和程式。
組織內的任何重大變更，例如合併、收購或重要人員的變更，都應該觸發事件回應策略的檢閱。 這些組織變更可能會帶來新的風險或轉移現有的風險，而事件回應計劃應該據以更新以維持有效。
指導方針：計劃檢閱
這通常可透過檢閱安全性事件或表格式練習的結果來辨識，其中已識別所學到的經驗，並導致事件回應計劃的更新。 計劃應該維護變更記錄，這也應該參考根據所學到的課程或組織變更實作的變更。
範例辨識項：計劃檢閱
下一個螢幕快照來自提供的事件回應計劃，其中包含根據所學到的課程和/或組織變更進行更新的區段。
注意：這些範例不是全螢幕螢幕快照，您必須提交具有任何 URL、登入使用者以及時間和日期戳記的全螢幕螢幕快照，以供辨識項檢閱。 如果您是Linux使用者，可以透過命令提示字元來完成此動作。
商務持續性計劃和災害復原計劃
商務持續性規劃和災害復原規劃是組織風險管理策略的兩個重要元件。 商務持續性規劃是建立計劃的程式，以確保基本商務功能可以在災害期間和之後繼續運作，而災害復原規劃則是建立計劃以儘快從災害復原並還原正常商務作業的程式。 這兩個方案彼此互補—您必須同時承受災害或非預期中斷所帶來的作業挑戰。 這些計劃很重要，因為它們有助於確保組織可以在災害期間繼續運作、保護其信譽、遵守法律要求、維護客戶信心、有效管理風險，以及保護員工安全。
控件 No. 28
請提供證明，示範：
檔已存在且已維護，其中概述商務持續性計劃，並包含：
相關人員的詳細數據，包括其角色和責任
具有相關聯應變需求和目標的商務功能
系統和數據備份程序、設定和排程/保留
復原優先順序和時間範圍目標
應變計劃，詳細說明在發生非預期和未排程中斷時要遵循的動作、步驟和程式，以傳回重要資訊系統、商務功能和服務來運作
已建立的程式，涵蓋最終的完整系統還原並返回原始狀態
意圖：商務持續性計劃
此控件背後的目的是要確保商務持續性計劃中包含具有指派角色和責任的明確定義人員清單。 這些角色對於在事件期間有效啟用和執行計劃而言非常重要。
指導方針：商務持續性計劃
請提供災害復原計劃/程式的完整版本，其中應包含控件描述中涵蓋已處理大綱的章節。 如果是在數位版本中，請提供實際的 PDF/WORD 檔，或者，如果透過在線平臺維護進程，則提供進程的匯出或螢幕快照。
範例辨識項：商務持續性計劃
下一個螢幕快照顯示商務持續性計劃的擷取，並顯示它存在並受到維護。
注意：此螢幕快照 () 顯示原則/程序檔的快照集，預期ISV會共用實際的支持原則/程序檔，而不只是提供螢幕快照。
下一個螢幕快照顯示原則的擷取，其中已概述 [關鍵人員] 區段，包括相關小組、聯繫人詳細數據和要採取的步驟。
意圖：優先順序
此控件的目的是記錄商務功能，並根據其重要性設定其優先順序。 這應該伴隨相對應的應變需求大綱，以在非計劃性中斷期間維持或快速還原每個函式。
指導方針：優先順序
請提供災害復原計劃/程式的完整版本，其中應包含控件描述中涵蓋已處理大綱的章節。 如果是在數位版本中，請提供實際的 PDF/WORD 檔，或者，如果透過在線平臺維護進程，則提供進程的匯出或螢幕快照。
範例辨識項：優先順序
下一個螢幕快照顯示商務持續性計劃的擷取，以及商務功能及其重要性層級的大綱，以及是否有任何應變計劃存在。
注意：此螢幕快照 () 顯示原則/程序檔，預期ISV會共用實際的支持原則/程序檔，而不只是提供螢幕快照。
意圖：備份
此子點的目標是要維護備份基本系統和數據的記載程式。 文件也應該指定組態設定，以及備份排程和保留原則，以確保數據是最新且可擷取的。
指導方針：備份
請提供災害復原計劃/程式的完整版本，其中應包含控件描述中涵蓋已處理大綱的章節。 如果是在數位版本中，請提供實際的 PDF/WORD 檔，或者，如果透過在線平臺維護進程，則提供進程的匯出或螢幕快照。
範例辨識項：備份
下一個螢幕快照顯示 Contoso 災害復原計劃的擷取，以及每個系統都有記載的備份設定。 請注意，在下一個螢幕快照中也會概述備份排程，請注意，在此範例中，備份組態會概述為災害復原計劃的一部分，因為商務持續性和災害復原計劃會一起運作。
注意：此螢幕快照 () 顯示原則/程序檔的快照集，預期ISV會共用實際的支持原則/程序檔，而不只是提供螢幕快照。
意圖：時間軸
此控件旨在為復原動作建立優先順序的時間軸。 這些復原時間目標 (RTO) 應與業務影響分析一致，而且必須明確定義，讓人員了解必須先還原哪些系統和功能。
指導方針：時程表
請提供災害復原計劃/程式的完整版本，其中應包含控件描述中涵蓋已處理大綱的章節。 如果是在數位版本中，請提供實際的 PDF/WORD 檔，或者，如果透過在線平臺維護進程，則提供進程的匯出或螢幕快照。
範例辨識項：時程表
下列螢幕快照顯示商務功能的接續和重要性分類，以及建立的復原時間目標 (RTO) 。
注意：此螢幕快照 () 顯示原則/程序檔，預期ISV會共用實際的支持原則/程序檔，而不只是提供螢幕快照。
意圖：復原
此控制項想要提供一個逐步程式，讓重要資訊系統、商務功能和服務恢復運作狀態。 這應該夠詳細，以在壓力高的情況下引導決策，因為快速且有效的動作是不可或缺的。
指導方針：復原
請提供災害復原計劃/程式的完整版本，其中應包含控件描述中涵蓋已處理大綱的章節。 如果是在數位版本中，請提供實際的 PDF/WORD 檔，或者，如果透過在線平臺維護進程，則提供進程的匯出或螢幕快照。
範例辨識項：復原
下一個螢幕快照顯示災害復原計劃的擷取，以及每個系統和商務功能都有記載的復原計劃，請注意，在此範例中，系統復原程式是災害復原計劃的一部分，因為商務持續性和災害復原計劃會一起運作，以達成完整復原/還原。
注意：此螢幕快照 () 顯示原則/程序檔，預期ISV會共用實際的支持原則/程序檔，而不只是提供螢幕快照。
意圖：驗證
此控制點旨在確保商務持續性計劃包含結構化程式，以引導組織在受控危機之後，將系統還原至其原始狀態。 這包括驗證步驟，以確保系統可完全運作並保留其完整性。
指導方針：驗證
請提供災害復原計劃/程式的完整版本，其中應包含控件描述中涵蓋已處理大綱的章節。 如果是在數位版本中，請提供實際的 PDF/WORD 檔，或者，如果透過在線平臺維護進程，則提供進程的匯出或螢幕快照。
範例辨識項：驗證
下列螢幕快照顯示商務持續性計劃原則中所述的復原程式，以及要採取的步驟/動作。
注意：此螢幕快照 () 顯示原則/程序檔的快照集，預期ISV會共用實際的支持原則/程序檔，而不只是提供螢幕快照。
控制節點 29
請提供證明，示範：
檔已存在且已維護，其中概述災害復原計劃，並至少包含：
相關人員的詳細數據，包括其角色和責任
具有相關聯應變需求和目標的商務功能
系統和數據備份程序、設定和排程/保留
復原優先順序和時間範圍目標
應變計劃，詳細說明在發生非預期和未排程中斷時要遵循的動作、步驟和程式，以傳回重要資訊系統、商務功能和服務來運作
已建立的程式，涵蓋最終的完整系統還原並返回原始狀態
意圖:D RP
此控件的目標是要為災害復原小組的每個成員提供妥善記載的角色和責任。 也應概述呈報程式，以確保在災害案例期間，適當人員會快速提升問題並加以解決。
指導方針:D RP
請提供災害復原計劃/程式的完整版本，其中應包含控件描述中涵蓋已處理大綱的章節。 如果是在數位版本中，請提供實際的 PDF/WORD 檔，或者，如果透過在線平臺維護進程，則提供進程的匯出或螢幕快照。
範例辨識項:D RP
下一個螢幕快照顯示災害復原計劃的擷取，並顯示它存在並受到維護。
注意：此螢幕快照 () 顯示原則/程序檔，預期ISV會共用實際的支持原則/程序檔，而不只是提供螢幕快照。
下一個螢幕快照顯示原則的擷取，其中已概述「應變計劃」，包括相關小組、聯繫人詳細數據和呈報步驟。
意圖：清查
此控件背後的目的是要維護所有資訊系統的最新清查清單，這些資訊系統對於支援商務營運至關重要。 這份清單是瞭解在災害復原工作期間必須優先處理哪些系統的基礎。
指導方針：清查
請提供災害復原計劃/程式的完整版本，其中應包含控件描述中涵蓋已處理大綱的章節。 如果是在數位版本中，請提供實際的 PDF/WORD 檔，或者，如果透過在線平臺維護進程，則提供進程的匯出或螢幕快照。
範例辨識項：清查
下一個螢幕快照顯示DRP的擷取，以及重要系統及其重要性層級以及系統函式的清查存在。
注意：此螢幕快照 () 顯示原則/程序檔，預期ISV會共用實際的支持原則/程序檔，而不只是提供螢幕快照。
下一個螢幕快照顯示分類和服務重要性定義。
注意：此螢幕快照 () 顯示原則/程序檔，預期ISV會共用實際的支持原則/程序檔，而不只是提供螢幕快照。
意圖：備份
此控制項需要有妥善定義的系統和資料備份程式。 這些程式應概述備份的頻率、組態和位置，以確保在發生失敗或災害時可以還原所有重要數據。
指導方針：備份
請提供災害復原計劃/程式的完整版本，其中應包含控件描述中涵蓋已處理大綱的章節。 如果是在數位版本中，請提供實際的 PDF/WORD 檔，或者，如果透過在線平臺維護進程，則提供進程的匯出或螢幕快照。
範例辨識項：備份
下一個螢幕快照顯示災害復原計劃的擷取，而且每個系統都有記載的備份組態。 請觀察下方的備份排程也已概述。
注意：此螢幕快照 () 顯示原則/程序檔的快照集，預期ISV會共用實際的支持原則/程序檔，而不只是提供螢幕快照。
意圖：復原
此控件會呼叫完整的復原計劃，其中概述還原重要系統和數據的逐步程式。 這可作為災害復原小組的藍圖，並確保所有復原動作在還原商務作業時都已預先準備且有效。
指導方針：復原
請提供災害復原計劃/程式的完整版本，其中應包含控件描述中涵蓋已處理大綱的章節。 如果是在數位版本中，請提供實際的 PDF/WORD 檔，或者，如果透過在線平臺維護進程，則提供進程的匯出或螢幕快照。
範例辨識項：復原
下一個螢幕快照顯示災害復原計劃的擷取，以及設備更換和系統復原步驟和指示存在且已記載，以及包含復原時間範圍的復原程式、要採取以還原雲端基礎結構的動作等。
注意：此螢幕快照 () 顯示原則/程序檔的快照集，預期ISV會共用實際的支持原則/程序檔，而不只是提供螢幕快照。
控制節點 30
請提供證明，示範：
商務持續性計劃和災害復原計劃會至少每隔 12 個月檢閱一次，以確保在不良情況下保持有效且有效，並根據下列專案進行更新：
計劃的年度檢閱。
所有相關人員都會接受有關應變計劃中指派的角色和責任訓練。
此方案會透過商務持續性或災害復原練習進行測試。
測試結果會記錄在內，包括從練習或組織變更中學習到的經驗。
意圖：年度檢閱
此控件的目的是要確保每年檢閱商務持續性和災害復原計劃。 檢閱應該確認計劃仍然有效、準確，且符合目前的商務目標和技術架構。
意圖：年度訓練
此控件會要求在商務持續性和災害復原計劃中具有指定角色的所有人員，每年都會收到適當的訓練。 目標是確保他們瞭解自己的責任，並且能夠在發生災害或業務中斷時有效地執行這些責任。
意圖：練習
這裡的目的是要透過真實世界的練習來驗證商務持續性和災害復原計劃的有效性。 這些練習應該設計成模擬各種不良狀況，以測試組織能夠維持或還原商務營運的程度。
意圖：分析
最後一個控制點旨在完整記載所有測試結果，包括分析哪些項目運作良好，以及哪些結果無效。 學習到的課程應該整合回計劃中，而且應該立即解決任何缺點，以改善組織的復原能力。
指導方針：檢閱
應提供報告、會議附註，以及年度商務持續性和災害復原計劃練習的輸出等證據，以供檢閱。
範例辨識項：檢閱
下一個螢幕快照顯示商務持續性和災害復原計劃演練 (練習) 的報表輸出，其中已建立案例以允許小組制定商務持續性和災害復原計劃，並逐步解說到成功還原商務功能和系統作業的情況。
注意：這些螢幕快照顯示快照集 (原則/程序檔的) ，預期ISV會共用實際的支持原則/程序檔，而不只是提供螢幕快照。
注意：這些螢幕快照顯示快照集 (原則/程序檔的) ，預期ISV會共用實際的支持原則/程序檔，而不只是提供螢幕快照。