翻譯聲明

本頁中文內容由 Anthropic Claude 自動翻譯，可能有不精確或不通順之處。如有疑義，請以英文原文為準（可用頁面上方的語言切換查看）；也歡迎至 GitHub 指正或送出 Pull Request。

Security and Risk Management¶

Vulnerability vs Risk¶

弱點（Vulnerability）：弱點是系統或應用程式中的一項缺陷，可能被利用來破壞該特定系統，而不涉及所牽連衝擊的任何脈絡。弱點指的是電腦或系統中讓攻擊得以成功的安全瑕疵。成功利用一個弱點可能導致資料被竄改、程式碼執行、資料遺失等。

風險（Risk）：風險是威脅、資產與弱點的交集。它是威脅利用弱點而導致資產可能發生損失、損害或毀壞的可能性。風險本質上是某個行動導致損失或非預期結果的可能性程度。風險甚至可能有所回報而不導致損失，它也可能帶來收益。進行風險評估（risk assessment）是為了判斷哪些是最重要、應現在而非稍後處理的潛在安全破口。

Threat vs Exploit¶

威脅（Threat）：威脅是我們試圖防範的對象。是對機器系統的潛在危險。它描述某件公司不希望發生的事。成功利用弱點就是一種威脅。威脅可能是試圖對資產取得未經授權存取的惡意攻擊者。自然或人為的事件、個人、實體或行動，具有或顯示出可能危害生命、資訊、營運、環境和／或財產的潛力。

漏洞利用（Exploit）：漏洞利用是某種利用資產中弱點的手段，用以在目標系統中產生非預期或意料之外的行為，進而使攻擊者能夠取得資料或資訊的存取權。

你如何衡量並量化風險？¶

概念上，風險 = 可能性 x 衝擊（Risk = Likelihood x Impact）。在量化方面（尤其是針對資產），你可以使用單一損失預期值（Single Loss Expectancy，SLE = 資產價值 x 暴露係數）與年度損失預期值（Annualized Loss Expectancy，ALE = SLE x 年度發生率），以金額來表達風險，並將其與控制措施的成本相權衡。在質化方面，你以某種尺度評定可能性與衝擊，並將它們繪製在風險矩陣（risk matrix）上（低／中／高）。像 FAIR 這樣的框架提供了更嚴謹的量化模型，而弱點的嚴重程度通常透過 CVSS 納入其中。

你如何為組織決定風險胃納（risk appetite）？¶

風險胃納是由領導層設定的商業決策，而非僅由安全團隊決定。它衍生自組織的目標、法規與法律義務、產業、吸收損失的財務能力，以及利害關係人的期望。實務上，你會與高階主管及風險擁有者合作，定義每個類別可接受多少風險、將其記錄下來（通常以與風險矩陣或 ALE 掛鉤的門檻表示），並用它來決定要緩解、接受、轉移還是規避哪些風險。

為什麼大多數公司都還沒有修復他們的弱點，主要原因是什麼？¶

通常不是不知道有這個瑕疵，而是優先順序與資源的問題——相互競爭的業務優先事項、有限的人力與預算、擔心破壞正式環境或造成停機、修補／變更管理的額外負擔，以及難以更新的老舊或第三方系統。風險往往是被接受或延後，而非被修補。

資訊安全在組織內的目標是什麼？¶

保護組織資訊與系統的機密性、完整性與可用性（CIA 三要素）——讓業務得以運作並達成其目標，同時將風險維持在可接受的水準。它是業務的推動者，而不只是一組控制措施。

假設你因為前一位負責人因能力不足被解僱，而到一家財星 500 大公司擔任首席工程師或 CSO，你的優先事項會是什麼？¶

（想像你在第一天上任，對環境一無所知。）

重要的資料在哪裡？
誰與它互動？
有記錄與稽核哪些東西？
網路架構圖。
可見性接觸點
進站與出站過濾（Ingress and egress filtering）
先前的弱點評估

關鍵在於看出他們能否在短短幾秒內迅速排出優先順序，判斷在一個未知情境中最重要、最該先了解的事情是什麼。

身為企業資訊安全專業人員，聚焦於威脅還是弱點更重要？¶

弱點通常應該是主要焦點，因為我們在企業界通常對威脅幾乎沒有控制力。

威脅（就攻擊向量而言）將永遠維持不變，而我們正在修復的弱點也只是已知的那些。

因此，除了讓自己保持在最新狀態之外，我們還應該基於威脅建模（threat modeling）來實施縱深防禦（defense-in-depth）。

當業務單位徵求許可時，什麼情況下適合回覆「不行」？¶

很少會斷然說「不行」。好的回答會重新框架這件事：先了解業務想要達成什麼、以商業語言解釋風險，並提供一個更安全的達成目標的方式。只有當該請求會在沒有可行緩解措施的情況下製造無法接受的風險時，才有正當理由給出堅決的「不行」——例如明顯違反法律／法規，或暴險程度顯然超過商業價值——即便如此，也應附上理由與替代方案。

OWASP top 10 中，就財務風險而言，我們組織最該關注的前 2 項是什麼？你會建議我們實施什麼來降低風險？¶

這是為了引發討論，但強而有力的答案會指向注入（injection，例如 SQL injection）與失效的存取控制／失效的身分驗證（broken access control / broken authentication）——這些瑕疵會直接導致資料外洩以及帳號或資料遭入侵，因而帶來最大的直接財務與法規暴險。緩解措施：針對注入採用參數化查詢（parameterized query）與輸入驗證；針對存取控制採用強制的伺服器端授權、最小權限，以及強健的工作階段／身分驗證控制（包括 MFA）。

你上任後的 30-60-90 天計畫是什麼？¶

這是一套框架，而非固定答案。前 30 天（學習）： 了解業務、其資產與核心資產（crown jewels）、既有的控制措施、團隊以及當前的風險；傾聽並建立關係。60 天（規劃）： 找出缺口、速效成果（quick wins）與優先事項，並草擬一份與業務風險相符的路線圖。90 天（執行）： 開始交付這些排定優先順序的改進、建立衡量指標，並展現可衡量的進展。

什麼是開放原始碼軟體（Open Source Software）？¶

開放原始碼軟體是原始碼任何人都可以檢視、修改與增強的軟體。能存取電腦程式原始碼的程式設計師，可以透過為程式新增功能或修復那些不總是正常運作的部分來改進該程式。

哪個更安全？開放原始碼專案還是專有專案？¶

這些專案的安全性主要取決於專案的規模、在該專案下工作的開發者總數，以及一個最為關鍵且重要的因素，也就是品質的控制。專案的類型本身並不會決定其品質，各專案內部的實質內容才是重點。

你從哪裡取得你的安全新聞？¶

相較於一般測試做法，漏洞獎勵計畫（bug bounty program）提供了哪些優勢？¶

你應該會聽到諸如眾多測試者對比單一測試者、給予誘因、聚焦於罕見漏洞等的內容。

你會如何衡量一個安全團隊做得好不好？¶

在這裡，我們期望他們反過來向我們提問，例如「哪種團隊？」不好的答案包括任何純粹以數字為本的東西，像是 IDS 事件的數量，或偵測到的各種小玩意兒。

對組織而言，誰更危險，內部人員還是外部人員？¶

強而有力的答案是：以單一事件而言，內部人員往往更危險：他們已經擁有合法存取權、知道有價值的資料存放在哪裡，並且能繞過周邊控制，這使他們更難被偵測——無論是惡意還是純粹疏忽。不過，外部人員的數量遠遠更多且持續不斷。重點在於以分層的控制、最小權限、監控來防範兩者，並且不假設信任就等於安全。

Vulnerability Assessment vs Penetration Testing¶

弱點評估（Vulnerability Assessment）是一種用來找出應用程式／網路中瑕疵的方法，而滲透測試（Penetration testing）則是像真實攻擊者一樣去找出可被利用的弱點的做法。VA 有如在表面上遊走，而 PT 則是深入挖掘以尋找黃金。

Chain of Custody（證據保管鏈）¶

處理將在法庭上提出的實體證物的規範，確保證據符合刑事訴訟程序的規定。

在為法律程序而追蹤資料或設備時，它必須維持在原封不動的狀態。

因此，在處理這種情況時，確切記錄誰在多長時間內存取了什麼是至關重要的。

資料的任何一絲毫損則都可能為相關各方帶來法律問題，並可能視情境導致審判無效（mistrial）或藐視法庭（contempt）。

緩解措施（Mitigations）¶

修補（Patching）
資料執行防止（Data Execution Prevention，DEP）
位址空間配置隨機化（Address space layout randomization，ASLR）
使緩衝區溢位更難在記憶體中已知位址執行特權指令
最小權限原則（Principle of least privilege）
例如在處理程序權杖中停用 Administrator SID 來執行 Internet Explorer。降低緩衝區溢位漏洞利用以提權使用者身分執行的能力。
程式碼簽署（Code signing）
要求核心模式（kernel mode）程式碼須經數位簽署
編譯器安全功能
使用能攔截緩衝區溢位的編譯器
加密
針對軟體和／或韌體元件
強制存取控制（Mandatory Access Controls）
（MAC）
具備強制存取控制的作業系統 - 例如 SELinux。
「例外情況下才不安全」（"Insecure by exception"）
何時該允許人們為了工作而做某些事，以及如何改善其他一切。不要試圖「修好」安全，只要把它改善 99% 就好。
不要責怪使用者
安全是為了保護人，我們應該打造人們能夠信任的技術，而不是不斷責怪使用者。