公司的資安治理該從何開始？(Part 3)
淺談資安評估文件 Security Review is a document.
組織治理常常會談到五種文件類型：步驟 Procedure, 流程 Process, 說明 Guidelines, 標準 Standard, 規範 Policy。 此五種文件的應用請參考底下 Reference 的相關連結，本文不另加贅述。仿間對於這五個文件的等級順序定義不完全一樣，但概念上它就是ㄧ個組織管理辦法與「溝通」的分級，本文的對應以圖一金字塔為主。
Security Review 是一個介於流程(Process)與標準(Standard)類型之間的文件，有些人會定義它為說明文件(Guideline) 但是它除了有說明的功能之外，應有更高的制約力。它的制約力來自於專案管理的檢核點、變更管理系統技術性的監控與審查點，以及董事會資安委員會的授權。
董事會資安委員會與執行長(CEO) 應大方向建立公司的資安願景與需求 (WHY DO WE NEED TO DO THIS)，由資安長轉換成規範型文件(Policy)。由於規範型文件屬於方向性非技術文件，資安長與資安管理團隊以規範型文件為基礎，建構出底層系統的標準文件 (Standard)。底層系統的標準指的像是對 Windows Server/Desktop, Windows AD, Linux OS, Database, Network 等系統的相關使用規範。為了節省開發成本與資源整合，會盡量簡化作業系統與資料庫架構的選擇，例如統一性的使用 Windows 10 作業系統或 Oracle 11g資料庫。有了規範與標準，流程與步驟型文件的制定才有所根據。由於沒有一個環境可以完美的只用ㄧ套標準系統，為了因應變化所以把 Security Review 流程綁入各個檢核點做非標準系統、變更型、及軟體應用層的資安評估 (Ad-hoc Review)。
每一個 Security Review 的文件格式內容大致上可分成四個區塊 (如圖二)。我之前任職的公司將 Security Review 系統用一個簡單的網頁 (HTML)呈現給大家使用，可以經由這個HTML做到版本追蹤、項目追蹤、及項目是否完成狀態的整理。Security Review文件一開始的時候，資安評審長表列出的所有項目都會放在區塊三。隨著專案時程與變化，項目內容會被更改並移動到區塊二或四。當區塊三的項目都完成。最新版本的review的審查狀態會改成Approved。
區塊一：組織, 管理人, 評估人, 評估日期, 報告日期, 專案代號, 軟體系統代號, 軟體系統名稱, 評估代號, 評估範圍
區塊二：項目 — Approved/Agreed/Completed
區塊三：項目 — Pending/To-Do/In-Progress
區塊四：項目 — Mitigated Risks
每ㄧ個 Security Review 的評估項目內容大致上可以分成幾個面向：一、系統與應用的管制 Control，二、稽核與政府法規的需求，三、弱點確認與應對措施。Security Review 的項目新增時，系統會自動帶入一些基本的問題點做提示，但是這些面向是靈活的，因爲每一套系統都不一樣，每一次的變動都有背後的因素與關聯性的資安疑慮。以下會透過上一篇文章的情境及案例應用提供假想的審查項目，由於可假想的案例與評估項目非常的多，這裡我只會列舉一個，如果你有實際案例 Use Case 想知道該如何審查，可以私下找我討論。
情境一提到的新開發軟體，Security Review 通常有一個預設基本項目就是要求有一個帳號登入與認證(authentication and entitlement）由於該公司有一套標準SSO認證系統(完整的API library支援所有的程式語言） 。所以除非有特殊資安原因，通常這是ㄧ個必要的項目。
情境二提到的證卷交易軟體，假如上一版軟體上線時個資法還未上線，但是此次改版時剛好遇到個資保護法的頒布 ( 例如：個資保護法第三條：當事人就其個人資料依本法規定行使之下列權利，不得預先拋棄或以特約 限制之: 一、查詢或請求閱覽。二、請求製給複製本。三、請求補充或更正。四、請求停止蒐集、處理或利用。五、請求刪除。 )資安評審長可以在這個時間點，把個資保護的需求/規格與執行細節說明等，加入此次的 Security Review項目 中，要求專案管理經理必須提供軟體應用介面UI與相關的應用流程Process，來做進一步審查與討論。當此評估項目已經完成時，便可以移到Approved區塊。日後稽核也會依照這些規格去做確認verification的動作。稽核的結果是否符合規定compliant，則由稽核部直接對董事會報告。
情境三提到評估審查SIEM的專案，由於此類系統通常是外部採購而來的產品，資安評審長必須充分了解該系統的應用與建置，才能做出對資安管理有實際意義的技術建議與評估。SIEM 架構上有非常多個設定方式，像是日誌搜集方式、日誌條件與規則應用等，都是需要仔細思量的考慮點。單從「系統與應用的管制Control」的面向，SIEM 網頁管理介面的管制與權限管理會是ㄧ個重要的評估點。若公司有ㄧ個高監管的網段 (Out Of Band)，Security Review規格項目之一就必須考慮要求把SIEM的網頁管理介面實體地隔離於OOB網段。
Security Review 在NIST框架下屬於 IDENTIFY，每個組織可以把自已的需求列入評估項目中，例如 SOX、SAS70、PCI、ISO27001、HIPAA、個資法等。專案管理者也應準備好技術文件、架構圖、應用流程圖等，當資訊越完整時，評估的過程就會越順利。
台灣有強大的資訊安全技術能量與人才，那為什麼資安管理卻做的不理想、或是直到事件發生也根本看不出來做的好不好？！我用了三篇文章告訴你：「治理」對資安的重要性，因為真正的問題是人與流程，能整合人與流程必需靠「溝通」，也就是說白紙黑字寫出來的好文件才是傳遞「知識」的基礎要件。其實某種程度上大家都有在做資安技術的「評估」、「評量」，只是沒有把這件事「正式化」及「標準化」，甚至化為「評審檢核點」與「文件記錄」。資安技術面向做得再好，若少了結構性知識傳遞與溝通 (如圖一 WHY、WHAT、HOW)，重要的資安應用知識也只會停留在公司少數人的腦袋裡，而無法完整全面落實。缺少資安評估文件與記錄的可見度Visibility，對稽核、符規與資安部門的效益評估(Security Metrics 或 KPI)將是一個非常大的問題。資安效益如果無法評估，又如何能制訂資安預算及執行風險評估？
所以資安管理要做的好，第一步就是先把資安的評估審查（Security Review)
「寫下來」
「寫下來」
「寫下來」…….很重要！
公司的資安治理該從何開始？(Part 1) 淺談資安評估流程 Security Review is an organizational decision-making process
公司的資安治理該從何開始？ (Part 2) 淺談資安評估應用情境 Security Review is a verb.
Reference:
https://frsecure.com/blog/differentiating-between-policies-standards-procedures-and-guidelines-2/
文章日期： 2020.08.27
作者 李彥民 Anthony3000 曾多年服務於美國金融機構，專精於資訊安全策略及框架規劃、資安評鑑與架構規劃，協助多家美國金融機構改善資安流程與制度管理。曾任大型投資銀行的資訊安全長(BISO)，擁有資訊管理碩士學位(專修資安管理) 與「電腦駭客鑑識調查員」證照 (CHFI)。本文撰寫時，任職於凱信資訊股份有限公司的資訊安全顧問經理。
Disclaimer: 本文圖片及內容由 Anthony3000 彙集製作，如需轉貼或改作我的文章與圖片：1. 請在圖片上與文章內註明並引用作者與網頁的出處連結。2. 歡迎您在尊重智慧財產權的前提下分享或轉貼我的文章與圖片，若有其他商業用途請先徵求本人的審查與同意。3. 歡迎下載提供的範例檔案或軟體，本網站作者不保證內容的完整性或適合在所有場合使用。
