五、 安全軟體設計(SD)
組織在導入安全軟體開發參考指引時,在安全軟體設計主要聚焦於「設計規範」、「安全開發環境」面向。茲就安全軟體設計的說明如下：
SD-1 設計規範
構建並發布安全軟體的設計規範,以利組織遵循。
SD-1-1 構建並發布安全性功能。
1.1概述：為確保專案使用到合格的安全功能或元件,應制定安全功能或元件清單,並審視其安全性,讓開發團隊可以從安全小組預先認可的安全功能或元件中受益。合格之安全功能或元件,也需定期審查更新,確保其安全性。
1.2執行建議：首先定義安全設計審查規則(識別、歸納和追蹤與重大議題討論等)及安全設計原則要求(確實落實執行與文件化,如：最小特權、盡量使用經通過驗證的安全組件或設計、精省的機制、安全設計樣板、記錄所有可信任邊界等)。所謂「安全功能或元件」係指認證、角色管理、金鑰管理、審核/日誌、加密和協定等。這些功能可能是在源碼審查期間發現的,可能是由安全小組或專門的開發團隊建立的,也可能是供應商提供的函式庫/SIP中所包含的。通用安全功能通常需要針對特定平台進行量身定制。開發團隊可以從安全小組預先認可的安全功能或元件中受益。
SD-1-2 構建“Secure by Design”的中介軟體框架和通用函式庫。
2.1概述：為確保資料傳輸之安全性、信賴性,並防止非法之、破壞、篡改,對於中介軟體框架及通用函式庫應使用有適當之Secure by Design保護措施以及資料傳輸之安全政策。
2.2執行建議：「Secure by Design(安全始於設計)」係指一個產品的設計基礎包含了安全的觀點。此觀點必須把針對該產品的惡意行為視為理所當然,並設法在安全漏洞被發現時,盡量減少對該產品的衝擊。於產品開發流程中的設計階段,列出安全需求、辨識安全風險及套用控制措施,以作為後續安全功能驗證的基礎,落實安全的軟體生命週期,從設計先期階段著手整體資訊系統安全。建立安全性設計原則展現紀錄,可識別和表現的介面(應加以考慮安全設計原則),安全設計審查及安全設技原則要求等措施,且落實定期審查作業。
SD-1-3 制定開源程式碼與第三方提供組件的分析機制。
3.1概述：為識別出專案中所使用的開源程式碼與第三方提供組件,其中可能包含的安全漏洞,組織應制定分析機制,如自動化掃描或人工審查,以找出相關的安全漏洞。
3.2執行建議：所謂開源程式碼(Open Source)」係指原所有權人在軟體協定的規定(如GPL、LGPL)之下將產品的程式原始碼公開釋出,讓任何人皆可以取得原始程式碼合法進行修改、編輯,對於原本產品進行改善或者客製化以符合自己的需求,制定建立企業專屬針對開源始程式碼的使用的方法或原則,如：使用原則及分析哪些開發的狀態可能需要使用到等。另外企業應建立並提供加強表列出的組件安全要求及分析之機制。
SD-1-4 制定應用程式的關聯清單。
4.1概述：為確保系統開發、變更內容及錯誤修復之正確性,應制定共用程式或元件的關聯清單(須包含版本),以便在一個產品中發現錯誤時,也可以修復共享相同程式碼或元件的其他產品。
4.2執行建議：建立共用程式碼或元件的部署地圖,如遇到發生問題時,即可能快速找到所有需要修正之關鍵位置。那些會在多個項目之間共享的通用元件應被標註,以便在一個產品中發現錯誤時,也可以修復共享相同元件的其他產品。評估與安全性相關的問題ex：異動性衝擊評估、嚴重的定義、識別問題根本、識別相關問題等。
SD-1-5 對程式碼儲存庫執行應用程式組成分析。
5.1概述：有關程式碼儲存庫應用軟體之組成分析,除開源軟體外,應包含內部開發,委託開發及第三方軟體等之軟體原始程式碼或二進位檔案及其關聯資訊,同時建置SBOM管理機制。
5.2執行建議：建立軟體清冊(SBOM)與軟體源碼庫中之元件關聯分析資料紀錄。
SD-2 安全開發環境
訂定安全開發環境標準,包括工具的基礎安全設定、源碼審查、滲透測試工具腳本等。
SD-2-1 訂定開發工具基礎之安全設定。
1.1概述：為確保開發工具之安全性,企業應當為每個開發工具組建立一套安全的基本設定,以進一步減少使用該開發工具組相關的工作量,並維護開發環境的安全性。
1.2執行建議：一個開發工具組可能包含一套作業系統、一個資料庫、一台應用伺服器及運行環境。理想情況下,企業應當為每個開發工具組建立一套安全的基本設定,從而進一步減少使用該開發工具組相關的工作量。建立開發環境安全建立相關產品文件紀錄(包含設計、實施、測試&發布保護產品或產品更新(修補/補丁)等。可參考採用SEMI E-188對合格惡意軟體掃描工具與組態弱點/合規掃描工具的使用建議。
SD-2-2 建立並使用自動化方法來模擬攻擊者。
2.1概述：為確保相關人員可以更容易使用工具或模組來模擬攻擊者等方式將其自動化,對於攻擊者行為應有適當之模擬工具及相關工具使用手冊,希望透過各種技術降低人為介入。
2.2執行建議：當團隊確定新型攻擊方法後,開發新攻擊方法的專案團隊,可能需要開發新的測試工具或模組來模擬攻擊者,安全小組就可以打包新工具並分發給測試人員,讓其他人更容易使用這些知識和技術。但針對新型攻擊方式之安全查證與確認需特別注意,可能會造成系統出異常或中斷等相關問題,因此建議可採用進階式逐步完善須完成以下安全功能測試,威脅測試,漏洞測試及黑箱測試等相關測試作業。
SD-2-3 制定滲透測試工具及腳本。
3.1概述：為提高滲透測試的效率,加強測試的深度及廣度,應選擇能夠自訂規則(腳本)的工具。
3.2執行建議：建立制定企業內部針對專案之黑箱測試的規範,可具體尋求專業人員協助,提出具體測試與規劃方案,區隔其差異性,透過不同的角度與方式,建立不同可執行的範本,如：專案類型之不同、方案時間、演練規劃與範圍等等。
下表為參考指引中安全軟體設計的內容列表：
| 次分類 | 編號 | 內容 | 控制項對應 | ||
| IEC
62443-4-1 |
GSMA NESAS | NIST SSDF | |||
| 設計規範 | SD-1-1 | 構建並發布安全性功能 | SD-4, SD-3 | PO.1.2、PW.1.3、PW.4.2 | |
| SD-1-2 | 構建“secure-by-design”的中介軟體框架和通用函式庫 | SD-1,SD-2,SD-3,SD-4,SG-7 | PW.1.3、PW.4.1、PW.4.2 | ||
| SD-1-3 | 制定開源始程式碼的分析機制 | SM-9 | PW.4.1、PW.4.4 | ||
| SD-1-4 | 制定應用程式的關聯清單 | DM-3 | [REQ-OPE-02] [REQ-IMP-02] | ||
| SD-1-5 | 對程式碼儲存庫執行應用程式組成分析(new) | ||||
| 安全開發環境 | SD-2-1 | 訂定開發工具基礎之安全設定 | SM-7 SG-7 |
PO.1.3、PO.3.2、PW.1.3 | |
| SD-2-2 | 建立並使用自動化方法來模擬攻擊者 | SVV-1, SVV-2, SVV-3,SVV-4 | |||
| SD-2-3 | 制定滲透測試工具及腳本 | SVV-4 | |||
| 資料來源：本計畫整理 | |||||
六、 安全程式碼撰寫(PG)
組織在導入安全軟體開發參考指引時,在安全程式碼撰寫主要聚焦於「撰寫規範」、「審查機制」面向。茲就安全程式碼撰寫參考指引,表列、說明如下：
PG-1 撰寫規範
制定實施標準化的安全程式碼撰寫方式,驗證程序與弱點或問題的描述方式。撰寫規範,可參考伍、參考文獻[12]、[13]、[23]、[24],再依組織需要做調適。
PG-1-1 實施安全程式碼撰寫標準。
1.1概述：安全程式碼撰寫程式時,應實施程式撰寫的標準化,以能在程式撰寫階段,確保軟體的品質。
1.2執行建議：「安全程式碼標準」係指特定程式語言(如C/C++、Assembly等)的撰寫標準。組織的安全程式碼標準通常是從一個簡單的禁止(或核准)功能列表開始強制執行的,違反這些標準就足以成為源碼審查駁回的理由。其它有用的程式碼標準可能包括正確使用產品的API、使用經過批准的密碼學技術、緩衝記憶體內容清除等。並定期進行審查會議與更新(包含已知安全漏洞及可能的設計模式與架構；已知安全漏洞而被禁用之函式模組；程式碼結構/設計樣式、自動化工具使用與設置；安全的程式編碼規範；可信賴邊界的所有輸入；錯誤處理等)。
PG-1-2 制定安全編碼標準之採用確認與驗證程序。
2.1概述：為提升系統可靠度,並確保內容之正確性,在系統開發、變更之各階段,其安全編碼之確認與驗證等應按規定程序辦理。
2.2 執行建議：安全程式碼主要挑戰來自於缺乏相關的技能、工具與方法。
組織應為開發人員提供安全培訓(參見BSIMM CR1.6)、提供清晰程式撰寫標準指導(參見BSIMM CR3.5)、進行人工或自動化源碼審查(參見BSIMM CR1.4)。建立安全實施審查作業程序,並每年審核考量新的風險威脅是否造成影響。
PG-1-3 標準化對弱點或問題的描述。
3.1概述：為提升人員對弱點或問題的解讀或為電腦處理提供助益,應訂定弱點或問題的標準化描述,以透過統一的術語、編號、分類等對弱點或問題進行說明。
3.2執行建議：安全小組偕同相關的資深人員或外部專家,針對弱點或問題描述參考現有的標準建立組織標準化的描述,將其文件化,並建立定期進行審查會議與更新機制,透過教育訓練,推廣至相關成員,建立組織內對弱點或問題的描述逐漸趨於標準化,以利組織內的溝通。
PG-1-4 自動化編譯建構源碼過程。
4.1概述：為減少因人為因素,造成編譯的過程有所漏漏,建議以自動化的編譯方式,確保建構源碼過程可以被重複執行,涵蓋了所有定義的安全程序。
4.2執行建議：在建構編譯源碼過程建議作法如下：應使用自動編譯及建構源碼的工具。將人為介入最小化。留存建構編譯源碼過程log。
PG-1-5 源碼建構編譯環境控制。
5.1概述：在源碼撰寫過程中,應注意編譯環境的控制,確保重複建構二進位的執行檔過程可以被反覆執行,並對任何修改有清晰的稽核軌跡。
5.2執行建議：建議對編譯環境,參考以下所列,進行相關的保護措施
為能確保重複建構二進位的執行檔過程編譯環境,建議記錄以下數據：包括源碼、編譯腳本、編譯工具和編譯環境,包括上述資料、工具、編譯環境的版本(如OS版本,patch版本等)。上述的資料,都應直接來自版本控制系統。
為能確保編譯環境,建議建立組態管理、書面紀錄、實作、監視並審查硬體、軟體、服務及網路之組態(包括安全組態),記錄所建立之硬體、軟體、服務及網路的組態,並宜維護所有組態變更的日誌。
PG-1-6 保護開發端點及環境。
6.1概述：保護和強化開發端點電腦(即,軟體設計者、開發者、測試者、構建者等的端點)。將軟體開發者相關的環境與一般OA、生產環境分離,且予以保護。
6.2 執行建議：建議對開發端點及環境,參考以下所列,進行相關的保護措施：
確認開發工具的完整性,確保所使用的工具集是安全且可信賴的,例如在編譯前確認編譯器未受惡意程式感染並以雜凑值確認其完整性。
使用多因子方式進行身分驗證,要求對軟體開發端點和開發資源的所有存取進行多重身份驗證。
在軟體開發環境,應與一般辦公環境網段區分管控,以減少攻擊面和攻擊者的橫向移動、特權存取/權限升級。
強制執行身份驗證並嚴格限制進入和退出每個軟體開發環境的連接,包括將對網際網路的存取,減少到僅在必要的情況下。
最小化對軟體工具鏈系統的直接存取,例如構建服務、持續監控和審核所有嘗試存取和所有特權存取的使用。
盡量減少非軟體開發環境中使用軟體開發軟體和服務。
定期記錄、監控和審核環境之間(如軟體開發、一般辦公、生產線等)及每個環境中的組件之間的授權和存取的信任關係。
持續記錄和監控軟體開發環境所有組件的操作和警示(訊),偵測、回應和從模擬/實際的網路事件中恢復。
配置安全控制和其他涉及分離和保護環境的工具,以便留下活動(操作)紀錄。
持續監控部署在每個環境中的所有軟體是否存在新漏洞,並按照基於風險的方法適當地回應漏洞。
依照零信任架構配置每個軟體開發端點。
根據組織核定的的資安指南、清單等配置強化每個軟體開發端點；例如,對所有靜態和傳輸中的敏感數據啟用符合 FIPS 140-2以上等級的加密模組進行加密。
配置每個軟體開發端點和開發資源,以提供服務所需的最少功能,並執行最小權限原則。
在非軟體開發網路上提供專用的開發端點,以執行所有與開發相關的任務。在軟體開發網路上為所有其他任務提供單獨的端點。安全小組應當與供應商(參見BSIMM CP2.4)合作並對供應商進行培訓以推廣組織的安全標準。
為能確保開發端點作業環境,建議建立組態管理、書面紀錄、實作、監視並審查硬體、軟體、服務及網路之組態(包括安全組態),記錄所建立之硬體、軟體、服務及網路的組態,並宜維護所有組態變更的日誌。
PG-2 審查機制
組織在推動軟體安全軟體開發參考指引時,需制定相關安全程式碼撰寫完成後的審查機制,予以記錄、追蹤、排除並避免相同的問題再次發生。
PG-2-1 制定高風險作業審查程序。
1.1概述：為提早發現漏洞並進行修復,應制定高風險作業審查程序。應透過審查程序擬定排除的方式並留下紀錄,以避免再次發生問題。
1.2 執行建議：源碼審查即Code Review,係指對電腦程式碼進行系統化的審核,其目的在於找出原始碼上是否存在著不妥之處,例如風格是否與團隊一致、是否有哪邊程式可讀性不佳、不容易維護、不容易擴充、有安全性疑慮、效能不佳,甚至根本就誤解了需求等。以資訊安全風險而言,源碼審查的目的是提早發現bug並進行修復。
PG-2-2 所有的專案强制執行源碼審查。
2.1概述：為確保所有源碼符合安全規範,應強制要求所有專案實施源碼審查,以識別、追蹤不符合項目的更新狀況。
2.2執行建議：對於安全小組權限下的所有專案,源碼審查都是強制執行的,缺少源碼審查或不合格的結果會導致發布停止、減慢或召回(recall)。查檢表即程式碼審查清單,其內容通常包括常規項(如,所有的程式碼是否簡單易懂?是否存在多餘的或是重複的程式碼?)、安全項(如,是否所有的資料輸入都進行了檢查並且進行了編碼?在哪裡使用了第三方工具? 錯誤情況是否均正確處置?)、說明項(如,是否有註釋並且描述了程式碼的意圖?所有的函式都有註釋嗎?)等。
PG-2-3 併行採用自動化工具和人工審查。
3.1概述：人工的檢查雖然精準,但是效率不及自動化工具,且無法全面檢驗,為達成互補,應採用自動化工具和人工審查併行之措施。
3.2執行建議：源碼審查可分為人工方式及透過自動化工具進行。人工源碼審查一般上會邀請同儕依據組織內部制定的關於程式碼品質及安全性規範,抽查程式碼的寫法。然而人工的檢查雖然精準,但是效率不及自動化工具,且無法全面檢驗。自動化源碼審查是一種軟體工具,用以檢查原始碼是否符合規定。規定可能是事先定義的規則,或是目前的最佳實務(best practice)。
PG-2-4 採用支援自訂規則的自動化源碼審查工具。
4.1概述：為了移除屢次發生的誤判,或是為了發現組織內特定編碼標準可能潛藏的安全缺陷(bug),應採用支援自訂規則的自動化工具。
4.2執行建議：自訂規則的目的可能是為了移除屢次發生的誤判,或是為了發現組織內特定編碼標準可能潛藏的安全缺陷(bug)而自訂之審查規則,用以彌補自動化工具的不足。
PG-2-5 採用自動化惡意程式碼檢測措施。
5.1概述：為早期發現程式碼中含有惡意行為,應有自動化檢測措施,防止機敏資料及資訊資產遭非法使用、破壞或竄改。
5.2執行建議：自動化惡意程式碼檢測,協助檢測開發過程中是否埋入惡意程式,如「後門程式」係指開發人員為了方便維護,繞過各種安全性檢查而留下後門或隱密通道。
於測試或維護時所建立的後門程式應僅能在測試環境中使用,組織必須於產品發布前進行詳細檢查並移除所有的後門程式。
PG-2-6 建立並維護一份最重要 N 項源碼缺陷與可能功擊行為列表。
6.1概述：在蒐集各種源碼撰寫缺陷與可能的攻擊行為時,應歸納出好發且容易遭利用的缺陷與攻擊行為,以建立相應的防範措施。
6.2執行建議：源碼缺陷可能導致如緩衝區溢出、提權、資料外洩等風險。目前靜態分析工具的缺陷檢測規則大多是基於CWE、OWASP Top10、CWE/SANS Top25等標準提取的,不同工具支持的語言數量多少不等。
企業可逐步彙整目前開發中發現的問題,如上述提的緩衝區溢出、提權、資料外洩等風險彙整並建立自己的面對與處理的缺陷與攻擊行為列表加以維護列管。並定期進行審查會議與更新。
PG-2-7 建立從整個源碼庫中消除特定缺陷之措施。
7.1概述：消除特定缺陷功能可能是目前的自動化工具所無法找到的,故應有培養自行撰寫規則在既有源碼庫中找出並修正相關缺陷之能力或支援方式,以有效修訂特定的缺陷。
7.2執行建議：針對一些源碼程式中,特定新的缺陷可能是目前的自動化工具所無法找到的,因此需多方評估其他管控措施或者增加自行撰寫規則方式進行修補,在既有源碼庫中找出並修正相關的缺陷變得十分重要。
PG-2-8 統一追蹤管理安全審查紀錄及報告,構建知識庫進行分享及提供當作培訓範例。
8.1概述：為能借助歷史源碼審查數據強化資安培訓課程內容,避免重蹈覆轍,應對相關人員實施培訓課程。並明訂培訓之目的、訓練計畫及實施辦法等。
8.2執行建議：借助歷史源碼審查數據,安全小組可以使用報告展示進度並促進開展培訓課程,參見SM1.3及培訓(T)。源碼審查的結果與數據可以成為典型的培訓實例,增進建立同仁安全專業知識。每年至少一次的定期審查安全相關議題。
下表為參考指引中安全程式碼撰寫的內容列表：
| 次分類 | 編號 | 內容 | 控制項對應 | ||
| IEC
62443-4-1 |
GSMA NESAS | NIST SSDF | |||
| 撰寫規範 | PG-1-1 | 實施安全程式碼撰寫標準 | SI-2 | [REQ-IMP-02] | PW.5.1、PW.7.2 |
| PG-1-2 | 制定安全編碼標準之採用確認與驗證程序 | SI-1 | [REQ-IMP-01] | PW.5.1 | |
| PG-1-3 | 標準化對弱點或問題的描述 | SI-2 | |||
| PG-1-4 | 自動化編譯建構源碼流程 | [REQ-BUI-01] | |||
| PG-1-5 | 源碼建構編譯環境控制 | [REQ-BUI-02] | |||
| PG-1-6 | 保護開發端點及環境 | PO.5.1
PO.5.2 |
|||
| 審查機制 | PG-2-1 | 制定高風險作業審查程序 | [REQ-IMP-01] [REQ-IMP-02] | PW.7.2 | |
| PG-2-2 | 所有的專案强制執行源碼審查 | SI-1 | [REQ-IMP-01] [REQ-IMP-02] | PW.7.1 | |
| PG-2-3 | 併行採用自動化工具和人工審查 | SI-1 | [REQ-IMP-01] [REQ-IMP-02] | PO.3.1、PW.5.1、PW.7.2 | |
| PG-2-4 | 採用支援自訂規則的自動化源碼審查工具 | SI-1 | [REQ-IMP-01] | PW.7.2 | |
| PG-2-5 | 採用自動化惡意程式碼檢測措施 | SI-1 | [REQ-IMP-01] | PW.7.2 | |
| PG-2-6 | 建立並維護一份最重要 N 項源碼缺陷列表 | SI-2 | PW.7.2 | ||
| PG-2-7 | 建立實施從整個源碼庫中消除特定缺陷之措施 | RV.3.3 | |||
| PG-2-8 | 統一追蹤管理安全審查紀錄及報告,構建知識庫進行分享及提供當作培訓範例 | DM-6,SM-4 | [REQ-IMP-01] [REQ-IMP-02] | PW.7.2 | |
| 資料來源：本計畫整理 | |||||