三、 安全軟體需求(RQ)
組織在導入安全軟體開發參考指引時,在安全軟體需求面主要聚焦於「要求與遵循」、「安全控制」、「供應鏈安全要求」面向。茲就安全軟體的需求說明如下：
RQ-1 要求與遵循
在導入安全軟體開發參考指引時,安全軟體需求可來自於國內外法規法令、監管單位要求及合約的規範,都需要列入需求清冊。
RQ-1-1 合規性約束轉變成作業要求。
1.1概述：為提高稽核時的可追溯性及可視性,組織的作業要求應依相關的法規、國際標準或合約規範等配合調整。
1.2執行建議：組織可藉由作業要求來證明合規性是可管理的任務。透過國際互通性目的而制定的技術標準中也可能包含軟體安全合規指引,把這些標準闡明為要求,將有助於提高稽核時的可追溯性及可視性。
確保記錄有關環境的假設與環境的最低安全性要求,並全面考量：實體安全、深度防禦策略與資安測試驗證環境架設等。
RQ-1-2 定期審查開發專案對組織之資訊安全政策及標準的遵循性
2.1概述：定期召開專案會議,審查並記錄專案進度，確保符合遵循組織之資訊安全政策及標準的要求。審查成員須包含設計開發、測試、面對客戶、安全小組代表。
2.2執行建議：要定期召開審查專案會議,並審查是否符合專案要求產出相關紀錄。定期採取專案執行的安全性審查作業,並同步確認人員專業資格。
RQ-1-3 資訊安全要求事項及控制措施,宜反映營運需求
3.1概述：應表列資訊安全要求事項及控制措施項目符合現況,如目前環境或同業發生的問題,及探討可能對企業造成潛在負面營運衝擊的項目。
3.2 執行建議：定期蒐集目前所發生之資安事件及同業發生之問題,並開會探討內部的控制措施及應對方案。
RQ-1-4 遵循與智慧財產權及專屬軟體產品使用相關之法律、法令、法規及契約的要求事項
4.1概述：遵循與智慧財產權及專屬軟體產品使用相關之法律、法令、法規及契約的要求事項。
4.2執行建議：專案執行須遵循與智慧財產權及專屬軟體產品使用相關之法律、法令、法規及契約的要求事項,如：不使用非法未授權之軟體。
RQ-2 安全控制
軟體安全的要求事項,在新開發或是既有專案的強化事項,以及個別環境上的安全要求,都需要納入考慮。
RQ-2-1 在新專案或既有專案之強化要求事項中納入資訊安全相關要求事項
1.1概述：資訊安全相關要求事項,需正面表列方式,並依照時事定期修正討論。
1.2執行建議：針對資訊安全相關要求事項,需正面表列方式,並依照時事定期修正討論。確保記錄有關環境的假設與環境的最低安全性要求,並全面考量：實體安全、深度防禦策略與資安測試驗證環境架設等。
RQ-2-2 將軟體執行環境特性之專屬安全要求納入專案安全要求考量規範內。
2.1概述：考量軟體開發實際環境之安全控制範圍,界定明確且不發散。
2.2執行建議：全面考量界定實體安全、深度防禦策略與資安測試驗證環境架設等範圍內符合法律、法令、法規及契約的要求事項。
RQ-2-3 需求分析須考量產品全生命週期(lifecycle)的安全需求。
3.1概述：需求分析須考量產品生命週期安全需求,包含安裝、維運、汰除等。
3.2執行建議：針對正在開發產品與功能的安全性要求進行紀錄,不僅限於產品使用之安全性要求,亦須包含安裝、維運汰除等安全需求。
RQ-3 供應鏈安全要求
使用第三方組件、技術或產品,須將安全性要求納入,列冊控管、追溯來源、有配套措施及備案。
RQ-3-1 當第三方之產品的安全功能性未符合組織所規定之要求時,於採購該產品前,應重新考量引入之風險及相關聯的控制措施。
1.1概述：供應鏈產品提供不符合安全規定之要求,團隊應重新評估考量替代方案,針對新採購產品前應有備案或相關配套應變控制措施。另需考量供應鏈產品發現弱點時安全更新、安全部署的應變控制措施。
1.2執行建議：應事前思考規劃如第三方提供不符合組織規定之產品,其替代方案或配套應變措施。採取一種方式來識別和管理產品內使用的所有外部提供之的安全性組件。
RQ-3-2 確保供應鏈夥伴完全知悉對其提供服務或使用服務之授權。
2.1概述：應於合約中明確規範供應鏈提供的服務,如非自有,須提出合規授權證明。
2.2執行建議：應要求供應鏈依照於合約內規範,確保其服務及通訊方式。針對供應鏈或第三方會造成影響的模組,因評估其風險性,並用威脅建模的方式來確認可能造成之影響。
RQ-3-3 對於資訊及通訊技術產品,若此等產品包含採購自其他供應者之組件,應要求供應者對整個供應鏈傳播適切之安全實務作法。
3.1概述：針對供應鏈提供之組件,應於合約內明文規定要求,供應者須提出確保其安全實務的作法。
3.2執行建議：合約內明文規定要求,供應鏈提供之組件,須提出確保其安全實務的作法,其中應包含對惡意程式檢查的機制,包含定義合格的惡意程式檢查工具,以及如何執行等規範,在將來自第三方供應商所提供之系統或設備加入組織內環境前之要求可參考SEMI E188之要求。來自第三方供應商制訂的開發組件須符合IEC 62443-4-1之要求。
RQ-3-4 取得關於關鍵組件及其來源於整個供應鏈可被追溯之保證。
4.1概述：針對關鍵性組件應造冊列管,並確保可以被追溯來源。
4.2執行建議：統整並彙整供應鏈提供之關鍵性組件,包含來源是開源軟體(或函數庫),依照相關開發來源版本造冊列管,並確保可以被追溯來源。
下表為參考指引中安全軟體需求的內容列表：
| 次分類 | 編號 | 內容 | 控制項對應 | ||
| IEC
62443-4-1 |
GSMA NESAS | NIST SSDF | |||
| 要求與遵循 | RQ-1-1 | 合規性約束轉變成作業要求 | SR-1 | PO.3.2、PO.3.3 | |
| RQ-1-2 | 定期審查開發專案對組織之資訊安全政策及標準的遵循性 | SR-5 | |||
| RQ-1-3 | 資訊安全要求事項及控制措施,宜反映相關資訊之營運價值 | ||||
| RQ-1-4 | 遵循與智慧財產權及專屬軟體產品使用相關之法律、法令、法規及契約的要求事項 | SR-1 | |||
| 安全控制 | RQ-2-1 | 納入資訊安全相關要求事項,在新專案或既有專案之強化要求事項中 | SR-1、SR-4 | ||
| RQ-2-2 | 將軟體執行環境特性之專屬安全要求納入專案安全要求考量規範內 | SR-1、SR-4 | |||
| RQ-2-3 | 需求分析須考量產品全生命週期許(lifecycle )的安全需求 | SR-3 | |||
| 供應鏈安全要求 | RQ-3-1 | 當第三方之產品的安全功能性未符合所規定之要求時,於採購該產品前,應重新考量引入之風險及相關聯的控制措施 | SM-9,SM-10 | ||
| RQ-3-2 | 確保通訊夥伴完全知悉其對提供服務或使用服務之授權 | SM-10 | |||
| RQ-3-3 | 對於資訊及通訊技術產品, 若此等產品包含採購自其他供應者之組件, 應要求供應者對整個供應鏈傳播適切之安全實務作法 | SM-10 | |||
| RQ-3-4 | 取得關於關鍵組件及其來源於整個供應鏈可被追溯之保證。 | SM-9 | |||
| 資料來源：本計畫整理 | |||||
四、 安全軟體分析(SA)
組織在導入安全軟體開發參考指引時,在安全軟體分析主要聚焦於「流程架構」、「威脅建模」、「安全性審查」面向。茲就安全軟體分析說明如下：
SA-1 流程架構
在導入安全軟體開發參考指引時,在安全軟體分析必須定義架構分析流程,標準化架構描述,並藉由架構分析結果回饋精進安全架構模式。在安全軟體的流程架構,可參考伍、參考文獻[11]微軟 Simplified Implementation of the Microsoft SDL流程架構,依組織的特性需求增修。
SA-1-1 定義並使用架構分析流程。
1.1概述：組織應定義架構分析流程,內容涵蓋駭客攻擊思維、安全特性和關聯風險的標準化方法,使其足以指導安全小組以外的人員(如產品安全架構師)執行流程。
1.2執行建議：架構分析流程包括考慮攻擊、安全特性和關聯風險的標準化方法,並且要周密界定,使其足以指導安全小組以外的人員(如產品安全架構師)執行流程。市面上不同的工具,支援SA的分析流程,建議組織可選用其一,如DFD、ERD、UML、BFD、WBS等,內容設計上涵蓋可能的駭客攻擊方式、安全特性和關聯風險。
SA-1-2 標準化對架構描述方式。
2.1概述：為確保組織人員能以統一的語言描述架構,應事先約定描述架構的格式與說明的內容,以確保架構描述的正確性與一致性。
2.2執行建議：採用約定的格式描述架構,並透過文件將流程結合標準化的架構描述記錄下來,可使那些不是安全專家的人員更加容易地處理架構分析。透過完善標準架構描述,可為需要保護的產品提供清晰的圖景(picture)。
SA-1-3 由開發團隊主導架構分析流程。
3.1概述：為確保架構分析的合理性及可執行性,應由開發團隊主導架構分析流程,惟安全小組應作為安全顧問角色或在特殊情況下參與架構分析給予相關建議。
3.2執行建議：大多數時候都是由開發團隊帶頭執行架構分析流程。安全小組仍然可能作為顧問或在特殊情況下參與架構分析。
SA-1-4 將架構分析結果回饋並納入標準安全架構模式。
4.1概述：為確實避免類似錯誤再度發生,應制定將架構分析結果回饋至標準安全架構的機制,經審視討論後修正改進未來相關的設計模式。
4.2執行建議：架構過程中發現的問題應回饋給安全設計委員會,以便通過改進設計模式來避免未來再發生類似錯誤(參見BSIMM SFD3.1)。
SA-1-5 建立資料保護目標清單且進行分類分級。
5.1概述：為防止重要機敏資料遭受危害,越高等級的機敏資料必採取越高強度的管理機制,並在分級上考量價值及保護與工作效率之間的平衡。
5.2執行建議：組織應以攻擊者的思維,關注那些有價值的資產(資料),並建立特定目的資料清單。例如，明確地與某個人相關的個人識別資訊(Personally Identifiable Information,PII)。在分級上應考量價值及保護與工作效率之間的平衡,愈高等級的機密必採取愈高密度的管理機制,因此,妥適的分級,對於後續管理機制會有連動之關係。在擬定管理機制時,可依資產(資料)在處理(in use)、儲存(at rest)與傳輸(in transit)時,依不同等級制定不同的保護機制,並考量價值、保護與工作效率之間的平衡。
SA-2 威脅建模
藉由威脅建模尋找潛在威脅建立對抗的策略,以建立安全的軟體。
SA-2-1 備有因應潛在攻擊者的對策。
1.1概述：當偵測發現潛在攻擊時,不論是否有蒙受損害,應有防止潛在攻擊行為擴大的因應對策與復原對策,同時,在分析潛在攻擊的原因後,應有防止再發生的對策。
1.2執行建議：「攻擊者」係指可能利用組織資訊資產弱點進行攻擊,而對組織之營運造成負面衝擊的內部或外部人員。因此應該定期(每年至少一次)審查其威脅建模模組之有效性與合宜性。
SA-2-2 蒐集及使用攻擊情報的對策。
2.1概述：組織應有適當的漏洞情報蒐集管道與使用對策,以隨時掌握最新的資訊。
2.2執行建議：「新型攻擊」係指新型態資安攻擊手法,所使用的攻擊技巧、手法及工具未廣為周知,為傳統資安防禦工具所難以偵測到的攻擊態樣。定期蒐集與使用的攻擊手法,並納入企業體系內化確認其有效性,並經彙整後評估其對策與方向措施是否合宜。蒐集並分析與資訊安全威脅相關之資訊, 以產生威脅情資。以提供對組織威脅環境之認知,以便採取適切的減緩措施。蒐集並分析與組織技術相關的攻擊知識以及既有或新出現威脅之資訊,以便用於下列事項：
(a) 促進採取知情行動,以防止威脅造成傷害。
(b) 降低此等威脅之衝擊。
通常最容易的方法是從現有的通用攻擊模式開始,以創建所需的特定技術模式,但僅僅在通用模式名稱的末尾添加,例如“適用於微服務”,是不夠的。
SA-2-3 建立與潛在攻擊者有關的攻擊模型和濫用案例。
3.1概述：針對值得保護且具有價值之資訊資產,組織應建立潛在攻擊者威脅模型,用來分析尋找合適的對抗方式,以降低內部或外部的威脅造成資產的損失。
3.2執行建議：「攻擊模型」是以攻擊者的角度為出發點,評估攻擊者的目的與他們如何達成目的。這種分析方式通常從侵入點或是標的資產著手思考。增加新的攻擊模型時,應多方面思考其入侵涉及點線面造成之影響。
SA-2-4 備有因應特定保護技術遭受攻擊的對策。
4.1概述：為防止特定保護技術如密碼、Trust Zone等遭受駭客非法侵害,應有適當的防禦對策。
4.2執行建議：所謂特定技術,舉例來說密碼保護即為一種特定技術。攻擊者可針對密碼保護發展出許多相關的攻擊方式,如字典攻擊法、暴力破解法等。定期將現有已被揭露之技術納入評估考量之對策。
SA-2-5 建立並維護最危險的N種攻擊列表。
5.1概述：在蒐集各種資安漏洞時,應歸納出好發且容易攻擊的弱點,以建立相應的防範措施。
5.2執行建議：最危險的N種攻擊列表,舉例來說,可指10種(Top 10)對組織所研發之產品造成最嚴重威脅的攻擊態樣。組織可根據預估的潛在業務損失程度或對產品攻擊之成功機率來確定優先順序。企業內部建立自我的攻擊列表,或最可能造成的攻擊型態列表。
SA-3 安全性審查
透過安全性審查,以掌握各項軟體安全的風險,研擬適當之因應措施。
SA-3-1 實施安全性功能審查
1.1概述：為確保安全性功能滿足安全需求並按預期運行,應實施安全功能審查,並建立安全性功能不符合之對策。審查的成員應包含設計、測試人員、客戶窗口、安全小組團隊成員。
1.2執行建議：需進行安全功能性審查,並檢查其功能是否符合預期,並針對不符合之功能進行處置。應定期審查威脅建模之安全性是否符合預期。
SA-3-2 掌握作業風險等級及優先順序。
2.1概述：掌握各種作業的風險等級,並研擬適當之因應措施及優先處理順序。
2.2執行建議：應研擬適當之因應措施及優先處理順序,針對各種預期風險處理回覆。彙整目前所有的風險進行分析彙整,找出其可能之共同性或處理方式。
SA-3-3 針對高風險應用開展設計審查。
3.1概述：在高風險應用的開發上,應以安全風險等級為基礎,訂定設計評估之作業程序,以維護相關設計之妥適性。
3.2執行建議：組織應以攻擊者的思維,關注那些有價值的資產(資料),並建立特定目的資料清單(如PII清單)。在分級上應考量價值及保護與工作效率之間的平衡,愈高等級的機密必採取愈高密度的管理機制,因此,妥適的分級,對於後續設計審查及維護管理機制會有連動之關係。
SA-3-4 由安全小組領導分析、設計審查工作。
4.1概述：明確指定分析、設計審查執行人員之目的,除了明確劃分責任外,發生審查缺失時,容易追究原因。
4.2執行建議：「攻擊者」係指可能利用組織資訊資產弱點進行攻擊,而對組織之營運造成負面衝擊的內部或外部人員,所以需要安全小組依照前面所述SA-3-1～SA-3-3設計制定後續審查作業原則,包含角色與審查議題追蹤狀態,減少當發生審查缺失時,可以明確其造成之原因與後續影響。
下表為參考指引中安全軟體分析的內容列表：
| 次分類 | 編號 | 內容 | 控制項對應 | ||
| IEC
62443-4-1 |
GSMA NESAS | NIST SSDF | |||
| 流程架構 | SA-1-1 | 定義並使用架構分析流程 | PW.2.1 | ||
| SA-1-2 | 標準化對架構描述方式 | PW.1.2 | |||
| SA-1-3 | 由開發團隊主導架構分析流程 | PW.2.1 | |||
| SA-1-4 | 將架構分析結果回饋並納入標準安全架構模式 | PW.1.2 | |||
| SA-1-5 | 建立資料保護目標清單且進行分類分級 | [REQ-GEN-04] | PO.1.2、PW.1.1 | ||
| 威脅建模 | SA-2-1 | 備有因應潛在攻擊者的對策 | SR-2 | PW.1.1 | |
| SA-2-2 | 蒐集及使用攻擊情報的對策 | SR-2 | PW.1.1、RV.1.1 | ||
| SA-2-3 | 建立與潛在攻擊者有關的攻擊模型和濫用案例 | SR-2 | [REQ-DES-01] | PW.1.1 | |
| SA-2-4 | 備有因應特定保護技術遭受攻擊的對策 | SR-2 | [REQ-DES-01] [REQ-GEN-03] | PW.1.1 | |
| SA-2-5 | 建立並維護最危險的 N 種攻擊列表 | SR-2 | PW.1.1 | ||
| 安全性審查 | SA-3-1 | 實施安全性功能審查 | SR-5 | PW.1.1、PW.2.1 | |
| SA-3-2 | 掌握作業風險等級及優先順序 | SR-5 | |||
| SA-3-3 | 針對高風險應用開展設計審查 | SR-5 | PW.2.1 | ||
| SA-3-4 | 由安全小組領導設計審查工作 | PW.2.1 | |||
| 資料來源：本計畫整理 | |||||