113 高普考高考二級 資訊處理 資訊管理與資通安全研究 考古題詳解

核心觀念

本題考查紅隊演練的角色分工、協作方式，以及演練期間的風險控管。紅隊演練不是單純進行弱點掃描，而是在事前授權與約定範圍內，模擬真實攻擊者的手法，檢驗機構的防禦、偵測、通報與應變能力。紅隊負責模擬攻擊，藍隊負責防禦與應變，紫隊則促進攻防雙方交流，把演練發現轉化為改善措施。

解題方法

作答可依序說明「角色目標、合作流程、風險控制」三部分。角色部分要分清攻擊方與防禦方的任務；合作部分要交代演練前、中、後如何銜接；風險控制部分則須涵蓋授權、範圍、技術限制、監控與緊急停止機制。

紅隊、藍隊、紫隊的目標

• 紅隊（Red Team）：在明確授權及演練範圍內，模擬外部或內部攻擊者，嘗試利用人員、流程、技術或實體環境中的弱點，達成預先設定的演練目標。紅隊重點在測試整體防禦能力，不只是列出系統弱點，也要觀察攻擊路徑是否能被偵測、阻止或及時處置。
• 藍隊（Blue Team）：維持機構的防禦與營運，透過監控、偵測、分析、通報、隔離及復原等措施，發現並處理攻擊活動。演練可採「不預先告知藍隊」的方式，以評估日常偵測及應變能力；也可採合作式演練，著重共同驗證防禦措施。
• 紫隊（Purple Team）：促進紅隊與藍隊之間的資訊交流與共同改進。紫隊可由雙方人員組成，也可作為協調與引導角色，協助將紅隊的攻擊手法、藍隊的告警與處置結果對照，找出偵測缺口，並將結果轉化為偵測規則、設定調整、程序更新或訓練項目。

三隊如何合作

1. 演練前：明確授權與目標 機構先核准演練，界定目標、範圍、期間、可使用的手法、禁止事項、聯絡窗口及緊急停止條件。依演練目的決定是否事先通知藍隊，並約定發生真實資安事件時如何辨識及處理。

2. 演練中：依分工執行並維持協調 紅隊依約定路徑模擬攻擊，記錄使用的手法、時間與達成情形；藍隊依日常流程監控、研判及應變。紫隊依演練設計促進必要的資訊交流，或在演練階段結束後協助雙方共同檢視攻防紀錄。若發現營運中斷、資料外洩或其他重大風險，依事前約定通報並停止相關活動。

核心觀念

本題考查零時差漏洞與零時差攻擊的定義、成因及防護策略。重點在於區分「漏洞」與「利用漏洞的攻擊行為」，並說明為何組織不能只靠安裝修補程式防禦。

• 零時差漏洞（zero-day vulnerability）：軟體、作業系統或韌體中尚未為使用者或廠商所知，或尚無可用修補程式的安全弱點。攻擊者在廠商完成修補、使用者完成更新之前，便有利用漏洞的機會。
• 零時差攻擊（zero-day attack）：攻擊者利用零時差漏洞，入侵系統、竊取資料、破壞服務或執行其他未授權行為的攻擊。
• 兩者的關係：漏洞是可被利用的弱點，攻擊是利用弱點的行為。零時差攻擊常利用零時差漏洞，但兩者不是同一概念；漏洞存在不代表已發生攻擊，攻擊也不必然只利用零時差漏洞。

解題方法

依「定義 → 成因 → 漏洞與攻擊的關係 → 防護」作答，可完整回應題目四個面向。說明成因時，須涵蓋軟體複雜度、開發與測試限制、攻擊者誘因及修補時差；說明防護時，則應採多層次縱深防禦，避免把防護等同於更新修補程式。

一、零時差漏洞為何層出不窮

1. 軟體規模與複雜度持續增加：作業系統、應用程式、瀏覽器、行動裝置、雲端服務及物聯網設備相互依賴，程式碼龐大且組態多樣，難以窮盡所有輸入、執行路徑及環境條件。
2. 人為錯誤與設計缺陷難以完全避免：輸入驗證不足、權限控管不當、記憶體管理錯誤、身分驗證或加密設計不周，都可能形成新的弱點。
3. 測試與檢測能力有限：測試只能涵蓋已設計的情境，靜態與動態分析工具也無法保證找出所有邏輯錯誤或複雜攻擊鏈。
4. 攻擊技術持續演進：攻擊者會研究新功能、更新版本及系統整合方式，尋找過去未被發現的弱點；防禦方的更新也可能引入新缺陷。
5. 漏洞具有經濟與戰略價值：犯罪組織、間諜活動者或其他攻擊者可能投入資源尋找、購買或保留漏洞資訊，形成發現能力與資源的不對稱。
6. 漏洞揭露到修補之間存在時間差：廠商確認問題、研發修補、發布更新，再到使用者測試並部署，均需時間。在這段期間，即使漏洞已被發現，也可能尚無可用修補程式；未安裝更新的系統則會延長曝險時間。

因此，「零時差」不是指漏洞只能存在零天，而是強調在廠商或使用者尚無足夠時間完成修補與防護時，攻擊者已能利用漏洞。

二、零時差攻擊與零時差漏洞的關係

兩者是「弱點」與「利用行為」的關係：

• 零時差漏洞是系統中的安全缺陷。
• 零時差攻擊是攻擊者利用該缺陷實施入侵或造成損害。
• 漏洞可能尚未被攻擊者利用；一旦遭利用，才構成相應的攻擊事件。

核心觀念

本題考查軟體供應鏈安全與 SBOM（Software Bill of Materials，軟體物料清單）。作答要點是說明：軟體產品從開發、建置、簽署、發布到部署，涉及多個元件、工具、供應商與人員；任一環節遭到入侵、竄改或誤用，都可能使風險沿供應鏈擴散。

SBOM 是軟體所含元件及其供應鏈關係的正式紀錄，可視為軟體的「成分清單」。內容通常包括元件名稱與版本、供應者、相依關係，以及識別元件所需的資訊。SBOM 本身不會自動修補弱點，也不能單獨證明軟體安全；它提供的是可追溯、可查詢的基礎資料。

解題方法

採用「先說明供應鏈風險，再分技術面與社交工程面分析，最後說明 SBOM 的管理價值與限制」的架構。題目明確要求兩個風險面向，因此應分段作答，並把 SBOM 連結到元件透明度、弱點應變與供應商管理。

申論詳解

一、供應鏈安全為何重要

現代軟體通常不是單一廠商從零撰寫，而是結合開源套件、第三方程式庫、商用元件、開發工具、雲端服務與外包人力。組織即使做好自身網路防護，仍可能因上游元件或供應商遭入侵而受害。

供應鏈攻擊的特點是攻擊者先控制可信任的供應商、開發流程或軟體元件，再利用既有信任關係，將惡意程式或弱點帶入下游客戶環境。受害者可能包含大量使用同一元件或產品的機關與企業，因此影響範圍大、擴散速度快，且不易從一般邊界防護中辨識。

二、技術面資安風險

1. 第三方元件與相依套件弱點 軟體引用的開源函式庫或商用元件可能存在已知漏洞、停止維護或版本過舊等問題。若產品未掌握實際使用的元件與版本，就難以判斷弱點是否影響自身系統，也難以迅速完成修補。

2. 原始碼、建置環境或更新流程遭竄改 攻擊者可能入侵程式碼儲存庫、持續整合／持續交付（CI/CD）平台、建置伺服器或套件發布帳號，在合法的建置或更新流程中植入惡意程式。這類軟體可能仍使用有效簽章或正常發布管道，使使用者更容易信任並安裝。

3. 套件來源與完整性風險 套件倉儲、鏡像站或下載管道遭到污染，可能讓使用者取得遭竄改的套件。若未驗證來源、簽章、雜湊值與版本資訊，惡意元件便可能混入正式產品。

4. 供應商與維護能力風險 供應商的安全開發能力、弱點通報流程或修補速度不足，可能使已知風險長期留在產品中。外包開發、代管服務或維護工具若權限過大，也可能成為進入客戶環境的通道。

5. 風險沿相依關係擴散 一個元件常被多個產品重複使用；若上游元件出現漏洞或遭植入惡意程式，下游產品可能同時受到影響。組織若不清楚軟體組成與相依關係，便難以評估受影響範圍及修補優先順序。

三、社交工程面資安風險

供應鏈也包含人員與信任關係，攻擊者會利用員工、開發者、供應商或維運人員的行為弱點，例如：

1. 釣魚與帳號竊取：以偽造郵件、登入頁面或技術支援訊息取得開發者、系統管理者或供應商帳號，進而存取程式碼庫、套件倉儲與建置平台。

核心觀念

傳統資訊安全三要素 CIA 分別是機密性（Confidentiality）、完整性（Integrity）與可用性（Availability）。本題進一步從資訊使用者的角度，考查可鑑別性（Authenticity）與可歸責性（Accountability）的意義，以及兩者如何相互配合。

• 可鑑別性（Authenticity）：確認資訊、身分或訊息確實來自所宣稱的來源，且未被冒用。例如，接收者能確認電子郵件確實由寄件者本人或其授權系統送出。
• 可歸責性（Accountability）：使使用者或系統的行為能被追溯至特定身分，並保留足以查證的紀錄，讓行為者無法輕易否認曾執行該行為。稽核紀錄、身分驗證、時間戳記與數位簽章等，都有助於建立可歸責性。

兩者相關但不相同：可鑑別性回答「這個身分或資訊是否真實可信」；可歸責性回答「某項行為能否追溯並歸屬於特定行為者」。可靠的身分鑑別與可信的紀錄，是建立可歸責性的重要基礎；但只有鑑別身分，若未記錄其後續行為，仍不足以達成完整的可歸責性。

解題方法

本題是觀念說明題，依序說明定義、兩者關係，再各舉實例呈現必要性即可。作答時應把「身分或來源是否真實」與「行為能否追查及歸屬」分開，避免將可鑑別性與可歸責性混為一談。

兩者的關係與必要性