資料結構
網路
關係資料庫管理系統 (RDBMS)
作業系統
Java
Microsoft Excel
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
服裝設計
法學安全系統開發生命週期
安全系統開發生命週期 (SecSDLC) 是一系列按照特定順序在整個軟體開發過程 (SDLC) 中執行的活動。它的建立方式能夠幫助開發人員以減少從一開始就存在的安全風險的方式來建立軟體和應用程式。
安全系統開發生命週期 (SecSDLC) 類似於軟體開發生命週期 (SDLC)，但是每個步驟中執行的活動有所不同。SecSDLC 是一個過程，包括識別特定威脅以及這些威脅對系統構成的風險，以及必要地部署安全控制措施來預防、消除和管理所涉及的風險。另一方面，SDLC 過程主要關注資訊系統的設計和實現。
系統開發生命週期 (SDLC) 是一種確保新系統或應用程式具有可接受的安全控制和要求的方法。將技術和實踐整合到新系統和應用程式部署的建立中，允許從一開始就在解決方案中構建安全性，而不是在解決方案部署後進行改進。
為此，系統和應用程式部署的 SDLC 過程應該明確定義，並指定和執行包含安全檢查的檢查點，然後才能進入下一個專案階段。如果沒有明確應用 SDLC 並交付所需的可交付成果，則很難成功監督開發過程並確保正確處理與安全相關的關注點。
系統開發生命週期及其階段
系統開發生命週期和軟體開發生命週期有什麼區別？端到端的員工、流程和技術部署（包括軟體、基礎設施和變更管理）都是系統開發生命週期的一部分。軟體開發生命週期只關注軟體元件，例如開發規劃、技術架構、軟體質量測試和軟體部署。簡單來說，系統開發的生命週期更全面、更徹底。
下面概述的分階段行動通常反映在 SDLC 中。
專案啟動
要開始所有系統開發和整合任務，請建立一個正式的專案請求。專案請求應包括專案目標、系統或應用程式的使用者、保密性、完整性和可用性方面的關鍵性以及重要的完成時間段。
分析
透過進行可行性評估來確定是否應允許開發專案建議。可行性研究應包括以下內容：
對當前環境的影響評估；
人員發展和資源需求；
專案開發成本分析；
程式維護成本；
評估替代的專案實施方法，例如構建與購買以及外包。
描述推薦的解決方案策略；
建議方案的風險；以及
成本節約、錯誤減少、新增客戶和改進的客戶服務都是效益分析的一部分。
在此階段，資訊安全團隊應開始參與專案，以驗證可行性研究中是否已解決適當的安全問題。
業務和運營需求規範
制定業務和運營需求規範，以確保理解實現業務目標所需的專案要求。此方法通常由使用者和開發團隊領導。業務需求應解決以下問題：
支援系統或應用程式所需的資料，以及它與其他資料的關聯方式
系統或應用程式的使用頻率；
對於線上處理，需要響應時間。
功能之間的關係及其對其他元件的依賴性；
識別任何適用的法律或法規要求或限制；以及
系統或應用程式的預期壽命。
運營需求應解決以下問題：
安全要求；
應急條款；
分散式和集中式處理需求；
承擔的責任和資料輸入方法
資料保留要求
輸出分發需求；
預期的交易量，包括專案交易量的增加；以及
系統性能標準至關重要。
本檔案還應描述專案所代表的開發活動型別。維護、增強、新系統和緊急變更都是常見的專案型別。當開發活動被分配到這些類別中的一個時，應建立標準。
為了確保安全問題得到充分解決並在需求文件中得到體現，資訊安全團隊應在整個業務和運營需求階段參與其中。在此階段，主要實施風險評估方法，為專案團隊提供早期安全見解。
功能需求
將業務和運營需求轉化為功能需求，以體現系統或應用程式的預期使用者體驗。使用者的觀點已透過功能需求轉移到早期設計中。維護和改進工作的目標是使用前後描述來記錄正在發生的變化。
功能規範應包括以下內容：
資料流圖顯示資料在其所有處理階段中的流動方式。
資料定義包括資料定義、連結和命名標準。
螢幕定義 – 輸入欄位定義、範圍檢查等；
資料來源、資料型別和資料描述都是輸入。
報表定義 - 每個報表的描述、其包含的資料、資料值的計算方式以及使用報表的人員；
控制和安全要求包括輸入編輯要求、來自起源點到處理點的關鍵資料的審計日誌跟蹤、特權使用的審計日誌跟蹤以及重要處理區域的識別。
此係統與其他系統之間的互動點、預期的輸入和輸出、響應時間預期以及其他系統間依賴性都是系統介面要求的一部分。
重新啟動、備份和恢復 - 備份頻率、備份理由、備份保留要求、指示程式應如何重新啟動的重新啟動要求以及恢復要求；
分析應用程式在影響公司之前可能停機的時間長度，以及識別必須在異地處理中心恢復的資料集、軟體和其他元素；
通訊需求、儲存空間、處理裝置和其他硬體要求；
正常執行時間要求、所需的響應時間、關鍵時期、輸入截止日期、報表分發截止日期和其他服務級別要求；
交易量、預計增長和其他容量需求；以及
在新系統上生成資料的技術、在轉換期間協調資料的技術、切換要求以及檢查轉換資料的過程都是轉換需求。
資訊安全團隊通常在功能規範階段扮演支援性角色，幫助專案團隊捕獲系統或應用程式的早期設計和功能描述。安全相關資訊，例如技術特性（例如，訪問限制）和操作標準，應包含在功能規範中（例如，意識和培訓）。在詳細設計階段之前，資訊安全團隊應審查並提供對此文件的輸入。
詳細設計規範
建立詳細的設計規範，將功能需求轉換為邏輯和物理佈局。詳細設計規範是在 SDLC 的設計階段建立的，詳細說明了如何構建系統或應用程式以滿足功能規範的需求。
詳細設計規範應包括以下內容：
資料元素之間的關係；資料庫需求
每個檔案的描述、檔案訪問方法、記錄中欄位的列表、資料屬性和預期的記錄數量都是必需的。
系統流程圖 - 顯示程式執行的順序，以及它們與輸入、輸出和安全措施的聯絡。
程式要求 - 使用的程式及其用途、公式和計算描述以及程式之間的相互關係；
作業流，包括處理的目的、使用的作業名稱以及重新啟動/恢復方法；系統操作需求
錯誤管理要求；
備份和恢復過程；
啟動和關閉系統的過程；
指定拉取其他螢幕的螢幕、執行的輸入檢查以及錯誤訊息描述的螢幕的邏輯流程；螢幕設計 - 每個螢幕中的欄位、每個欄位的目的、每個螢幕觸發方式的描述、指定拉取其他螢幕的螢幕的邏輯流程、執行的輸入檢查以及錯誤訊息的描述；
每個報表每個欄位中包含的資料，以及如何獲得每個資料結果的說明；以及報表設計
安全設計中描述了訪問控制技術、審計日誌規定、使用者身份驗證和加密要求。
在詳細設計階段，資訊安全團隊應再次協助專案團隊努力構建系統以達到預期的解決方案。根據專案團隊的要求，安全專家應參加重要的設計評審會議，包括安全設計評審。資訊安全團隊應在詳細設計階段審查安全需求是否得到妥善處理，以及是否制定了合適的測試程式。在進入下一步之前，他們應評估全面的設計需求。
開發
在整個開發過程中，系統或應用程式的安全方面都經過設計、配置和啟用。使用程式規範來指定程式邏輯和處理需求。在程式設計開始之前，程式需求是在開發過程中建立的。這些需求概述了必須遵循的思維過程，以便建立必須採取的程式來編寫程式。
資訊安全團隊應保留對系統或應用程式關鍵元件（例如使用者身份驗證、授權和財務交易）的原始碼評估。在原始碼審查期間，應更加關注第三方程式碼，例如離岸開發公司提供的程式碼。
SecSDLC 的階段
系統調查 - 組織最高管理層的官員/主管啟動此程式。為了執行此程式，必須首先確定專案的客觀和目標。建立資訊安全策略，其中包括對已部署的安全應用程式和程式的描述，以及它們在組織系統中的實現。
系統分析 - 此階段對在系統調查階段獲得的文件進行全面的文件分析。檢查現有的安全策略、程式和軟體，以檢視系統中是否存在任何弱點或漏洞。還考慮未來可能出現的威脅。此方法僅負責風險管理。
邏輯規劃 - 邏輯設計階段關注的是建立用於實施不同資訊安全規則及其應用程式和軟體的工具和藍圖。為了避免未來的損失，還建立了備份和恢復計劃。還準備了發生災難時應採取的程式。在此階段，確定是否將公司專案外包。確定專案是否可以在組織內部完成，或者是否必須將其外包給另一家公司完成。
物理佈局 - 技術團隊獲得軟體實施和系統安全應用程式所需的工具和藍圖。在此步驟中，針對未來可能出現的任何意外問題研究了各種解決方案，並對這些解決方案進行了分析和記錄，以解決在分析階段被忽視的大多數漏洞。
實施 - 無論專案是內部完成還是外包，都會生成足夠的文件來滿足為專案設定的標準。在多個團隊的協助下執行專案的實施和整合，這些團隊嚴格驗證產品是否符合系統文件中給出的系統需求。
維護 - 安全程式實施後，必須確保其有效執行並得到適當監控。為了應對在建立時可能未被注意到的新興風險，必須使安全軟體保持最新狀態。
6K+ 次瀏覽
