-VPN 和 EAP
在 802.1X 中，請求者與身份驗證者通信，身份驗證者將身份驗證消息轉發到身份驗證服務器。請求者不直接向身份驗證服務器進行身份驗證。
一般而言，網絡訪問服務器（NAS）是指提供遠程訪問服務的服務器，例如撥號、VPN 等。VPN 服務器可以看作是一種類型的 NAS。
-EAP 協議比較
-可擴展身份驗證協議 (EAP)
資料來源： Wentz Wu QOTD-20210625
PS:此文章經過作者同意刊登 並且授權可以翻譯成中文
月份: 2021 年 7 月
-SAMM 概述（來源：https : //owaspsamm.org）
軟體保障成熟度模型（SAMM）是一個 OWASP 專案，一個規範模型和一個開放框架，使用簡單、定義完整且可衡量。SAMM 2.0 包含五個業務功能（治理、設計、實施、驗證和操作），它們主要遵循邏輯順序或映射到通用軟體開發生命週期。每個業務功能都有通過兩個流連接的三個安全實踐，將它們組織成一個層次結構以進行性能測量。換句話說，每個安全實踐的活動屬於流 A 或流 B。安全實踐的成熟度級別，作為軟體保證目標，可以分為三個級別。
[Stream B] 確定教育和指導的安全擁護者，成熟度級別 1
“確定安全冠軍”是安全實踐、教育和指導的 Stream B 活動，處於成熟度級別 1。它帶來了安全在開發組織中的基本嵌入的好處。以下摘自OWASP SAMM v2.0 – 核心模型文檔：
. 實施一個計劃，其中每個軟體開發團隊都有一名成員被視為“安全冠軍”，他是資訊安全和開發人員之間的聯絡人。
. 根據團隊的規模和結構，“安全冠軍”可能是軟體開發人員、測試人員或產品經理。
. “安全冠軍”每周有固定的小時數用於資訊安全相關活動。他們定期參加簡報會，以提高對不同安全學科的認識和專業知識。
. “安全冠軍”接受了額外的培訓，以幫助培養這些軟體安全主題專家的角色。出於文化原因，您可能需要自定義創建和支持“安全冠軍”的方式。
. 該職位的目標是提高應用程序安全和合規性的有效性和效率，並加強各個團隊與資訊安全之間的關係。為實現這些目標，“安全冠軍”協助研究、驗證和確定與安全和合規性相關的軟體缺陷的優先級。他們參與所有風險評估、威脅評估和架構審查，通過使應用程序架構更具彈性並減少攻擊威脅面來幫助確定修復安全缺陷的機會。
. 除了協助資訊安全之外，“安全冠軍”還為專案團隊定期審查所有與安全相關的問題，以便每個人都了解問題以及任何當前和未來的補救工作。通過讓整個開發團隊參與進來，這些評論被用來幫助集思廣益解決更複雜的問題。
評估問題
您是否為每個開發團隊確定了一名安全冠軍？
– 否
– 是，對於某些團隊
– 是，對於至少一半的團隊
– 是，對於大多數或所有團隊
質量標準
– 安全冠軍接受適當的培訓
– 應用程序安全和開發團隊會定期收到安全冠軍的簡報安全計劃和修復的總體狀態
——安全冠軍在添加到應用程序積壓之前審查外部測試的結果
[Stream A] 定制安全培訓、教育和指導@成熟度級別 2
安全冠軍就 SDLC 各個階段的安全主題進行培訓。他們接受與開發人員和測試人員相同的培訓，但也了解威脅建模和安全設計，以及可以集成到構建環境中的安全工具和技術。
[Stream B] 建立安全社區，教育和指導@成熟度級別 3
圍繞角色和職責形成社區，並使來自不同團隊和業務部門的開發人員和工程師能夠自由交流並從彼此的專業知識中受益。鼓勵參與，建立一個計劃來提升那些幫助最多的人成為思想領袖，並讓管理層認可他們。除了提高應用程序安全性之外，該平台還可以根據他們的專業知識和幫助他人的意願幫助確定安全軟體卓越中心的未來成員或“安全冠軍”。
[Stream B] 標準化和擴展威脅建模，威脅評估@成熟度級別 2
培訓您的架構師、安全擁護者和其他利益相關者如何進行實際威脅建模。威脅建模需要理解、清晰的劇本和模板、特定於組織的示例和經驗，這些都很難實現自動化。
[Stream B] 建立滲透測試流程，Security Testing @ Maturity Level 2
滲透測試案例包括用於檢查業務邏輯健全性的特定於應用程序的測試，以及用於檢查設計和實現的常見漏洞測試。一旦指定，精通安全的質量保證或開發人員就可以執行安全測試用例。中央軟體安全組監控專案團隊安全測試用例的首次執行，以協助和指導團隊安全冠軍。
[Stream B] 建立持續的、可擴展的安全驗證，安全測試@成熟度級別 3
安全冠軍和中央安全軟體小組在開發過程中不斷審查自動和手動安全測試的結果，將這些結果作為開發團隊安全意識培訓的一部分。整合整體劇本中的經驗教訓，以改進作為組織發展一部分的安全測試。如果有未解決的發現仍然是發布的可接受風險，利益相關者和開發經理應共同製定解決這些問題的具體時間表。
參考
. OWASP SAMM 2.0
資料來源： Wentz Wu QOTD-202107014
PS:此文章經過作者同意刊登 並且授權可以翻譯成中文
Authentication Procedure
- Identification: a subject confesses its identity.
- Validation: the authentication server (AS) validates the identity against a directory.
- Assertion: the AS asserts the identity through identity/access tokens.
認證程序
身份證明：對象承認其身份。
驗證：身份驗證服務器 (AS) 根據目錄驗證身份。
斷言：AS 通過身份/訪問令牌斷言身份。
OAuth 2.0 指定了存取資源的存取令牌，但它沒有提供提供身份信息（ID Token）的標準方法，這就是 OpenID Connect（ODIC）出現的原因。
. （身份、認證）+ OAuth 2.0 = OpenID Connect
. OIDC 是第三代OpenID 技術，它與 OAuth 2.0 對齊並從 XML 切換到 JSON。
. OIDC 通過ID 令牌處理身份和身份驗證，而 OAuth 2.0 通過存取/承載令牌處理授權。
. 由於 OIDC 建立在 OAuth 2.0 之上，因此OpenID 提供程序與OAuth 2.0 授權服務器基本相同。
身份令牌(ID Token)
-理解 ID Token 由 Takahiko Kawasaki
不記名令牌（Bearer Token）
擁有不記名令牌（“持有者”）的任何一方都可以使用它來存取相關資源（無需證明擁有加密密鑰）。為了防止濫用，需要保護不記名代幣在存儲和運輸過程中不被洩露。
來源：RFC 6750
Microsoft.AspNetCore.Authentication.JwtBearer是一個軟體組件，用於處理 .NET 5.0 中的承載令牌。
OpenID Connect (OIDC) 和 OAuth 2.0
OpenID Connect 是一種基於 OAuth 2.0 系列規範的可互操作的身份驗證協議。它使用簡單的 REST/JSON 消息流，其設計目標是“讓簡單的事情變得簡單，讓複雜的事情成為可能”。與之前的任何身份協議相比，開發人員集成起來非常容易。
OpenID Connect 使開發人員無需擁有和管理密碼文件即可跨網站和應用程序驗證其用戶。對於應用程序構建器，它為以下問題提供了一個安全的可驗證答案：“當前使用與我連接的瀏覽器或本機應用程序的人的身份是什麼？”
OpenID Connect 允許所有類型的客戶端（包括基於瀏覽器的 JavaScript 和本機移動應用程序）啟動登錄流程並接收有關登錄用戶身份的可驗證斷言。
（身份、認證）+ OAuth 2.0 = OpenID Connect
來源：OpenID Connect 常見問題和問答
OpenID 的早期版本（Earlier Versions of OpenID）
OpenID Connect 是第三代 OpenID 技術。第一個是最初的 OpenID，這是一個有遠見的工具，從未獲得太多商業採用，但讓行業領導者思考什麼是可能的。OpenID 2.0考慮得更周全，提供了出色的安全性，並且在正確實施時運行良好。然而，它受到一些設計限制——其中最重要的是依賴方可以是網頁而不是本機應用程序；它還依賴於XML，導致一些採用問題。
OpenID Connect 的目標是對開發人員更加友好，同時擴展可以使用的用例集。它已經在這方面取得了成功；有大規模運行的生產部署。任何有足夠經驗通過 HTTP 發送和接收 JSON 消息的程序員（現在大多數是這樣）應該能夠使用標準的加密簽名驗證庫從頭開始實現 OpenID Connect。幸運的是，大多數甚至不必走那麼遠，因為有很好的商業和開源庫來處理身份驗證機制。
來源：OpenID Connect 常見問題和問答
OAuth 2.0 抽象協議流程（OAuth 2.0 Abstract Protocol Flow）
OAuth 2.0 Abstract Protocol Flow
OIDC 協議流程（OIDC Protocol Flow）
OpenID Connect協議，在抽象的，遵循下列步驟。
- RP（客戶端）向 OpenID 提供者（OP）發送請求。
- OP 對最終用戶進行身份驗證並獲得授權。
- OP 使用 ID 令牌和通常的存取令牌進行響應。
- RP 可以向 UserInfo Endpoint 發送帶有存取令牌的請求。
- UserInfo 端點返回有關最終用戶的聲明。
這些步驟如下圖所示：
OIDC Protocol Flow
參考
. RFC 6749：OAuth 2.0 授權框架
. RFC 6750：OAuth 2.0 授權框架：不記名令牌的使用
. OAuth 2.0
. 歡迎使用 OpenID Connect
. OpenID Connect 常見問題和問答
. OAuth 2.0 / OpenID Connect 說明
. 了解 ID 令牌
. 將標識提供程序存取令牌傳遞到 Azure Active Directory B2C 中的應用程序
. AccessToken Vs ID Token Vs Refresh Token – 什麼？為什麼？什麼時候？
資料來源： Wentz Wu QOTD-20210622
-RESTful HTTP 方法
HTTP 方法/動詞 GET 通常用於檢索數據，這會影響機密性。
HTTP 方法
-Semantics of HTTP methods (Source: RFC 7231)
RESTful 風格架構
2000 年，Roy Fielding 在他的博士論文中引入並定義了表徵狀態轉移這一術語。Fielding 的論文解釋了 REST 原則，這些原則從 1994 年開始被稱為“HTTP 對像模型”，並用於設計 HTTP 1.1 和統一資源標識符 (URI) 標準。該術語旨在讓人聯想到精心設計的 Web 應用程序的行為方式：它是一個 Web 資源網絡（虛擬狀態機），用戶通過選擇資源標識符（例如http://www）在應用程序中前進.example.com/articles/21和資源操作，例如 GET 或 POST（應用程序狀態轉換），導致下一個資源的表示（下一個應用程序狀態）被傳輸給最終用戶供他們使用。
資料來源：維基百科
參考
. FRC 7231：超文本傳輸協議 (HTTP/1.1)：語義和內容
. 為 RESTful 服務使用 HTTP 方法
. HTTP 請求方法
資料來源： Wentz Wu QOTD-20210621
PS:此文章經過作者同意刊登 並且授權可以翻譯成中文
. RC4 在 WEP 中用於強制保密。然而，“在 2001 年 8 月，Scott Fluhrer、Itsik Mantin 和 Adi Shamir 發表了 WEP[14] 的密碼分析，它利用了 WEP 中使用 RC4 密碼和 IV 的方式，導致被動攻擊可以恢復 RC4 密鑰後竊聽網絡。” （維基百科）
. WPA3 使用 HMAC 來確保真實性；不可否認性由數字簽名強制執行。
. WPA 使用 TKIP，使用 RC4 作為底層密碼，以確保機密性。
. WPA2 在 CCM 模式下使用 AES，一種分組密碼（CBC-MAC 計數器）。
參考
. Wi-Fi 保護訪問
. 有線等效保密
. CCMP（密碼學）
. 分組密碼操作模式
. Wi-Fi Alliance® Wi-Fi® 安全路線圖和 WPA3™ 更新
. WPA3 和增強型開放：下一代 WI-FI 安全
. WPA3 解釋
資料來源： Wentz Wu QOTD-202104021
PS:此文章經過作者同意刊登 並且授權可以翻譯成中文
-SAMM 概述（來源：https : //owaspsamm.org）
文化有不同的背景或層次，例如安全文化、組織文化或民族文化。高級管理層是在組織層面提升安全意識和文化的好人選；然而，安全冠軍在軟體開發中是更合適的角色。
安全冠軍和 OWASP SAMM(Security Champion and OWASP SAMM)
安全冠軍是軟體安全主題專家，他們在 OWASP 軟體保障成熟度模型 (SAMM) 中組織和文化的成熟度級別 1 中發揮著關鍵作用。提名一名成員，例如軟體開發人員、測試人員或產品經理，作為安全擁護者，有助於將安全嵌入到開發組織中。
. 安全冠軍接受適當的培訓。
. 應用程序安全和開發團隊會定期收到安全冠軍關於安全計劃和修復整體狀態的簡報。
. 安全冠軍在添加到應用程序積壓之前審查外部測試的結果。
高級管理人員(Senior Management)
高級管理人員是攻擊的高優先級目標。為高級管理層制定安全意識計劃至關重要。他們必須以身作則，理解和遵守安全政策，絕不應該被發現說壞話或自相矛盾的政策。
安全文化(Security Culture)
. 文化本質上是“一組用語言表達的共同理解”或“意義的共享模式”或“與組織結構和控制系統相互作用以產生行為規範的共享價值觀和信念”。如果可以證明文化會影響安全結果，那麼文化在安全環境中就會引起人們的興趣。( IEEE )
. 資訊安全文化指導組織在資訊安全方面的工作，以保護資訊資產和影響員工的安全行為。( IEEE )
參考
. SAMM 敏捷指南
. OWASP聚寶盆
. IT 安全培訓和意識計劃的遊戲化
. 從上到下發展安全文化的 6 種方法
. 國際民航組織 AVSEC2018
. 安全文化
. 嵌入資訊安全文化 新出現的問題和挑戰
. 如何建立安全文化
資料來源： Wentz Wu QOTD-202104019
PS:此文章經過作者同意刊登 並且授權可以翻譯成中文
“原始密碼(Raw password)”和“散列密碼(hashed password)”是可行的解決方案。但是，HTTPS 下的原始密碼更常用，例如 Google 和 Facebook。以下原因解釋了為什麼原始密碼更可行，因為信息安全應該與業務需求保持一致：
. 在瀏覽器中，散列密碼是通過自定義 JavaScript 模塊計算的；如果客戶關閉 JavaScript 功能或防病毒軟件干擾操作，則無法正常工作。這將對市場份額、客戶滿意度和客戶服務成本產生負面影響。
. 如果攻擊者可以破壞 HTTPS 連接，發送原始密碼或散列密碼沒有任何區別，因為他可以竊取訪問令牌並劫持會話。剩餘風險幾乎相同。
. 此外，發送散列密碼意味著用戶的密碼必須被散列或加鹽，並且變得不可逆轉。但是，有些網站可能需要支持“找回密碼”功能，對密碼進行加密，客戶可以查詢自己忘記的密碼。
鹽密碼(Salted Password)
加鹽密碼是指根據原始密碼和鹽的串聯計算得出的哈希值，鹽是“作為輔助輸入合併到單向或加密函數中的隨機變量，用於派生密碼驗證數據”。(ISO/IEC 11770-4:2017) 加鹽通常在服務器端生成並且對客戶端保密，因此客戶端不可能提交加鹽密碼。
電子簽名(Digital Signature)
數字簽名在技術上是可行的，但對於電子商務網站要求客戶安裝數字證書進行身份驗證來說實際上是不可行的。
參考
. 為什麼客戶端對密碼的散列如此不常見？
. 為什麼幾乎沒有網頁在提交之前在客戶端散列密碼（並在服務器上再次散列它們），以“防止”密碼重用？
. 你（可能）做錯了登錄系統
資料來源： Wentz Wu QOTD-202104018
PS:此文章經過作者同意刊登 並且授權可以翻譯成中文
-治理結構(Governance Structure)
稽核委員會(Audit Committee)
稽核委員會是組織董事會的一個委員會，負責監督財務報告流程、選擇獨立稽核師以及接收內部和外部稽核結果。
美國上市公司在證券交易所上市需要一個合格的（參見下面的“組成”段）稽核委員會……隨著薩班斯 – 奧克斯利法案的通過，稽核委員會的作用繼續發展. 許多稽核委員會還監督監管合規和風險管理活動。
資料來源：維基百科
執行委員會(Executive Committee)
執行委員會的組織和授權代表整個董事會，因為董事會成員，尤其是大型董事會，親自聚集以做出決策並採取一些必要的行動並不總是可行的。
執行委員會是一個常設委員會，常作為指導運作委員會和組成的高層管理人員和董事會人員，例如:首席執行官，以及管理人員和董事的一個子集，以代表的基板時的整個董事會不能開會。
資料來源：有效的 CISSP：安全和風險管理
參考
. 治理委員會
. 治理委員會 (ACFID)
. 公司治理委員會和章程
. 治理委員會：非營利董事會的新趨勢
資料來源： Wentz Wu QOTD-202104017
PS:此文章經過作者同意刊登 並且授權可以翻譯成中文
由於管理是實現一個或多個目標的系統方法，我根據維基百科和NIST CSRC 術語表中的定義定義漏洞管理，並將它們擴展如下：
漏洞管理是識別、分類、優先排序、修復和驗證資訊系統、系統安全程序、內部控製或實施中的漏洞以降低風險的周期性實踐。
維基百科
漏洞管理是“識別、分類、確定優先級、修復和緩解”軟件漏洞的循環實踐。（維基百科）
NIST CSRC術語表
狹義上，漏洞可能是指那些被列入常見漏洞和暴露 (CVE) 的漏洞。
例如，漏洞管理是“一種識別設備上的漏洞 [常見漏洞和暴露 (CVE)] 的 ISCM 功能，這些漏洞可能被攻擊者用來破壞設備，並將其用作將破壞擴展到網絡的平台。” （NIST CSRC術語表）
從更廣泛的意義上講，漏洞是“資訊系統、系統安全程序、內部控製或實施中可能被威脅源利用或觸發的弱點”。（NIST CSRC術語表）
內部安全控制是資訊系統內的硬體、分位或軟體功能，將資源訪問權限限制為僅授權主體。[NIST CSRC術語表)]
資料來源：Wentz Wu網站
PS:此文章經過作者同意刊登 並且授權可以翻譯成中文