- 等保2.0
-
網絡安全等級保護2.0時代，于2019年12月1日正式開始。
各企業(yè)需透徹了解等保合規(guī)要求，在等保標準的基礎上構建覆蓋技術和管理的綜合防御體系，提升網絡安全風險治理意識，做好安全防護基礎工作，加強網絡安全防御和檢測能力，爭取順利通過等保2.0的測評“大考”。
和大家聊聊安全管理部分的高風險項。所謂高風險項，指等保測評師可以一票否決的整改項，如果不改，無論你多少分都會被定為不合格。
今年的7月14日相關部門發(fā)布了《網絡安全等級保護測評高風險判定指引》，是依據GB/T 22239-2019《信息安全技術網絡安全等級保護基本要求》有關條款，對測評過程中所發(fā)現(xiàn)的安全性問題進行風險判斷的指引性文件。指引內容包括對應要求、判例內容、適用范圍、補償措施、整改建議等要素。
PS：需要指出的是，本指引無法涵蓋所有高風險案例，測評機構須根據安全問題所實際面臨的風險做出客觀判斷。本指引適用于網絡安全等級保護測評活動、安全檢查等工作。信息系統(tǒng)建設單位亦可參考本指引描述的案例編制系統(tǒng)安全需求。
9、安全管理制度
9.1 管理制度
9.1.1 管理制度建設：
對應要求：應對安全管理活動中的各類管理內容建立安全管理制度。
判例內容：未建立任何與安全管理活動相關的管理制度或相關管理制度無法適用于當前被測系統(tǒng)的，可判定為高風險。
適用范圍：所有系統(tǒng)。
滿足條件（任意條件）：
1、未建立任何與安全管理活動相關的管理制度。
2、相關管理制度無法適用于當前被測系統(tǒng)。
補償措施：無。
整改建議：建議按照等級保護的相關要求，建立包括總體方針、安全策略在內的各類與安全管理活動相關的管理制度。
10、安全管理機構
10.1 崗位設置
10.1.1 網絡安全領導小組建立：
對應要求：應成立指導和管理網絡安全工作的委員會或領導小組，其最高領導由單位主管領導擔任或授權。
判例內容：未成立指導和管理信息安全工作的委員會或領導小組，或其最高領導不是由單位主管領導委任或授權，可判定為高風險。
適用范圍：3級及以上系統(tǒng)。
滿足條件（同時）：
1、3級及以上系統(tǒng)；
2、未成立指導和管理信息安全工作的委員會或領導小組，或領導小組最高領導不是由單位主管領導委任或授權。
補償措施：無。
整改建議：建議成立指導和管理網絡安全工作的委員會或領導小組，其最高領導由單位主管領導擔任或授權。
11、安全建設管理
11.1 產品采購和使用
11.1.1 網絡安全產品采購和使用：
對應要求：應確保網絡安全產品采購和使用符合國家的有關規(guī)定。
判例內容：網絡關鍵設備和網絡安全專用產品的使用違反國家有關規(guī)定，可判定為高風險。
適用范圍：所有系統(tǒng)。
滿足條件：網絡關鍵設備和網絡安全專用產品的使用違反國家有關規(guī)定。
補償措施：無。
整改建議：建議依據國家有關規(guī)定，采購和使用網絡關鍵設備和網絡安全專用產品。（《網絡安全法》第二十三條規(guī)定網絡關鍵設備和網絡安全專用產品應當按照相關國家標準的強制性要求，由具備資格的機構安全認證合格或者安全檢測符合要求后，方可銷售或者提供。國家網信部門會同國務院有關部門制定、公布網絡關鍵設備和網絡安全專用產品目錄，并推動安全認證和安全檢測結果互認，避免重復認證、檢測）。
11.1.2 密碼產品與服務采購和使用：
對應要求：應確保密碼產品與服務的采購和使用符合國家密碼管理主管部門的要求。
判例內容：密碼產品與服務的使用違反國家密碼管理主管部門的要求，可判定為高風險。
適用范圍：所有系統(tǒng)。
滿足條件：密碼產品與服務的使用違反國家密碼管理主管部門的要求。
補償措施：無。
整改建議：建議依據國家密碼管理主管部門的要求，使用密碼產品與服務。（如《商用密碼產品使用管理規(guī)定》等）。
11.2 外包軟件開發(fā)
11.2.1 外包開發(fā)代碼審計：
對應要求：應保證開發(fā)單位提供軟件源代碼，并審查軟件中可能存在的后門和隱蔽信道。
判例內容：對于涉及金融、民生、基礎設施等重要行業(yè)的業(yè)務核心系統(tǒng)由外包公司開發(fā)，上線前未對外包公司開發(fā)的系統(tǒng)進行源代碼審查，外包商也無法提供相關安全檢測證明，可判定為高風險。
適用范圍：涉及金融、民生、基礎設施等重要核心領域的3級及以上系統(tǒng)。
滿足條件（同時）：
1、3級及以上系統(tǒng)；
2、涉及金融、民生、基礎設施等重要行業(yè)的業(yè)務核心系統(tǒng)；
3、被測單位為對外包公司開發(fā)的系統(tǒng)進行源代碼安全審查；
4、外包公司也無法提供第三方安全檢測證明。
補償措施：
1、開發(fā)公司可提供國家認可的第三方機構出具的源代碼安全審查報告/證明，可視為等效措施，判符合。
2、可根據系統(tǒng)的用途以及外包開發(fā)公司的開發(fā)功能的重要性，根據實際情況，酌情提高/減低風險等級。
3、如第三方可提供軟件安全性測試證明（非源碼審核），可視實際情況，酌情減低風險等級。
4、如被測方通過合同等方式與外包開發(fā)公司明確安全責任或采取相關技術手段進行防控的，可視實際情況，酌情降低風險等級。
5、如被測系統(tǒng)建成時間較長，但定期對系統(tǒng)進行安全檢測，當前管理制度中明確規(guī)定外包開發(fā)代碼審計的，可根據實際情況，酌情減低風險等級。
整改建議：建議對外包公司開發(fā)的核心系統(tǒng)進行源代碼審查，檢查是否存在后門和隱蔽信道。如沒有技術手段進行源碼審查的，可聘請第三方專業(yè)機構對相關代碼進行安全檢測。
11.3 測試驗收
11.3.1 上線前安全測試：
對應要求：應進行上線前的安全性測試，并出具安全測試報告，安全測試報告應包含密碼應用安全性測試相關內容。
判例內容：系統(tǒng)上線前未通過安全性測試，或未對相關高風險問題進行安全評估仍舊“帶病”上線的，可判定為高風險。安全檢查內容可以包括但不限于掃描滲透測試、安全功能驗證、源代碼安全審核。
適用范圍：3級及以上系統(tǒng)。
滿足條件（同時）：
1、3級及以上系統(tǒng)；
2、系統(tǒng)上線前未進行任何安全性測試，或未對相關高風險問題進行安全評估仍舊“帶病”上線。
補償措施：
1、如被測系統(tǒng)建成時間較長，定期對系統(tǒng)進行安全檢測，管理制度中相關的上線前安全測試要求，可根據實際情況，酌情減低風險等級。
2、如系統(tǒng)安全性方面是按照技術協(xié)議中的約定在開發(fā)過程中進行控制，并能提供相關控制的證明，可根據實際情況，酌情減低風險等級。
3、可視系統(tǒng)的重要程度，被測單位的技術實力，根據自檢和第三方檢測的情況，酌情提高/減低風險等級。
整改建議：建議在新系統(tǒng)上線前，對系統(tǒng)進行安全性評估，及時修補評估過程中發(fā)現(xiàn)的問題，確保系統(tǒng)不“帶病”上線。
12、安全運維管理
12.1 漏洞和風險管理
12.1.1 安全漏洞和隱患的識別與修補：
對應要求：應采取必要的措施識別安全漏洞和隱患，對發(fā)現(xiàn)的安全漏洞和隱患及時進行修補或評估可能的影響后進行修補。
判例內容：未對發(fā)現(xiàn)的安全漏洞和隱患及時修補，會導致系統(tǒng)存在較大的安全隱患，黑客有可能利用安全漏洞對系統(tǒng)實施惡意攻擊，如果安全漏洞和隱患能夠構成高危風險，可判定為高風險。
適用范圍：3級及以上系統(tǒng)。
滿足條件（同時）：
1、3級及以上系統(tǒng)；
2、通過漏洞掃描，發(fā)現(xiàn)存在可被利用的高風險漏洞；
3、未對相關漏洞進行評估或修補，對系統(tǒng)安全構成重大隱患。
補償措施：如果安全漏洞修補可能會對系統(tǒng)的正常運行造成沖突，應對發(fā)現(xiàn)的安全漏洞和隱患進行評估，分析被利用的可能性，判斷安全風險的等級，在可接受的范圍內進行殘余風險評估，明確風險等級，若無高危風險，可酌情降低風險。
整改建議：建議對發(fā)現(xiàn)的安全漏洞和隱患進行及時修補評估，對必須修補的安全漏洞和隱患進行加固測試，測試無誤后，備份系統(tǒng)數(shù)據，再從生產環(huán)境進行修補，對于剩余安全漏洞和隱患進行殘余風險分析，明確安全風險整改原則。
12.2 網絡和系統(tǒng)安全管理
12.2.1 重要運維操作變更管理：
對應要求：應嚴格控制變更性運維，經過審批后才可改變連接、安裝系統(tǒng)組件或調整配置參數(shù)，操作過程中應保留不可更改的審計日志，操作結束后應同步更新配置信息庫。
判例內容：未對運維過程中改變連接、安裝系統(tǒng)組件或調整配置參數(shù)進行變更審批，且未進行變更性測試，一旦安裝系統(tǒng)組件或調整配置參數(shù)對系統(tǒng)造成影響，有可能導致系統(tǒng)無法正常訪問，出現(xiàn)異常，可判定為高風險。
適用范圍：3級及以上系統(tǒng)。
滿足條件（同時）：
1、3級及以上系統(tǒng)；
2、未建立變更管理制度，對于重大變更性運維過程無審批流程；
3、變更過程未保留相關操作日志及備份措施，出現(xiàn)問題不發(fā)進行恢復還原。
補償措施：無。
整改建議：建議對需要作出變更性運維的動作進行審批，并對變更內容進行測試，在測試無誤后，備份系統(tǒng)數(shù)據和參數(shù)配置，再從生產環(huán)境進行變更，并明確變更流程以及回退方案，變更完成后進行配置信息庫更新。
12.2.2 運維工具的管控：
對應要求：應嚴格控制運維工具的使用，經過審批后才可接入進行操作，操作過程中應保留不可更改的審計日志，操作結束后應刪除工具中的敏感數(shù)據。
判例內容：未對各類運維工具（特別是未商業(yè)化的運維工具）進行有效性檢查，未對運維工具的接入進行嚴格的控制和審批，運維工具中可能存在漏洞或后門，一旦被黑客利用有可能造成數(shù)據泄漏，可判定為高風險。
適用范圍：3級及以上系統(tǒng)。
滿足條件（同時）：
1、3級及以上系統(tǒng)；
2、未對各類運維工具（特別是未商業(yè)化的運維工具）進行有效性檢查，如病毒、漏洞掃描等；對運維工具的接入也未進行嚴格的控制和審批；操作結束后也未要求刪除可能臨時存放的敏感數(shù)據。
補償措施：
1、如使用官方正版商用化工具，或自行開發(fā)的，安全可供的運維工具，可根據實際情況，酌情降低風險等級。
2、如對于運維工具的接入有嚴格的控制措施，且有審計系統(tǒng)對相關運維操作進行審計，可根據實際情況，酌情降低風險等級。
整改建議：如果必須使用運維工具，建議使用商業(yè)化的運維工具，嚴禁運維人員私自下載第三方未商業(yè)化的運維工具。
12.2.3 運維外聯(lián)的管控：
對應要求：應保證所有與外部的連接均得到授權和批準，應定期檢查違反規(guī)定無線上網及其他違反網絡安全策略的行為。
判例內容：制度上服務器及終端與外部連接的授權和批準制度，也未定期對相關違反網絡安全策略的行為進行檢查，存在違規(guī)外聯(lián)的安全隱患，一旦內網服務器或終端違規(guī)外聯(lián)，可能造成涉密信息（商密信息）的泄露，同時增加了感染病毒的可能性，可判定為高風險。
適用范圍：3級及以上系統(tǒng)。
滿足條件（同時）：
1、3級及以上系統(tǒng)；
2、管理制度上無關于外部連接的授權和審批流程，也未定期進行相關的巡檢；
3、無技術手段檢查違規(guī)上網及其他網絡安全策略的行為。
補償措施：在網絡部署了相關的準入控制設備，可有效控制、檢查、阻斷違規(guī)無線上網及其他違反網絡安全策略行為的情況下，如未建立相關制度，未定期進行巡檢，可酌情降低風險等級。
整改建議：建議制度上明確所有與外部連接的授權和批準制度，并定期對相關違反行為進行檢查，可采取終端管理系統(tǒng)實現(xiàn)違規(guī)外聯(lián)和違規(guī)接入，設置合理的安全策略，在出現(xiàn)違規(guī)外聯(lián)和違規(guī)接入時能第一時間進行檢測和阻斷。
12.3 惡意代碼防范管理
12.3.1 外來接入設備惡意代碼檢查：
對應要求：應提高所有用戶的防惡意代碼意識，對外來計算機或存儲設備接入系統(tǒng)前進行惡意代碼檢查等。
判例內容：外來計算機或存儲設備本身可能已被感染病毒或木馬，未對其接入系統(tǒng)前進行惡意代碼檢查，可能導致系統(tǒng)感染病毒或木馬，對信息系統(tǒng)極大的危害，可判定為高風險。
適用范圍：所有系統(tǒng)。
滿足條件（同時）：
1、未在管理制度或安全培訓手冊中明確外來計算機或存儲設備接入安全操作流程；
2、外來計算機或存儲設備接入系統(tǒng)前未進行惡意代碼檢查。
補償措施：無。
整改建議：建議制定外來接入設備檢查制度，對任何外來計算機或存儲設備接入系統(tǒng)前必須經過惡意代碼檢查，再檢查無誤后，經過審批，設備方可接入系統(tǒng)。
12.4 變更管理
12.4.1需求變更管理：
對應要求：應明確變更需求，變更前根據變更需求制定變更方案，變更方案經過評審、審批后方可實施。
判例內容：未明確變更管理流程，未對需要變更的內容進行分析與論證，未制定詳細的變更方案，無法明確變更的需求與必要性；變更的同時也伴隨著可能導致系統(tǒng)無法正常訪問的風險，可判定為高風險。
適用范圍：3級及以上系統(tǒng)。
滿足條件（同時）：
1、3級及以上系統(tǒng)；
2、無變更管理制度，或變更管理制度中無變更管理流程、變更內容分析與論證、變更方案審批流程等相關內容。
補償措施：無。
整改建議：建議系統(tǒng)的任何變更均需要管理流程，必須組織相關人員（業(yè)務部門人員與系統(tǒng)運維人員等）進行分析與論證，在確定必須變更后，制定詳細的變更方案，在經過審批后，先對系統(tǒng)進行備份，然后在實施變更。
12.5 備份與恢復管理
12.5.1 數(shù)據備份策略：
對應要求：應根據數(shù)據的重要性和數(shù)據對系統(tǒng)運行的影響，制定數(shù)據的備份策略和恢復策略、備份程序和恢復程序等。
判例內容：未明確數(shù)據備份策略和數(shù)據恢復策略，以及備份程序和恢復程序，無法實現(xiàn)重要數(shù)據的定期備份與恢復性測試，一旦系統(tǒng)出現(xiàn)故障，需要恢復數(shù)據，存在無數(shù)據可恢復的情況，或者備份的數(shù)據未經過恢復性測試，無法確保備份的數(shù)據可用，可判定為高危風險。此外，如有相關制度，但未實施，視為制度內容未落實，可判定為高風險。
適用范圍：3級及以上系統(tǒng)。
滿足條件（同時）：
1、3級及以上系統(tǒng)；
2、無備份與恢復等相關的安全管理制度，或未按照相關策略落實數(shù)據備份。
補償措施：
1、未建立相關數(shù)據備份制度，但若已實施數(shù)據備份措施，且備份機制符合業(yè)務需要，可酌情降低風險等級。
2、如系統(tǒng)還未正式上線，則可檢查是否制定了相關的管理制度，目前的技術措施（如環(huán)境、存儲等）是否可以滿足制度中規(guī)定的備份恢復策略要求，可根據實際情況判斷風險等級。
整改建議：建議制定備份與恢復相關的制度，明確數(shù)據備份策略和數(shù)據恢復策略，以及備份程序和恢復程序，實現(xiàn)重要數(shù)據的定期備份與恢復性測試，保證備份數(shù)據的高可用性與可恢復性。
12.6 應急預案管理
12.6.1 應急預案制定：
對應要求：應制定重要事件的應急預案，包括應急處理流程、系統(tǒng)恢復流程等內容。
判例內容：未制定重要事件的應急預案，未明確重要事件的應急處理流程、系統(tǒng)恢復流程等內容，一旦出現(xiàn)應急事件，無法合理有序的進行應急事件處置過程，造成應急響應時間增長，導致系統(tǒng)不能在最短的事件內進行恢復，可判定為高風險。
適用范圍：所有系統(tǒng)。
滿足條件：未制定重要事件的應急預案。
補償措施：如制定了應急預演，但內容不全，可根據實際情況，酌情降低風險等級。
整改建議：建議制定重要事件的應急預案，明確重要事件的應急處理流程、系統(tǒng)恢復流程等內容，并對應急預案進行演練。
12.6.2 應急預案培訓演練：
對應要求：應定期對系統(tǒng)相關的人員進行應急預案培訓，并進行應急預案的演練。
判例內容：未定期對相關人員進行應急預案培訓，未根據不同的應急預案進行應急演練，無法提供應急預案培訓和演練記錄，可判定為高風險。
適用范圍：3級及以上系統(tǒng)。
滿足條件：
1、3級及以上系統(tǒng)；
2、未定期對系統(tǒng)相關的人員進行應急預案培訓；
3、未進行過應急預案的演練。
補償措施：如系統(tǒng)還未正式上線，可根據培訓演練制度及相關培訓計劃，根據實際情況判斷風險等級。
整改建議：建議定期對相關人員進行應急預案培訓與演練，并保留應急預案培訓和演練記錄，使參與應急的人員熟練掌握應急的整個過程。
圖片來自e安教育文章，版權歸原作者
“三分技術,七分管理”一直是網絡安全領域的至理名言。等級保護2.0標準中，以三級要求為例，技術部分要求共計84項，管理部分要求共計127項（占比達60%），所以安全管理一定要重視起來?。?！