實踐 SSDLC 深入附表十《資通系統防護基準修正規定》DSCS 的饗宴 🍱

2022-01-29

Headfirst : Defense Standard of Cyber System，藉由深入探討資通安全責任等級分級辦法中的附表十《資通系統防護基準修正規定》，探討需求、設計、開發、測試以及部署維運階段上，需要實踐的安全控制措施，並代入 ASP.NET 的程式設計與微軟生態系的維運經驗，思索實踐方式。

logo

編輯紀錄

2023-01-27 根據 《Web應用程式安全參考指引》 以及 《資通系統防護基準驗證實務》 更新 稽核與可歸責性 實踐方式。

資訊安全

各控制措施來源為資通安全責任等級分級辦法中的附表十《資通系統防護基準修正規定》，並參考 NCCST 的資通系統防護基準驗證實務《110年資通系統防護基準驗證實務》。

相關的說明除整理自《110年資通系統防護基準驗證實務》外，並加入ASP.NET 的程式設計與微軟生態系的維運經驗，同時思索各種實踐與優化的方式，讓資訊安全有更好的追求😉

存取控制

  • 帳號的管理，確認系統的使用者範圍，定義如何驗證使用者，並區分使用者的角色、權限。
  • 帳號依照 SQL Server 授權方式可以分為主體、權限與物件

1-1-1. 建立帳號管理機制，包含帳號之申請、開通、停用及刪除之程序。

  • 應用系統使用網域驗證且開放所有的網域使用者使用，則不另外實作帳號管理機制。
  • 限制部分網域使用者使用，限制的方式在應用系統的資料庫當中實作，則必須由應用系統負責帳號管理機制。

帳號的管理設計

  • AD 使用者 Windows 驗證成功
  • 使用者存在於系統資料庫當中
  • 使用者的狀態非停用

1-1-2. 已逾期之臨時或緊急帳號應刪除或禁用。
1-1-3. 資通系統閒置帳號應禁用。

逾期、緊急以及閒置帳號的定義。

臨時逾期
開發人員帳號、測試人員帳號
緊急逾期
備援、移機用途帳號
閒置
90天未有登入紀錄
在設計帳號管理上加入帳號使用期限，在新建帳號時自動設定為 90 天，臨時帳號則為 30 天、緊急帳號則為 1 天，逾期後帳號自動轉為停用。

1-1-4. 定期審核資通系統帳號之建立、修改、啟用、禁用及刪除。

系統進入維運階段後，定期檢視系統帳號。

定期：每週、每月、每季人員異動
審核要點：建立帳號、修改帳號、啟用帳號是否能與文件勾稽

1-1-5. 逾越機關所定預期閒置時間或可使用期限時，系統應自動將使用者登出。

帳號登出機制，主動留意 Session 逾期的行為。

1-1-6. 應依機關規定之情況及條件，使用資通系統。

  • 時間 (不允許非上班時間)
  • IP 位址 (限制白名單 IP / Intranet / VPN)
  • 裝置 (裝置 MAC / 限制特定的作業系統 / 瀏覽器)

1-1-7. 監控資通系統帳號，如發現帳號違常使用時回報管理者。

違常使用
時間、位址、裝置、行為 (無效、大量上傳下載、觸發特定的 Http Status Code)
回報管理者
電子郵件、SMS、社群訊息

1-2-1. 採最小權限原則，僅允許使用者(或代表使用者行為之程序)依機關任務及業務功能，完成指派任務所需之授權存取。

IIS 資料夾權限深入 (IIS & SMB)
You Don't Need Database Owner

1-3-1. 對於每一種允許之遠端存取類型(如遠端桌面連線、SSH、網路芳鄰或FTP)，均應先取得授權，建立使用限制、組態需求、連線需求及文件化，使用者之權限檢查作業應於伺服器端完成。

遠端存取類型
遠端桌面：MSTSC、SSH、SMB (Shared Folder)、FTP

1-3-2. 使用者之權限檢查作業應於伺服器端完成。

相似於 7-3-2. 使用者輸入資料合法性檢查應置放於應用系統伺服器端。

1-3-3. 應監控資通系統遠端連線。

1-3-4. 資通系統應採用加密機制。

資料使用加密的傳輸方式，並且要避免有安全性的演算法及通訊協定 (TLS 1.1 含以下)。

  • Web App: HTTPS
  • Database: Encryption Connections
  • FTP: SFTP。

呼應 6-1-1 資通系統應採用加密機制，以防止未授權之資訊揭露或偵測資訊之變更。

1-3-5. 資通系統遠端存取之來源應為機關已預先定義及管理之存取控制點。

遠端存取應避免開放任何任何人使用，應以時間、位址、裝置的方式進行遠端存取限制。

稽核與可歸責性

2-1-1. 訂定日誌之記錄時間週期及留存政策，並保留日誌至少六個月 (依規定時間週期及紀錄留存政策，保留稽核紀錄)。

原則是至少 6 個月，但若 ISMS 有更嚴格的定義稽核紀錄保存的時間，從 ISMS。

2-1-2. 確保資通系統有稽核特定事件之功能，並決定應稽核之特定資通系統事件。

資通系統的層級：

網路設備
防火牆、路由器、交換器 Logs
作業系統
事件檢視器、稽核紀錄、效能 (ResMon, PerfMon)
網頁伺服器
IIS Logs
資料庫系統
SQL Server Error Logs / Agent Logs / Extended Events
應用系統
Database / SQLite / Text File

IIS Log Parser

特定事件：身分驗證、存取資源、敏感或大量資料異動、觸發特定錯誤代碼及管理者行為等。

《資通系統防護基準驗證實務》建議包含下列系統事件：

  • 管理者行為(如調整系統組態、異動系統帳號)
  • 身分驗證失敗(如帳號登入失敗、觸發帳戶鎖定)
  • 存取資源失敗(如頁面失效、資料庫連線失敗)
  • 功能錯誤(如系統功能無法使用、帳戶無法登入)
  • 重要資料異動(如存取個人資料或機敏資訊)
  • 重要操作行為(如變更個人密碼、金融轉帳交易)

《Web應用程式安全參考指引》則提到日誌紀錄應包含下列項目：

  • 使用者ID，不可為個資類型，避免共用帳號之情況。
  • 時間，系統應設定定期校時。
  • 執行之功能或存取之資源名稱。
  • 事件類型或優先等級。
  • 執行結果或事件描述。
  • 事件發生當下相關物件資訊。
  • 網路來源與目的位址。
  • 錯誤代碼

《Web應用程式安全參考指引》 示範如何使用 NLog 進行日誌紀錄的 Sample Code：

NLog.Logger logger = NLog.LogManager.GetCurrentClassLogger();
if (UserLogin(this.TextBoxAccount.Text, this.TextBoxPassword.Text)){
  logger.Info(TextBoxAccount.Text + "登入成功!!");
}
else{
  logger.Warn(TextBoxAccount.Text + "登入失敗!!");
}

2-1-3. 應稽核資通系統管理者帳號所執行之各項功能。

管理者帳號
授權權限、系統參數修改權限、特定的內容維護者
功能的界定
ASP.NET MVC Action / ASP.NET ASPX / Permissions & Objects

《資通系統防護基準驗證實務》建議管理者帳號功能執行紀錄應包含下列行為：

  • 管理者帳號登入與登出
  • 管理者帳號密碼變更
  • 異動使用者帳號密碼、鎖定狀態及存取權限等
  • 異動系統重要功能組態
  • 存取機敏資訊，如使用者個人資料、帳戶資訊等

2-1-4. 應定期審查稽核事件。

定期：每週、每月、每季、每半年、每年

2-2-1. 資通系統產生之稽核紀錄(Audit Logs)應包含事件類型、發生時間、發生位置及任何與事件相關之使用者身分識別等資訊，並採用單一日誌紀錄機制，確保輸出格式之一致性。
2-2-2. 資通系統產生之稽核紀錄(Audit Logs)，應依需求納入其他相關資訊。

基本的稽核紀錄欄位：

  • 事件類型 (應用系統自定義)
  • 發生時間 (Timestamp)
  • 發生位置 (Server, Database, Files)
  • 使用者資訊 (IP, Port, MAC, ComputerName, AD User)

2-3-1. 依據稽核紀錄(Audit Logs)儲存需求，配置稽核紀錄所需之儲存容量。

  • 計算稽核所需的磁碟容量
  • 統計每月產生的稽核資料量
  • 空間不足的處理措施：循環紀錄

2-4-1. 資通系統於稽核處理失效時，應採取適當之行動。
2-4-2. 機關規定需要即時通報之稽核失效事件發生時，資通系統應於機關規定之時效內，對特定人員提出警告。

關於稽核處理的失效，包含下列情形：

如果是磁碟空間低於警戒值，應通知 (郵件、簡訊) 相關人員。
而如果是稽核處理失效 (包含磁碟空間不足或其他任何原因)，處理方式有三種：停止資訊系統的使用、複寫最舊的日誌紀錄、停止日誌紀錄。

無法處理稽核的對應方式，避免因稽核失效影響系統的服務可用性，對應方式：循環紀錄、停止紀錄、主動通知。

2-5-1. 資通系統應使用系統內部時鐘產生稽核紀錄(Audit Logs)所需時戳，並可以對應到世界協調時間(UTC)或格林威治標準時間(GMT)。
2-5-2. 系統內部時鐘應依機關規定之時間週期與基準時間源進行同步。

留意各種稽核紀錄的時間戳記：

Log UTC
IIS Logs UTC
SQL Server Logs UTC+8
Windows Eventvwr UTC+8

使用網路時間協定 (Network Time Protocol) 進行伺服器校正時間。

2-6-1. 對稽核紀錄(Audit Logs)之存取管理，僅限於有權限之使用者。

Logs 存取權限於設計身分權限時加入考量。

如何提供應用系統管理者讀取資料庫 Logs、IIS Logs。

2-6-2. 應運用雜湊或其他適當方式之完整性確保機制。

應用系統稽核資料儲存於資料庫中，資料表欄位新增欄位總和雜湊，雜湊的實作方法搭配加鹽，避免單一欄位直接由資料庫進行修改。

評估進行稽核資料雜湊的單位：Record, Files, Daily File

2-6-3. 定期備份稽核紀錄(Audit Logs)至與原稽核系統不同之實體系統。

稽核紀錄的流向：本機 -> 磁碟備份 -> 磁帶備份

《Web應用程式安全參考指引》 有提到可以將 Log 儲存在 App_Data，因此 Log 可以為 SQLite 或者是 Text File 的方式儲存於 App_Data 資料夾。但如果考慮到要備份至不同實體系統，一開始就直接將日誌紀錄儲存在資料庫較為一勞永逸。

營運持續計畫

3-1-1. 訂定系統可容忍資料損失之時間要求。

系統應該主動訂定資料的損失可容忍時間 (RPO) ，並採用能符合 RPO 目標的備份方式。

如果是小時等級的 RPO 必須搭配交易紀錄備份，如果是分秒等級的則必須搭配高可用技術。

3-1-2. 執行系統源碼與資料備份。

系統源碼：系統開發原始碼、編譯後的應用程式檔、系統的部署檔
資料：保存於資料庫的檔案、保存於檔案伺服器的圖片、文件、影像等檔案

3-1-3. 應定期測試備份資訊，以驗證備份媒體之可靠性及資訊之完整性。

定期測試備份的頻率：每季 / 每半年 / 每年
如何驗證可靠性：還原成功就是可靠
如何驗證完整性：資料庫備份使用 DBCC 檢查

3-1-4. 應將備份還原，做為營運持續計畫測試之一部分。

營運持續計畫測試的具體內容：問題通報、營運持續替代、原服務水準復原。

資訊安全營運持續運作管理

3-1-5. 應在與運作系統不同處之獨立設施或防火櫃中，儲存重要資通系統軟體與其他安全相關資訊之備份。

異地備份。

3-2-1. 訂定資通系統從中斷後至重新恢復服務之可容忍時間要求。

系統應該主動訂定復原時間目標 (RTO)、最大可容忍中斷時間 (MTPD) 。

3-2-2. 原服務中斷時，於可容忍時間內，由備援設備取代提供服務。

備援設備的種類：數位措施 / 紙本作業
備援啟用的銜接時間：是否會超過 MTPD

識別與鑑別

4-1-1. 資通系統應具備唯一識別及鑑別機關使用者(或代表機關使用者行為之程序)之功能，禁止使用共用帳號。

禁止共用帳號為原則，另評估單人使用多重帳號的問題 (Context Switch 機制)

4-1-2. 對帳號之網路或本機存取採取多重認證技術。

評估登入方式如何結合多因子認證。

4-2-1. 使用預設密碼登入系統時，應於登入後要求立即變更。

呼應「5-5-2. 資通系統相關軟體，不使用預設密碼。」，原則不允許預設密碼，但如果使用預設密碼應該要求登入後立即變更。

4-2-2. 身分驗證相關資訊不以明文傳輸。

SQL Server 的連線資訊本身會採用加密方式，但資通系統在 IIS 若非採 Windows 驗證，該如何保證身分驗證的不使用明文傳輸？

4-2-3. 具備帳戶鎖定機制，帳號登入進行身分驗證失敗達三次後，至少十五分鐘內不允許該帳號繼續嘗試登入或使用機關自建之失敗驗證機制。

採 AD 驗證，應用程式端的錯誤是否會觸發暫時停止帳戶登入？如果沒有的話應由應用程式端自行實作。

停用的對象評估：登入帳號、IP 位址

4-2-4. 基於密碼之鑑別資通系統應強制最低密碼複雜度、強制密碼最短及最長之效期限制。(但對於非內部使用者可依機關自行規範辦理)
4-2-5. 使用者更換密碼時，至少不可以與前三次使用過之密碼相同。(但對於非內部使用者可依機關自行規範辦理)

採 AD 驗證與 AD 一致的密碼複雜度以及密碼循環次數規則

4-2-6. 身分驗證機制應防範自動化程式之登入或密碼更換嘗試。

如果有身分登入的輸入頁面，應加入 CAPTCHA 防範自動化登入程式、爬蟲工具。

4-2-7. 密碼重設機制對使用者重新身分確認後，發送一次性及具有時效性符記。

採 AD 驗證的方式；如果自行實作，應注意變更密碼郵件時限以及加入連結 Token。

4-3-1. 資通系統應遮蔽鑑別過程中之資訊。

<input type="password" name="pwd" id="pwd">

4-4-1. 資通系統如以密碼進行鑑別時，該密碼應加密或經雜湊處理後儲存。

資料表保存的帳號密碼必須雜湊或加密保存

4-5-1. 資通系統應識別及鑑別非機關使用者(或代表機關使用者行為之程序)。

資通系統必須可以識別外部使用者，資通系統的身分資料表對於外部使用者以欄位加註。

外部使用者
其他政府機關、機構、委外開發與維護廠商、臨時人員、勞務人員及一般民眾

系統服務與取得

保留完整資通系統之版本更新過程與紀錄，另及時更新與納管系統分析與設計文件，以落實系統發展生命週期各階段作業。

110 年政府機關(構)資通安全稽核作業 - 技術面

1. 針對資通系統所使用之外部元件或軟體，應建立系統化管理機制，並納入驗收程序。

2. 針對外部元件或軟體之安全性漏洞通告，應落實評估更新，並關閉資通系統不必要之服務及埠口。

110 年政府機關(構)資通安全稽核作業 - 技術面

資通系統定期進行弱點掃描、系統滲透測試及資通安全健診，並應追蹤檢測結果修補情形，以確實降低機關之資安風險。

110 年政府機關(構)資通安全稽核作業 - 技術面

5-1-1. 針對系統安全需求(含機密性、可用性、完整性)，以檢核表方式進行確認。

系統設計初期即按資通系統防護基準提列安全需求，使用檢核表的方式驗證安全需求。

  • 檢核表範例 | NCHU
  • 技服中心「資通系統委外開發RFP資安需求範本(V2.0)-附件1資通系統資安需求項目查檢表

對於已經上線的系統，應針對系統進行分級，按所需要實作安全控制措施進行盤點與補強缺漏。

  1. 委外需求時，須完成「所定資通系統防護需求分級原則評估等級」，並讓受託開發者知悉；分級評估結果應由資安長確認。
  2. 以專案百分之五的預算作為資安預算。
  3. 廠商的資安作為應納入評選項目。
  4. 受託開發的系統如屬核心系統，評選委員應包含一位資安專業人員。
  5. 使用「資訊服務採購案之資安檢核事項」確認各項資安需求。
資通系統籌獲各階段資安強化措施 - 需求階段

5-2-1. 根據系統功能與要求，識別可能影響系統之威脅，進行風險分析及評估。

依照威脅識別與風險分析相關方法論

  • 誤用模型(Misuse case)
  • 威脅建模 (Threat Modeling)
  • STRIDE 威脅類別
  • DREAD風險計算方法

5-2-2. 將風險評估結果回饋需求階段之檢核項目，並提出安全需求修正。

DREAD 風險計算後提出對應的控制措施

5-3-1. 應針對安全需求實作必要控制措施。

依照需求規格文件 (5-1-1) 內容，實作相關安全功能或機制，藉由 SRTM 將安全需求、功能實作及後續測試驗證等活動串聯起來。

  • 資通系統安全需求追蹤矩陣 (Secure Requirement Traceability Matrix, SRTM)

5-3-2. 應注意避免軟體常見漏洞及實作必要控制措施。

  • 系統安全開發教育訓練 (Training)
  • 訂定安全程式碼撰寫原則 (Security Coding Principles)
  • 執行源碼掃描修補安全漏洞 (Static Code Analysis)
  • 執行弱點掃描修補安全漏洞 (Vulnerability Scanning)
  • 執行滲透測試修補安全漏洞 (Penetration Testing)

一定要知道的 OWASP top 10:2017 Web 開發攻防之道

CWE/SANS TOP 25

5-3-3. 發生錯誤時，使用者頁面僅顯示簡短錯誤訊息及代碼，不包含詳細之錯誤訊息。

IIS 網頁伺服器關閉「錯誤詳細檢視」，ASP.NET 實作 Custom Error Page。

⭐IIS 錯誤頁面客製設定 (IIS Custom Erros, Error Pages)
⭐ASP.NET MVC 如何客製錯誤畫面 (Custom Error Page)
⭐ASP 網頁服務的維護指南

5-3-4. 執行「源碼掃描」安全檢測。

呼應 5-3-2 應注意避免軟體常見漏洞及實作必要控制措施。

5-3-5. 具備系統嚴重錯誤之通知機制。

NLog / Elmah / Try Catch / SOC

  1. 資通安全專責人員以適當方式協助統籌獲取需求單位，進行與確認受託開發團隊遵循 SSDLC。
  2. 核心系統，應有外部資安專家協助於重點里程碑檢視履約與成果相關的資安管理作為。
  3. 核心資通系統且委託金額達一千萬以上，應導入獨立檢驗與驗證機制 (IV&V)，評估結果應由資安長確認。
資通系統籌獲各階段資安強化措施 - 開發階段

5-4-1. 執行「弱點掃描」安全檢測。

驗證實務上需要搭配弱掃的修補紀錄。

5-4-2. 執行「滲透測試」安全檢測。

驗證實務上需要搭配滲透的修補紀錄。

5-5-1. 於部署環境中應針對相關資通安全威脅，進行更新與修補，並關閉不必要服務及埠口。

定期進行軟體及元件安全性更新，加入 資安弱點通報機制 VANS。

💡使用 NMAP 驗證伺服器所支援的 Port

nmap -sV 192.168.112.1

5-5-2. 資通系統相關軟體，不使用預設密碼。

資通系統資料庫與資通系統伺服器等軟體元件如避免預設密碼，但這邊提到的資料庫與伺服器作業系統，資料庫與伺服器作業系統本身是否可以認定為資通系統？

5-5-3. 於系統發展生命週期之維運階段，應執行版本控制與變更管理

使用版控系統並搭配變更管理機制，進行系統的維護。

進行系統變更作業時，應完成申請與審核程序後進行（填寫資通系統變更作業申請單）。

執行變更作業前，應先執行系統備份作業並訂定復原計畫，系統變更完成後，應更新相關系統操作文件及紀錄。

進行變更作業應以積極管理為原則，避免完全由委外廠商負責。

5-6-1. 資通系統開發如委外辦理，應將系統發展生命週期各階段依等級將安全需求(含機密性、可用性、完整性)納入委外契約。

參考委外安全需求可參考技服中心「資通系統委外開發RFP資安需求範本(V2.0)」，將安全需求加入委外契約。

5-7-1. 開發、測試及正式作業環境應為區隔。

開發、測試、正式環境以網段及設備 (實體或邏輯)進行區隔，避免互相影響。系統的變更管理應由開發、測試到正式依序進行。

避免開發、測試汙染到正式環境。

5-8-1. 應儲存與管理系統發展生命週期之相關文件。

相關文件舉隅：

  • 軟體發展計畫書
  • 軟體需求規格書
  • 系統規格書
  • 軟體測試計畫
  • 維護手冊
  • 軟體使用手冊
  • 系統文件審查表
  • 系統原始碼
  • 測試問題紀錄表
  • 軟體測試報告
  • 驗收紀錄表
  1. 由管理及需求單位負責主要的 SSDLC 及履約執行的監督、確認工作，並由資安專責人員協助第二線的勾稽確認。
  2. 受託者應配置資安專責人員，協助確認履約執行階段作業符合委託及受託雙方的資安管理規範。
  3. 契約期間，按資通系統防護需求「中級」、「高級」向受託者進行資安稽核，確認受託者符合資安要求。
資通系統籌獲各階段資安強化措施 - 維運階段

系統與通訊保護

6-1-1. 資通系統應採用加密機制，以防止未授權之資訊揭露或偵測資訊之變更。但傳輸過程中有替代之實體保護措施者，不在此限。

呼應 1-3-4. 資通系統應採用加密機制。

  • Web App: HTTPS
  • Database: Encryption Connections
  • FTP: SFTP。

6-1-2. 使用公開、國際機構驗證且未遭破解之演算法。

停用 SSL 3.0、TLS 1.0、TLS 1.1 等不安全的通訊協定。
停用 RC2、RC4、DES、3DES 等不安全加密法。

💡使用 NMAP 檢測方式

namp --script ssl-enum-ciphers -p 443 192.168.112.1

6-1-3. 支援演算法最大長度金鑰。

AES 256
SHA 384
RSA 2048

6-1-4. 加密金鑰或憑證週期性更換。

避免使用萬年憑證，注意憑證是否過期。

6-1-5. 伺服器端之金鑰保管應訂定管理規範及實施應有之安全防護措施。

憑證及金鑰的管理防護措施。

6-2-1. 靜置資訊及相關具保護需求之機密資訊應加密儲存。

組態設定檔 (web.config、connectionStrings) 進行加密保護。

系統與資訊完整性

7-1-1. 系統之漏洞修復應測試有效性及潛在影響，並定期更新。

呼應 5-5-1. 於部署環境中應針對相關資通安全威脅，進行更新與修補，並關閉不必要服務及埠口。

定期進行作業系統、資通系統伺服器、開發框架，以及第三方函式庫的更新，加入 VANS 主動掌握弱點資訊，使用 White Source 檢查開源軟體弱點。

先於測試環境進行更新，驗證不影響系統功能，但緊急性更新仍應先於測試環境驗證主要功能是否正常如期使用。

7-1-2. 定期確認資通系統相關漏洞修復之狀態。

瀏覽 CVE、廠商安全通告、弱掃等安全性檢測結果，追蹤漏洞的修復情形。

弱點修補紀錄是驗證重點。

7-2-1. 發現資通系統有被入侵跡象時，應通報機關特定人員。

通報的對象：網管、系統管理者、系統擁有者、各級資安人員。

7-2-2. 監控資通系統，以偵測攻擊與未授權之連線，並識別資通系統之未授權使用。

重點一在於監控，使用下列工具達到：

  • WAF, Web Applications Firewall
  • IDS, Intrusion Defense Systems
  • IPS, Intrusion Prevention Systems
  • 防毒軟體
  • 網路監控軟體

重點二在於識別：

  • 攻擊行為
  • 未授權連線
  • 未授權使用

7-2-3. 資通系統應採用自動化工具監控進出之通信流量，並於發現不尋常或未授權之活動時，針對該事件進行分析。

針對通信的異常流量為事件進行分析

7-3-1. 使用完整性驗證工具，以偵測未授權變更特定軟體及資訊。

避免應用程式、目錄、組態被惡意竄改，使用雜湊函數、同位元檢查、循環冗餘檢查，使用目錄檔案監控工具，針對異動提出示警。

7-3-2. 使用者輸入資料合法性檢查應置放於應用系統伺服器端。

相似於 1-3-2. 使用者之權限檢查作業應於伺服器端完成。，強調伺服器端進行輸入合法性與權限檢查的動作，避免被惡意使用者繞過檢查機制，不當存取。

合法性檢查主要是為避免 XSS 以及 Injection 的攻擊。

7-3-3. 發現違反完整性時，資通系統應實施機關指定之安全保護措施。

保護措施包含修復工作外，尚包含進行資安通報。

國家資通安全通報應變網站

7-3-4. 應定期執行軟體與資訊完整性檢查。

將 7-3-1 的完整性驗證列為定期執行與檢查機制。

參考資料

安全系統發展生命週期 | NCHU

110年資通系統防護基準驗證實務 | NCCST

試行 資通系統籌獲各階段資安強化措施

111年資通安全稽核計畫及稽核作業：資料來源

#CyberSecurity #SSDLC