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


  1. 資訊安全
    1. 存取控制
    2. 稽核與可歸責性
    3. 營運持續計畫
    4. 識別與鑑別
    5. 系統服務與取得
    6. 系統與通訊保護
    7. 系統與資訊完整性
  2. 參考資料

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

logo

資訊安全

各控制措施來源為資通安全責任等級分級辦法中的附表十《資通系統防護基準修正規定》,並參考 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

特定事件:

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

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)至與原稽核系統不同之實體系統。

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

營運持續計畫

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. 資通系統應識別及鑑別非機關使用者(或代表機關使用者行為之程序)。

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

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

系統服務與取得

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

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

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

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

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

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. 應儲存與管理系統發展生命週期之相關文件。

相關文件舉隅:

  • 軟體發展計畫書
  • 軟體需求規格書
  • 系統規格書
  • 軟體測試計畫
  • 維護手冊
  • 軟體使用手冊
  • 系統文件審查表
  • 系統原始碼
  • 測試問題紀錄表
  • 軟體測試報告
  • 驗收紀錄表

系統與通訊保護

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