九、 安全軟體維運(MA)
組織在導入安全軟體開發參考指引時,在安全軟體維運主要聚焦於「事件監控」、「滲透測試」、「異常管理」面向。茲就安全軟體維運的參考指引,表列、說明如下：
MA-1 事件監控
為能安全維運,應建立機制程序,監控相關日誌,檢查錯誤發生的原因,尋找攻擊者留下的蹤跡。
MA-1-1 制定軟體清冊。
1.1概述：隨著攻擊者和攻擊的發展、合規性要求的變化以及補丁項目數量極其龐大時,能夠靈活應對,應制定軟體清冊、軟體元件清單,了解運行中軟體的所有元件位置,以在發生安全事件時可及時回應。
1.2執行建議：正式環境中的應用軟體及其位置清單是任何經營良好的企業的關鍵資訊,其軟體清冊有助於組織加強其安全狀態,即隨著攻擊者和攻擊的發展、合規性要求的變化以及補丁項目數量極其龐大時,能夠靈活應對。了解運行中軟體的所有元件(components)位置可在發生安全事件時及時回應。
MA-1-2 對系統日誌之監控。
2.1概述：為使資訊系統安全運轉,應監視系統的日誌文件,檢查錯誤發生的原因,或者尋找攻擊者留下的蹤跡,必要時應有控制機制。
2.2執行建議：這裡的日誌文件,是用以記錄系統中硬體、軟體和系統問題的資訊,同時還可以監視系統中發生的事件。組織可通過它來檢查錯誤發生的原因,或者尋找攻擊者留下的蹤跡。可參考ISO27001:2022 A8.16監視活動之資訊安全要求事項,建議相關控制措施,以監視網路、系統及應用之異常行為,並採取適切措施,以評估潛在資訊安全事故,並偵測異常行為及潛在資訊安全事故。亦可參考SEMI E-187之[E187.00-RQ-00011-00]10.2之安全日誌、日誌類型等要求 作業。
MA-1-3 加強對軟體行為之監控。
3.1概述：為加強對軟體行為之監控,對於帳戶應有適當的管理(如更改預設帳戶等),以利於找出入侵徵兆,對軟體異常行為如連續登入錯誤、操作失誤、不恰當的使用時間等進行監控或檢測,必要時應用控制機制。
3.2執行建議：為找出入侵徵兆,應對軟體異常行為如連續登入錯誤、操作失誤、不恰當的使用時間等進行監控或檢測,必要時應用控制機制。
MA-2 滲透測試
為降低遭受新型攻擊的危害,應明訂定滲透測試計畫、測試時機,並將滲透測試結果應予分析、評估,作為規劃下一次測試及修改測試計畫的參考。
MA-2-1 定期開展滲透測試。
1.1概述：新型攻擊手法隨時都可能出現,為確保程式不會遭受新型攻擊的危害,應明確訂定滲透測試計畫並定期執行。
1.2執行建議：需定期執行滲透測試,並針對其報告內容,組織需進行修改補正或採取其他相關措施補強。
MA-2-2 聘請外部滲透測試者開展深度分析。
2.1概述：為協助組織了解攻擊者的最新思路以找到未知攻擊類型,應聘請外部滲透測試人員對關鍵性的產品進行中立的深度分析。
2.2執行建議：為協助組織了解攻擊者的最新思路以找到未知攻擊類型,應聘請外部滲透測試人員對關鍵性的產品進行中立的深度分析,在測試方式上可分三大類：黑箱測試：測試者除了知道網站或軟體的名稱外,對目標一無所知；白箱測試：測試者完全了解網路組態(configuration),也能進入網路和使用相關裝置；灰箱測試：測試者掌握若干資訊和某種程度的系統進入權限。組織選擇什麼類型的測試,取決於它最想保護什麼、最擔心什麼類型的敵人,以及它估計敵人會蒐集多少資訊來發動惡意攻擊。
MA-2-3 建立軟體和基礎架構部署的自動檢測機制。
3.1概述：為確保軟體和基礎架構部署符合預期,應建立自動檢測機制並產出報告。
3.2執行建議：為確保軟體和基礎架構部署符合預期,依組織政策和設定標準,建立自動檢測機制來自動檢測營運基礎架構的安全性,例如驗證組織所規定的安全加固(harderning)屬性是否確實執行等。基礎架構包括應用軟體、網路、容器或雲端環境等。
MA-2-4 對已部署的應用程式建立攻擊面管理(威脅管理)。
4.1概述：為確保已部署的應用程式軟體,應建立攻擊面管理(威脅管理)機制並產出報告。
4.2執行建議：1.應透過威脅情報,進行弱點掃描及滲透測試等程序,找出應用程式及介面之弱點及漏洞等相關資訊,並利用前述資訊進行風險管理,以減少被入侵機會；同時將前述資訊回饋至威脅建模(威脅管理)及SBOM表。2.應確保各項安全參數已被設定,如雲服務、VPN、分隔網段、網路、主機和應用程式等安全參數配置等。
MA-3 異常管理
為確保正式作業環境之安全性並能及時回應異當狀態,應實施異常風險處理及追蹤管理機制,建立預防再次發生相同失誤的對策。
MA-3-1 實施軟體缺陷回饋給開發人員的機制。
1.1概述：建立將上線後的軟體缺陷回饋給開發人員的機制,以修正改進未來相關的開發執行,避免類似錯誤再度發生。同時,透過收集這些資料有助於組織及早發現缺陷或第一時間防止漏洞。
1.2執行建議：建立組織內部接收與追蹤機制,並規劃回饋開發團隊機制,由開發團隊進行優化與分享。可以精進開發人員的作為,修正其不良的程式撰寫習慣,改進未來的開發內容,避免類似錯誤再度發生。同時,修正源碼檢視清單、安全測試自訂規則、測試案例等方式,有助於組織及早發現缺陷或第一時間防止漏洞。
MA-3-2 實施軟體錯誤的風險處理及追蹤管理機制。
2.1概述：為確保正式作業環境之安全性,應建立軟體錯誤的風險處理及追蹤管理機制,明確訂定發生軟體錯誤時之風險處理作業程序、相關的責任及權責,同時標註哪些軟體錯誤與安全相關,進行追蹤管理直到完全修復。亦須定期檢視機制實踐的有效性。
2.2執行建議：正式環境中發現的缺陷需要被回饋到開發部門,將其載入既有的缺陷管理系統,依照定的嚴重程度及優先順序,執行修復流程及進行追蹤管理,直到修復為止。
MA-3-3 修復存在於個別應用的相同錯誤。
3.1概述：為全面修復存在於個別應用的相同錯誤,應建立源碼庫之維護制度,並制定將發現的錯誤轉換為一套可以通過自動源碼審查進行掃描的規則。對於每次的修復,需有可識別的機制(編號),以利後續追溯。
3.2執行建議：組織欲全面修復存在於個別應用的相同錯誤,其關鍵之一在於以源碼庫的方式進行維護及針對每個應用軟體建立SBOM。透過SBOM了解錯誤的模組,存在於那些應用軟體中,以利發布修復的版本。
MA-3-4 建立防止軟體錯誤再次發生的機制。
4.1概述：為防止相同錯誤重複發生,應訂定防範對策,於每個事件回應的事後環節加入一個「回饋到開發流程」的步驟,對於回饋到開發流程機制,亦須定期審查機制實踐的有效性。
4.2執行建議：於每個事件回應的事後環節加入一個「回饋到開發流程」的步驟,在回饋到開發團隊後,開發團隊的leader應將事件軟體的錯誤,經分析研判後,將程式修復,經所有檢視、測試過程後,更新源碼庫及人工源碼審查清單,如果可行,將自動測試工具,加入新的樣式(pattern),新增或更新測試案例,避免錯誤再度發生,並進行教育訓練及經驗分享,深化開發人員的了解認知。
MA-3-5 建立資安事件回應機制。
5.1概述：為使人員能迅速有效回應各種資安事件,應建立資安事件回應、安全問題管理(包含審查、評估、解決、揭露、定期審查安全問題管理機制)機制,實施資安事件回應演練,同時安全小組與事件回應團隊應交流有關事件相關訊息。
5.2執行建議：為使人員能迅速有效回應各種資安事件,應建立資安事件回應機制,實施資安事件回應演練,同時安全小組與事件回應團隊應交流有關事件相關訊息。
其機制應包含接收安全問題之來源、審查、評估與揭露,並定期審查安全缺陷管理等。機制建立,可參考國際標準ISO/IEC 29147漏洞揭露與處理。
MA-3-6 建立應用程式或源碼遭受攻擊時，緊急回應機制。
6.1概述：當偵測發現程式碼遭攻擊時,為防止危害擴大的因應對策略與源碼復原作業程序應明確訂定。偵測到非法存取時,不論是否有蒙受損害,應有防止非法存取行為擴大的因應對策與復原對策,同時,在分析非法存取的原因後,應有防止再發生的對策。
6.2執行建議：1.修復源碼的方式包括投入修補程式的開發、回退到前一個安全無虞的版本等。2.一般而言,緊急回應團隊就是開發團隊。團隊此時必須具有明文規定的應變流程,平時的演練有助於發現明文規定但沒有實際用途的流程。將解決相關資安的問題留下紀錄,回饋並建立企業專屬的開發問題回覆。程式遭受攻擊時,緊急源碼回應機制與流程,可參考ISO 30111漏洞處理流程。
MA-3-7 建立軟體安全危機的應變機制並演練。
7.1概述：為降低軟體因駭客入侵所遭受的損害,應檢視軟體環境之變化而可能發生之入侵事故,並訂定防範對策。
7.2執行建議：企業變機制應考量增加類似因應相關軟體造成影響之情境,如：因駭客入侵軟體造成或遭受的損害,其企業單位如何因應與相關處理措施,應包含檢測軟體環境之變化而可能發生之入侵事故,並訂定相關防範對策。可參考ISO27001:2022 A5.30營運持續之ICT備妥性要求,並依服務營運持續目標及ICT持續之要求事項,規劃、實作、維護及測試ICT備妥性。以確保於中斷期間,組織之資訊及其他相關聯資產的可用性。
MA-3-8 建立安全軟體線上更新機制。
8.1概述：為降低已上線軟體因更新造成的安全風險,應建立正式的線上更新機制,並嚴格執行,以降低可能的安全風險及商譽損失。
8.2執行建議：安全軟體更新機制包含發布安全性問題及修補程式。發布對象可能是組織的業主或顧客,建議可參考伍、參考文獻[11]、[12]、[13]、[14],Cisco、IBM、Synology、合勤、威聯通的PSIRT(product security incident respond team)作業方式,再依組織需求作調整,建立屬於組織的安全軟體線上更新機制。流程由接獲通知開始,在接獲通知後,應先進行分析對目前安全軟體是否有影響,影響嚴重程度範圍,擬定緩解措施並對外公布,經風險評估後訂定修補程式的開發計畫時程,進行修補程式安全開發流程,確認修補程式可以上線後,對外正式公告安全問題及同時發布修補程式。此節亦可參考SEMI E-187之[E187.00-RQ-00001-00] 7.2之支援生命週期要求與系統更新作業程序文件要求作業。
MA-3-9 簡化外部漏洞發現者與內部相關人員的溝通流程。
9.1概述：為能迅速有效查證確認漏洞並予以回應,減少可能造成的營業、商譽損失,應儘可能以公開方式接受漏洞發現者的訊息,並簡化外部與內部相關人員溝通流程。
9.2執行建議：為能迅速有效查證確認漏洞並予以回應,減少可能造成的營業、商譽損失,應儘可能以公開方式,接受漏洞發現者的訊息,如很多組織在企業(官方)網站明顯處,以電子郵件回應的方式(如以security@..),接受漏洞發現者的訊息;在組織內部對於外部有關漏洞的回應機制,內部相關回應團隊除資安團隊、開發團隊,應包含公關、業務及高階管理階層,以簡化並加速過程。
下表為參考指引中安全軟體維運的內容列表：
| 次分類 | 編號 | 內容 | 控制項對應 | ||
| IEC
62443-4-1 |
GSMA NESAS | NIST SSDF | |||
| 事件監控 | MA-1-1 | 制定軟體清冊 | SM-1,SM-9 | PS.3.2、PW.4.1、PW.4.4 | |
| MA-1-2 | 加強對系統日誌之監控 | SG-3,SG-5,SG-6 | |||
| MA-1-3 | 加強對軟體行為之監控 | SG-3,SG-5,SG-6 | [REQ-REL-01] | ||
| 滲透測試 | MA-2-1 | 定期開展滲透測試 | PW.8.1 | ||
| MA-2-2 | 聘請外部滲透測試者開展深度分析 | PW.8.2 | |||
| MA-2-3 | 建立軟體和基礎架構部署的自動檢測機制 | ||||
| MA-2-4 | 對已部署的應用程式建立攻擊面管理(威脅管理) (new) | ||||
| 異常管理 | MA-3-1 | 實施軟體缺陷回饋給開發人員的機制 | DM-1 | [REQ-OPE-02] [REQ-OPE-03] [REQ-OPE-05] [REQ-GEN-05] | RV.1.1、RV.2.1 |
| MA-3-2 | 實施軟體錯誤的風險處理及追蹤管理機制 | DM-6、SUM-5 | [REQ-OPE-02] [REQ-OPE-03] [REQ-OPE-05] | RV.2.1 | |
| MA-3-3 | 修復存在於個別應用的相同錯誤 | SUM-1 | [REQ-OPE-02] [REQ-OPE-03] [REQ-OPE-05] | RV.1.2、RV.3.1、RV.3.3 | |
| MA-3-4 | 建立防止軟體錯誤再次發生的機制 | DM-6,SM-13 | [REQ-OPE-02] [REQ-OPE-03] [REQ-GEN-05] | RV.3.1、RV.3.2、RV.3.4 | |
| MA-3-5 | 建立資安事件回應機制 | DM-1,DM-2,DM-3,
DM-4,DM-5,DM-6 |
RV.1.3 | ||
| MA-3-6 | 建立應用程式遭受攻擊時,緊急源碼回應機制 | DM-4 | [REQ-OPE-02] | RV.1.1、RV.1.3、RV.2.2 | |
| MA-3-7 | 建立軟體安全危機的應變機制並演練 | RV.1.3 | |||
| MA-3-8 | 建立安全軟體線上更新機制 | DM-1,DM-2,DM-3,
DM-4,DM-5 |
|||
| MA-3-9 | 簡化外部漏洞發現者與內部相關人員的溝通流程。 | [REQ-OPE-01] [REQ-OPE-02] [REQ-OPE-03] | RV.1.1、RV.1.3 | ||
| 資料來源：本計畫整理 | |||||
十、 第三方風險管理(TPM)
組織在導入安全軟體開發參考指引時,在第三方風險管理(Third-party management),主要聚焦於「範圍確認」、「履約管理」、「稽核」面向。茲就第三方風險管理的參考指引,表列、說明如下：
TPM-1 範圍確認
在與第三方合作時,合作的範圍應明訂,包含交付的資訊資產、軟體安全目標、安全需求、驗證的標準等。
TPM-1-1 識別第三方作業所包含的資訊資產。
1.1概述：確認第三方作業時應提供之資訊資產。
1.2執行建議：識別針對第三方作業所產生或提供的資訊資產,執行E 188所要求的惡意程式與安全組態檢測,交付軟體物料清單(SBOM),並制訂軟硬體造成損壞之防範對策。
TPM-1-2 明訂第三方軟體安全目標、安全需求。
2.1概述：明確安全的目標及需求,避免爭議。
2.2執行建議：針對合約內有要求第三方有明確的軟體安全要求與SLA。
TPM-2 履約管理
第三方在各階段產出及交付項目,需驗證及檢核結果的正確性,以管理交付品質。
TPM-2-1 驗證第三方控制措施是否正確、有效的完成實作。
1.1概述：驗證第三方控制措施是否正確、能有效的實作完成,確認是否符合合約約定。
1.2執行建議：確認第三方依照合約有落實執行安全控制項目。確認第三方供應商提供之模組元件符合IEC 62443 4-1之要求(第三方供應商提供之模組元件之安全議題)。
TPM-2-2 驗證第三方安全需求檢視結果的正確性。
2.1概述：檢視安全需求追溯表或紀錄以確認是否符合約定,或進行抽測(如機敏資料儲存必須依約定加密機制加密)。
2.2執行建議：第三方所執行之安全需求紀錄需留存,並檢視是否落實執行。第三方供應商提供之模組元件落實安全執行紀錄。
TPM-2-3 驗證第三方源碼安全查檢表之正確性。
3.1概述：檢視源碼安全查檢表確認是否符合約定。
3.2執行建議：第三方交付之原始碼規範須符合合約要求交付要求(第三方供應商提供之模組元件)。
TPM-2-4 追蹤確認第三方檢測結果報告中的安全弱點被修正。
4.1概述：檢視源碼審查報告確認是否符依事前設定源碼審查標準,完成測試並將安全弱點修正,或依報告進行抽驗。
4.2執行建議：事前須規劃源碼審查之要求項目,第三方須配合提供報告並追蹤(第三方供應商提供之模組元件)。
TPM-2-5 檢視滲透測試或弱點掃描歷程報告是否符合約定。
5.1概述：事前設定滲透測試或弱點掃描標準,追蹤確認第三方結果報告中的安全弱點缺陷是否依合約中規範被修正。
5.2執行建議：第三方須配合在時程內完成安全弱點修補。此節亦可參考SEMI E-187之[E187.00-RQ-00005-00]9.2之弱點緩解要求作業。
TPM-3 稽核
應定期或於內外部(如法規異動)環境改變、第三方組織重大調整時,進行第三方執行狀況的稽核,以確認是否符合約定的要求,管理交付品質。
TPM-3-1 確認第三方部署上線時,強化部署環境之程序如實被執行。
1.1概述：可檢視部署環境程序紀錄(如checking list)是否符合程序。
1.2執行建議：確認第三方部署上線或上版的紀錄與變更記錄的落實。
TPM-3-2 確認第三方監控量測程序有效執行。
2.1概述：可檢視監控量測紀錄確認是否符合規範的時間、內容及回應。
2.2執行建議：第三方監控量測值需依約定規範落實執行與記錄,並定期審視相關紀錄資訊。
TPM-3-3 確認第三方事故處理程序的有效性。
3.1概述：可檢視事故處理紀錄確認是否符合程序規範。
3.2執行建議：確認第三方有提出事故處理程序,並安排其演練,確認其有效性。
TPM-3-4 確認第三方按照變更管理程序執行軟體維護。
4.1概述：檢視變更管理紀錄確認是否符合程序,或進行抽測(查)確認結果是否與紀錄相同。
4.2執行建議：當異動變更作業時,需經審核並經確認同意後留存相關變更紀錄。
下表為參考指引中第三方風險管理的內容列表：
| 次分類 | 編號 | 內容 | 控制項對應 | ||
| IEC
62443-4-1 |
GSMA NESAS | NIST SSDF | |||
| 範圍確認 | TPM-1-1 | 識別第三方作業所包含的資訊資產 | |||
| TPM-1-2 | 明訂第三方軟體安全目標、安全需求 | [REQ-GEN-06] | |||
| 履約管理 | TPM-2-1 | 驗證第三方控制措施是否正確、能有效的實作完成 | SM-10 | ||
| TPM-2-2 | 驗證第三方安全需求檢視結果的正確性 | SM-10 | |||
| TPM-2-3 | 驗證第三方源碼安全查檢表之正確性 | SM-10 | |||
| TPM-2-4 | 事前設定源碼審查標準,追蹤確認第三方檢測結果報告中的安全弱點被修正 | SM-10 | |||
| TPM-2-5 | 檢視滲透測試或弱點掃描歷程報告是否符合約定 | SM-10 | |||
| 稽核 | TPM-3-1 | 確認第三方部署上線時,強化部署環境之程序如實被執行 | |||
| TPM-3-2 | 確認第三方監控量測程序有效執行 | ||||
| TPM-3-3 | 確認第三方事故處理程序有效執行 | [REQ-OPE-01] | |||
| TPM-3-4 | 確認第三方按照變更管理程序執行軟體維護 | ||||
| 資料來源：本計畫整理 | |||||