Information Security Fundamentals and Practices 資訊安全概論與實務

第四篇第14章 資訊安全管理系統

資訊風險的定義 • 美國國家標準暨技術局 (NIST) 的 SP800-30 文件 “Risk Management Guide for Information Technology ” (資訊技術的風險管理指導) 是資訊領域的風險管理重要準則之一。他對風險的定義如下： Risk is a function of the likelinessof a given threat-source’sexercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization. • 我們將這個定義用中文做更精簡的表達為：風險= 威脅利用弱點對資產造成衝擊的可能性 • 依照這個定義，分析資訊風險應該先分析組織的資產、資訊弱點、威脅、以及可能性與衝擊這五項元素。其中弱點、威脅、與可能性這三項構成「意外發生的機率」；而資產與衝擊這兩項則構成「意外所造成的損失」，前後相乘就是風險值。

資訊資產的估價方法

識別資訊弱點 • NIST 的 SP800-30 文件對弱點 (vulnerability) 的定義可簡述為：系統安全程序、設計、裝置、或內部控制裡的一個瑕疵或缺點，若被使用 (含無意的啟動或有意的利用)，會造成安全性的破壞或系統安全政策的違背。 • 就像身體衰弱的人更容易受病菌感染；駭客攻擊能夠成功大多得利於組織本身的資訊弱點。資訊安全弱點的範圍很廣，例如： • 公司沒有接待員也沒有門禁管制，訪客自由進出，造成實體安全的漏洞。 • 公司員工的進用沒有簽保密協定，且工作角色從不調動，形成管理死角。 • 網路商店的線上付款系統沒有妥善地檢查交易完整性，讓有心人士有機會偽造交易紀錄。 • 公司的網站伺服器許久沒有做補丁更新。 • 公司的個人電腦沒有管制允許使用的軟體，員工恣意下載軟體卻又無法分辨木馬程式。

識別資訊威脅 • NIST 的 SP800-30 文件對威脅 (threat) 的定義可簡述為：一個威脅來源有機會成功地運用 (無意的啟動或有意的利用) 特定的弱點。 • 如前頁所述，威脅與弱點互相效力才會出現資訊安全風險。下表是一些威脅與弱點之間的關係：

威脅來源的種類

分析衝擊 • 一些衝擊可以做量化的評估，例如金錢的損失、修復系統的成本、或是在威脅發生之後解決問題所需要付出的財力與時間等。 • 另一些衝擊則無法做量化的測量，例如公信力的喪失、公司形像損傷等。NIST 的 SP800-30 文件以定性的方式將它們描述為高、中、及低度的衝擊。

決定可能性 • 我們可以用「可能性評分 (likelihood rating)」來表現一個潛在的弱點被威脅所運用的機率，以下因素決定這項評分： • 威脅來源的動機與能力 • 弱點的特性 • 安全防禦措施是否存在並有效 • NIST 的 SP800-30 文件將它分為三個評分：高、中、低。

風險分析的種類 • 風險分析所使用的方法可被分為「定量法 (quantitative)」與「定性法 (qualitative)」兩種。 • 定量風險分析法最基本的假設就是：風險可以用金錢衡量。定量風險分析將資訊資產以及衝擊所造成的損失完全以金錢來計算；當它乘上可以量化的意外發生機率後，所得的風險值也就是以金錢為單位。 • 完全的定量風險分析很難做到，主要是資訊資產及衝擊損失很難完全以金錢為單位來評估。 • 定性風險分析則不為這些成分指定金錢數值，而是使用高、低、強、弱之類的權重排序 (weighted ranking) 作表達與計算。 • 風險分析可以參雜地使用定性與定量法，得到更清楚的全貌。

定量風險分析 • 定量風險分析要為一些風險的成份指定客觀的金錢價值，且給予頻率、機率、效果等經驗或測量數字，使風險評鑑以數學方法進行。 • 定量風險分析的優點之一是客觀。執行風險評鑑的人對「價值」有不同的成見，若兩個人對同一標的物做定性分析，得到的結果可能差異很大。定量法有比較客觀的標準。 • 定量風險分析的另一個優點是比較精準、有依據。 • 定量風險分析的缺點是花費時間與公司資源。 • 定量風險分析分為三個步驟： • 估算潛在損失 • 進行威脅分析 • 計算全年的損失期望值

定量風險分析 – 第一步驟 • 名詞定義： • 資產價值 (asset value)：計算資產的價值，以金錢表示。 • 暴露因子 (exposure factor)：當威脅成功的攻擊該資產時，該資產所損失的價值，以資產價值的百分比表示。 • 單一損失期望值 (single loss expectancy, SLE)：一次成功的威脅所造成的資產損失。亦即：SLE=(資產價值) X (暴露因子) • 定量風險分析範例： • 筆記型電腦的資產價值如下：a. 折舊後的硬體價值 (5 萬元)，b. 折舊後的軟體價值 (4 萬元)，c. 所儲存資料的價值 (2 萬元)，d. 客戶資料的商譽價值 (10 萬元)，e. 若失去這台電腦對營運流程造成的損失 (5 萬元)。 • 若電腦遭竊，則這五種價值成份的暴露因子為：a. 40%(已買保險), b. 0%(軟體供應商可重新授權), c. 0% (已備份), d. 100%, e. 100%。SLE為17萬元。

定量風險分析 – 第二步驟 • 名詞定義： • 全年發生率 (annual rate of occurrence, ARO)：在一年的時間內，某種威脅成功地對某種資產造成衝擊的次數。 • 定量風險分析的第二個步驟是進行威脅分析，也就是估算各種威脅的全年發生率。 • 全年發生率很難有正確的算法，只能靠有經驗的人從組織記錄中去統計。例如某公司的記錄顯示，過去三年員工筆記型電腦遭竊的次數為六次；這家公司筆記型電腦遭竊的全年發生率就可以被設定為 2。 • 全年發生率是風險管理所亟欲降低的目標。我們也可以設法降低前述的單一損失期望值 (SLE)，但沒有降低 ARO 這麼直接有效。例如我們可以提高保險額度，讓每一次筆記型電腦遭竊的損失降低；但不如透過宣導及教育訓練，讓筆記型電腦遭竊的全年發生率由兩次降為一次。

定量風險分析 – 第三步驟 • 名詞定義： • 全年損失期望值 (annual loss expectancy, ALE)：在一年的時間內，成功的威脅所造成的資產損失。亦即：ALE=SLEx ARO • 定量風險分析的第三個步驟是計算全年的損失期望值，這個數字是指某種威脅成功地對某種資產造成衝擊所產生的損失；若要計算全組織所有資訊風險的 ALE，需要加總各種威脅的 ALE。 • 在第一及第二步驟裡的例子，筆記型電腦的有形及無形資產價值為26萬元，遭竊的單一損失期望值 (SLE) 為17萬元，而遭竊的全年發生率 (ARO) 為兩次，因此該公司「筆記型電腦遭竊」平均一年損失 (ALE)34 萬元！ • 這個損失金額足以讓高階主管及員工重視這個問題。 ALE=SLEx ARO

定性風險分析 (I) • 礙於時間及資源的限制，大部分組織在建置資訊安全管理系統時，都使用定性風險分析法。 • 定性風險分析法的流程簡述如下： • 開始風險評鑑工作前，必須要得到組織高階主管的授權。在過程中，仍應經常向高階主管做說明，以持續得到支持。 • 得到授權後，要組成風險評鑑小組，應有成員來自資訊、法律、人事、稽核等單位。 • 風險評鑑小組要針對各部門進行會談，以識別環境中的弱點、威脅、以及可能的防禦措施。 • 會談完成後，要對收集到的資料進行分析。其中重要的工作是「配對」，包括威脅對弱點；威脅對資產等。決定一種威脅運用一個弱點的可能性如何；如果運用成功了，對組織造成的衝擊如何。後頁續

定性風險分析 (II) • 完成配對與分析後，就可以計算風險了。在定性風險分析中，「發生的可能性」乘以「造成衝擊的強度」就是風險的等級。如下圖所示，一些大與極大的風險就是亟需降低的風險。 • 一旦風險值決定之後，就可以推薦防禦的方法，以其有效的降低、轉移、或避免這個風險。

風險的處置方法 • 當我們評鑑出風險值後，就可以採用適當的處置方法，例如： • 為圖方便機房不上鎖：幾乎確定會出極大的資安事件，應該「避免」。 • 地震震垮機房：衝擊巨大但幾乎不會發生，可以「轉移」這種風險。 • 同仁電腦感染病毒：衝擊中等、機會也中等，應該「降低」這種風險。 • 指尖的靜電破壞鍵盤IC板：機會不高、衝擊也小，可以「接受」。降低避免接受轉移

接受風險 • 有人認為資訊安全就是「接受風險」與「採用防禦手段」之間的選擇。下一頁是 NIST SP800-30 說明的風險處置行動點， • 風險存在的條件是一個系統有威脅來源，而且有可被利用的弱點。風險存在不代表需要採取防禦手段，當攻擊者的獲益小於成本時，或是預估損失在組織可以容忍的範圍內，都可以考慮接受風險。 • 為何家用電腦只需要裝一套防毒軟體，但銀行的電腦卻需要極綿密的安全防禦？因為駭客侵入銀行系統的獲益遠高於侵入家用電腦；因此他們願意投入更高的成本來攻擊銀行。 • 另一方面，如果家用電腦被植入木馬程式，頂多重灌了事；但銀行若遭駭客入侵就絕非組織所能容忍之事，所以會採取更多的防禦手段。 • 接受風險 (risk acceptance) 是「成本」與「損失」間的取捨。每個人或組織都想要最安全的資訊環境，但在成本考量下 (時間、金錢、與不方便)，會選擇接受損失較小的風險 (發生較少且衝擊較小)。

風險處置行動點 威脅來源攻擊弱點存在系統設計 YES YES AND 有弱點嗎？會被運用嗎？ NO NO 無風險無風險風險存在 YES 無法接受的風險 YES 攻擊者的成本<獲益？預估損失 >容忍範圍？ NO NO 接受風險接受風險本圖參考 NIST SP800-30

轉移風險 • 轉移風險 (risk transfer) 是將風險轉給另一個組織，例如保險公司。能以保險方式轉移的風險通常具有以下特性： • 大量的組織具有類似的風險 (例如火災)，因此保險公司可將自身的風險分散到大批客戶的保費中。 • 只有「意外」需要保險，因此受保風險應該發生機率低且無人為控制。 • 通常損失巨大的風險才需要考慮以契約方式轉移。 • 轉移風險並沒有消除弱點或者降低威脅的成功率，只是一種緩和巨大衝擊的方法。除了保險之外，還有以下方法可供參考： • 分散風險：在系統中儘量避免單點失敗 (single point of failure) 的可能性。 • 兩面下注 (hedging)：將投資避險的手法用於資訊安全。例如讓最重要的應用分別執行在 Windows 和 Unix 系統並互成備援，同時遭攻擊的機率不高。 • 資訊外包 (outsourcing)：讓專業公司幫組織做資訊營運可能是個好選擇，外部虛擬主機服務可能比缺乏專業人員的組織內更安全。

避免風險 • 避免風險 (risk avoidance) 可以解決所有的風險問題 (例如不搭飛機就沒有飛安風險)；但避免風險也代表放棄這個風險所伴隨的利益，如方便性、節省時間、或商機與利潤等。 • 在以下的情況，個人或組織可能會選擇避免風險： • 衝擊會超過組織所能承受時：例如第12頁所述的高等級衝擊可能會「嚴重地違背、傷害或阻礙一個組織的使命、聲譽、或利益」或「可能造成人員的死亡或嚴重受傷」，這種風險應該避免。 • 風險的利益低於潛在損失時：例如在程式裡保留一個維護用的後門可以方便未來修改，但若被駭客發現則損失更大；這種風險也應考慮避免。 • 保險費用太高時：保險的前提是損失很大但機率很低；因此可以用經常性的低廉保費來減緩一次性的巨大損失。但有些風險損失大而且機率高，就不屬於適合保險的範圍，而應選擇避免風險。

降低風險 • 雖然接受、轉移、與避免風險都是處置某些風險的有效方法，但是資訊安全管理的重心在降低風險 (risk reduction)。 • 降低風險是選擇並建置適當的安全防禦措施以減少損失；它可以從三方面著手： • 縮小衝擊：藉由偵測、預防等措施來縮小衝擊、降低風險。例如我們很難控制火災不發生，但若有適當的滅火設備並做好防火宣導，就能在火災發生時減少損失。 • 彌補弱點：找到個別的弱點或缺陷並設計矯正措施，可以有效的降低風險。假如發現許多員工使用太弱的通關密碼，我們可以修改登入軟體，要求這些員工重設密碼並測試它們的強度。 • 降低威脅的成功率：透過全面的安全管理計畫可以封閉入侵管道，降低威脅的成功率。防禦必須全面，有組織花大錢做網路防禦，卻疏於員工的資訊安全教育；若駭客轉而運用社交工程，整體威脅成功率未必降低。

建立風險管理計畫 • 對於每一個風險都要有處置的行動，如果決定採取「降低風險」，就要有對應的防禦措施。「風險管理計畫 (risk management plan)」讓組織依循一定的流程與防禦措施持續地降低風險。 • 「資訊安全管理系統 (ISMS)」也是一種風險管理計畫，它從風險評鑑開始，再針對分析的結果做管理計畫。ISMS 提供133種控制項目 (防禦措施)，組織挑選適合者，並將它們寫成「適用性聲明書 (statement of applicability, SoA)」做為推動資訊安全管理的腳本。 • 接著依計畫執行緩和風險的行動：為決定轉移的風險買保險，避免不影響組織目標的風險，降低主要風險，並接受其它較不重要的風險。 • 最後，要持續的檢討與評估風險管理計畫。 • 評估先前選擇的控制項目是否仍然適用且有效。 • 評估風險值是否有改變，做為更新風險管理計畫的依據。

識別殘餘風險 • 殘餘風險 (residual risk) 是在經過風險管理程序，各種防禦措施都被執行之後還殘留下來的風險。它也包括所有一開始沒有被識別的風險，與被識別卻沒被指定處置方法的風險。 • 組織的管理階層和決策者應清楚瞭解殘餘風險；因此必須將它們寫入文件，並經常檢討。部分殘餘風險可以在下階段的風險管理中處置。縮小衝擊風險管理中的各項防禦措施殘餘風險彌補弱點降低威脅的成功率

ISMS / ISO 27001的要求 安全政策遵循性資訊安全的組織營運持續管理 • 風險評鑑 • 四階文件 • 內部稽核 • 管理審查 • 教育訓練資產管理人力資源安全資訊安全事故管理資訊系統獲取、開發及維護實體與環境安全通訊與作業管理存取控制

戴明循環 Plan：規劃階段 Do：執行階段 Act：行動階段 Check：檢查階段 1、風險評鑑：建立表單並調查資訊資產 2、四階文件：收集現有程序文件並參考相關程序文件樣本 3、內部稽核：選擇內部稽核人員與撰寫稽核計劃 4、管理審查：資訊安全組織確定 5、教育訓練：資訊安全宣導 1、風險評鑑：建立資產清冊並實施風險評鑑作業 2、四階文件：修訂並確認程序文件後，實施資訊安全管理制度 3、內部稽核：依據查核表執行內部稽核作業 4、管理審查：發佈資安政策，並依據風險評鑑報告決定可接受風險 5、教育訓練：ISMS 實務訓練 P 1、風險評鑑：風險處理計劃執行 2、四階文件：依據需求檢討與修正四階文件 3、內部稽核：追蹤矯正預防措施 4、管理審查：追蹤管理審查會議討論之各項決議之執行 5、教育訓練：資訊安全進階課程 D A 1、風險評鑑：風險處理計畫評估 2、四階文件：確認並列管程序文件 3、內部稽核：發出內部稽核不符合通知並調查根因 4、管理審查：通過四階文件並討論內部稽核發現 5、教育訓練：業務持續管理研討 C

ISO 四階文件 • 第一階是最高的指導文件，在 ISMS 為「安全手冊」，內容包括資訊安全政策與適用性聲明等。 • 第二階文件是資訊安全的「管理辦法」，將 ISMS 的主要架構文件化。 • 第三階是「作業程序」文件，規定標準作業細節。像是備份作業管理程序、門禁安全作業程序等。 • 第四階文件是「紀錄表單」如辦公室安全檢查表與資訊設備攜出表。

ISMS四階文件範例

ISO 27001資訊安全管理系統 以下各頁為 ISO 27001 之條文摘要，中文翻譯參考「中華民國國家標準」之 CNS 27001文件，由經濟部標準檢驗局公布於95年6月16日。

建立與管理 ISMS – 4.2 (I) • 組織應該在它的業務與所面臨的風險中，規畫 ISMS、執行ISMS、監視與審查 ISMS、並採取行動維持與改進 ISMS。推動文件化的 ISMS 所採用之過程以右圖的 PDCA 模型為基礎。 • 應執行下列事項建立 ISMS： • 界定ISMS之範圍及諸邊界。 • 界定 ISMS 政策。 • 界定組織的風險評鑑作法。 • 識別各項風險。 • 分析與評估各項風險。 • 識別並評估風險處理的各項做法。 ★標題尾端之數字 (4.2) 為 ISO27001 的章節編號。後頁續

建立與管理 ISMS – 4.2 (II) • 選擇處理風險的控制目標與措施。 • 管理階層核准殘餘風險。 • 管理階層核准執行 ISMS。 • 擬定適用性聲明書。 • 「適用性聲明書 (statement of applicability, SoA) 」是描述與組織之 ISMS 相關且對其適用之各項控制目標與措施的文件化聲明。 • 執行 ISMS 包括下列事項： • 實作風險處理計畫。 • 實作所選擇的控制措施。 • 界定如何量測控制措施之有效性。 • 實作訓練與認知計畫。 • 管理 ISMS 的運作與資源。 • 監視與審查 ISMS 包括下列事項： • 執行監視與審查程序找出錯誤並量測控制措施之有效性。 • 審查風險評鑑與殘餘風險。 • 施行 ISMS 內部稽核。 • 執行 ISMS 管理階層審查，確定各項改進均已識別。 • 維持與改進 ISMS 包括下列事項： • 實作所識別之 ISMS 各項改進。 • 採取適當矯正與預防措施。 • 與利害相關者就各項措施與改進進行溝通。 • 確保各項改進達到預期目標。

文件化的要求 – 4.3 • 文件化要求概述 • 文件化應包括管理階層決策的紀錄；並且能展示從「ISMS 政策」到「風險評鑑結果」到「選擇的控制措施」之間的關係。 • ISMS文件化應包括： • ISMS 政策與 ISMS 範圍。 • 支援 ISMS 的程序及控制措施。 • 風險評鑑方法、報告、處理。 • 量測控制措施有效性之程序。 • ISO27001 所要求之各項紀錄。 • 適用性聲明書 (SoA)。 • 文件與記錄的管制 • ISMS 的文件 (documents) 與記錄 (records) 都應受保護及管制。 • 文件管制重點如下： • 文件發行前應核准其適切性。 • 必要時應審查、更新，並重新核准文件。 • 在使用處應有適切版本之文件。 • 確保文件之分發、儲存、與作廢都受到管制。 • 應防止作廢文件被誤用。

管理階層的承諾 – 5.1 • ISMS 的推動需要組織的人力與財力資源，因此管理階層應藉下列各項支持 ISMS： • 建立一份 ISMS 政策。 • 確保建立 ISMS 各項目標及計畫。 • 建立資訊安全之各種角色與責任 (R&R)。 • 向組織傳達推動 ISMS 的重要性。 • 提供充分資源來推動 ISMS。 • 決定接受風險的準則。 • 確保施行內部 ISMS 稽核 (audits)。 • 施行 ISMS 之管理階層審查 (management review)。

資源管理 – 5.2 • 組織應提供推動 (包括建立、實作、運作、監視、審查、維持及改進) ISMS 所需要的資源。 • 組織應確保各項資訊安全程序被正確使用在組織的營運。 • 組織應識別並因應法律與法規要求，以及契約的安全義務。 • 組織應提供足夠的資源，正確應用所有已實作的控制措施，以維護適當之安全；並應對其有效性進行審查與改進。 • 組織應確保下列事項，使被指定責任的人員可履行工作： • 界定他們履行工作所需要的能力。 • 藉由教育訓練或招聘來滿足上述需求。 • 維持各項教育訓練的紀錄，同時須評估所採措施之有效性。

ISMS 內部稽核 – 6 • 組織應依已規劃的期間實施 ISMS 內部稽核，以判定其 ISMS 之控制與程序是否符合要求。 • 稽核準則、範圍、頻率及方法應被界定。稽核的計畫、施行、報告結果與維持紀錄的責任與要求，應以文件化程序加以界定。 • 稽核人員的選擇與稽核活動應力求公平、客觀。稽核人員不應稽核其本身的工作。 • 受稽核單位的管理階層應確保該單位與稽核人員之合作，使稽核活動能順利進行。 • 相關之稽核技巧與細節將在本章稍後討論。

ISMS 之管理階層審查 – 7 • 管理階層應該至少一年一次審查組織的 ISMS，審查結果應文件化且紀錄應予以維持。 • 審查輸入： • ISMS 稽核結果。 • 相關人員之回饋。 • 可改進 ISMS 之技術、產品或程序。 • 預防與矯正之狀況。 • 未處理之弱點與威脅。 • 有效性測量的結果。 • 先前管理審查之跟催。 • 可能影響ISMS之改變。 • 改進建議。 • 審查輸出： • ISMS 有效性之改進。 • 風險評鑑與風險處理計畫之更新。 • 影響資訊安全之程序與控制措施之必要時的修改。 • 資源需求。 • 控制措施的有效性如何測量之改進。

ISMS 之矯正措施 – 8.2 • 以 PDCA 來區分，內部稽核與管理階層審查屬於檢查 (check) 階段；而矯正措施 (corrective action) 與預防措施 (preventive action) 則屬於行動 (act) 階段。 • 組織應採取矯正措施，以消除與 ISMS 要求不符合之原因，程序如下： • 識別各項不符合事項。 • 判定各項不符合之原因。 • 評估措施之需求，以確保各項不符合事項不會復發。 • 執行矯正措施。 • 紀錄矯正措施的執行結果。 • 審查所採取之矯正措施。

ISMS 之預防措施 – 8.3 • 「矯正措施」是防止不符合 ISMS 要求的狀況再次發生；「預防措施」是消除潛在不符合 ISMS 要求的狀況發生。兩者都需要有文件化的程序來界定各項要求。 • 預防措施程序如下： • 識別潛在的各項不符合事項及其原因。 • 評估措施之需求，以防止不符合事項的發生。 • 執行預防措施。 • 紀錄預防措施的執行結果。 • 審查所採取之預防措施。 • 預防不符合事項之措施通常較矯正措施更具成本效益。

控制目標與控制措施 – 附錄 A • ISO 27001 的附錄A表列了ISMS 的11個領域，39個控制目標，和133個控制措施。 • 這些控制措施源自 BS 7799 (現已演變為 ISO 17799)；ISO 17799 名為「資訊安全管理之作業要點 (Code of Practice for information security management)」針對每一個控制措施提供實作指引與其他資訊。 • 推動 ISMS 時，以文字精準的 ISO 27001 為標準；以說明詳細的 ISO 17799 做為建置控制措施的參考。 • ISO 27001 的附錄A直接取自 ISO 17799 第5至15節，因此11個領域的編號從A.5 起至 A.15。 • 因篇幅限制，以下數頁僅列出附錄A的39個控制目標，我們不細述控制措施，僅略作說明。條文的中文翻譯參考「中華民國國家標準」之 CNS 27001文件，由經濟部標準檢驗局公布於95年6月16日。

安全政策與資訊安全的組織 • A.5 安全政策 • A.5.1 資訊安全政策：依照營運要求及相關法律與法規，提供管理階層對資訊安全之指示與支持。 • 資訊安全政策應由管理階層核准並公布；同時應依規劃之時間或發生重大變更時審查，以確保適用性 (suitability)、充分性 (adequacy) 及有效性 (effectiveness)。 • A.6 資訊安全的組織 • A.6.1 內部組織的控制目標：於組織內管理資訊安全。 • 管理階層應對資訊安全責任做出承諾，並確保組織內部與外部對資訊安全的推動有明確的分工與協調。資訊安全活動應有獨立審查之機制。 • A.6.2 外部團體的控制目標：維持外部團體所存取、處理、管理或其它通信之組織資訊與資訊處理設施的安全。 • 核准外部團體存取之前應識別相關風險，並在第三方協議 (third party agreements)等文件上說明安全需求。

資產管理的控制目標 • A.7 資產管理 • A.7.1 資產責任的控制目標：達成及維持組織資產的適切保護。 • 應識別所有資產並製作重要資產清冊，與資訊處理相關的所有資訊及資產應由組織指定的部門所「擁有 (own)」；其適當之使用方法應予以文件化。 • 例如公司影印室有一台彩色印表機，大家隨意使用且無人負責管理。推動ISMS後該影印機必須列入資訊資產清冊，並劃分由A部門所擁有(管理)，並明文規定使用方法：例如該印表機由A, B, C三個部門共用；列印卻未取走之文件於每日銷毀；在列印機密文件時，列印者需站在印表機旁等。 • A.7.2 資訊分類 (classification) 的控制目標：確保資訊受到適切等級的保護。 • 資訊應該依據其價值與敏感性等因素加以分類，並使用一套適當的資訊標示與處置程序 (information labeling and handling procedures)。 • 機密等級劃分與各種安全模型如Bell-LaPadula等。這項控制目標就是選擇組織所適用的方法來保護資訊。

人力資源安全的控制目標 • A.8 人力資源安全 • A.8.1 聘僱之前的控制目標：確保員工、承包者及第三方使用者了解其責任，並勝任其所被認定的角色，以降低竊盜、詐欺或設施誤用的風險。 • 組織應有清楚的角色與責任 (roles and responsibilities, R&R)；透過背景查證檢核與聘僱契約之簽定，力求參加組織的每個成員都不會造成新的安全問題。 • A.8.2 聘僱期間的控制目標：確保所有員工、承包者及第三方使用者認知資訊安全的威脅與關切事項、其基本責任與強制責任，並有能力在日常工作中支持組織安全政策與降低人為錯誤的風險。 • 達到這項控制目標的手段包括：管理階層的督導、教育訓練以及對違反安全的員工施以適當的懲處。 • A.8.3 聘僱的終止或變更的控制目標：確保員工、承包者及第三方使用者以有條理的方式脫離組織或變更聘僱。 • 應特別注意資產的歸還與存取權限的移除。

實體與環境安全的控制目標 • A.9 實體與環境安全 • A.9.1 安全區域的控制目標：防止組織場所與資訊遭未經授權的實體存取、損害及干擾。 • 應建立實體安全防禦措施，從實體安全周界，如牆、門、警衛等，到進出口管制、室內及設施與工作區或公共區域等都是實體安全控制的範圍。除了防範犯罪行為外，也要預防火災、地震等天災人禍。 • A.9.2 設備安全的控制目標：防止資產的遺失、損害、竊盜或破解，並防止組織活動的中斷。 • 這個控制目標在保護置於實體範圍內的設備與設施，包括電腦、纜線等。藉由對設備的保護，也保護其上之資訊。 • 除了實體保護以防止竊盜及破壞之外，也需要程序性的控制措施來規範內部對設備的使用，例如設備淘汰時清除資料的方法與資訊資產攜出組織的核准辦法等。

通訊與作業管理的控制目標 (I) • A.10 通訊與作業管理 • A.10.1 作業之程序與責任：確保正確並安全地操作資訊處理設施。 • 將程序文件化，其變更應受控制。各項職務要做區隔以降低資產遭濫用之機會。 • A.10.2 第三方服務交付管理：實作與維持適切等級之資訊安全及服務交付，並能與第三方服務交付協議一致。 • A.10.3 系統規劃與驗收：使系統失效的風險最小化。 • 為避免資訊服務中斷，應對系統的未來容量要求預作規畫，例如網路頻寬、記憶體空間與作業系統都應考慮業務擴張後的狀況。此外在系統升級或新系統驗收時，應實行適當的系統測試。 • A.10.4 防範惡意碼與行動碼：保護軟體與資訊的完整性。 • 這一項控制目標是要以制度及工具來防禦木馬程式等惡意軟體的侵入。「行動碼 (mobile code)」是指 Java 與 Active-X 等語言所寫成可從網站直接下載的程式；組織應防止執行未經授權的行動碼。

通訊與作業管理的控制目標 (II) • A.10.5 備份的控制目標：維持資訊及資訊處理設施的完整性與可用性。 • 應依據所議定的備份政策，定期進行資訊與軟體的備份與測試。 • A.10.6 網路安全管理：確保對網路內資訊與支援性基礎建設的保護。 • 網路應加以管理，以保護系統、應用程式及傳輸的資訊。不論內部或委外提供之網路服務的安全與水準應以協議訂定之。 • A.10.7 媒體的處置 (media handling)：防止資產被未經授權的揭露、修改、移除或破壞，以及營運活動的中斷。 • 應有適當程序管理可移除式媒體 (removable media)，包括磁帶、磁碟、USB碟、可移除式硬碟、CD、DVD 以及列印之媒體等。 • 當媒體不再使用時，應以正式程序安全地報廢。 • 應建立資訊的處理及儲存程序，這些資訊包含文件、電腦與網路系統內的資訊、電子郵件與語音信箱等，以保護資訊不被未經授權的揭露或誤用。

通訊與作業管理的控制目標 (III) • A.10.8 資訊交換 (information exchange) 的控制目標：維護組織內以及組織與任何外部個體所交換之資訊與軟體的安全。 • 與外部進行資訊交換應有適當之政策、程序與控制措施，並建立交換協議。應保護含有資訊的電子傳訊，包括實體媒體。 • 與外部資訊交換的範圍很廣，除了電子郵件等電子傳輸外，電話與傳真都應一併考慮，答錄機留言與未取走的傳真文件都可能造成洩密。 • A.10.9 電子商務服務：確保電子商務服務的安全性及其安全的使用。 • 電子商務需要可靠的身分認證 (authentication) 系統，並以 PKI 機制確立服務的機密性、完整性與不可否認性。線上交易的每一方都應使用電子簽章。 • A.10.10 監視 (monitoring) 的控制目標：偵測未經授權的資訊處理活動。 • 使用各種監視系統產生記錄或發出警訊，並由管理人判斷處置。這些監視系統包括入侵偵測系統 (IDS) 與防毒軟體等。相關監視紀錄應被保護不受竄改。

存取控制的控制目標 (I) • A.11 存取控制 (access control) • A.11.1 存取控制的營運要求：控制資訊的存取。 • 應基於存取的營運與安全要求，建立、文件化並審查存取控制政策。 • A.11.2 使用者存取管理：確保經授權使用者對資訊系統的存取，並防止未經授權之存取。 • 應有適當的使用者註冊與註銷註冊程序，使用者ID與通關密碼的產生與分派都應有正式管理流程。管理階層應定時審查使用者存取權限。 • A.11.3 使用者責任的控制目標：防止未經授權的使用者存取資訊與資訊處理設施，以及使其遭受破壞或竊盜。 • 前一個控制目標是管理者的角度，而這一個控制目標則是指使用者自己的責任。 • 使用者應正確地使用通關密碼，並採用桌面淨空與螢幕淨空政策，同時要確保無人看管的設備有適當保護。

存取控制的控制目標 (II) • A.11.4 網路存取控制：防止網路服務遭未經授權的存取。 • 網路存取控制就是讓有授權的使用者才能使用服務，當然需要身分認證機制。除此之外，也要在技術上保護網路服務。 • A.11.5 作業系統存取控制：防止作業系統遭未經授權的存取。 • 作業系統應有身分認證與登入程序，超過時間不動作則應有登出的措施。 • A.11.6 應用系統與資訊存取控制：防止應用系統中的資訊遭未經授權之存取。 • 應根據所界定的存取控制政策，限制使用者對資訊與應用系統之存取。此外敏感性的系統應有隔離的電腦作業環境。 • A.11.7 行動計算與遠距工作的控制目標：確保使用行動計算與遠距工作設施時之資訊安全。 • 行動計算包括筆記型電腦、PDA、智慧卡和行動電話等，行動計算之作業政策應考慮在沒有保護的環境下使用行動計算設備的風險。而遠距工作則應考慮遠端環境與資訊傳送是否安全。

資訊系統獲取、開發及維護 (I) • A.12 資訊系統獲取、開發及維護 • 許多組織不自行開發資訊系統，因此一些A.12的安全目標並不適用，可以在適用性聲明書 (SoA) 中予以剔除。 • A.12.1 資訊系統的安全要求：確保安全是整體資訊系統的一部分。 • 規劃新資訊系統或現有資訊系統升級時，應詳細敘述安全要求與規格。 • A.12.2 應用系統的正確處理：防止應用系統中資訊的錯誤、遺失、未經授權的修改或誤用。 • 輸入與輸出的資料應予確認，以確保該資料正確。應用系統應具備確認查核功能 (validation check)，以偵測有意或無意的資料損壞，例如偵測緩衝區溢位等。 • A.12.3 密碼控制 (cryptographic control) 措施：藉由密碼方式以保護資訊的機密性、鑑別性或完整性。 • 使用加解密作業來保護資訊，並提供適當的金鑰管理。

資訊系統獲取、開發及維護 (II) • A.12.4 系統檔案的安全：確保系統檔案的安全。 • 應備妥各樣程序，以控制作業系統上軟體的安裝。系統的測試資料及系統的原始碼應予保護並控制存取。 • A.12.5 開發與支援過程的安全：維持應用系統軟體與資訊的安全。 • 應經由正式的變更控制程序 (change control procedures) 來變更作業系統、應用系統及套裝軟體。 • 開發過程中應防範資料洩漏的機會；委外的軟體開發應監督與監視。 • A.12.6 技術脆弱性管理：降低因利用已公布的技術脆弱性所導致的風險。 • 應取得使用中資訊系統之技術脆弱性的及時資訊，並評估它對組織的影響；採取適當措施以因應相關的風險。 • 若有修補程式 (補丁)，則評鑑安裝修補程式之風險，安裝前後應測試評估。

Information Security Fundamentals and Practices 資訊安全概論與實務