ISO27001:2013信息安全控制實用守則之操作安全
發布時間：2018-11-07 瀏覽次數：2090
12 操作安全
12.1 操作程序和職責
目標：確保正確、安全的信息處理設施運行。
12.1.1 文件化的操作程序（原 10.1.1）
控制措施
運行程序應形成文件、并對所有需要的用戶。
實施指南
應為與信息處理和通信設施相關的操作活動準備形成文件的程序，例如計算機啟動和關機程序、備份、設備維護、介質處理、計算機機房、郵件處置管理和安全設備等。
運行程序應詳述操作指南，包括：
a） 系統的安裝和配置；
b） 自動和手動加工和處理信息；
c） 備份（見 12.3）；
d） 規劃要求，包括與其他系統的相互關系、最早工作開始時間和最后工作完成時間；
e） 在工作執行期間處理錯誤或其它的異常條件的操作指南，包括對系統工具的使用限制（見 9.4.4）；
f） 支持和升級聯系，包括出現非預期操作或技術難題時的外部支持聯系；
g） 特定輸出及介質處理的指作指南，諸如特殊文具的使用或保密輸出的管理，包括任務失敗時輸出的安全處置程序（見 8.3 和 11.2.7）；
h） 系統失敗事件使用的系統重啟和恢復程序；
i） 審計跟蹤和系統日志信息的管理（見 12.4）；
j） 監視程序。
操作程序和系統活動的文檔化程序應作為正式的文件處理，其變更由管理者授權。技術上可行時，信息系統應使用相同的程序、工具和工具軟件進行一貫的管理。
12.1.2 變更管理（原 10.1.2）
控制措施
對影響信息安全的組織、業務流程、信息處理設施和系統的變更應加以控制。
實施指南
特別的，下列條款應予以考慮。
a）重大變更的識別和記錄；
b）變更的策劃和測試；
c）對這種變更的潛在影響的評估，包括信息安全影響；
d）對建議變更的正式批準程序；
e）驗證信息安全要求已被滿足；
f） 向所有有關人員傳達變更細節；
g）回退程序，包括從不成功變更和未預料事件中中止和恢復的程序與職責；
h）緊急變更處理的規定使需要恢復事件的變更能快速且在受控下完成。
正式的管理職責和程序應是適當的，以確保所有的變更的的控制。當發生變更時，包含所有相關信息的審計日志要予以保留。
其它信息
對信息處理設施和系統的變更缺乏控制是系統或安全故障的常見原因。對運行環境的變更，特別是當系統從開發階段向運行階段轉移時，可能影響應用程序的可靠性。（見14.2.2）。
12.1.3
容量管理（原 10.3.1）
控制措施
資源的使用應加以監視、調整，并應作出對于未來容量要求的預測，以確保擁有所需的系統性能。
實施指南
關注有關系統的業務臨界狀態，應識別容量要求。應使用系統調整和監視確保必需提高的系統可用性和效率。應有檢測控制措施以及時地指示問題。未來容量要求的預測應考慮新業務和系統的要求以及組織信息處理容量的當前和預期的趨勢。需要特別關注長訂貨交貨周期或高成本相關的所有資源；因此管理者應監視關鍵系統資源的使用。他們應識別出使用的趨勢，特別是有關業務應用或信息系統管理工具。管理者應使用這些信息來識別和避免潛在的瓶頸及對關鍵員工的依賴，他們可能引起對系統安全或服務的威脅，并策劃適當的行動。
提供足夠的容量可以由增加容量或降低需求來獲得。管理容量需求的例子包括：
a) 廢棄數據的刪除（磁盤空間）；
b) 應用、系統、數據庫或環境的退役；
c) 優化批處理和進度；
d) 優化應用邏輯或數據庫隊列；
e) 拒絕或限制渴求資源的帶寬，如果這些不是關鍵業務（如，視頻流）。應考慮關鍵任務系統的文檔化的容量管理計劃。
其它信息
這個控制措施也處理人力資源、辦公室和設備的容量，
12.1.4 開發、測試和運行環境分離（原 10.1.4）
控制措施
開發、測試和運行環境應被分離，以減少未授權訪問或對運行環境變更的風險。
實施指南
為防止操作的問題，運行、測試和開發環境之間的的分離級別應被識別并實施是必須的。
下列條款應加以考慮：
a) 軟件從開發轉移到運行狀態的規則應被定義并形成文件；
b) 開發和運行應運行在不同的系統或計算機處理器上，且在不同的域或目錄內；
c) 運行系統和應用的變更應在應用到運行系統之前，在測試或升級環境中進行測試；
d) 除特殊例外情況，測試不應在運行系統上完成；
e) 編譯器、編輯器、其他開發工具或系統工具如果沒有要求，不應從運行系統中訪問到；
f) 用戶應在運行和測試系統中使用不同的用戶檔案文件，菜單要顯示合適的標識消息以減少出錯的風險；
g) 敏感數據不應拷貝到測試系統環境中，除非為測試環境提供等效的控制措施（見14.3）。
其它信息
開發和測試活動可能引起嚴重的問題，例如，文件或系統環境的不需要的修改或者系統故障。有必要保持一種已知的和穩定的環境，來執行有意義的測試并防止不適當的開發者訪問到運行環境。若開發和測試人員訪問運行系統及其信息，那么他們可能會引入未授權和未測試的代碼或改變運行數據。在某些系統中，這種能力可能被誤用于實施欺詐，或引入未測試的或惡意代碼，從而導致嚴重的運行問題。開發者和測試者還造成對運行信息保密性的威脅。如果開發和測試活動共享相同的計算環境，那么可能引起非故意的軟件和信息的變更。因此，為了減少意外變更或未授權訪問運行軟件和業務數據的風險，分離開發、測試和運行環境是有必要的（見 14.3 的測試數據保護）。
12.2 惡意軟件防護
目標：確保信息和信息處理設施不受惡意軟件侵害。
12.2.1 控制惡意軟件（原 10.4.1）
控制措施
與適當的用戶意識相結合，實施檢測、預防和恢復控制措施來防范惡意軟件。
實施指南
防范惡意代碼要基于惡意代碼監測、修復軟件、信息安全意識、適當的系統訪問和變更管理控制。下列指南要加以考慮：
a）建立禁止使用未授權軟件的正式策略（見 12.6.2 和 14.2）；
b）實施控制措施預防和檢測未授權軟件的使用（如，應用程序白名單）；
c）實施控制措施預防和檢測已知或可疑惡意代碼網絡的使用（如，黑名單）；
d）建立防范風險的正式策略，該風險與來自或經由外部網絡或在其他介質上獲得的文件和軟件相關，此策略指示應采取什么保護措施；
e）減少可能被惡意代碼利用的脆弱性，如，通過技術脆弱性管理（見 12.6）；
f） 對支持關鍵業務過程的系統中的軟件和數據內容進行定期評審。應正式審查存在的任何未批準的文件或未授權的修改；
g）安裝和定期更新惡意代碼檢測和修復軟件來掃描計算機和介質，以作為預防控制或作為例行程序的基礎；執行的掃描應包括：
1）惡意代碼使用前，掃描從網絡上接收到的任何文件或通過任何存儲介質的格式；
2）惡意代碼使用前，掃描電子郵件附件和下載內容；該掃描應被執行在不同地方，如，在電子郵件服務器、臺式計算機和進入組織的網絡時；
3）針對惡意代碼，掃描 web 頁面；
h）定義程序和職責，以處理在系統上防護惡意代碼、對他們使用的培訓、惡意代碼攻擊報告和恢復；
i） 制定適當的從惡意代碼攻擊中恢復的業務連續性計劃，包括所有必要數據和軟件備份以及恢復安排（見 12.3）；
j） 實施程序定期收集信息，如，訂閱郵件列表或檢查提供新惡意代碼信息的 web 站點；
k）實施檢驗與惡意代碼相關信息的程序，并確保警告公告是準確和翔實的；管理者應確保使用合格的來源，如，聲譽好的期刊、可靠的 Internet 網站或防范惡意代碼軟件的供應商，被用來區分虛假的和真實的；要讓所有用戶了解欺騙問題，以及在收到它們時要做什么。
l） 孤立的環境，可能導致災難性的影響。
其它信息
在信息處理環境中使用來自不同供應商和技術的防范惡意代碼的兩個或多個軟件產品，能改進惡意代碼防護的有效性。應注意防止在實施維護和緊急程序期間引入惡意代碼，這將避開正常的惡意代碼防護的控制措施。
某種情況下，惡意代碼防護可能導致運行中的干擾。
惡意代碼檢測和修復軟件的使用獨立的作為一個惡意代碼控制措施，通常是不勝任的，一般需要伴有預防惡意代碼介紹的運行程序。
12.3 備份
目標：防止數據丟失。
12.3.1 信息備份（原 10.5.1）
控制措施
根據既定的備份策略備份信息、軟件和系統映象的拷貝，并定期測試。
實施指南
應建立備份策略來定義組織對信息、軟件和系統備份的要求。備份策略應定義保留和保護要求。應提供足夠的備份設施，以確保所有基本信息和軟件能在災難或介質失效后進行恢復。當設計備份計劃時，下列條款應加以考慮：
a） 精確的和完整的備份拷貝的記錄和文檔化恢復程序應被產生；
b） 備份的程度（如，全備份或差異備份）和頻率應考慮組織的業務要求、涉及信息的安全要求和組織連續運行信息的臨界狀態；
c） 備份應被存儲在遠端場所，這個場所應保持足夠的距離以避免因主場所發生災難而對備份造成的任何損害；
d） 應給予備份信息一個與主辦公場所應用標準相一致的適當的物理和環境保護等級（見 11）;
e） 必要時，定期地測試備份介質，確保當需要應急使用時可以依靠這些備份介質；這應與恢復程序結合并檢查對恢復所需要的時間。測試恢復備份數據的能力應被執行，映射到專用的測試介質，不是重寫原始介質，避免備份或恢復過程失敗而導致不可修復的數據損壞或丟失；
f） 在保密性十分重要的情況下，備份應通過加密方法進行保護。
運行程序應監視備份的執行和預定備份的故障處理，以確保備份根據備份策略來完成。各個系統和服務的備份安排應定期測試，以確保他們滿足業務連續性計劃的要求。對于關鍵系統和服務，備份安排覆蓋在發生災難時恢復整個系統所必需的所有系統信息、應用和數據?；緲I務信息的保存期應被確定，考慮對永久保存的存檔拷貝的任何要求。
12.4 日志和監控
目標：記錄事態并生成證據。
12.4.1 事態日志（原 10.10.1）
控制措施
事態日志記錄用戶活動、例外、故障和信息安全事態，應被產生、保持和定期評審。
實施指南
當相關聯的時候，事態日志應包括：
a） 用戶 ID；
b） 系統活動；
c） 日期、時間和關鍵事態的細節，例如注冊和注銷；
d） 若有可能，設備身份或位置，以及系統標識；
e） 成功的和被拒絕的對系統嘗試訪問的記錄；
f） 成功的和被拒絕的對數據以及其他資源嘗試訪問的記錄；
g） 系統配置的變化；
h） 特權的使用；
i） 系統工具和應用程序的使用；
j） 訪問的文件和訪問類型；
k） 網絡地址和協議；
l） 訪問控制系統引發的報報警；
m） 防護系統的激活和停用，如，防病毒系統和入侵檢測系統；
n） 用戶在應用上執行的交易記錄。
事態日志安置基本的自動監視系統，在系統安全上能產生統一的報告和告警。
其它信息
事態日志可以包含敏感數據和個人可識別的信息。應采取適當的隱私保護措施（見18.1.4）?？赡軙r，系統管理員不允許刪除或停用他們自己活動日志。
12.4.2 日志信息的保護（原 10.10.3）
控制措施
日志設施和日志信息應加以保護，以防止篡改和未授權的訪問。
實施指南
應實施控制措施以防止日志信息被未授權更改和與日志設施有關的操作問題，包括：
a) 更改已記錄的消息類型；
b) 日志文件被編輯或刪除；
c) 超越日志文件介質的存儲容量，導致不能記錄事態的故障或過去記錄事態被覆蓋。一些審計日志可能需要被存檔，以作為記錄保留策略的一部分，或由于收集和保留證據的要求（也見 16.1.7）。
其它信息
系統日志通常包含大量的信息，其中許多與信息安全監視無關。為幫助識別出對安全監視目的有重要意義的事態，應考慮將相應的消息類型自動地拷貝到第二份日志，或使用適合的系統工具或審計工具，執行文件查詢及合理化。需要保護系統日志，因為如果其中的數據被修改或刪除，它們的存在可能產生安全的虛假感覺。實時拷貝系統日志到系統管理員或操作員控制外的系統，可以用來保護日志。
12.4.3 管理員和操作員日志（原 10.10.4）
控制措施
系統管理員和系統操作員活動應被記錄、日志被保護并定期檢查。
實施指南
特權用戶帳號持有者在他們的直接控制下也許能夠操縱信息處理設施上的日志，因此，保護和審查維護日志對特權用戶賦予責任是必要的。
其它信息
對在系統和網絡管理員控制之外進行管理的入侵檢測系統可以用來監視系統和網絡管理活動的符合性。
12.4.4 時鐘同步（原 10.10.6）
控制措施
一個組織或安全域內的所有相關信息處理系統的時鐘應使用一個單一的時鐘源進行同步。
實施指南
時間的表現、同步和精確性的外部和內部的要求應被文件規定。這些要求可能是法律的、監管的、合同要求的、標準符合性的或內部監視要求的。組織內使用的標準參考時間應被定義。組織從外部源獲得參考時間的方法和如何可靠地同步內部時鐘應被記錄在案并被實施。
其它信息
正確設置計算機時鐘對確保審計記錄的準確性是重要的，審計日志可用于調查或作為法律、法規案例的證據。不準確的審計日志可能妨礙調查，并損害這種證據的可信性。鏈接到國家原子鐘無線電廣播時間的時鐘可被使用作為日志系統的主時鐘。網絡時間協議可被使用，保持所有的服務器與主時鐘同步。
12.5 運行軟件的控制
目標：保證操作系統的完整性
12.5.1
操作系統上軟件的安裝（新增）
控制措施
控制在操作系統上軟件安裝的程序應被落實。
實施指南
在操作系統上軟件的變更控制應考慮下列指南：
a) 運行軟件、應用和程序庫的更新僅應由經過訓練的管理員在適當的管理授權下來執行（見 9.4.5）；
b) 操作系統僅保留被批準的執行代碼，沒有開發代碼和編譯程序；
c) 應用和操作系統軟件僅應被執行在廣泛的和成功的測試之后；這個測試應涵蓋可用性、安全性、對其它系統的影響和用戶友好性，并應在獨立的系統上執行（見12.1.4）；它應被確保所有的對應的源代碼庫已被更新；
d) 配置控制系統應被使用以保持所有執行軟件和系統文檔的控制；
e) 變更實施前應安置一個回退策略；
f) 對運行程序庫的所有更新的審計日志應被維護；
g) 應用軟件的先前版本應被保留作為應變措施；
h) 軟件的老版本應被存檔，與所有要求的信息、參數、程序、配置細節和支持軟件作為長久數據以存檔的方式被保留。操作系統中使用的由廠商提供的軟件應以供應商的水平來維護，隨著時間的推移，軟件廠商將停止老版本軟件的支持。組織應用考慮信賴于不被支持的軟件的風險。任何對新版本的升級決定，應考慮版本變更和安全的業務要求，如，新的信息安全功能、數量的引入和影響這個版本的信息安全問題的嚴重性。軟件補丁應被應用，當他們可以幫助來消除或降低信息安全弱點的時候（見 12.6 ）.
物理或邏輯訪問應僅被給到需要時的供應商的支持目的，并得到管理批準。供應商的活動應被監視（見 15.2.1）。信賴于外部提供的軟件和模塊的計算機軟件，應被監視和控制，以避免可能引入安全弱點的非授權變更。
12.6 技術脆弱性管理
目標：防止技術脆弱性的利用。
12.6.1 技術脆弱性的管理（條款不變）
控制措施
應及時獲得信息系統技術脆弱性的信息，評價對這些脆弱性組織的暴露程度，并采取適當的措施來處理相關的風險。
實施指南
當前并完整的資產清單（見 8）是進行有效的技術脆弱性管理的前提。支持技術脆弱性管理所需的特定信息包括軟件廠商、版本號、當前部署的狀態（如，在什么系統上安裝什么軟件），以及組織內負責軟件的人員。
應采取適當的和及時的行動以響應對潛在技術脆弱性的識別。為建立有效的技術脆弱性管理過程應遵循下面的指南：
a) 組織應定義并建立與技術脆弱性管理相關的角色和職責，包括脆弱性監視、脆弱性風險評估、補丁、資產追蹤，和任意需要的協調職任；
b) 識別有關技術脆弱性和維護脆弱性意識的軟件和其它技術的信息資源應被識別，對于軟件和其他技術（基于資產清單，見 8.1.1）；這些信息資源應根據清單的變更或當發現其它新的或有用的資源時進行更新；
c) 應制定時間表對潛在的有關技術脆弱性的通知做出反映；
d) 一旦潛在的技術脆弱性被確定，組織應識別相關的風險并采取措施；這些措施可能包括對脆弱系統的補丁，或者應用其它控制措施；
e) 依據技術脆弱性需要解決的緊急程度，應根據變更管理相關的控制措施（見12.1.2），或者遵照信息安全事態響應程序（見 16.1.5）采取措施；
f) 如果有來自合法源的可用的補丁，則應評估與安裝該補丁相關的風險（由脆弱性引起的風險與安裝補丁帶來的風險應進行比較）；
g) 在安裝補丁之前，應進行測試和評估，以確保它們是有效的，且不會導致不能容忍的負面影響；如果沒有可用的補丁，應考慮其它控制措施，如：
1）關閉與脆弱性有關的服務和能力；
2）選配或增加訪問控制措施，如，在網絡邊界上添加防火墻（見 13.1）；
3）增加監視以檢測真實的攻擊；
4）提高脆弱性意識；
h) 應保持所有執行程序的審計日志；
i) 應定期對技術脆弱性管理過程進行監視和評價，以確保其有效性和效率；
j) 處于高風險中的系統應首先處理；
k) 有效的技術脆弱性管理過程應與事件管理活動結合考慮，脆弱性數據傳達給事件響應功能，事件發生時提供技術脆弱性程序來執行；
l) 定義一個程序來處理，脆弱性已被識別，但沒有合適的對策的情形。在這種情形中，組織應評估與已知脆弱性相關的風險，并規定合適的檢測和糾正行動。
其它信息
技術脆弱性管理可以作為變更管理的一個子功能被評審，并可利用變更管理過程和程序（見 12.1.2 和 14.2.2）。
廠商往往盡早發布補丁要承受重大的壓力。因此，補丁可能不足以解決該問題，并且可能存在負作用。而且，在某些情況下，一旦補丁被應用后，很難被卸載。
如果不能對補丁進行充分的測試，如，由于成本或資源缺乏，那么可以根據其它用戶的報告經驗，考慮推遲打補丁，評價相關的風險。
12.6.2 軟件安裝限制（原 12.4.1）
控制措施
應建立和執行規則來控制由用戶安裝軟件。
實施指南
組織應定義和執行嚴格的策略，用戶可以安裝的軟件類型。最小特權原則應被應用。如果準許某個特權，用戶可以有能力來安全軟件。組織應識別被允許安裝軟件的類型（如，對現有軟件的更新和安全補丁），和禁止安裝的軟件（如，僅由個人使用的軟件和出身于未知和懷疑帶潛在惡意代碼的軟件）。用戶所涉及的角色的特權應被準許。
其它信息
在計算機設備上不受控的軟件安裝可能導致引入脆弱性、產生信息泄漏、丟失完整性或其它信息安全事件，或違反知識產權。
12.7 信息系統審計的考慮
目標：將運行系統上審計活動的影響最小化。
12.7.1 信息系統審計控制（原 15.3.1）
控制措施
涉及對運行系統驗證的審計要求和活動，應謹慎地加以規劃并取得批準，以便最小化業務過程的中斷。
實施指南
應遵守下列指南：
a) 應與合適的管理者商定對系統和數據訪問的審計要求；
b) 技術審計測試的范圍應商定并被控制；
c) 審計測試應限于對軟件和數據的只讀訪問；
d) 非只讀的訪問應只允許隔離的系統文件的拷貝，當審核完成時，應被刪除，或者在審計文件要求下，具有保留這些文件的義務，則要給予適當的保護；
e) 特定的或附加的過程要求應被識別和同意；
f) 可能影響系統可用性的審計測試應在非業務時間段來完成；
g) 所有訪問應被監視和記錄，以產生參考蹤跡。
