安全性品質需求工程(Security Quality Requirements Engineering, SQUARE) 提供了資訊技術系統與應用軟體安全性需求誘詢、分類、及優先化的方法。該方法論聚焦於將安全性概念構築到發展生命週期的早期階段。模型亦能用於記錄與分析已派用系統的安全性構面，及指導該等系統未來的改善與修改。

SQUARE過程最好是由專案需求工程師及安全性專家於高階管理階層及利害相關者的支持的全景(環境)下應用。SQUARE可以解構為9個獨立的步驟(如下圖)，每個步驟均定義了所需的輸入、主要的參與者、建議的技法、以及最後的輸出。原則上，步驟1-4是安全性需求工程前真正的活動，但乃是確保安全性需求工程成功所必須者。各步驟工作說明如下。


Step 1：同意定義(Agree on Definitions)為成為安全性需求工程的前提而有需求。在給定的專案上，團隊成員傾向根據其先前的經驗，於將定義記在心中，然而那些定義通常是有差異的。例如，對於某些政府組織來說，安全性根據安全性淨空層級(security clearance levels)與進出有關，然而對於其他的政府部門，安全性可能與實體安全性或網路安全性有關。沒有必要去發明定義。IEEE與軟體工程知識體系(SWEBOK)提供了大量的定義以供選用與裁適。與有關各方的聚焦小組會議最有可能啟動安全性需求活動所使用之一組一致定義的選擇。

Step 2：識別資產與安全性目標(Identify Assets and Security Goals)，應於組織層級上完成，其為支援進行中專案之軟體發展所需要。此提供了對組織政策與營運安全性環境的一致性檢核。不同的利害相關者通常有不同的目標。例如，人力資源部門的利害相關者，其所關切的可能是人員紀錄之機密性的維護，所以，從他們的觀點來看，人事紀錄是一項資產，而財務領域的利害相關者關心的可能是財務資料未經授權不得存取或修改的確休，所以他們會認為財務資料是一項資產。擁有一組代表性的利害相關者，包含具有營運專業知識者是重要的。一旦各利害相關者的資產與目標識別之後，就需對之優先化。在缺乏共識的情況下，可能需要高層的決策以對這些資產與目標優先化。

Step 3：發展工作物(Develop Artifacts)，為支援所有後續安全性需求工程活動之所需。常見的情況是，組織在專案上並沒有書面化的營運概念、簡要陳述的專案目標、書面化的正常使用與威脅情境、誤用或濫用案例、及其他支援需求定義所需的文件。此意味著，若非整個需求過程構築於未明述之假設上，即是花了許多時間在試著回溯以獲得此類文件。

Step 4：履行風險評鑑(Perform Risk Assessment)，需要有風險評鑑方法方面的專家、利害相關者的支持、以及安全性需求工程師的支持。有許多的風險評鑑方法可供選擇。風險評鑑專家能根據組織的需要，提出特定方法建議。步驟3的工作物提供輸入給風險評鑑過程。風險評鑑成果，能於高優先安全性曝險的識別上提供協助。未履行風險評鑑的組織，通常在識別安全性需求時，對於組織風險的思考缺乏邏輯作法，且傾向於選擇諸如加密之類的特定解決方案或技術，而未對正在求解的問題真正瞭解。

Step 5：選擇誘詢技法(Select Elicitation Technique)，在有許多不同的利害相關者時變得重要。更正規的誘詢技法，諸如加速需求法(Accelerated Requirements Method)、聯合應用設計(Joint Application Design)、或結構化訪談等，在有許多不同文化背景的利害相關者時，能有效克服溝通議題。在其他情況下，誘詢單純就是和主要的利害相關者坐下來，然後試著理解利害相關者在安全性需求上的需要。

Step 6：誘詢安全性需求(Elicit Security Requirements)，為使用選定之技法的實際誘詢過程。絕大多數誘詢技法均提供如何履行誘詢的細節。此構築於稍早步驟所發展出來之工作物上，諸如誤用與濫用案例、攻擊樹、威脅與情境。

Step 7：分類化需求 (Categorize Requirements)，讓安全性需求工程師分辨需要呈現的重要需求、目標(所欲需求)、以及架構限制條件。真正屬於限制條件的需求，通常在特定系統架構於需求過程前已選定時出現。這樣很好，因為它讓與這些限制條件有關的風險的評鑑能被實施。此分類化亦能對後續的優先化活動提供協助。

Step 8：優先化需求 (Prioritize Requirements)，憑藉的不只是先前的步驟，亦可能涉及成本效益分析的履行，以判斷哪些安全性需求相對其成本有較高的報償。當然，優先化亦視安全性漏洞的其他後果而定，諸如損失生命、損失聲譽、損失消費者的信心等。

Step 9：檢視需求(Inspect Requirements)，能以各種正規性層級實施，從Fagan檢視到同儕審查。一旦檢視完成，專案團隊應該會有一組初步的優先化安全性需求。專案團隊亦應理解哪個領域是不完整的，且須俟後再度訪視。最後，專案團隊應理解哪些領域與特定的架構及實作有關，且亦應規劃以再度訪視該等領域。

----------------
引文: