上海計算機軟件技術開發中心 嚴超 周悅 張孟
安全一直是軟件開發中一個重要且熱門的話題。隨著科技和信息化的發展,云計算、信息系統、手機APP被應用在人們生活的各個角落,隨之而來的是國家信息、商業信息和個人信息泄露事件呈現顯著式增加。在這種嚴峻的安全威脅形勢下,從軟件開發起步階段就將安全因素考慮進去顯得尤為重要。
目前,在傳統軟件開發生命周期(SDLC, Software Development Life Cycle)中,軟件安全主要在后期得到考慮,而沒有明確指出在開發早期進行安全需求分析與安全設計,因此大量時間與成本被消耗于開發后期的故障排除。另外,在軟件設計完成之后基本難以再修改軟件框架,此時再進行安全分析會發現許多安全需求無法在已確定的框架下得到滿足。在這樣的背景下,微軟公司提出了安全軟件開發生命周期(SSDLC, Secure Software Development Life Cycle)受到了廣泛的關注。SSDLC的基本思路是將安全工作左移,側重在事前事中做好安全控制,而不是在事后修補。由于安全階段的提前,大量工作和時間將花費在安全需求分析中,但卻能整體提高安全開發的效率和效果。一個全面的安全需求設計能降低程序員排除故障的成本,并有助于構建安全的代碼。目前已經存在一些理論研究和實踐來規范軟件開發流程中的安全問題。例如Microsoft SDL[1]和OWASP CLASP[2]軟件開發安全實踐指南,在開發過程的所有階段均引入了安全和隱私;BSIMM[3]和OpenSAMM[4]是安全評估機構評估企業軟件安全的成熟度模型,通過描述和量化實際運行結果來不斷構建和發展模型,從而形成指導;安全質量需求工程(Security Quality Requirements Engineering,SQUARE)[5]是需求工程的安全升級版,可用于SSDLC需求階段。
本文針對SSDLC進行研究,總結了目前在SDLC與SSDLC中的一些不足,并結合國內外相關法律、標準等,提出了安全軟件開發需求體系,將更多的安全因素增加在軟件設計、開發和編程、測試和集成、部署和發布等軟件開發周期的各個過程中,其中包含業務安全評估、個人信息安全評估、商業密碼評估、數據跨境評估、等保等,從而更加完善安全開發需求,增強企業網絡安全管理、減少故障排除時間、信息泄露風險以及降低開發成本。
SDLC是軟件從生產到報廢的一個類似于生命周期的過程,也是一種具有明確定義且用于創建高質量軟件的流程方法[6]。SDLC的具體構成如圖1所示,包括問題定義與規劃、需求分析、軟件設計、開發和編程、測試和集成、部署和發布以及運行維護。

圖1 軟件開發生命周期階段
SDLC流程能有效地管理控制開發進度和開發文檔,清晰地明確開發人員工作內容。使得所有參與人員能對所要達成的目標保持一致認識,并為同一目標制定清晰明了計劃。項目的大致花費和資源需求可以被所有參與者所了解[6]。然而,SDLC的缺點也是顯而易見的。首先,SDLC沒有提出消除開發過程中弱點的指導方針,因此開發結果容易存在安全問題,有時甚至會導致嚴重的事件[7]。第二,Mingyu Lee等專家們提出如果在SDLC的設計、實現和測試階段存在尚未消除的漏洞,那么成本將隨著時間呈指數級增長。一個脆弱點往往會伴隨著多個脆弱點的產生[7]。第三點是在修復安全問題上,成本花費巨大。Preeti Mulay和Dr. Parag Kulkarni[8]指出與在需求分析階段進行安全問題修復相比,在軟件開發處于生產階段時修復問題的成本大約要高出200倍,而在SDLC中,技術人員是在開發和編程階段完成之后的測試和集成階段才開始修復安全問題。對于小型軟件開發項目,這個系數降到4左右,但是對于非常大的項目,這個系數可以超過500[8]。
基于SDLC對安全問題的忽略以及網絡安全事件的增加,微軟提出了SSDLC[9]。SSDLC與SDLC相比提前考慮軟件開發所需要注意的安全問題,并將具體安全因素添加到SDLC的各個環節中。在軟件需求階段或者設計階段考慮安全問題,可以把修復漏洞的人力成本、時間成本融入開發成本,將緊急安全事件的救火處理變為預防和指導性工作,做到防患于未然[10]。SSDLC的軟件開發階段包括:需求分析、軟件設計、開發和編程、測試和集成、部署和發布[11],具體框架如圖2所示。

圖2 安全軟件開發生命周期階段
在需求分析階段,除了與SDLC中相似的常規開發需求之外,還需要考慮安全功能需求、安全保障需求和安全管理需求。例如:未征得用戶同意前,不收集個人信息或打開可收集個人信息的權限;傳輸和存儲個人敏感信息時,應采用加密等安全措施;應及時刪除或停用多余的、過期的賬戶,避免共享賬戶的存在等。在軟件設計階段,增加的是安全設計審查內容,根據需求分析階段中的安全需求分析,進行軟件設計。在開發和編程階段與測試和集成階段,安全代碼審計會被用來檢測開發編碼的合規性,是否使用安全措施,是否使用含有已知漏洞的函數或組件等。在部署和發布階段,滲透測試將會被實施,從而更好評估軟件的防御能力。
相較于SDLC,SSDLC存在著許多優勢。第一,如在SDLC的缺點中提及的,及早識別安全漏洞有助于降低實施安全控制和漏洞修復過程的成本。在需求分析階段解決安全問題的成本遠低于在軟件開發編程階段,成本約可以縮減到原來的二百分之一[8]。第二,SSDLC可以建立企業安全文化,這種安全文化不僅可以幫助發現并修復在軟件開發中的安全問題,而且可以幫助企業實現在其他方面的安全優化[12]。例如,在安全需求分析階段,企業安全管理、研發人員安全意識和人員賬戶權限管理也可以納入安全需求中,從而幫助企業在整體安全管理上進一步提高,而不再局限于單個軟件開發。第三,由于將考慮安全因素提前到開發需求階段,因此一些重要決策將在開發前就被記錄,這樣有助于微調開發策略,以確保在SSDLC進行時構建安全代碼。第四,SSDLC有助于降低組織內部業務風險。在安全需求階段,需求制定往往需要與業務人員溝通,通過考慮某些安全需求對該業務是否必要、業務可行性等問題,從而降低業務風險。
通常來說,一個軟件開發項目是基于安全需求分析來建立軟件開發安全流程和體系,安全需求分析是重中之重。安全需求分析主要依賴于安全專家的經驗,通過將合規要求、專家知識、制度要求、歷史安全事件、審計發現、業務風控等匯總形成安全知識圖譜,降低安全需求分析的難度和工作量。
本文提出了安全軟件開發需求分析體系及設計流程。首先是要明確項目需求,然后進行標準調研,特別是要結合軟件安全開發相關領域的國家和行業標準,最后構建完善的安全軟件開發需求分析體系。具體安全需求設計流程圖如圖3所示。

圖3 安全需求分析流程
明確需求階段:主要包括了解項目背景、明確開發產物、掌握安全需求。參與者需要了解該項目需要解決的問題與事件、受益群體、戰略意義和社會環境等內容。還需要了解開發的最終產物形式是什么,例如:瀏覽器/服務器模式(B/S)網頁、移動應用程序(APP)、服務器/客戶機結構(C/S)軟件等,從而更好的理解和考慮安全需求設計方案。理解安全需求還需要考慮系統功能和系統不應該做什么,從而達到功能需求、安全需求、和安全目標的三方平衡。明確需求常用的方法包括:問卷調查、現場詢問、推薦系統等。
資料查詢階段:是指根據已明確的軟件開發類型進行開發產品安全標準的查詢工作,從而能使開發的軟件產品更安全以及更加符合國際和國家規定。目前,在國際上通用安全標準采用《ISO/IEC 15408信息技術安全技術信息技術安全的評估標準》,而在我國安全開發軟開領域所包含的標準有《GB/T 35273-2020信息安全技術個人信息安全規范》、《GB/T 34975-2017信息安全技術移動智能終端應用軟件安全技術要求和測試評價方法》、《GBT 39786-2021信息安全技術信息系統密碼應用基本要求》等。
標準整理階段:是指將整理完成的標準進行整體調研,為后期制定標準類別進行前期準備。如果有新需求增加,需要重復循環執行明確需求、資料查詢和標準整理等步驟。
制定標準類別階段:是指根據開發軟件產品,對整理完成的標準進行分類。標準分類類別應根據軟件產品不同業務產品進行分類設計,從而使最后的安全設計框架具有可讀性以及可追溯性。不同的分類模塊能夠使開發人員更便捷地查詢安全標準以及判斷安全需求的整改優先級,優先級可描述為必須整改、建議整改、暫不整改或者不適用。
制定框架階段:是指根據開發軟件產品和調研的標準內容將標準模塊化分類,從而清晰的呈現給使用者。例如:數據安全的輸入標準和輸出標準等。然后,對每條進行整改優先級和風險等級判斷并劃分責任主體。接著詳細記錄標準內容、標準文件名稱、章節、備注和整改建議,從而有利于后期使用框架文檔者追蹤溯源以及理解標準內容和指導意見。框架的最后一部分包括檢測日期、業務檢查、技術復核、存在疑問、后續跟蹤,這樣有利于和業務人員、技術人員溝通,符合企業實際情況。
安全需求分析體系是安全需求分析的最終產物,是軟件開發安全需求的核心內容。本文提出的安全體系包括四部分內容:安全分類模塊、風險等級評估模塊、標準內容模塊以及參與人員答疑模塊。

圖4 安全需求分析體系
安全分類模塊:包含安全分類1級、安全分類2級和安全分類3級。安全分類模塊是對安全標準進行分類。安全分類1級最為廣義,安全分類2級次之,安全分類3級則最為細致。例如,安全分類1是安全接口,安全分類2級是安全運維,安全分類3級安全監測,說明該條標準屬于安全接口目錄下的安全運維模塊中的安全檢測。
風險等級評估模塊:包含整改優先級、風險、業務類型和責任主體。整改優先級是指該安全標準是否需要被整改。整改等級分為必須整改、建議整改、暫不整改到不適用,整改程度依次遞減。其中不適用代表該安全標準不適用當前企業業務或者開發技術。風險是指該安全標準的風險等級,有高、中、低3種等級。風險程度越高,開發人員需要對所對應的安全標準越重視。業務類型是指該條安全標準所對應的開發產品類型,包括所有類型、B/S網頁、移動APP、C/S軟件等。責任主體是指該安全標準的責任落實的部門。主要包括:開發部門、運維部門、法務部門、業務部門、測試部門等。
標準內容模塊:包含檢查項、標準名稱、章節、備注和整改建議。檢查項是指每一條標準的具體內容。標準名稱是指該安全標準的出處。這樣能更便捷的追溯標準的出處,從而理解標準內容。章節是指該條安全檢查項的文件所在的章節。這樣能更便捷的溯源。備注是指該安全標準的備注。整改建議是指根據該安全標準內容所提出的建議、最佳實例截圖或重要參數建議等。
參與人員答疑模塊:包含檢測日期、業務檢查、技術復核、存在疑問和后續跟蹤。檢查日期是指最新核查該安全標準的日期。業務檢查是指與業務部門核實該安全標準是否符合企業業務邏輯,或者是否存在該業務。技術復核是指該條安全標準是否符合技術部門的要求規范。存在疑問是指如果該條安全標準存在待解決的問題,則標識存在的問題,以便于后續跟蹤解決問題。后續跟蹤是指如果該安全檢查項內容未滿足要求,相關人員需要記錄并更新后續跟蹤情況。
本文結合某銀行開發網上銀行移動APP在中國應用市場應用的安全需求,實現了第三章節所建立的安全需求體系。為了滿足安全需求,通過基于合規要求、專家知識、制度要求等方面,選取《GBT 35273-2020信息安全技術個人信息安全規范》、《JRT 0068-2020網上銀行系統信息安全通用規范》、《JRT 0185-2020商業銀行應用程序接口安全管理規范》、《常見類型移動互聯網應用程序必要個人信息范圍規定》等13個標準。
本文結合SSDLC周期,將安全需求分為開發前、開發中和開發后三個階段,同時將依據的安全標準分為5大類:網上銀行、個人信息安全、密碼安全、接口安全和等保。開發前階段,網上銀行是該開發產品的主要業務并且目前中國尤為重視個人信息安全,所以其中2大分類就是網上銀行和個人信息安全。在開發中階段,需要嚴格把控密碼安全和接口安全,因此,密碼安全和接口安全作為2個安全標準分類。在開發后階段,需要嚴格進行等保、電子銀行評估等相關測評工作,因此,等保作為最后一個標準分類。

圖5 安全分類案例
安全分類2級包括隱私規則、移動支付、移動端安全、收集、傳輸、存儲、使用等,而安全分類3級包含常見攻擊防范、Web頁面安全、應用安全、數據安全、個人金融信息、風險控制等。根據整體安全標準,逐條對安全標準進行整改優先級、風險、業務類型和責任主體判定。經過多輪與對方業務、技術人員討論,再次針對整改優先級、風險和責任主體進行修改,以確保符合企業實際情況。最終形成了600多條檢測項的安全需求體系。
結果證明某銀行通過落實該安全需求體系得到了以下改善:第一,涵蓋了各個方面亟待解決的安全需要,而且完善了企業網絡安全管理需求。第二,有效的減少軟件開發安全問題,降低后續安全修復成本,包括存在的已知漏洞等。第三,由于考慮安全分類的全面性,商業信息和個人信息泄露時間明顯減少。第四,由于整改優先級和風險等級的劃分,能更好的幫助企業優先實現最重要的安全需求。
本文基于SSDLC在需求分析階段提出了一種安全需求分析體系。通過明確需求、資料查詢、標準整理、制定標準類別和制定體系框架,建立了有效的安全軟件開發需求體系,更好的挖掘和規避安全風險問題。從實際應用的效果來看,該安全軟件開發需求體系在一定程度上增強企業網絡安全管理、減少程序調試時間和信息泄露,降低開發成本。