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