Choson資安大小事CISSP(Certified Information Systems Security Professional)相關知識
認證程序
身份證明：對象承認其身份。
驗證：身份驗證服務器 (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協議，在抽象的，遵循下列步驟。
這些步驟如下圖所示：
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:此文章經過作者同意刊登 並且授權可以翻譯成中文
-戰略層次
通常，CEO 負責制定公司戰略或大戰略，董事會的意見和高級管理團隊的支持。
CISO 不是製定企業戰略的主要角色，而是與企業戰略保持一致以創造價值並實現組織願景和使命的信息安全戰略。此外，他還必須定位安全職能（部門），確定其組織、角色和職責，將安全融入組織流程，支持產品和服務的持續交付（所謂的“業務連續性”），並保護信息資產以加強安全。信息安全管理系統 (ISMS) 可確保有效地制定和實施安全策略。
CISO 的匯報路線因組織而異，各有利弊，但 CISO 向 CFO 或其他高級官員匯報並非不可能。
. CISO 向 CIO 報告的安排可能會導致利益衝突。
. CISO 向 CFO 報告的安排可能會花費更多時間來交流技術內容。
. CISO 向審計職能報告的安排將對其獨立性產生不利影響。
參考
. 什麼是安全功能
. 信息安全職能和職責
. 管理安全功能：診斷版本 1 摘要
. 企業安全
. 組織中安全管理的角色
. 如何組織您的安全團隊：網絡安全角色和職責的演變
. 萬豪-數據洩露
. ICO 因未能保證客戶個人數據安全而對萬豪國際進行罰款
. 什麼是企業戰略？
. 誰負責制定公司的戰略計劃？
. 如何制定企業戰略（CEO 分享最佳技巧和工具）
. 多元化公司的戰略規劃
. 如何評估企業戰略
資料來源： Wentz Wu QOTD-202104015
PS:此文章經過作者同意刊登 並且授權可以翻譯成中文
微服務(Microservices)
微服務是一個低耦合的架構，可以通過以下方式實現重構一個單片應用，即，轉向進程內的應用程序組件成自包含的網絡服務適於被部署在可伸縮或彈性容器或無服務器環境。
託管環境(Hosting Environment)
微服務可以通過兩種方式部署：容器化和無服務器。
容器化（Docker 主機或節點）(Containerization (Docker hosts or nodes))
容器化用於捆綁應用程序或應用程序的功能、所有依賴項及其在容器映像中的配置。此映像部署在主機操作系統上，捆綁的應用程序作為一個單元工作。
容器鏡像的概念允許我們在幾乎不做任何修改的情況下跨環境部署這些鏡像。通過這種方式，可以輕鬆快速地擴展微服務，因為新容器可以輕鬆部署用於短期目的。
Docker將用於向我們的微服務添加容器化。Docker 是一個開源項目，用於創建可以在雲端或本地的 docker 主機上運行的容器。
-來源：使用 ASP.NET Core 3.1 的微服務
無服務器(Serverless)（FaaS）
微服務具有“可擴展”的特點，但由於接口的細粒度，會導致微服務管理的高度複雜性。一個API網關或立面緩解這個問題。
無服務器減少了安裝和維護服務器作為託管環境的負擔。AWS Lambda是一種功能即服務 (FaaS) 產品，是無服務器計算中最著名的雲服務之一。
-資料來源：AWS 的無服務器微服務模式
參考
. Kubernetes 與 Docker：入門
. Node.js 中的無服務器：初學者指南
. Node.js 中的無服務器架構：開源應用的案例研究
. 無服務器和微服務：天作之合？
. 使用容器部署微服務
. 什麼是無服務器微服務？| 無服務器微服務解釋
. 適用於 AWS 的無服務器微服務模式
. 使用 ASP.NET Core 3.1 的微服務
資料來源： Wentz Wu網站
PS:此文章經過作者同意刊登 並且授權可以翻譯成中文