安全軟體開發參考指引架構,依安全軟體開發的組織與階段,分成10個部分,發展安全軟體開發參考基準。分別為組織管理(Business Unit,BU)、專案管理(Project Management,PM)、安全軟體需求(Security Requirement,RQ)、安全軟體分析(System Analysis,SA)、安全軟體設計(System Design,SD)、安全程式碼撰寫(Programming,PG)、安全軟體測試(Security Testing,ST)、安全軟體部署(Deployment,DP)、安全軟體維運(Maintenance,MA)與第三方風險管理(Third-Party Management,TPM)；詳如下圖所示：
資料來源：本計畫整理
圖1安全軟體開發參考指引架構
本指引章節架構,依開發流程分為10分類/29次分類,各次分類下的控制項數量以(n)表示,如下圖所示：
資料來源：本計畫整理
圖2安全軟體開發參考指引章節
本指引架構與BSIMM之對映原則,如下圖所示：
資料來源：本計畫整理
圖3安全軟體開發參考指引架構與BSIMM之對映
本指引以BSIMM安全軟體開發最佳實務為基礎,再融入IEC62443-4-1安全標準、GSMA網路設備安全認證方案(NESAS)V2.1及NIST SP 800-218安全軟體開發框架(SSDF)V1.1、SEMI E187與SEMI E188。
依安全軟體開發的組織與開發生命週期階段-組織管理(BU)、專案管理(PM)、安全軟體需求(RQ)、安全軟體分析(SA)、安全軟體設計(SD)、安全程式碼撰寫(PG)、安全軟體測試(ST)、安全軟體部署(DP)、安全軟體維運(MA)與第三方風險管理(TPM)等10個部分,分述如下：
一、 組織管理(BU)
組織在導入安全軟體開發參考指引時,在管理面主要聚焦於「組織架構」、「政策與標準」、「法規遵循」、「訓練推廣」次分類。茲就組織管理說明如下：
BU-1 組織架構
在導入安全軟體開發參考指引時,組織架構上需做適切的調整,以利推動整個指引的導入。
BU-1-1 成立軟體安全小組
1.1概述：組織應有專責單位與角色執掌,統一處理軟體安全事宜,以利推動軟體安全計畫。
1.2 執行建議：「安全小組」即指負責實施和推動資安作業工作(如”IC設計/IC製造”)的內部任務小組。當組織發布一項涵蓋整個組織機構的作業安全項目,用於以協調一致的方式來灌輸、評估、管理並進行作業安全活動,其第一步工作就是組建安全小組,以便致力於作業安全,例如提供作業安全服務、制定政策、提供測試工具、提供內部作業安全諮詢等,工作小組成員可在組織內亦可組織外,另外可參考RACI矩陣落實使用。RACI分別代表了以下四種角色在小組中的職責:
當責者(Accountable)：必須負起專案或任務的全部責任的人,通常只有一個人可扮演此角色。他擁有決定權與否決權,以及伴隨著權力而來的責任,不但要「把對的事情做到最好」,更要對自己所決定與否決的事情,負起最後成敗責任；負責者(Responsible)：在當責者領導之下做事的執行者,團隊中可有多人扮演此角色。執行者的首要之務就是擁有100%的工作責任感,並且將自身責任往外延展,致力於追求「個人當責」；諮詢者(Consulted)：當責者在做出重大決定前,向他尋求建議或徵詢意見的對象,彼此進行雙向溝通。諮詢者可能是顧問,也可能是頂頭上司或資深主管；被告知者(Informed)：在決策做成或行動完成後,必須被知會的人,可能是人資部門人員,要幫你尋覓人才；可能是財務部門,提供你所需經費；也可能是往後要接你棒子的人。當責者與被告知者的溝通是單向的,只需事後報備,無須事前報告。
BU-1-2 建立組織內部之軟體安全推動者角色
2.1概述：軟體安全推動者為軟體安全小組成員之一,扮演組織內部軟體安全推動者角色,負責內部宣導。
2.2 執行建議：「安全推動者」通常來自於安全小組,其設立之目的主要是為了與內部團隊(包括高層)進行溝通,與外部進行交流,撰寫僅供內部閱讀的白皮書,發布論文、書籍和其他資料,以便在組織中獲得各方對作業安全性的支持。
BU-1-3 建立或擴大安全小組以外的週邊組織
3.1概述：為加速軟體開發作業過程中的安全性部署、填補軟體安全小組在安全技能和領域知識的不足,組織應成立安全週邊小組協助推廣。
3.2 執行建議：「安全週邊小組」是指分散在組織內各處的一群員工,而他們對安全活動或相關問題,具能有超過一般水準興趣或安全技術。這些員工也被稱為擁護者,安全週邊小組的成立有助於加速安全性在作業過程中的部署,人員來源可為內部指定/招募新人/培訓既有員工。建立「安全週邊小組」可以算是成熟軟體安全計畫的良好指標,因小組成員具備能夠説明並整合安全技能與領域知識。
BU-1-4 建立吸引安全技能卓越和具熱情的員工加入週邊小組之制度
4.1概述：為發掘出更多具熱情的員工加入安全軟體相關推廣活動,組織透過培訓課程等方式進行人員招募。
4.2 執行建議：「技能卓越和熱情的員工」係指在培訓課程、辦公環境、奪旗練習、駭客攻擊以及其他場合因為展示出卓越技能和熱情而脫穎而出的人,為適時發掘與培養其專業性後,作為招募「安全週邊小組」後備人員。
BU-1-5 明訂安全小組提供他人諮詢的服務時間
5.1概述：辦公時間可以是廣而告之的特定諮詢時間,或在正常的辦公時間內安排提供諮詢協助。
5.2 執行建議：係指安全小組應廣而告之的諮詢時間,或在正常安排的辦公時間內為每一名和全部來訪者提供幫助。也可以採用現場辦公方式,即根據請求巡訪特定的產品或應用小組提供交流與諮詢服務。
BU-1-6 成立軟體安全開發標準審查委員會
6.1概述：為規範標準制定的流程,並確保所有利益相關者都有機會表述意見,應由組織建構或組織風險部門承擔起設立和管理標準審查委員會的責任。
6.2執行建議：成立審查委員會來規範制定標準的流程,並確保所有利益相關者都有機會表述意見。透過指定標準草案的擁護者,由擁護者來證明該標準符合其目標並獲得審核委員會的核准和支持。通常會由組織架構或組織風險部門承擔起設立和管理標準審查委員會的責任。落實善用RACI矩陣的兩種檢查方式：
1.橫向檢查即檢查每一個任務在每個部門的分工。關注點是：檢查右側是否有沒有遺漏的人員或部門；
2.縱向檢查即是按部門來檢查：檢查每個部門分配了分工類型為R(當責)的任務,評估該部門是否有足夠的資源來負責這些任務。
BU-1-7 成立軟體安全設計審查委員會
7.1概述：對已發布的設計標準,為確保其設計決策不會落伍或過時,組織應成立軟體安全設計審查委員會來核可並維護安全的設計模式。審查委員代表應涵蓋軟體安全小組成員、程式架構師、測試人員、專案經理。審查項目應包含但不限於,設計是否已經充分解決安全的要求,識別未遵循安全實踐的設計(如違反最小特權),對於縱深防禦是否存在任何威脅(如攻擊介面、信任邊界等)。
7.2執行建議：軟體安全設計審查委員會應採取的安全要求審查方式,而審查委員代表應涵蓋軟體安全小組成員、程式架構師、測試人員、專案經理等。其安全要求審查方式審查項目應包含但不限於：設計是否已經充分解決安全的要求；識別未遵循安全實踐的設計(如：違反最小特權)；對於縱深防禦是否存在任何威脅(如：攻擊介面、信任邊界等)。應建立清冊或清單,定期審查已經發布的(特別是圍繞身份驗證、授權和密碼學的)設計標準,以確保設計決定不會陳舊無用。
BU-1-8 建立軟體安全小組參與架構設計工作的制度
8.1概述：為達成安全始於設計(Security-by-Design),組織應明訂架構設計之工作團隊組成方式,透過其資安專長將安全需求置入架構設計中,避免事後昂貴的軟體修復成本。
8.2執行建議：軟體安全小組應注意所有的架構設計都是由一開始的需求決定,而架構設計的好與壞,取決於架構師對功能性需求、非功能性需求,及約束的理解有多透徹。上述「約束」係指在所處的環境下,無法改變或改變成本過高的遊戲規則、如長官或客戶壓下來的時程、政府法規、公司可用資金、團隊技術能力、舊有系統架構包袱等。
BU-1-9 建立開發新型攻擊方法的科學團隊
9.1概述：主要目的是在業界尚未充分探索該攻擊方法前進行相關前瞻的研究,以便組織能夠在真正攻擊者知道這些攻擊方法存在之前,識別和防堵此類新的攻擊類別。
9.2執行建議：所謂「開發新型攻擊方法」係指組織能夠在真正的攻擊者知道這些攻擊方法存在之前,蒐集識別和防堵此類新的攻擊類別,針對其新型攻擊方法,建立專屬組織自己內部文化資料。
BU-2 政策與標準
組織在推動軟體安全軟體開發時,需制定相關的政策標準,作為執行時的依據。
BU-2-1制定安全軟體政策
1.1概述：為實現安全軟體的目標,應制定包含一連串經過規劃和有組織的行動或活動的安全軟體政策。
1.2執行建議：組織可透過制定各種安全政策,通過統一的方法來滿足各方治理方面的安全要求,讓各專案團隊無需費力去掌握合規的各項細節,及再重複了解客戶的安全要求。所謂政策是為實現特定的目標,在具體情境下的行動指南或準則。
BU-2-2 制定安全標準
2.1概述：為滿足開發團隊對安全指導的需求,應制定軟體安全標準,以解釋公認的遵守策略和執行方式。
2.2執行建議：安全小組可建立標準來滿足組織對於安全指導的需求,以解釋公認的遵守策略和執行特定安全性的操作方式,也可以提供安全程式碼範例,以要求被採用或強制執行。舉例來說,可能是描述如何在IoT設備上進行身份驗證,或如何辨別某項韌體更新的真偽。安全設計原則或標準應多方全面考量,如：識別和產品的介面,包括實體與邏輯介面、保護機制、數據資產(資料)定義等。加上縱深防禦設計,如以威脅建模的風險方法為設計多層次的防禦機制等。建立版本編碼的機制,所有的發布版本,無論是主要或次要版本的發布,都應依照軟體版本編碼機制規範,給予唯一識別碼後發布。
BU-2-3 制定軟體安全開發作業處理流程
3.1概述：為確保產品開發生命週期中於”需求、設計、開發、測試”等階段的安全,降低產品後續之資安風險,應在軟體開發的流程中加入安全項目。在產品開發生命週期中應具備需求定義的可追溯性、變更的控制管理、查證與確認、型態管理,審查與核准等過程紀錄。
3.2執行建議：所謂「軟體安全開發作業」係指組織內為了某種目的所進行的消耗人力、技術、原材料、方法和環境等資源的活動,而「安全處理流程」係指為確保前述活動而制定產出的開發流程,例如於產品開發生命週期中於”需求、設計、開發、測試”等階段加入資安要求項目,降低產品後續的資安風險。
明確定義且可經證實的產品開發生命週期,並假定存在成熟的產品開發生命週期(考量包含ISO 9001及 ISO 27034,但不限於此),技術至少支持型態管理、需求定義、設計、實施與測試等項目。
BU-2-4 建立軟體安全指標
4.1概述：為以明確和明顯的方式把技術成果與業務目標聯繫起來,證明所提供資源的合理性,應建立軟體安全指標,以衡量作業安全性風險。
4.2執行建議：所謂「作業安全指標」係指管理層能夠定量定義和衡量作業安全性風險的指標,相關指標可以是“安全缺陷密度”,如每個功能其源碼的資安缺陷數量。這裡的關鍵是應當以明確和明顯的方式把技術成果與業務目標聯繫起來,以證明提供資源的合理性。選擇一種執行方式來持續改善SSDLC(包含技術/子系統/系統技術)之安全缺陷分析,並設定目標定期檢視現場的過程與安全缺陷 (於專案執行過程中,將發現之問題彙整後建立KM),進而分析出專案合宜的「作業安全指標」。
BU-2-5 將自SSDLC流程中回饋內容納入到安全軟體政策中
5.1概述：SSDLC所產生的資料可協助組織及早發現缺陷或第一時間防止漏洞,藉蒐集所產生的各種數據,做為後續政策調整與實施之依據。
5.2執行建議：「安全軟體開發生命週期」(SSDLC)可參見BSIMM SM2.6、NIST SP800-60 IT Security in the SDLC、Microsoft安全性開發生命週期與政府委外服務實施作業流程等等,思考於各項階段中評量加上安全控制措施。SSDLC所產生的資料可協助組織及早發現缺陷與第一時間防止漏洞,例如及早發現簽核流程中加了太多的官僚主義等。明確定義如何蒐集安全性問題的通知,以及相關處理與結案的相關步驟。
BU-2-6 建立實施跨區整合安全軟體開發專案生命週期的管理機制
6.1概述：目的在於有效管理組織內各專案SSDLC執行狀況,如現況檢查、開發狀態、缺陷發現和管理、合規性驗證以及確保遵從政策和標準等。
6.2 執行建議：在進行跨區的專案開發,組織可借助自動化工具來驅動作業生命週期和交付流程,如：現況檢查、開發狀態、缺陷發現和管理、合規性驗證以及設法確保遵從政策和標準等。
自動化的工具如ALM「應用軟體生命週期管理」(Application Lifecycle Management) 、ADLM「應用軟體開發生命週期管理」(Application Development Lifecycle Management)、開源持續交付軟體等,都是可運用的工具,協助跨區整合安全軟體開發專案生命週期的管理。
BU-2-7 採用已獲核可的安全性功能及框架
7.1概述：採用已經獲得核可的安全性功能及框架,目的在於「重複使用」一致的產品架構,讓開發人員不花時間重新開發既有的功能,且審查團隊不必在新的專案或平台時處理以往相同的缺陷。
7.2執行建議：針對已獲核可的安全性功能及框架,將其編號識別,在爾後開發時,優先審查企業內部是否已有相同屬性或類似的產品架構,進而可有效率降低並節省開發人員花費之時間,將其時間關注於是否符合當下技術,確認使用時是否會產生新的功能缺陷或漏洞,有效提升審查團隊工作績效。
BU-2-8 實施發現軟體錯誤的激勵措施
8.1概述：激勵措施可為獎金、額外休假等。主要是要能激起仿效的作用,鼓勵發掘錯誤及時改善。
8.2執行建議：獎金通常按照浮動比例支付,該比例與多種因素相關,例如漏洞類型、可利用性(可論證的利用性高錯誤將獲得更高獎金),或特定的服務和軟體版本。
BU-2-9 確保供應商採用組織的安全標準之措施
9.1概述：為讓供應商了解組織對安全的期望,可用SLA(Service Level Agreement)規範供應商採用組織的安全標準,及對供應商進行培訓以推廣組織的安全標準等方向著手。
當供應商為組織特定目的開發的組件,就必須要求供應商產品開發的流程遵守組織的安全標準。
9.2執行建議：安全小組應當與供應商合作並對供應商進行培訓以推廣組織的安全標準。安全小組應當積極與供應商保持聯繫,討論供應商的安全實踐,並以確切的詞語(而不是法律術語)來說明組織對供應商的安全期望。供應商應該照SLA規範提供符合組織的安全標準模組。
BU-2-10 確保供應商遵守組織安全政策的措施
10.1概述：為能管控外部提供的產品組件或服務的安全,組織應有一套流程來識別與管理由供應商提供產品組件或服務的安全風險。為證明供應商的產品組件或服務通過了檢驗,應要求供應商必須提交相關的合規性證明,如源碼審查(CR)、滲透測試(PT)的結果及軟體物料清單(SBOM)。
10.2執行建議：這裡的「合規性證明」係指供應商必須提交資料來證明其產品或服務通過了檢驗。遵循不同的政策要求,這些合規性證明可以是源碼審查(Code Review,CR)或滲透測試(Penetration Test,PT)的結果。另,供應商應交付軟體物料清單(Software Bill of Materials,SBOM)以確保使用供應商的產品時,不會受到已知安全漏洞或者是誤用違反授權的Open Source套件,供應商所提供的SBOM也可作為後續相關活動使用。供應商應提供組織的安全標準模組相關安全佐證資料或查證證明。
BU-2-11 制定軟體安全性SLA契約
11.1概述：為確保供應商不會危及組織的合規性工作,應要求供應商以契約方式向組織承諾其產出將滿足組織規定的安全標準,解決安全性問題並依照組織的安全政策來提供產品或服務。
11.2執行建議：所謂「供應商」係指直接向組織提供商品及相應服務的組織及其分支機構、個體工商戶,包括製造商、經銷商和其他中介商,如EDA(Electronic Design Automation)工具供應商、矽智財(Silicon Intellectual Property,SIP)供應商、開發過程中所需的各種軟硬體設備供應商等。SLA係指服務等級協議,是服務供應商與組織之間具體達成的服務指標承諾,包括品質、可用性,責任等。最常見的形式是供應商以契約方式向組織承諾其產出將滿足組織規定的安全標準。組織應在契約中要求供應商解決安全性問題並依照組織的安全政策來提供產品或服務,以確保供應商不會危及組織的合規性工作。
BU-2-12 建立軟體安全性SLA範本制定制度
12.1概述：為確保SLA符合組織內外部要求,應建立SLA範本,規範應參與SLA擬定的人員及部門。
12.2執行建議：企業組織內部應審視針對SLA的要求,以符合內部文化與實際需求,並依照各專案屬性或類別的不同,建立其不同的SLA範本,也許是服務供應商與組織之間具體達成的服務指標承諾,包括品質、可用性,責任等。或者是供應商以契約方式向組織承諾其產出將滿足組織規定的安全標準模組等。而企業組織應特別注意在契約中要求供應商解決安全性問題並依照企業的安全政策來提供產品或服務。
BU-3 法規遵循
在推動軟體安全軟體開發參考指引時,需將法規及主管機關的要求,一併納管。
BU-3-1 建立將監管規定轉換為內部控制的方法
1.1概述：為將所有監管單位法規適用的部分,整合成一致性的作法來遵循法規需求,推動至全組織,並去除不同監管單位相互重疊的合規性要求,剔除冗餘和衝突,應建立一套作業安全指南能夠確保合規性工作盡可能高效率地完成。
1.2執行建議：安全小組可建立或協同建立一套統一的方法,用於從法規或相互重疊的合規性要求中剔除冗餘和衝突,並精準的將相關要求,從監管規定中適用的部分逐一轉換為組織專屬之安全指南,以解釋組織如何能夠遵法與合規。這套安全指南包含內部控制方法,能夠確保合規性工作盡可能高效率地完成。某些組織則直接參與到探索新技術和強制性規則的標準化機構工作中,以期影響監管環境。
BU-3-2 制定並施行合規性風險驗收和問責流程
2.1概述：為確保產品在發布前已就產品狀態進行審慎評估及核可,應制定一套正式的流程來處理所有的作業安全開發項目之驗收,包含但不限於查證與確認過程中的相關紀錄。
2.2執行建議：「合規性風險驗收和問責流程」係指組織透過制定一套正式的流程來處理所有的作業開發項目之驗收。在這個過程中,當風險驗收者在產品發布之前就產品狀態進行核可時,係表示經審慎評估,產品的合規性要求均能確實有效執行。安全小組可在風險驗收者進行核可時發揮顧問諮詢的作用,例如,核可政策可以要求業務部門負責人針對尚未得到處理的合規性問題或者針對與合規性相關但被跳過的SSDLC(參見BSIMM SM2.6)步驟進行核可,安全小組可據此揭露相關的風險。
BU-3-3 制定證明組織本身已遵守所適用的法規或標準的方法
3.1概述：為滿足監管機構的合規性要求,應透過制定作業安全控制說明書等方法來證明自己遵守了適用的法規,並對所發現的問題進行追蹤管理。
3.2執行建議：組織可通過表明其作業安全與安全小組開發之作業安全控制說明書相互一致,證明自己遵守了適用的法規。一般而言,安全小組負責追蹤控制機制、處理問題領域,並確保滿足審計機構和監管機構的合規性要求。
BU-3-4 制定提供監管單位合規性報告的處理流程
4.1概述：為確保滿足審計機構和監管機構的合規性要求,組織應制定一個合規性報告處理流程,並視需要請供應商就其控制手段來證明其如何支持企業滿足合規需求而提供額外資訊。
4.2執行建議：所謂「合規性報告」係指組織用以證明其滿足合規性要求的資料,這些資料包括書面政策、控制文件以及通過安全作業蒐集到的資料,如：源碼審查(CR)結果、安全測試(ST)結果、滲透測試(PT)結果等。
某些情況下,企業可要求供應商(參見BSIMM CP2.4)就其控制手段來證明其如何支持滿足合規需求而提供額外資訊。
BU-3-5 對使用的軟硬體設備進行持續性的監控
5.1概述：為透過持續性的監控數據資料來進行威脅建模,找出最可能影響系統的各種威脅行為,應對使用的軟硬體設備進行持續性的監控。
5.2執行建議：企業組織在透過自動化方式持續性的監控數據資料來進行威脅建模(即建構資安威脅模型)。針對目前監控發現的分散式阻斷服務（DDoS）、SQL注入式攻擊(SQL injection)、網路釣魚（Phishing）等已知攻擊,建立威脅模型。透過威脅建模讓企業組織對最可能影響系統的各種威脅行為,包含將企業組織內的軟硬體設備做為標的,經系統性識別和評估後,進行造成影響之監控記錄與分析。並可考量將第三方供應商的模組清單提供,納入建立其資訊安全威脅建模。(請參考IEC 62443-4-1 SM-9威脅建模(開發使用工具、組件)。
BU-3-6 制定個資保護機制
6.1概述：個資管理責任義務,因不同國家有不同規範,組織應識別目前所保有的個資,其蒐集目的、處理、利用、傳輸的對象及方式,並建立確保委外商能遵守組織的個資保護規範的機制。
6.2執行建議：因配合法規之要求,主動識別企業組織保有那些個資,個資蒐集目的、處理、利用、傳輸的對象及方式,並訂定相關個資保護規範之機制,如客戶涉及其他國家時或涉境外傳輸等疑慮,應特別審視其該國家之個資管理之要求,並配合進行相關管理措施。制定個資保護機制,建議可以參考 ISO 27701 個人資料隱私資訊管理系統與TPIPAS(臺灣個人資料保護與管理制度(Taiwan Personal Information Protection and Administration System))。
BU-3-7 制定個資清單管理方式
7.1概述：為降低任何個資受侵害之事件所可能帶來的衝擊,應制定個資清單管理方式。
7.2執行建議：應優先考量依照本國個資法之要求進行相關措施,如：個資清單內容包含個資的項目、蒐集的目的,處理、利用、傳輸、保存的方式(資料庫、伺服器)等,並建立個資外洩應變措施；如涉境外傳輸需另外考量配合其國家之相關要求措施。
BU-4 訓練推廣
在推動軟體安全軟體開發參考指引時,應對組織成員進行教育訓練,以利指引推動。
BU-4-1 建立對管理階層進行資安教育宣導的政策
1.1概述：為協助管理階層了解安全防護或資安意識不足可能帶來的風險並取得支持,應建立相關資安教育宣導政策,進行與核心作業相關之資安教育。
1.2執行建議：相關資安教育包括向高層人員介紹資訊安全措施及相關作業不完備所造成的後果,及其可能會給企業帶來的負面業務影響,此外也包括介紹其它組織為實現作業安全性正在開展的工作等。在了解問題及其對策之後,高層人員將意識到風險管理的必要性,從而支持資訊安全作業安全教育計畫,建立並定期審視企業內專屬資訊安全作業安全教育計畫表。
BU-4-2 應備有確保組織高層瞭解合規性和隱私義務之對策。
2.1概述：為讓高階管理層了解如果不履行這些義務時可能產生的後果,違反合規性要求以及資料外洩所造成的直接成本和商譽損失,並取得其支持,應有確保組織高層瞭解合規性和隱私義務之對策。
2.2執行建議：讓高階管理層了解合規性的要求並取得其支持的方法有許多,包括向其解釋組織的合規性和隱私義務以及如果不履行這些義務時可能產生的後果,或解釋違反合規性要求以及資料外洩所造成的直接成本和潛在後果。邀請外部專家對董事會做演講可能會更有效,因為某些高層人員更加重視外部專家的觀點,將其規劃落實納入資訊安全作業安全教育計畫表內。
BU-4-3 實施員工安全意識教育訓練
3.1概述：為建立組織的安全文化,應實施員工安全意識教育訓練,提升員工軟體開發作業資訊安全的觀念。並保留培訓紀錄。
3.2執行建議：所謂「安全文化」係指個人和組織集體的價值觀、態度、能力和行為方式的綜合產物。
人的行為養成,教育訓練是其中一個重要手段,應定期執行並留下培訓紀錄,另外也要佐證確認證明其專案人員的專業安全知識。安全意識教育訓練建議每年至少3小時,組織可依實際需求增減時數。
BU-4-4 實施新進人員安全方面的培訓
4.1概述：為確保新招聘員工對安全能有更進一步了解,新進人員培訓內容通常包含如何選取適當密碼以及如何防止外人尾隨進入組織安全管制區域,亦可涵蓋資安相關的課程,例如安全程式碼之撰寫方式、安全開發作業及內部資安資源等議題。
4.2執行建議：新進員工培訓內容通常包含如何選取適當密碼以及如何防止外人尾隨進入組織安全管制區域,但入職培訓時間可以延長以涵蓋資安相關的課程,例如安全程式碼之撰寫方式、安全開發作業及內部資安資源等議題,其目標是確保新招聘員工對安全文化有所貢獻,其中涉及安全文化之定義請參見BSIMM T1.1,並確認專案相關人員的專業安全知識的證明。
BU-4-5 提供以工作角色為基礎之進階安全教育訓練
5.1概述：所謂「進階訓練課程」係指培訓內容涵蓋與受訓人員最相關的工具、技術組合、開發方法或各類缺陷等。
5.2執行建議：培訓對於企業中的其他不同角色也是很重要的,這包括品質檢查、產品管理人員、高階管理人員以及其他職能人員,並確認專案相關人員的專業安全知識的證明,規劃落實入資訊安全作業安全教育計畫表。
進階訓練建議每年至少12小時,組織可依實際需求增減時數。
BU-4-6 應提供依個人需求的安全培訓機制(on-demand training)
6.1概述：為減輕受訓人員的負擔並降低培訓工作的成本,應提供按照員工個人需求來進行的培訓。可透過線上課程直接提供培訓,但在某些情況下,培養新技能(如源碼審查和威脅建模)可能更適合於講師引導的培訓。
6.2執行建議：所謂「個人化培訓」係指組織透過不同角色的人員提供按照員工個人需求來進行的培訓,藉此減輕受訓人員的負擔並降低培訓工作的成本。對開發人員而言,可在需要時通過線上課程直接提供培訓,採用不定期舉行方式,但在某些情況下,培養新技能(如源碼審查和威脅建模)可能更適合於講師引導的培訓。
BU-4-7 實施參加年度的作業安全宣導教育訓練課程的制度
7.1概述：其目的在於讓安全軟體開發團隊了解最新的安全動態,確保組織不會因為人員流動、方法演進或開發模式變化而失去工作重點之相關課程。
7.2執行建議：所謂「與作業安全相關人員」係指參與產品開發生命週期(參見BSIMM SM1.1)中各階段的人員。
「作業安全課程」係指於產品開發生命週期中各階段,能夠讓員工了解最新的安全動態,並確保企業不會因為人員流動、方法演進或開發模式變化而失去工作重點之相關課程。
BU-4-8 將與組織相關的資安事件案例納入培訓課程中
8.1概述：其目的在於讓培訓參與者能夠在組織過去曾遭遇過的資安事件事故中看到自己的身影,使其更了解這些培訓材料如何與自己的工作相關,也能夠了解應該在什麼時候、以何種方式把所學到的東西應用到工作中。
8.2執行建議：「過去發生的實例」係指組織過去曾遭遇過的重大資安事件,讓培訓參與者能夠在相關問題中看到自己的身影,讓其更了解這些培訓材料如何與自己的工作相關,也能夠了解應該在什麼時候、以何種方式把所學到的東西應用到工作中。而這些成功和不成功的案例都可以成為良好的內部教育訓練教材,讓同仁採用討論的方式可以更加身同感受。
BU-4-9 制定提升週邊小組能力的措施
9.1概述：這裡的活動不是指一般的電腦標準培訓課程,或是常設性會議,是就進階主題(例如最新IC設計/IC製造安全技術)透過邀請演講舉辦之活動。
9.2執行建議：這裡的活動是指進階的活動,包含最新安全軟體開發設計的技術,安全軟體開發新的執行模式等,可能透過參與外部的研習或邀請相關專家舉辦演講等方式進行。
BU-4-10 制定培養安全小組解決棘手設計問題能力的措施
10.1概述：可能的方法包括邀請技術嫻熟的人員(專家)參與新架構設計,以便可以分析現有架構的安全影響,並確定應該複製或避免的元素,以避免後續大量的麻煩。
10.2執行建議：透過邀請專業之技術人員(專家)參與新架構設計或指導,將可以有效分析現有架構之安全所造成之影響,進而重新評估進而識別作業,並可降低因複製造成後續大量的資訊安全問題。
預先設計安全性比先分析現有的安全設計,再從發現的缺陷進行重構之做法更加有效。
BU-4-11 實施產品安全事故應變教育訓練
11.1概述：為使事故發生時相關單位知道如何通報及應變,應實施事前安全事故應變教育訓練。
11.2執行建議：安全小組應當持續監控組織中的安全知識,而不要完全放棄控制力或監督權,應該包含實施安全事故應變教育訓練。因此應針對通報應變作業進行演練,演練的方式不拘,重點是讓所規劃之演練作業可以如期推演或實作,讓相關單位知道正確的通報流程與應變措施,並進而審視檢討其不足之處進行改善。
BU-4-12 實施通過安全訓練課程的獎勵機制
12.1概述：依課程對組織重要性或內部規定,當員工通過訓練課程,應實施獎勵制度,如頒發獎狀、公開表揚、提供獎金、升遷等。
12.2執行建議：獎勵方法可以是正式的：最終提供證書或者在人力資源系統中記錄在案；獎勵體系也可以不那麼正式，例如在年度評審時給予書面表揚等激勵。讓企業的培訓部門及/或人力資源部門參與進來,有利於彰顯安全方面的能力對職業發展的影響。
BU-4-13 建立提供內部員工有關安全資訊的平台
13.1概述：為讓員工可以取得有關軟體安全資訊,如培訓內容、最新最廣泛使用的安全標準及要求等,應建立一個眾所周知的平台(如內部網站)來提供相關資訊。
13.2執行建議：企業內部應提供一個眾所周知的位置(例如：內部網站)來提供相關資訊。通常由安全小組維護內部網站,員工可從中取得有關軟體安全標準和要求方面的資訊,及培訓內容等其他資源。互動式wiki優於只提供靜態文件卻幾乎不更新內容的網站,應同步公告或email等措施告知同仁相關資訊。
BU-4-14 建立討論各種資安攻擊及攻擊方法的平台
14.1概述：透過建立組織內部論壇、互動式wiki等平台方式進行,而非只是重複發布群組郵件。
14.2執行建議：討論方式可透過組織內部論壇、互動式wiki等。若只是重複發布群組郵件列表中的攻擊方法,並不能達到與積極討論相同的效果。因此可於安排於專案會議內納入此議題,讓同仁們探討目前各種資安攻擊的資訊分享。
BU-4-15 提供委外廠商及供應商安全教育訓練
15.1概述：為讓委外廠商及供應商了解組織的政策、標準及要求等,應對委外廠商提供有關安全軟體教育訓練。
15.2執行建議：組織內應提供委外廠商及供應商之人員,適度的了解組織的政策、標準及要求等,而委外廠商及供廠商應提供自身的資訊安全訓練及相關委外相關的教育紀錄。
BU-4-16 舉辦軟體安全性相關活動,邀請外部人員前來演講介紹相關議題。
16.1概述：邀請外部人員前來演講介紹安全性相關議題,可以讓員工可以從聆聽外部觀點中受益。
16.2執行建議：透過外部專業人員之觀點學習,應定期邀請外部人員來進行演講軟體開發安全性相關議題之活動。
BU-4-17 實施對外宣導安全軟體推廣計畫措施
17.1概述：目的在於培養外部資安意識,讓作業安全不僅僅是一項降低風險的活動,而是一項競爭優勢。
17.2執行建議：透過上述許多的教育訓練措施等目的在於培養外部資安意識,讓同仁深刻了解其來自外部的威脅與弱點,當發現可以第一時間進行通報及應變措施等,進而改善提升企業內部安全軟體開發之氛圍。
下表為組織管理指引的內容列表：
| 次分類 | 編號 | 內容 | 控制項對應 | ||
| IEC 62443-4-1 | GSMA NESAS | NIST SSDF | |||
| 組織架構 | BU-1-1 | 成立軟體安全小組 | SM-2 | ||
| BU-1-2 | 建立組織內部之軟體安全推動者角色 | [REQ-OPE-01] | PO.2.1、OP.2.3 | ||
| BU-1-3 | 建立或擴大安全小組以外的週邊組織 | PO.2.1 | |||
| BU-1-4 | 建立吸引安全技能卓越和具熱情的員工加入週邊小組之制度 | ||||
| BU-1-5 | 明訂安全小組提供他人諮詢的服務時間 | ||||
| BU-1-6 | 成立軟體安全開發標準審查委員會 | SM-2 | PO.1.1 | ||
| BU-1-7 | 成立軟體安全設計審查委員會 | SR-5、SD-3 | PW.1.2 | ||
| BU-1-8 | 建立軟體安全小組參與架構設計工作的制度 | ||||
| BU-1-9 | 建立開發新型攻擊方法的科學團隊 | [REQ-DES-01] | |||
| 政策與標準 | BU-2-1 | 制定安全軟體政策 | PO.1.1、PO.1.2 | ||
| BU-2-2 | 制定安全標準 | SD-1、2 | [REQ-GEN-01] [REQ-GEN-02] [REQ-REL-02] | PO.1.1、PO.3.2、PW.1.3、PW.4.2 | |
| BU-2-3 | 制定軟體安全開發作業處理流程 | SM-1 | [REQ-GEN-04] [REQ-OPE-01] | PO.1.2、PO.2.1 | |
| BU-2-4 | 建立軟體安全指標 | SM-13 | PO.4.1 | ||
| BU-2-5 | 將自 SSDLC 流程中回饋內容納入到安全軟體政策中 | DM-1 | RV.3.2、RV.3.4 | ||
| BU-2-6 | 建立實施跨區整合安全軟體開發專案生命週期的管理機制 | SM-1 | PO.3.3、PO.4.2 | ||
| BU-2-7 | 採用已獲核可的安全性功能及框架 | PW.1.3、PW.4.1、PW.4.2 | |||
| BU-2-8 | 實施發現軟體錯誤的激勵措施 | [REQ-OPE-02] [REQ-OPE-03] | RV.1.1 | ||
| BU-2-9 | 確保供應商採用組織的安全標準之措施 | SM-9、10 | PW.4.4 | ||
| BU-2-10 | 確保供應商遵守組織安全政策的措施 | SM-9、10 | [REQ-GEN-06] | PO.1.3、PW.4.4 | |
| BU-2-11 | 制定軟體安全性 SLA 契約 | SM-9、10 | [REQ-GEN-06] | PO.1.3 | |
| BU-2-12 | 建立軟體安全性SLA範本制定制度 | SM-9、10 | [REQ-GEN-06] | PO.1.3 | |
| 法規遵循 | BU-3-1 | 建立將監管規定轉換為內部控制的方法 | [REQ-GEN-04] | PO.1.1、PO.1.2 | |
| BU-3-2 | 制定並施行合規性風險驗收和問責流程 | SM-12 | [REQ-GEN-04] | PO.4.1 | |
| BU-3-3 | 制定證明組織本身已遵守所適用的法規或標準的方法 | [REQ-GEN-04] | PO.1.2 | ||
| BU-3-4 | 制定提供監管單位合規性報告的處理流程 | ||||
| BU-3-5 | 對使用的軟硬體設備進行持續性的監控並自動產生資產清冊 | SM-9 | |||
| BU-3-6 | 制定個資保護機制 | [REQ-GEN-04] | PO.1.2 | ||
| BU-3-7 | 制定個資清單管理方式 | PO.1.2 | |||
| 訓練推廣 | BU-4-1 | 建立對管理階層進行資安教育宣導的政策 | [REQ-GEN-03] | PO.1.1、OP.2.3 | |
| BU-4-2 | 應備有確保組織高層瞭解合規性和隱私義務之對策 | OP.2.3 | |||
| BU-4-3 | 應實施員工安全意識教育訓練 | SM-4 | [REQ-GEN-03] | PO.2.2 | |
| BU-4-4 | 實施新進人員安全方面的培訓 | SM-4 | [REQ-GEN-03] | PO.2.2 | |
| BU-4-5 | 提供以工作角色為基礎之進階安全教育訓練 | SM-4 | [REQ-GEN-03] | PO.2.2 | |
| BU-4-6 | 應提供依個人需求的安全培訓機制(on-demand training) | SM-2、4 | [REQ-GEN-03] | PO.2.2 | |
| BU-4-7 | 實施參加年度的作業安全宣導教育訓練課程的制度 | SM-4 | [REQ-GEN-03] | PO.2.2 | |
| BU-4-8 | 將與組織相關的資安事件案例納入培訓課程中 | PO.2.2 | |||
| BU-4-9 | 制定提升週邊小組能力的措施 | [REQ-GEN-03] | PO.2.2 | ||
| BU-4-10 | 制定培養安全小組解決棘手設計問題能力的措施 | PW.1.1 | |||
| BU-4-11 | 實施產品安全事故應變教育訓練 | SM-4 | |||
| BU-4-12 | 實施通過安全訓練課程的獎勵機制 | [REQ-GEN-03] | PO.2.2 | ||
| BU-4-13 | 建立提供內部員工有關安全資訊的平台 | ||||
| BU-4-14 | 建立討論各種資安攻擊及攻擊方法的平台 | PW.1.1 | |||
| BU-4-15 | 提供委外廠商及供應商安全教育訓練 | SM-9、10 | PO.2.2 | ||
| BU-4-16 | 舉辦有關軟體安全性相關活動 | ||||
| BU-4-17 | 實施對外宣導安全軟體推廣計畫的措施 | SM-4 | |||
| 資料來源：本計畫整理 | |||||
二、 專案管理(PM)
組織在導入安全軟體開發參考指引時,在專案管理面主要聚焦於「風險控管」、「安全情報發布」、「能力的培養」面向。茲就專案管理的說明如下：
PM-1 風險控管
在導入安全軟體開發參考指引時,在專案管理面應有適當的管理措施,以掌握專案風險。
PM-1-1 於安全軟體開發過程中建立檢核點,定義需蒐集資訊與通過標準。
PM-1-2 以集中管理的機制,用以追蹤確定每個安全軟體開發的進展情況。
PM-1-3 落實控管開源程式碼風險。
PM-1-4 落實安全軟體開發過程中檢核點查驗,並追蹤異常處理狀況
PM-1-5 落實變更管理機制(包含提出變更要求、評估、實作變更、檢視與結案)。
PM-1-6 制定並執行相關的安全性驗收標準流程並簽署安全證明文件。
PM-1-7 整合軟體供應鏈風險管理。
PM-2 安全情報發布
組織應適時發布相關的安全情報,如成熟的設計模式、組織軟體安全性的數據、組織遭受攻擊的案例,從中吸取有益的教訓,以推動不斷改進。
PM-2-1 尋找及發布成熟的設計模式。
PM-2-2 於組織內部發布有關軟體安全性的資料。
PM-2-3 蒐集並發布組織遭攻擊案例資料。
PM-3 能力的培養
應培養專案成員的在安全軟體開發能力,以利提升專案執行品質。
PM-3-1 培養安全小組能力,成為安全軟體架構分析諮詢資源或教練。
PM-3-2 指定安全檢核、掃描工具的使用輔導員。
下表為參考指引中組織管理的內容列表：
表6 專案管理
| 次分類 | 編號 | 內容 | 控制項對應 | ||
| IEC
62443-4-1 |
GSMA NESAS | NIST SSDF | |||
| 風險控管 | PM-1-1 | 於安全軟體開發過程中建立檢核點,定義需蒐集資訊與通過標準。 | SR-5、SD-3、SI-1、SM-12、SUM-1 | PO.1.2、PO.3.3、PO.4.1、PO.4.2 | |
| PM-1-2 | 以集中管理的機制,用以追蹤確定每個安全軟體開發的進展情況。 | ||||
| PM-1-3 | 落實控管開源程式碼風險。 | SM-9、 | [REQ-GEN-01] [REQ-GEN-02] [REQ-IMP-02] | PW.4.1、PW.4.4 | |
| PM-1-4 | 落實安全軟體開發過程中檢核點查驗,並追蹤異常處理狀況 | SM-11 | PO.1.2、PO.4.1、PO.4.2 | ||
| PM-1-5 | 落實變更管理機制(包含提出變更要求、評估、實作變更、檢視與結案) | SM-1 | |||
| PM-1-6 | 制定並執行相關的安全性驗收標準流程並簽署安全證明文件 | SM-12 | PO.4.1 | ||
| PM-1-7 | 整合軟體供應鏈風險管理(new) | ||||
| 安全情報發布 | PM-2-1 | 尋找及發布成熟的設計模式。 | PW.1.2 | ||
| PM-2-2 | 於組織內部發布有關軟體安全性的資料。 | PO.4.1、PO.4.2 | |||
| PM-2-3 | 蒐集並發布組織遭攻擊案例資料 | PW.1.1 | |||
| 能力培養 | PM-3-1 | 培養安全小組能力,成為安全軟體架構分析諮詢資源或教練。 | |||
| PM-3-2 | 指定安全檢核、掃描工具的使用輔導員 | [REQ-IMP-01] | PO.2.1 | ||
| 資料來源：本計畫整理 | |||||