第215期 / September 5, 2015

產業觀察

分享到臉書!分享到維特!分享到噗浪!分享到Google+!分享到微博!轉寄友人友善列印

ISO/IEC27001新舊差異分析與實作(下)

作者/林信忠

[發表日期:2015/8/20]


前言

本文(上)篇(請參閱第213期(6月號))描述了ISO/IEC27001新舊版條文主要差異、新版引入的觀念與新舊版條文本文部分的逐一對照。基於目前通過ISO/IEC27001的組織以導入舊版ISMS居多,如同裝修房子一樣,針對條文改版可在原管理架構上做修正,不需要整個重新打掉重建,只需加入或補強新的要求,這是一般輔導顧問建議的做法,這種方式也能符合組織的成本效益。

植基於此,本篇重點放在新版新增且實施上較多討論空間的條文要求,說明一些建議性的做法。這些建議性作法不一定要完全照著依循,而是參考性質,組織可依實際環境或要求採取其他做法,茲說明如下。

組織全景(Context of the organization)

條文中本文第4章談到組織全景,包含理解組織內外在環境、理解利害關係人的需求與期望等,主要是管理制度中如何界定範圍(scope)的前置性要求。以往管理制度中最令人詬病的一點就是為認證而認證,許多組織會框一個小範圍或是非核心業務來當作認證範圍,如此方式即使通過認證但對組織資訊安全的幫助不大;稽核員藉由高層人員訪談了解為何會制定這個範圍的大概輪廓,但是沒有明確證據來作佐證。也因舊版條文中沒有明確的要求,但這些卻是真正最基本的。正因如此,新版條文中特別強調了這部分。

實務上要如何執行這個新要求並在認證時能保有相關的證據呢?建議可採SWOT(Strengths,Weakness,Opportunities,Threat或PEST(Political,Economic,Social and Technological analysis)分析來處理。先在一階文件中增列組織全景的文字敘述,設計SWOT或PEST(表格來記載分析內外環境與識別利害關係人的過程,如表一與表二。至於利害關係人的期望是甚麼則可保留與各利害關係人開會之會議記錄、往來公文、組織公告資料來滿足相關證據要求。


《表一》



《表二》


溝通(Communication)

條文中本文7.4節提到溝通,要求組織應確定有關資訊安全管理系統內外部進行溝通的需求,包含:
  • 甚麼需要溝通

  • 甚麼時候溝通

  • 跟誰進行溝通

  • 由誰負責溝通

  • 影響溝通的流程

  • 五個要求。由於溝通行為本來就難具體化,可以在任何時間,任何地點採任何方式進行,故認證時如何提供溝通的證據是個傷腦筋的問題,實務上建議可設計如表三的表格,將前述五項要求納入。該表格中的對象欄位可用組織已識別出來的利害關係人來作歸類,如此較有一貫性與邏輯性。


    《表三》


    資訊安全目標(Information Security Objectives)

    條文中本文6.2提到組織應在相關職能與層級上建立資訊安全目標,且這些目標有著如下的要求:
  • 與資訊安全政策一致

  • 可量測(如可行)

  • 考慮適用的資訊安全要求以及風險評估和風險處理結果

  • 被溝通

  • 適時更新

  • 要做什麼

  • 需要什麼資源

  • 由誰負責

  • 什麼時候完成

  • 如何評估結果

  • 實務上應將目標依資訊安全組織層級化來做細分,由細部目標逐層提高到更上層的目標,最後達到所設定的總安全目標,且目標與政策不能偏離。建議導入資訊安全管理系統時可將條文對資訊安全目標的要求納入一或二階文件中,設計出一張類似表四的表格,將上述要求儘可能地納入。


    《表四》


    風險所有人

    舊版條文中的資產所有人在新版已調整為風險所有人。在上篇文章中曾提及舊版的風險評鑑由識別出資訊安全管理系統範圍內的資產開始,繼而鑑別出該資產的價值。由於只有資產所有人方能正確無偏誤的鑑別出價值方得進行後續之威脅與弱點,故資產所有人於舊版條文中扮演著重要的角色。新版風險評鑑不再強調以資產識別為起始,其評鑑風險的方式也不像舊版那麼單一,故有必要調整資產所有人,由風險所有人來承繼其角色,感覺起來新版的作法更切合組織運作上的真正需求。建議可將原資產清冊中屬於資產所有人的部分改為風險所有人。另外要提醒一點的是風險所有人的層級通常較資產所有人為高,比方說人事業務承辦人是人資系統的資產所有人,改成風險所有人後,則以人事業務承辦人的主管擔任人資系統的風險所有人為宜。

    附錄

    新版條文附錄A相較舊版,實作上較值得討論的是A.6.1.5專案(project)管理的資訊安全與A.15 供應商關係。

    一、專案管理的資訊安全

    附錄A.6.1.5專案管理的資訊安全要求無論專案是什麼類型,在專案管理中都應處理資訊安全問題。這些籠統敘述的證據產生不易。實作上建議可於一或二階文件中增加宣示性的文字如下敘述:
  • 不管任何型態的專案,其專案目標需考量資訊安全

  • 專案應於初始階段辨識其資訊安全風險並有相對應的風險處理計畫;其餘各專案階段(規劃、執行、監督與控制、結束)如遭遇資訊安全風險亦應規劃並執行對應的控制措施,表達組織各專案階段將資訊安全納入考量,並將資訊安全管理系統中每個矯正措施視作成專案來實施,而專案管理之資訊安全風險之識別與回應可參考PMBOK 專案風險管理章節說明

    二、供應商關係

    附錄A.15供應商關係包含:
    A.15.1 供應商關係之資訊安全
    A.15.1.1 供應商關係的資訊安全政策
    A.15.1.2 供應商協議中之安全說明
    A.15.1.3 資訊與通信技術的供應鏈
    A.15.2 供應商服務交貨之管理
    A.15.2.1 供應商服務的監視與審查
    A.15.2.2 供應商服務的變更管理
    為了能含括上述供應商安全控制的要求,實作上建議管理體系文件中增加一本二階或三階關於供應商安全管理文件來滿足要求。另外新版附錄A中除專案與供應商的資訊安全控制措施外,為因應行動化裝置的普及而增列A.6.2 行動裝置與遠端工作相關控制要求,同樣作法上可仿效供應商安全控制一般增加一本行動與遠端工作之二階或三階行動裝置與遠端工作安全管理文件。

    結語

    從2005到2013整整八年的時間,全球資安環境已不知變化了多少,ISO/IEC國際組織適時推出了改版的資訊安全標準無吝是場及時雨,使ISO/IEC27001免於受到不合時宜的批評。以新版條文內容來說,個人覺得風險評鑑是門大學問,雖然短期可採取舊版的方式,長期而言,如組織有足夠的資源不妨試試ISO/IEC 31000所提到的作法,或許更切合單位資訊安全運作的需要。(全文畢)

    參考資料

    1.資訊安全管理制度(ISMS)2013轉版訓練課程講義,QA,2014。
    2.ISMS Lead Auditor Transition Course from ISO/IEC 27001:2005 to ISO/IEC 27001:2013 Training Course,BSI,2014。
    3.“ISO/IEC 27001:2013, Information technology-Security techniques-Information Security management system-Requirement”,2013。
    4.“ISO/IEC 27001:2005, Information technology-Security techniques-Information Security management system-Requirement”,2005。
  •